- Broken API authentication mechanisms, SSO that doesn't work properly. The frequency with which they could simply register accounts and then make themselves some sort of admin by sending ordinary HTTP requests, without ever once needing to confirm with anyone in person, is quite astounding.
- Everything being totally exposed on the internet: frontends, backends, all of it. Apparently IP firewalls are history.
- Stringly typed APIs and protocols in which adding escaped control characters in various places allows bypass of critical comparison logic.
- And a bit of SQL injection. Apparently only worth looking for on old web apps - progress?
It feels like the ad-hoc way user accounts were added to the web platform have led to a universe of different implementations and varying exploits. Still, it'd be good to know what their failure rate was. How many companies did they attack without finding any (serious) problem?
> And a bit of SQL injection. Apparently only worth looking for on old web apps - progress?
Yes, but very minimal and disappointing.
Sure, people got serious about this and today, SQL injection is hard to near-impossible to introduce using modern frameworks and practices. But we got there by learning the wrong lesson.
We've treated SQL injection as its own vulnerability class. We've taught a generation of developers to Not Write SQL Statements By Hand, to Use Prepared Statements or Use ORMs. Libraries and frameworks were changed accordingly. Sanitizing, which evolved to "Web Application Firewalls", was introduced to detect and block SQL injection attempts. We've solved this as a specific case, instead of learning the general principle: never work with structured operations on structured data in their string representation form.
"Stringly typed APIs" you mention are just another form of this, they're the same class of problems as SQL injection. So are XSS attacks. So are ${any other query language} injection attacks. So is your site breaking apart because of a stupid mistake or malformed user input that broke your templating engine. All of them are caused by gluing unstructured strings together and then deserializing the result.
Operations like "interpolate this value in this place of structure/query" aren't string-level operations, they're structure representation level operations (e.g. DOM node replacements). If you do them in their natural representation, injection vulnerabilities cease to exist.
This is something I bang on about a lot in the last few years. So many exploit classes go away entirely if you write an app using standard OOP desktop UI frameworks and tooling. Take a toolkit like Jetpack Compose, JavaFX, WPF and combine it with gRPC or, alternatively, log in directly to the database (as your own user). Now it becomes nigh on impossible to mount injection attacks.
In particular, if your ACL logic is expressed in the database itself (row level security, security-definer views, stored procedures etc), and every user of the system has a database user, then SQL injection goes away entirely by design because you're now designing on the assumption that the user can run arbitrary SQL anyway. If something goes wrong with the containment it's a flaw in the database or your declarative ACLs, and can be patched in one place (+if it's a db bug you can hold the vendor responsible if you license a commercial rdbms).
Now, this type of design can't solve all the problems that cropped up in their explorations, and it adds a few new ones - you have to be careful to configure your database correctly, obviously, and you might become more vulnerable to DoS attacks, although for web apps like dealer consoles DoS is probably not your primary concern. But you will at least have one place to declaratively assert what data everyone should be able to see, and authorization is enforced by centralized logic. Some of the problems found in these websites seem to be caused by devs losing track of what bits of code are meant to enforce security. There are auth tokens everywhere but nothing is being enforced properly. Two tier direct-to-db designs would fix that.
Still, the worst vulns here all seem to be related to creation of new accounts for semi-private systems and the onboarding process for how to assign roles to them. Most auth systems consider account creation and role assignment to be out of scope, which encourages/forces everyone to roll their own account system on top of the web. The results speak for themselves.
(The vim people at least insist. The IDE people just roll their eyes, not understanding what is being talked about and how code could look any different.)
And while you'll have to pry my Emacs from my cold, dead hands, the no #1 thing I wish for is the ability to keep the code in a database (or at least treat it as such, and not look at the raw text files) and expose it through various structured view, allowing editing at higher level of abstraction.
There are benefits to 2D textual representation, not the least of which is that both Emacs and vim let you work with it with efficiency and ergonomics unmatched by any other tool. But it should still be seen as representation, not the ground truth, and exploited to its full potential.
Some trivial examples of what I'm thinking about:
1) Render class content as an org-mode table like:
With this, I can very quickly add, modify, or reorder fields, and the view should either immediately or on "commit" step ensure that I can't possibly get this wrong syntactically. Renames and other changes should, obviously, do appropriate "refactors".
2) Imagine something like 1), but rendering the result of a query "every field of every class in the current module, that is of type Frobalizer<?>". I'd then be able to e.g. rename these fields in bulk using, say, one or two regex-replace calls, and then commit it to execute a mass renaming "refactor".
The benefits of staying with 2D text as a representation form is that vim and Emacs are really that good at navigating and editing it, much better than GUI-based equivalents could ever be. I think it also maps quite nicely to how people think - there's the abstract structure, which you inspect by viewing it in various representation, and when you want to change something, you think in terms of how you'd want the representation to look like after the change - e.g. "I want all those Y and Z to be X and Q instead".
The thing we interact on the surface should stay "text like" of course.
But the tools used should work on the actual data structure (and this should be also what ends up it on disk).
Proper editors (and IDEs) do this partly anyway. Only that things get converted (loosely!) back and forth between the internal representation of the IDE and the text on disk. The compiler than again extracts the rich data form the text, over and over. Pure madness…
If just the LISP machine would have won… Things would likely look much better now. We would work with rich ASTs instead of text blobs I guess.
You should check out JetBrains MPS. It's very similar to what you're asking for. They have what they call a projectional editor, which edits the structure of the program directly and you can thus cast code into different views like tables.
Although all vulnerabilities affect cloud services and/or mobile apps (SaaS and similar areas) looks like this eventually leads to closely interact with the single vehicles. Which raises questions about the recent Cybersecurity UNECE Regulations R155 and R156 that any new vehicles manufacturer must take into account while submitting a new model for approval in Europe and other areas. Those regulations explicitly cover the vehicle itself and not connected cloud services. Should an urgent revision extend coverage?
From R155 4.3.1 "threats regarding back-end servers related to vehicles in the field" covers it? Of course the whole standard is still pretty focused on the on-vehicle side of things, but it certainly touches on it.
Surprised to see these even mentioned on HN. I've read R155 as part of my job and am responsible for implementing it.
The consensus among manufacturers (and auditors) is that R 155 does cover the security of vehicle backend services with its wording and intent. There are of course still active discussions about what exactly constitutes a backend service, e.g. whether a production planning system that provides data to a direct vehicle backend service should also be considered relevant under R155. But in general, this is something that manufacturers in Europe are aware of and are working towards.
This is exactly the reason why I'm trying my best to keep my non-smart vehicle running as well as possible for as long as possible.
I have no idea what exactly will be exposed to the manufacturer's backend, what can be manipulated and hacked on the front-end, and the possible safety repercussions involved with this.
Who's to say some government/corporate espionage results in a manufacturer getting their back-end hacked and having every online vehicle immediately get their brakes applied? Definitely some Black Mirror-esque stuff...
Not to mention the convenient ability to surveil any vehicle and their locations with a busted and easily crackable API - why does it take external hackers with a (thankfully good) sense of morals and ethics to bring these things to companies' attention?
It'll probably take something hitting national/international news before lawmakers or companies take this security seriously.
There have been many, many past instances of automotive security issues hitting national and international news.
The automotive industry has simply been slow to adapt. Manufacturers were almost universally founded in an era when mechanical systems dominated and that's how they want to treat everything. There's been a painful and ongoing learning process for them to realize that software and computerized systems are fundamentally different from the mechanical systems they understand well.
On the inside, doing things securely takes a lot of deliberate and careful work. COTS stuff is rarely designed for high security systems. I've sat in more than one pen test where we found a wireless interface unintentionally added by some dev board that was selected for a completely different purpose. I've also seen cases where the security team/software teams were hired/onboarded after the vehicle design was essentially finalized with little consideration for their requirements.
The automotive industry has simply been slow to adapt.
And so have the legislators and regulators who should have been preventing the automotive industry from selling products where it increasingly seems plausible or even likely that a vulnerability will be found and exploited at scale by someone really trying to do harm and the consequences will be catastrophic.
The danger has been obvious to many who work in tech for a long time and has been publicly demonstrated often enough against enough different types of vehicles that the threat should be like a giant billboard that is repeated every 100m along every road in the world by now. Someone in power needs to realise that even the kind of intense scrutiny and safety culture that we see in for example aviation or some medical fields or nuclear power stations doesn't scratch the surface of what we need for an industry that sells around 100,000,000 new vehicles every year.
The auto industry is infamous for treating the human cost of its failures as a mere financial cost of doing business and operating accordingly. It simply can't be trusted to "adapt". It must be forced through unprecedented levels of oversight, regulation and sanctions for businesses, executives and investors who don't act responsibly.
> Manufacturers were almost universally founded in an era when mechanical systems dominated and that's how they want to treat everything.
That is a huge understatement, as they mostly (majorly?) employ electrical/mechanical engineers who end up writing code for the ECU's. Cloud services are mostly an afterthought in design. In my experience, regulation isn't the main problem.
With inequality on the rise, I would expect hats to start darkening at increased rates.
I've personally sworn off any more responsible disclosures to companies not paying at least $1,000/hr(USD) in rewards or without clearly good intentions. I am not bending and very backwards to find it either. Any shenanigans is instant disclosure and shenanigans exposure.
I'm about to be homeless and know of exploits currently working at 20billion dollar companies. They can't even bother responding to emails...
There's a point where one has to focus on needs. Morality I want, food I need.
Yes, but jail food isn't all that it's cracked up to be and if you are able to get that kind of work done then your choice isn't $1000/hour for undisclosed vulnerabilities or starving, the viable alternative is just to get a job.
With those skills you are 10x as employable as most people that are currently jobless. At least.
Prison food is okay, depends where you go and how you handle yourself. Low security prison is just adult daycare, which is where a hacker will end up. Hacker knowledge is highly appreciated in prison.
I should mention that I don't intend to release or sell anything harmful. I just recently experienced this issue and I came out on the right side(?). I can see someone coming out the other side too, too easily. My intent rather is to stop working for free. I will notice it, note it, eliminate my personal exposure, and ignore it. I would say that puts me somewhere between white and black.
It's not easy (for me) to find employment. My last company was in automotive advertising(bankrupt) and I am aware of quite a few more problems than what you see in this disclosure. Though the listed brands are outside of my knowledge.
This attitude isn't helping anyone, yourself included... but if you leaned into responsible disclosure you might find your way into a job that saves you from homelessness.
I imagine my odds of being an accident in which 25 years of crash safety advancements help are higher than being hacked.
(and for the inevitable flood of "But the A pillars are bigger" comments, if you're safety conscious you can still get cars with reasonably sized A pillars. A few years ago Honda specifically called out smaller, further recessed, A pillars for visibility in the Accord redesign)
I'm fine. But I was almost in two crashes with a very new model car on account of buggy software. And the chances of that are higher than being hacked. Considerably higher.
The best way to avoid crashes is to drive less, which is what I'm also doing and why I expect this car to last the rest of my life (and probably well beyond, the way I'm maintaining it). It's my daily driver because that's what I would be driving if I were to drive on any given day but I'm actually quite surprised to find out that I spent more last year on insurance than on fuel.
Yes, the functionality that tries to keep the vehicle in the lane nearly steered me into a concrete barrier in a construction zone when I rented a vehicle a few years back. Not exactly the kind of stuff I want happening while I'm driving on a highway in a foreign country. Could have ruined the trip, or worse.
In my case a fairly new C-class MB that decided that posts on bridges are in front of the car and not to the side and a large advertising board in a corner was about to be hit. In both of those cases the car turned what was a perfectly safe ride into instant near accident and if not for many years of experience I'm pretty sure the first would have resulted in a major crash. I got rid of the car after the second one.
Automatic emergency braking is probably great if all you do is highway traffic and stop-and-go but it really sucks that you can't disable it and that it isn't able to distinguish between safe and unsafe to a degree that it will turn a safe situation into an unsafe one all by itself. At that point in time a safety feature becomes a risk in itself. Possibly the statistics are still in favor of the solution but I'd rather take my chances.
I’d add that the pollution from older vehicles causes the premature deaths of quite a lot of people and sickness in a whole bunch more. Particularly if it’s burning oil, which a lot of old cars do.
I'll happily bet that mine is in better shape than 80% or so of what rolls of the assembly line. It's better than it was when it was first built. Anyway, it's interesting how 'old' is immediately associated with 'unsafe', whereas the main deciding factor isn't really how old the car is but how well it has been maintained, what price bracket it is in (cheap cars are much less safe than expensive ones) and what make & model. Then there is the driver, experience level, whether they drink and drive and are well rested. Because the best way to survive an accident is to avoid getting into one in the first place. There are obvious outliers on all of these and my personal safety is rather high on my list of things to be careful with.
I tend to drive almost exclusively older cars. Once I had an accident in a 15 year old golf (this was around 2015 so the golf was made in around year 2000). This was basically emergency breaking on wet road at motorway speeds(about 130kph or 80mph)followed by loss of traction, then some sideways sliding finished with head on smashing into a side barrier with enough force that the car ended in the middle of the road (it must have bounced, but I have to admit I can't remember the exact moment, I estimate it was probably still going at last 45kph 30mph when it hit). I was perfectly fine except loosing few seconds of time. I managed to jump out of the car and have enough presence of mind to drag it off to the side of the road before incoming traffic crashed into it(thankfully wheels were fine enough for this). The car was totaled, and I didn't even have a scratch. That's an example of now 20 year + car safety...
A single anecdote is not data. I can fall by slipping on ice dressed in shorts and a tshirt, and walk away fine. But i can also do the same, but dressed in a way more padded and protective winter coat, pants, boots, then fall and twist my ankle. That doesn't say much about relative safety of shorts+tshirt and protective winter gear when it comes to falling on ice.
Back to the topic at hand, are you claiming that all of the safety improvements added to the cars over the past 20 years didn't make a massive positive impact on passenger safety during collisions? Arent't there agencies worldwide that issue safety ratings after performing variety of tests and studies (that are way more rigorous and quantitative than a one-off anecdote), and they show massive safety improvements over time for all cars in general? Or are you trying to claim that those agencies can't be trusted, and that their tests are not valid?
I am not trying to be combative about it. I am just genuinely trying to figure out what point you were trying to make with this anecdote, but all I have right now is pure guesses.
Not the op, but I'll note all of those tests are about what physically happens once you're in crash or specific situation. Many or most don't gauge how or why you got into that situation, or how likely you are to do so in that vehicle. I don't know how "firmware update made care less safe" or "adaptive cruise control disengaged unexpectedly" or (my personal concern) "car UI negatively impacted drivers situational awareness and reaction time" etc would show up in e.g. IIHS rating?
A good 10-20 year old car may have as good crash rating as many modern cars. top or average modern cars may be better than top or average 10 year old cars. Stats are interesting thing. But then there's the average driver assistance vs average UI vs average visibility vs average handling of these cars.
Bottom line, I don't feel less safe but I do feel differently safe, in my old Subaru and new Honda.
> I don't know how "firmware update made care less safe" or "adaptive cruise control disengaged unexpectedly" or (my personal concern) "car UI negatively impacted drivers situational awareness and reaction time" etc would show up in e.g. IIHS rating?
What percentage of crashes can be attributed to that? Let's make it simpler, how many crashes per year as a raw number happen due to those reasons you listed?
Because out of all things I would be worried about when it comes to car safety, this is the one that is least concerning to me. Especially since for most modern cars that have such a thing as "software updates" in the first place, they have the driving subsystem and infotainment subsystem entirely detached (yes, even on Teslas). Very easy to confirm yourself by force rebooting the infotainment center and seeing that the car still drives just fine.
This is false, even more so for most Tesla models. Cars have a distributed E/E architecture where embedded software runs on several computers (called ECUs that range from anywhere between 10 and 100+). Most newer Tesla models are ahead of the curve and have a more centralized (zonal) E/E architecture with very few number of ECUs.
In summary, the infotainment system and the drivetrain definitely speak to each other and unless a secure architecture comes along, I would not discount the possibility of unintended interactions due to bugs. In fact, most famous car hacks start from the infotainment system and make their way into the drivetrain.
1. I am not a car engineer,or anywhere near it, but everything I've ever read about modern cars indicates their infotainment system and engine control unit are at very least on same bus and can and do communicate.
2. I don't have those numbers, in fact point of my post I'd that I don't know how we get those numbers. When I'm a passenger I'm terrified how distracted people can be by poor UI. I wish we had more hard data. Some studies are slowly emerging.
I'm all for forbidding touch screens for driver interaction in vehicles and I'm honestly surprised that this hasn't happened yet. Anything that takes your eyes of the road is a risk. Where I live we're pretty hard on smartphones in the car while driving (and rightly so) and yet we accept touch screens with menus four levels deep for basic stuff.
The point I was trying to make is that from crash safety point of view an upper tier car(for example a well equipped golf) made 20 years ago might be a lot safer than a cheapest modern car(at least here in EU where safety standards in 2000 were pretty good already, I have no idea about other countries). Yes, this is just a single anecdote, but I seriously doubt I would be here to tell it if I was driving let's say a 2014 Fiat Punto or similar.
Why do I compare an old "upper class car" with a modern "lowest tier"? Isn't this unfair? No, because that is usually the choice people have. If they can afford just the cheapest of new cars, there is likely a much better one that is not new available for the same price or a lot cheaper.
This is pretty much on the money. Car safety with respect to the occupants is increasing over time, but it has always also increased over the budget with the time pegged to a certain point. So your 1997 high end car may well be safer than your 2015 budget car.
Case in point: I've restored a Daihatsu Trevis, a small Japanese budget car, and after working on it and bringing it back up to the standard required to pass a salvage title inspection (which is a higher standard than the original one where I live, you have to book an inspection for the vehicle that takes several hours and that will have cross frame measurements and all kinds of assessments to make sure that the vehicle is safe) I decided that this is not a car that is suitable for many kilometers of highway driving. A crash in that car that would be survivable in even the cheapest Golf or Skoda would be lethal in that little car. So I ended up passing it on to people that only drive in the city and got an elderly Golf instead.
And a Golf was definitely not the high end of safety at that time, but it was tons better than the much more modern Trevis.
This somewhat reminds me of my first car. An Eastern German VW Trabant with a two stroke 600cc engine. It was a car I did drive on motorways occasionally as it was my only car (I bought it for $100 when I was 18,the car was 18 years old too at the time).
That car was often a butt of many jokes as people thought its chassis was made off "recycled paper" (in fact it was one of the first composite chassis cars). It was called a plastic-soap-box, but it was so simple to repair one needed a push bike set of tools to fix anything (until once a suspension strut in a rear wheel failed). Then all it took to be able to get back home slowly was to wrap it with some steel wire... Fun little car. Unfortunately it was scrapped against my will when I was abroad (my parents weren't happy I drove it). Today many people consider it a classic and it has quite a following.
The last 25 years have seen some improvements, but nothing nearly as dramatic as the change between the 25 years prior to that. Seatbelts, airbags, crash testing and designing a car for survivability in case of an accident are all things that happened between 1970 and 1990, since then we've seen incremental improvements but for the most part things have not changed all that much. That's also why automobile manufacturers have trouble introducing new models because the older ones are really pretty good. The car I'm driving has gone through 2 upgrades since 1997 (the year it was built) and neither of those is a huge improvement safety wise over the one that I've got. The biggest question mark is probably the longevity of the pyrotechnics and the airbag materials, but for both I've been reassured multiple times by the dealership that they are fine (not something you want to test), and that this goes for any airbags manufactured after 1993 except for one particular notorious bad batch made by Takata, and those fortunately are not in my car.
I wouldn't say a road barrier had any positive effect on the situation. What probably saved the situation is that a 20 year old golf handles way better in a slip than the cheapest of current cars (at least back then in 2015) which was the usual choice when I rented at the time. Would I be doing 80mph in a Fiat Punto in the first place?Probably not. Would 60 mph be enough to loose traction in it? Who knows.
If you extend the time range to 25 years I might agree, but let's say we start at year 2000. I fail to see those "huge strides in vehicle safety". Perhaps what you mean is that certain "upper tier" features made their way into basic equipment. That no doubt has positive impact on an average driver.
However, at least for me, any time I bought/rented an old car it was always a top spec version, so as mentioned. I don't see those huge strides.
>my daily driver is 25 years old this February and it's the last car I'll own.
I've gritted my teeth every time somebody on HN has referred to their computer as their "daily driver", but I will remain silent no more: You, sir, are the daily driver of your automobile, and NOT vice versa.
However, I'll allow that to connect any new auto you purchase to your computer, you might need to download new drivers.
Wouldn't it be cool though to use the same back doors to disable all the telemetry automakers are pouring into our cars though? Well I mean cool until somebody steals the car but all you'd have to do is have your own tracker on it.
I've never actually had one fail in service. My older one (which is actually a few months newer than my "newer" one which I got a couple of years ago) did over 100,000 miles with only fairly minor repairs, and is currently on 270,000 miles.
I'd drive either of them to any spot in the world. I'd carry tools and spares, but I'd still drive them there.
The people that are responsible for writing a law like that want to make encryption illegal to make law enforcement easier, with no thought whatsoever to the obvious everyday security implications of doing so.
There’s no way they would remove remote control functions in cars, regardless of the safety implications for the drivers.
> we get the first terrorist act in history to reach millions of victims,
Depends how you define reach.
I can't buy dynamite without a bunch of onerous license requirements thanks to a variety of 70s "activists". I can't buy a bunch of fertilizer without getting on a list because the FBI doesn't like when people make them crispy. I can't call overseas without the metadata being recorded in perpetuity by the NSA because some terrorists hijacked some planes. So a nation of 300+mil has already been "reached" by plenty of terrorists if you count putting up with not directly violent but inconvenient BS.
>I can't call overseas without the metadata being recorded in perpetuity by the NSA because some terrorists hijacked some planes.
Why would anyone call overseas (i.e., using voice service with a "phone number") in this day and age anyway? Anyone with half a brain knows to use chat apps and their voice-calling (or video-calling) functions to talk to their friends overseas.
Unless you're doing this for work which involves international relations, why would you ever need to call such places outside your own country? I live outside my home country and have never needed to make an international call.
Depends on what you’re doing and where you are. eg working in finance in Europe a /lot/ of your partners are international - and even though there are sometimes options other than PSTN, odds are your company will record conversations regardless of whether it’s on a desk phone or an app.
Again, you keep talking about work. I'm not talking about work, I'm talking about personal use. If companies want to waste money on per-minute international phone charges, that's their problem. Most regular people are smart enough to avoid this stupidity and use a chat app these days.
>I've had to call the embassy for visa/passport issues.
Why on earth would you do this? Your country's embassy is a local phone call, in whatever country you're in. Your embassy isn't in your home country, it's in the country you're now present in (geographically at least, but not legally, but the phone number is still a local number).
Also, this stuff can usually be handled online these days.
That depends massively on the countries concerned. US, UK and the like yes but for many countries even friendly ones the closest diplomatic mission is often in a nearby country, eg for Bangladesh it might be in Delhi, for NZ in Canberra. And by their nature they deal with a lot of things which aren't readily handled online.
Really wonder how long it will take before you can't renew your vehicle registration unless your older vehicle has been "upgraded" to include such a kill switch?
Great finds. I always wondered how "White hat" hackers didn't land themselves in legal trouble while probing and toying around with systems like this. How do you ensure you won't be tracked down and legally charged?
Most of us get private invites by the companies themselves or there are already open public bug bounty programs on HackerOne, Bugcrowd, Intigriti etc for anyone to try to hack them within confined scopes.
There are a lot of money to be made if you're good, so there's the incentive as well.
I don't know about the auto industry but web apps post bug bounties on hackerone.
And Google's bounty program reward hackers who will find bugs in apps with over 100 million installs, or in google's open source apps. And they pay up to $30,000 per bug depending on impact.
$0, as far as I know. For example, Ford has HackerOne programs but only pays bounties for an extremely small set of their applications. Other companies had no program at all, like Ferrari, and we had to message them on LinkedIn.
Looks like another recurring movie where evil/young wizards (car manufacturers) would summon some attractive daemons for their own needs (profit/power) thanks to some new magic spells (IoT tech) without mastering it, leading to unintended consequences (vulnerabilities and bad exploits) that others wiser wizards (security researchers/industry) know for ages.
Not good, but seems to be the IT curse repeating again and again.
The scary thing with any of these disclosures is the thought that state intelligence would be stupid to not spend a lot more resources than these ethical hackers did to discover the same.
- Broken API authentication mechanisms, SSO that doesn't work properly. The frequency with which they could simply register accounts and then make themselves some sort of admin by sending ordinary HTTP requests, without ever once needing to confirm with anyone in person, is quite astounding.
- Everything being totally exposed on the internet: frontends, backends, all of it. Apparently IP firewalls are history.
- Stringly typed APIs and protocols in which adding escaped control characters in various places allows bypass of critical comparison logic.
- And a bit of SQL injection. Apparently only worth looking for on old web apps - progress?
It feels like the ad-hoc way user accounts were added to the web platform have led to a universe of different implementations and varying exploits. Still, it'd be good to know what their failure rate was. How many companies did they attack without finding any (serious) problem?