10 ms·

This is currently downmodded because people don't like the implication. And they shouldn't, because it quickly forces someone into either a) agreeing with the

by patio11 13y ago

This is currently downmodded because people don't like the implication. And they shouldn't, because it quickly forces someone into either a) agreeing with the law or b) saying that SQL injections must be, ipso facto, legal. Including ones like: 1 AND ("1" = SUBSTRING(select social_security_number from employees where employee_name = 'Angela Smith', 1, 1)) You can use variations on this to... a) Ask our librarian for a series of about 50 books and hear whether or not she has them in stock. b) Read Angela Smith's Social Security number right out of the database. There apparently exist a lot of people on HN who would prefer to think that, despite my near-magical ability to correctly divine the SSN of any employee (or any other piece of data in the DB) with a SQL injection attack, the fact that I'm just looking at a book listing page in a totally authorized fashion means I must not be doing anything wrong.

nitrogen 13y ago
This is currently downmodded because people don't like the implication. And they shouldn't, because it quickly forces someone into either a) agreeing with the law or b) saying that SQL injections must be, ipso facto, legal. You're drawing a false dichotomy based on premises that nobody in this thread has actually raised. It's entirely reasonable to a) disagree with the law, b) believe that SQL injections can be illegal based on some other rationale, and c) disagree with others on the appropriate penalty for SQL injections.
victorf 13y ago
No, it is because lying about your user-agent is not explicitly trying to make an HTTP server perform an action it is not supposed to perform and is therefore not in the same category as SQL injections. HTTP servers are not supposed to use user-agent as authentication.
- pyre 13y ago
  It's the equivalent of going to a Chinese restaurant and asking for the "Chinese menu" rather than the "American menu" even if you can't read Chinese.
  - nederdirk 13y ago
    Except for that the Chinese menu wasn't written in Chinese but in English. Moreover it contained an access card to the staff lounge where the customer records were open on the table.
    - victorf 13y ago
      Again completely wrong because trespassing on the staff lounge is nothing like receiving a response from an HTTP server. It is like asking for the Chinese menu and being given a list of customer records. EDIT: and then noticing what happened you ask if they have a version in Korean.
  - rmc 13y ago
    Heh, I'm reminded of an anecdote of an elderly English relative who was in a chinese restaurant (in England), and was suprised that the English menu was chinese food but written in English, instead of steak, potatoes and veg that used to be on the "english menu" in chinese restauarants decades ago. :P
jrockway 13y ago
I approach this from a different angle. If someone broke into my web app by injecting SQL, I'd be mad that I allowed them to do so. If someone broke into my apartment by smashing the window with a brick, I wouldn't be mad at myself for not using thicker glass. Therefore, I see SQL injections as sloppy programming, but physical break-ins as sloppy ethics. IMHO YMMV IANAL KTHXBYE.
- jussij 13y ago
  So does that mean if someone picked the lock on your front door and just had a look around your apartment, without doing any damage; you’d be ok with that and just be mad at yourself for not installing a better lock?
  - jrockway 13y ago
    I guess if I never knew about it, I wouldn't be upset.
