I agree that both of those shouldn't be punished. I'm not sure how one would properly define the law tho - for ex. an SQL injection could also be "just a query parameter" and the server would haply reply with a 200.
That would make a lot of companies responsible for the data they keep and should be responsible for protecting.
SQL injection can be (and probably is) malicious though, so I suppose it becomes a unclear line for that example. Maybe punishment of both parties would be appropriate but I'm not a lawyer so don't have expertise in law punishments. But I could see this as incentivizing data security. Even if a 0 day is discovered, companies will be less inclined to drag their feet for a patch when one becomes available.
Honestly, I'd want to see strict liability for data breaches, with revealing of personal information included as a type of injury, and not merely something that must be shown to have led to other forms of injury. Right now, the most I can do is reduce the amount of personal information that is collected about me, and I have no ability to ensure that it is stored in a secure manner. Companies that record personal information about me (e.g. Google, Equifax, Facebook, etc) have the ability to improve their security, or to reduce the scope of collected data, but have no incentive to do so. By placing the liability on the same entity as makes the decisions, it creates that incentive.
I’m not sure I believe in 100% strict liability. Imagine if someone were to perform a B&E or armored robbery at a physical location to steal hard copies of records.
Clearly if someone uses a zero day to steal personal information from an otherwise secure server than the server’s owners were not negligent.
In addition, often times the only people that know there was a data breach is the organization that had their data breached and the attackers that stole the data. None of the parties could report the data breach without violating their 5th amendment rights if they both had legal liability.
It would make the most sense to define software as a legal agent of those who deploy it.
If an HTTPS server prints OK and returns a document for a straightforward request, then it's manifestly obvious that the owner's agent intended to give you that information. If the owner did not intend that to happen, the issue is between them and their agent. (Think: a customer service rep who didn't follow policy)
Supplying a SQL injection to an HTTPS server would be akin to fraud or false pretenses - like if you walked up to a customer service rep, showed them a fake ID, and asked for information about your account.
(Furthermore, copyright trolls wouldn't be able to wriggle out of their fraudulent DMCA requests by blaming it on software that they themselves deployed)
Yes, that was my point about SQL injection. By knowingly performing an SQL injection, you're deceiving the software agent webserver. Whether you're guilty of a crime then depends on your intent for why you did that. If you do this to find and report a bug, and don't do much else with the ill-gained information, you're demonstrating good intent. If you use the information to make further compromises or otherwise profit by it, then not so much.
But in the larger scenario here the software-agent webserver was not tricked at all, making it hard to argue that the person accessing the willfully-published information did something improper regardless of their intent.
You send a query string to a server with the hopes that the server will give you what you want. Isn't that the World Wide Web?
Proving "intent" is much harder than proving action. And, to me it seems bad for the law to enforce based on whether the server's authors "wanted" to provide a specific piece of information.
> With a sql injection, you have to willfully provide an input with the hope that it results in injection
If I send you a link that happens to include arguments that happen to be a SQL injection (or my cat steps on my keyboard in just the right way), there was no intent.
Thats a third party. Youre mixing responsibility and ascribing it to an innocent party. That was the obvious point, with an incidental mention of another (random input) case where innocence is a reasonable deduction. Therefore, it is not necessary for an sql injection attack to be connected with the intent of the actor. Period.
From US caselaw, theres a little history about the not chasing after infected botnet hosts as bad actors.
If you commit wire fraud through an innocent intermediary, you're still guilty of wire fraud. If you give someone a link that's an attack and they unknowingly run it, then you're the one at fault not the person clicking the link.
> an SQL injection could also be "just a query parameter" and the server would haply reply with a 200. (true)
> With a sql injection, you have to willfully provide an input with the hope that it results in injection (false)
> If I send you a link that happens to include arguments that happen to be a SQL injection (or my cat steps on my keyboard in just the right way), there was no intent. (true)
> Your intent by crafting such a link was clear. (irrelevant)
You can have SQL injection without intent, as I have adequately explained.
This redirection to an "original actor" is a bad faith argument toward finding if there is someone culpable. The poster I responded to, made a bad general assertion and I stand by it. GL with whatever.
SQL injection is probably malformed input in lots of cases and should return a 400 Bad Request. If you are returning a 200 maybe you really did want to take SQL (think of Mode or PHPMyAdmin).
That's the entire point of hacking, circumventing protections that the server has in place to get a response you were not supposed to get. The status code is irrelevant.
The same applies in the real world too. If I perform a social engineering hack and get you to pay a fake invoice, it's still theft (or fraud), even though someone willingly and deliberately sent you money.
That assumes that the server recognized it as invalid. It it had, then it should take measured to block the input, but if the attack succeeded then the server would not be recognizing the attach and would respond with a 200
SQL injection can be (and probably is) malicious though, so I suppose it becomes a unclear line for that example. Maybe punishment of both parties would be appropriate but I'm not a lawyer so don't have expertise in law punishments. But I could see this as incentivizing data security. Even if a 0 day is discovered, companies will be less inclined to drag their feet for a patch when one becomes available.