6 ms·

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

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.

jdavis703 5y ago
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).
- Tagbert 5y ago
  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
- underwater 5y ago
  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.
milkytron 5y ago
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.
- MereInterest 5y ago
  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.
  - after_care 5y ago
    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.
chrsig 5y ago
With a sql injection, you have to willfully provide an input with the hope that it results in injection my understanding is that the reporter looked at the source that was being sent as intended -- no manipulation of input by the client
- Supermancho 5y ago
  > 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.
  - wvenable 5y ago
    Your intent by crafting such a link was clear.
    - Supermancho 5y ago
      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.
      - chrsig 5y ago
        You're kind of just describing why it's hard to prosecute based on intent though. For the purposes of distinguishing between if something is an exploit or not, it doesn't seem too relevant
      - wvenable 5y ago
        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. I think it's pretty straight forward.
mindslight 5y ago
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)
- underwater 5y ago
  If you socially engineer an employee to access data or steal money it's still a crime.
  - mindslight 5y ago
    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.

jdavis703 5y ago

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).

Tagbert 5y ago
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
underwater 5y ago
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.

milkytron 5y ago

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.

MereInterest 5y ago
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.
- after_care 5y ago
  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.

chrsig 5y ago

With a sql injection, you have to willfully provide an input with the hope that it results in injection my understanding is that the reporter looked at the source that was being sent as intended -- no manipulation of input by the client

Supermancho 5y ago
> 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.
- wvenable 5y ago
  Your intent by crafting such a link was clear.
  - Supermancho 5y ago
    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.
    - chrsig 5y ago
      You're kind of just describing why it's hard to prosecute based on intent though. For the purposes of distinguishing between if something is an exploit or not, it doesn't seem too relevant
    - wvenable 5y ago
      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. I think it's pretty straight forward.

mindslight 5y ago

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)

underwater 5y ago
If you socially engineer an employee to access data or steal money it's still a crime.
- mindslight 5y ago
  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.