- meowface 13y ago
  Where do you draw the line? What if your site uses Wordpress or some CMS, and it has a SQL injection zero day that is then exploited to gain access? Even if you did due diligence, kept your kernel and all your software up to date, and generally secured the server and the application as best you could, you could still be entirely unaware of flaws lurking within. It'd be more comparable to the lock on your front door being vulnerable to easy lockpicking with a paperclip and 4 seconds. You're still not "allowing them to break in" by being sloppy (it's not like you left the door unlocked), but the manufacturer of the lock was sloppy and as a result, someone is able to break in without any "brute force".
  - tekacs 13y ago
    If you actually cared about your data being taken care of in this instance you should probably be running an IDS-esque or similar to notice and stop that form f attack in a blanket fashion (these certainly exist for SQLi attacks, names escape me in this moment). When using a proprietary, paid for web service or app you can blame the service provider. When hosting OSS code on your own server, exactly this is what the NO WARRANTY section in the license is about, thus making it fully your responsibility to go over the code or to accept that bugs and security vulnerabilities happen. Edit: To all those talking about the skill level of the individual - if you are using a proprietary service, you can easily point the finger at the service provider. In the case of OSS code, the license is there to remind you that you are taking responsibility for being competent enough to use the code yourself. If your house was broken into because the lock was shoddily installed by a locksmith, you might have some legal recourse (though, IIRC, you may be required to validate & disclaim the install) but if you were to install the lock yourself, you have nobody to blame.
ajays 13y ago
It is the server's problem. A misconfigured server is not a client's problem. Set aside the SQL injection. Suppose there's a bug in Apache's path parsing such that using "\" instead of "/" causes it to interpret it as an escaped string, which somehow (bear with me) causes it to run exec("/bin/rm -r /"). Now some n00b comes along and uses "\" in the path, because he's used to paths on MSDOS; crashing the server. Whose problem is it? The client's, for sending a malformed request? How do you expect the client to know that the "\" will trigger a catastrophe? Or what if the client made a mistake, and while he thought it was "some query string" in his cut buffer, it turned out to be "; drop table *" (or something like that). Now whose problem is it? If the server willy-nilly takes any input and doesn't check it, it is the server's fault.
- meowface 13y ago
  Whether it's the server's or the client's fault doesn't matter that much from a legal perspective. Intent plays a big role: if you knew that ending a URL with "\" causes `rm -rf /*` to be run, and intentionally run that on a server, you could likely be prosecuted and convicted if it were proven that you did it intentionally. If it were done accidentally by a client, they would (likely, and hopefully) not be convicted. Weev intentionally exploited an information disclosure flaw. Should he have gone to jail for that? No, I don't think so at all. But the scenario you're presenting has no relation to what happened here.
  - ajays 13y ago
    No, Weev did not "exploit" anything. He _requested_ information from a server. If the server owner had so desired, they could have made the data private by adding a password. They chose not to. In the end, the decision to offer Weev the data was made _by the server_ . And if you're going to bring up the UserAgent spoofing, let me remind you that most browsers have done something like that for > 15 years.
    - meowface 13y ago
      He did not exploit a software flaw or a platform flaw, however he exploited an information disclosure / access separation EXPOSURE. Exploiting just means "taking advantage of something." He did exploit the fact that AT&T did not make the endpoint in question accessible only if the logged-in user matched the actual user ID (or just made it entirely inaccessible).
guelo 13y ago
You: Can you provide me with Angela Smith's email address? Librarian: Sure, here you go. Later, Librarian's manager: You weren't supposed to give out that information! Librarian: Oops. I had the wrong access rules. Librarian's manager: Let's call the cops on that guy. It's his fault that you gave him the information he wasn't supposed to have.
- icambron 13y ago
  Later, when I crack your bank password, Me: Can you provide me with all of guelo's money? Bank: Sure, here you go. Also, when I approach your house, Me: I have these lock picks. Will you let me in? Lock: Sure thing, boss!
  - nightski 13y ago
    Well in a private by default world, browsing the internet just became one hell of a lot scarier. Any page you visit could become a felony.
    - EliAndrewC 13y ago
      Not so, because as others in this thread have stated, the key is intent.
      - tankenmate 13y ago
        And we peer into the mind of a third party how?
        BryantD 13y ago
        There's a fairly large body of law that hinges on the intent of the individual. http://en.wikipedia.org/wiki/Intention_(criminal_law) http://en.wikipedia.org/wiki/Intention_(criminal_law)
      - nitrogen 13y ago
Dylan16807 13y ago
>This is currently downmodded because people don't like the implication. And they shouldn't, because it quickly forces someone into either a) agreeing with the law or b) saying that SQL injections must be, ipso facto, legal. Not if you make a distinction between using a service and breaking a service. Analogize with entering vs. breaking and entering. In many cases it is valid to punish someone for bypassing security. But if a system has no security by design, then there is nothing to bypass. SQL injection, on the other hand, is always bypassing the design of the code, and loses any presumption of authorization. P.S. Yes there will be edge cases. There are always edge cases. But this is not an edge case. The lack of security was definitely design, not software-bug.
- icambron 13y ago
  Tackling that out of order, because it seems clearer. > Analogize with entering vs. breaking and entering. From Free Dictionary [1]: breaking and entering v., n. entering a residence or other enclosed property through the slightest amount of force (**even pushing open a door**), without authorization. Emphasis mine. If pushing a door counts, so does changing the user agent header or auto-incrementing IDs. The key here is "without authorization". As that analogizes with the Weev situation and our librarian, much of the debate I see here on HN seems to hinge on whether that means authorization in some technical sense or in the sense meant by that breaking and entering definition. I submit that it means the latter, in part because that reflects how we see authorization in other contexts (like doors we're not supposed to enter) and in part because I don't think the first view holds up to scrutiny on its own terms. Let me explain what I mean by that. Consider two situations: 1. A server responds to requests for email addresses without checking whether the user is authorized to receive that information. 2. A server responds to all requests without checking whether they contain injected SQL. In pure technology terms, these aren't really any different. In either case, the server is simply failing to check that the request has certain properties (came from the right user/does not contain context escapes). But of course case 2 is particularly nefarious, because passing SQL directly to the database is clearly not the intent of that interface, and that it's not the intent is obvious to the SQL injector. So the intent of the software is what matters. But then it's what matters in case 1 too. The lack of technical enforcement of this intent is not the issue. Which leads me to some clarity about this: > Not if you make a distinction between using a service and breaking a service. I believe this use/break distinction exists, but the distinction isn't something that's determined by the code or the vaguer "design of the code"; it's determined by the purpose of the service. The service as it would be described functionally, not technically. The service was not meant to be used by Weev and his scraper any more than our librarian's database was meant to be used by SQL injection, or any more than your unencrypted traffic was meant to be intercepted by my packet sniffer (you did nothing to not authorize me to see it!). To drive that home, the library's hapless database admin who foolishly decides to update the list of books using her own SQL injection bug is not hacking, because she is authorized to fiddle with the database, even though, in your terms, it's bypassing the design of the code. In other words, authorization is not the same as the technical artifacts involved in authorization. More generally, I don't think being bad at making software justifies people accessing it when they know it's not meant for them. As the law is actually applied here, I am somewhat sympathetic to Weev, on the grounds that I don't think it was a serious crime (imagine if it were bank account information!), but that's a quantitative issue, not a qualitative one. I can also see that there are many cases where it isn't obvious whether something is meant for you to access or not (like a door that seems to lead into a public place but which turns out to be a private space), and I can imagine there being issues there. But this isn't one of them. [1] http://legal-dictionary.thefreedictionary.com/breaking+and+entering http://legal-dictionary.thefreedictionary.com/breaking+and+e...
Zak 13y ago
I think SQL injection in many cases[0] demonstrates a clear difference in intent from a GET request for a resource the user legitimately expects to exist. There's no good analog in describing the behavior of a librarian because humans generally know not to follow arbitrary instructions from random people. The closest analog I can think of would be giving the giving the librarian drugs to modify his behavior before asking him to perform some act or provide some information he normally would not. Giving the librarian a brownie before requesting access to the staff lounge would probably not alter his behavior nor be treated as a crime. Giving him a brownie laced with scopolamine before requesting access to the staff lounge would be, even if scopolamine had no dangerous side-effects. [0] One might reasonably expect an SQL injection string to return a legitimate resource on a documentation site or general-purpose search engine, for example.

by patio11 13y ago

nitrogen 13y ago

This is currently downmodded because people don't like the implication. And they shouldn't, because it quickly forces someone into either a) agreeing with the law or b) saying that SQL injections must be, ipso facto, legal. You're drawing a false dichotomy based on premises that nobody in this thread has actually raised. It's entirely reasonable to a) disagree with the law, b) believe that SQL injections can be illegal based on some other rationale, and c) disagree with others on the appropriate penalty for SQL injections.

victorf 13y ago

No, it is because lying about your user-agent is not explicitly trying to make an HTTP server perform an action it is not supposed to perform and is therefore not in the same category as SQL injections. HTTP servers are not supposed to use user-agent as authentication.

pyre 13y ago
It's the equivalent of going to a Chinese restaurant and asking for the "Chinese menu" rather than the "American menu" even if you can't read Chinese.
- nederdirk 13y ago
  Except for that the Chinese menu wasn't written in Chinese but in English. Moreover it contained an access card to the staff lounge where the customer records were open on the table.
  - victorf 13y ago
    Again completely wrong because trespassing on the staff lounge is nothing like receiving a response from an HTTP server. It is like asking for the Chinese menu and being given a list of customer records. EDIT: and then noticing what happened you ask if they have a version in Korean.
- rmc 13y ago
  Heh, I'm reminded of an anecdote of an elderly English relative who was in a chinese restaurant (in England), and was suprised that the English menu was chinese food but written in English, instead of steak, potatoes and veg that used to be on the "english menu" in chinese restauarants decades ago. :P

jrockway 13y ago

I approach this from a different angle. If someone broke into my web app by injecting SQL, I'd be mad that I allowed them to do so. If someone broke into my apartment by smashing the window with a brick, I wouldn't be mad at myself for not using thicker glass. Therefore, I see SQL injections as sloppy programming, but physical break-ins as sloppy ethics. IMHO YMMV IANAL KTHXBYE.

jussij 13y ago
So does that mean if someone picked the lock on your front door and just had a look around your apartment, without doing any damage; you’d be ok with that and just be mad at yourself for not installing a better lock?
- jrockway 13y ago
  I guess if I never knew about it, I wouldn't be upset.
meowface 13y ago
Where do you draw the line? What if your site uses Wordpress or some CMS, and it has a SQL injection zero day that is then exploited to gain access? Even if you did due diligence, kept your kernel and all your software up to date, and generally secured the server and the application as best you could, you could still be entirely unaware of flaws lurking within. It'd be more comparable to the lock on your front door being vulnerable to easy lockpicking with a paperclip and 4 seconds. You're still not "allowing them to break in" by being sloppy (it's not like you left the door unlocked), but the manufacturer of the lock was sloppy and as a result, someone is able to break in without any "brute force".
- tekacs 13y ago
  If you actually cared about your data being taken care of in this instance you should probably be running an IDS-esque or similar to notice and stop that form f attack in a blanket fashion (these certainly exist for SQLi attacks, names escape me in this moment). When using a proprietary, paid for web service or app you can blame the service provider. When hosting OSS code on your own server, exactly this is what the NO WARRANTY section in the license is about, thus making it fully your responsibility to go over the code or to accept that bugs and security vulnerabilities happen. Edit: To all those talking about the skill level of the individual - if you are using a proprietary service, you can easily point the finger at the service provider. In the case of OSS code, the license is there to remind you that you are taking responsibility for being competent enough to use the code yourself. If your house was broken into because the lock was shoddily installed by a locksmith, you might have some legal recourse (though, IIRC, you may be required to validate & disclaim the install) but if you were to install the lock yourself, you have nobody to blame.

ajays 13y ago

It is the server's problem. A misconfigured server is not a client's problem. Set aside the SQL injection. Suppose there's a bug in Apache's path parsing such that using "\" instead of "/" causes it to interpret it as an escaped string, which somehow (bear with me) causes it to run exec("/bin/rm -r /"). Now some n00b comes along and uses "\" in the path, because he's used to paths on MSDOS; crashing the server. Whose problem is it? The client's, for sending a malformed request? How do you expect the client to know that the "\" will trigger a catastrophe? Or what if the client made a mistake, and while he thought it was "some query string" in his cut buffer, it turned out to be "; drop table *" (or something like that). Now whose problem is it? If the server willy-nilly takes any input and doesn't check it, it is the server's fault.

meowface 13y ago
Whether it's the server's or the client's fault doesn't matter that much from a legal perspective. Intent plays a big role: if you knew that ending a URL with "\" causes `rm -rf /*` to be run, and intentionally run that on a server, you could likely be prosecuted and convicted if it were proven that you did it intentionally. If it were done accidentally by a client, they would (likely, and hopefully) not be convicted. Weev intentionally exploited an information disclosure flaw. Should he have gone to jail for that? No, I don't think so at all. But the scenario you're presenting has no relation to what happened here.
- ajays 13y ago
  No, Weev did not "exploit" anything. He _requested_ information from a server. If the server owner had so desired, they could have made the data private by adding a password. They chose not to. In the end, the decision to offer Weev the data was made _by the server_ . And if you're going to bring up the UserAgent spoofing, let me remind you that most browsers have done something like that for > 15 years.
  - meowface 13y ago
    He did not exploit a software flaw or a platform flaw, however he exploited an information disclosure / access separation EXPOSURE. Exploiting just means "taking advantage of something." He did exploit the fact that AT&T did not make the endpoint in question accessible only if the logged-in user matched the actual user ID (or just made it entirely inaccessible).

guelo 13y ago

You: Can you provide me with Angela Smith's email address? Librarian: Sure, here you go. Later, Librarian's manager: You weren't supposed to give out that information! Librarian: Oops. I had the wrong access rules. Librarian's manager: Let's call the cops on that guy. It's his fault that you gave him the information he wasn't supposed to have.

icambron 13y ago
Later, when I crack your bank password, Me: Can you provide me with all of guelo's money? Bank: Sure, here you go. Also, when I approach your house, Me: I have these lock picks. Will you let me in? Lock: Sure thing, boss!
- nightski 13y ago
  Well in a private by default world, browsing the internet just became one hell of a lot scarier. Any page you visit could become a felony.
  - EliAndrewC 13y ago
    Not so, because as others in this thread have stated, the key is intent.
    - tankenmate 13y ago
      And we peer into the mind of a third party how?
      - BryantD 13y ago
        There's a fairly large body of law that hinges on the intent of the individual. http://en.wikipedia.org/wiki/Intention_(criminal_law) http://en.wikipedia.org/wiki/Intention_(criminal_law)
    - nitrogen 13y ago

Dylan16807 13y ago

>This is currently downmodded because people don't like the implication. And they shouldn't, because it quickly forces someone into either a) agreeing with the law or b) saying that SQL injections must be, ipso facto, legal. Not if you make a distinction between using a service and breaking a service. Analogize with entering vs. breaking and entering. In many cases it is valid to punish someone for bypassing security. But if a system has no security by design, then there is nothing to bypass. SQL injection, on the other hand, is always bypassing the design of the code, and loses any presumption of authorization. P.S. Yes there will be edge cases. There are always edge cases. But this is not an edge case. The lack of security was definitely design, not software-bug.

icambron 13y ago
Tackling that out of order, because it seems clearer. > Analogize with entering vs. breaking and entering. From Free Dictionary [1]: breaking and entering v., n. entering a residence or other enclosed property through the slightest amount of force (**even pushing open a door**), without authorization. Emphasis mine. If pushing a door counts, so does changing the user agent header or auto-incrementing IDs. The key here is "without authorization". As that analogizes with the Weev situation and our librarian, much of the debate I see here on HN seems to hinge on whether that means authorization in some technical sense or in the sense meant by that breaking and entering definition. I submit that it means the latter, in part because that reflects how we see authorization in other contexts (like doors we're not supposed to enter) and in part because I don't think the first view holds up to scrutiny on its own terms. Let me explain what I mean by that. Consider two situations: 1. A server responds to requests for email addresses without checking whether the user is authorized to receive that information. 2. A server responds to all requests without checking whether they contain injected SQL. In pure technology terms, these aren't really any different. In either case, the server is simply failing to check that the request has certain properties (came from the right user/does not contain context escapes). But of course case 2 is particularly nefarious, because passing SQL directly to the database is clearly not the intent of that interface, and that it's not the intent is obvious to the SQL injector. So the intent of the software is what matters. But then it's what matters in case 1 too. The lack of technical enforcement of this intent is not the issue. Which leads me to some clarity about this: > Not if you make a distinction between using a service and breaking a service. I believe this use/break distinction exists, but the distinction isn't something that's determined by the code or the vaguer "design of the code"; it's determined by the purpose of the service. The service as it would be described functionally, not technically. The service was not meant to be used by Weev and his scraper any more than our librarian's database was meant to be used by SQL injection, or any more than your unencrypted traffic was meant to be intercepted by my packet sniffer (you did nothing to not authorize me to see it!). To drive that home, the library's hapless database admin who foolishly decides to update the list of books using her own SQL injection bug is not hacking, because she is authorized to fiddle with the database, even though, in your terms, it's bypassing the design of the code. In other words, authorization is not the same as the technical artifacts involved in authorization. More generally, I don't think being bad at making software justifies people accessing it when they know it's not meant for them. As the law is actually applied here, I am somewhat sympathetic to Weev, on the grounds that I don't think it was a serious crime (imagine if it were bank account information!), but that's a quantitative issue, not a qualitative one. I can also see that there are many cases where it isn't obvious whether something is meant for you to access or not (like a door that seems to lead into a public place but which turns out to be a private space), and I can imagine there being issues there. But this isn't one of them. [1] http://legal-dictionary.thefreedictionary.com/breaking+and+entering http://legal-dictionary.thefreedictionary.com/breaking+and+e...

Zak 13y ago

I think SQL injection in many cases[0] demonstrates a clear difference in intent from a GET request for a resource the user legitimately expects to exist. There's no good analog in describing the behavior of a librarian because humans generally know not to follow arbitrary instructions from random people. The closest analog I can think of would be giving the giving the librarian drugs to modify his behavior before asking him to perform some act or provide some information he normally would not. Giving the librarian a brownie before requesting access to the staff lounge would probably not alter his behavior nor be treated as a crime. Giving him a brownie laced with scopolamine before requesting access to the staff lounge would be, even if scopolamine had no dangerous side-effects. [0] One might reasonably expect an SQL injection string to return a legitimate resource on a documentation site or general-purpose search engine, for example.