You: Can you provide me with Angela Smith's email address?
Librarian: Sure, here you go.
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.There is a difference between:
You: Can you give me the email address of user 50?
Librarian: Sure, here you go
Librarian: Oh balls, I wasn't supposed to hand that over, that could have been anyone!
You: Can you give me the email address of user 50?
Librarian: Sure, here you go
You: Hmm
You-irc: Hey guise! The librarian is giving out everyones email addresses, this is totally breaking privacy laws right?
You-irc: lols, I'm going to get all of them! This could be used for a massive phishing operation
You-irc: or even make their stock price drop, we could short it
You: Hey librarian, can you give me the email address of user 51?
Librarian: Sure, here you go
You: Hey librarian, can you give me the email address of user 52?
Librarian: Sure, here you go
You: Hey librarian, can you give me the email address of user 53?
Librarian: Sure, here you go
...
You: Hey librarian, can you give me the email address of user 1023821?
Librarian: Sure, here you go
The service was clearly not intended to be a directory of email addresses for people to use. It was clearly there to return the email address to the user of the iPad with that ICC-IDC code (which, unlike my example, aren't obviously guessable)
I'm not going to say anything about the sentence, but I do think he was guilty.
He knew what he was doing was illegal and didn't care, he got caught and tried to justify his actions by blaming AT&T for having a faulty configured server.
Not good enough for me and the jury agreed.
Suppose I write a scraper with user agent "I am a teapot" and I discover AT&T emits personal data when I access with that user agent. What is the arbitrary cutoff for number of things downloaded before I am a criminal?
There are in fact actual criminal charges that can be brought for identity theft, we don't need the US courts to be more aggressive with the CFAA by considering thoughtcrime in their deliberations.
Me: Can you provide me with all of guelo's money?
Bank: Sure, here you go.
Me: I have these lock picks. Will you let me in?
Lock: Sure thing, boss!But the company leaking consumer information to the public without any proper security at all is not punished.
Everyone here keeps purposefully ignoring intent, but in the context of the law this is impossible. So no matter how much you hate it, this isn't something that can be a binary yes/no illegal/legal question based on some computer response to your query.
The law involves intent. They proved he intended to act in bad faith while gathering that data and he was rightfully found guilty.
Why you are having a hard time understanding that "we put him in jail because we don't like what he did" is wrong I have no idea. You must be a troll disagreeing on purpose.
For me this is rather a good argument against using home banking (which I indeed don't use for security reasons - and as a computer scientist I'm surely not technologically backward).
UPDATE: if money is lying around on the street you are not be allowed to keep it (the same as I should not be allowed to keep the "money lying around in the internet"), but you can claim for getting the legitimate finder's reward.
It's actually a bit more complicated than that. Property (chattels) can be lost, mislaid, or abandoned. The distinction between lost and mislaid is that you mislay something when you intentionally put it somewhere but forget to retrieve it. That doesn't really apply to currency in the street -- it's unlikely that someone would intentionally leave money in the street.
So we are dealing with lost property. At common law the rule was that the finder of a chattel in a public place had a superior title to anyone except the true owner, and that if such a possessor knew or could reasonably ascertain the owner's identity he had a duty to notify the owner. A breach of that duty could result in either tort or criminal liability or both. In the case of fungible currency in the street, I'd say there's a good argument that it is not reasonable to ascertain the true owner.
However this common law rule has been modified in most jurisdictions by statute. Illinois has a typical such statute:
(765 ILCS 1020/27-8)
Sec. 27. If any person or persons find any lost goods, money, bank notes, or other choses in action, of any description whatever, such person or persons shall inform the owner thereof, if known, and shall make restitution of the same, without any compensation whatever, except such compensation as shall be voluntarily given on the part of the owner. If the owner is unknown and if such property found is of the value of $100 or upwards, the finder or finders shall, within 5 days after such finding file in the circuit court of the county, an affidavit of the description thereof, the time and place when and where the same was found, that no alteration has been made in the appearance thereof since the finding of the same, that the owner thereof is unknown to the affiant and that the affiant has not secreted, withheld or disposed of any part thereof. The court shall enter an order stating the value of the property found as near as the court can ascertain. A certified copy of such order and the affidavit of the finder shall, within 10 days after the order was entered, be transmitted to the county clerk to be recorded in his estray book, and filed in the office of the county clerk. ...
Sec. 28. In all cases where such lost goods, money, bank notes or other choses in action shall not exceed the sum of $100 in value and the owner thereof is unknown, the finder shall advertise the same at the court house, and if the owner does not claim such money, goods, bank notes or other choses in action within 6 months from the time of such advertisement, the ownership of such property shall vest in the finder and the court shall enter an order to that effect.
If the value thereof exceeds the sum of $100, the county clerk, within 20 days after receiving the certified copy of the court's order shall cause a notice thereof to be published for 3 weeks successively in some public newspaper printed in this county and if the owner of such goods, money, bank notes, or other choses in action does not claim the same and pay the finder's charges and expenses within one year after the advertisement thereof as aforesaid, the ownership of such property shall vest in the finder and the court shall enter an order to that effect.
My lock isn't authorised to give permission to anyone. Lock picks are forcing it, not requesting it.
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.
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.
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.
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.
> If the server owner had so desired, they could have made the data private by adding a password.
But the server is still just sending data in response to a request, even with a password. The only reason a password is a line we draw is intent. It's hard to say you didn't realise that guessing at someones password was wrong.
A logical step is to make that machine readable. Oh, wait, suddenly this is getting to the server software and configuration, that server developer/administrator had screwed up.
My question is - why we don't make that logical step and simplify things instead of relying on some "should be common sense" and "you should've known you wasn't supposed to do so" completely-gray-area?
You mean like the Terms of Use for the AT&T website?
As for those exact terms, I suspect (IANAL) those exact terms prohibit almost any access to the site, as, for example, they forbid any programmatic access to obtain the information, and I haven't heard of any non-software user-agent implementations.
As opposed to a human being in a non-programmatic way, opening his browser and accessing the website.
What's so hard about it?
Doesn't, for example, Firefox, perfectly fit this description? Yes, I do manually enter the base URL to access, but if that's the distinctive feature...
> As opposed to a human being in a non-programmatic way, opening his browser and accessing the website.
... then manually typing in ./scrape.py www.att.com is non-programmatic, too. :)
Or, maybe, I'm not getting the correct meaning of "automated" due to bad English comprehension and false analogies from other languages. But I always thought every request on the Internet is automated and done by some kind of hardware+software combo, so forbidding "programmatic" access is complete nonsense (access control and rate-limiting are the proper solutions).
(And, if that matters, author of scrape.py does not need to conform to AT&T's TOS if s/he don't actually use the script by themself.)
What if I set up a website, put a clause saying "you agree to pay $50/page view" in there, and hid it away. Google crawlers will find my site in no time, and then I can start raking the dollars in, right?
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).
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.
EDIT: and then noticing what happened you ask if they have a version in Korean.
Therefore, I see SQL injections as sloppy programming, but physical break-ins as sloppy ethics. IMHO YMMV IANAL KTHXBYE.
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".
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.
However, in terms of legal (or ethical) culpability it shouldn't really matter. An intruder is an intruder. Sometimes it's due to utter ignorance and foolishness on the part of the owner, sometimes it's due to a latent flaw in something they're using, sometimes it's a compromise of their hosting company, sometimes they get hit by a complete zero-day.
You should have legal recourse no matter the case, unless you are truly grossly negligent (posting your admin password on your index page, for example).
OK, but did they do anything wrong with SQL-injecting/breaking-a-window? I mean, if someone smashes your window can you call the cops and/or sue them for damages? In order to call the cops on the window smasher, you have to acknoledge they did a wrong.
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.
> 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.
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+e...
I'm not so sure about that. If it's not pushing to request record 334, why is it pushing to request record 335?
But I digress. Normally making standard web requests is analogized to looking, without touching. You have explicit authorization to go through the front door, and anything 'bad' you did inside was restricted to what you looked at.
>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.
But then you get into the realm of having TOS be a legal, no matter how inane they are. This seems a far worse alternative.
>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.
That's why I only said they lose the presumption of authorization. If all you know is someone SQL injected, you have to resort to other means to figure out if it was authorized. For example, if they already have equivalent access through non-code-bug means, and they simply prefer SQL injection, then there is no problem. But if they were doing it to avoid audit logs, there might be a huge problem.
>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.
When it comes purely to accessing it, when it's non-HIPAA/etc. data, I don't think there needs to be very much justification.
And I don't see 'has no password' as a technical artifact. Details of web servers don't need to be involved here. The design is wrong on a fundamental, user-understandable level.
For the same reason that it's OK for me to push in my door, but not to push in yours. Or why it's OK for me to type in my password, but not to type in your password.
> You have explicit authorization to go through the front door, and anything 'bad' you did inside was restricted to what you looked at.
There certainly isn't explicit permission; I think you mean implicit. Assuming you do, we just disagree here. You don't have a "presumption of authorization" when accessing something a reasonable person would know isn't meant for them to see. I think most of the rest of our disagreement flows from this.
I also don't see where you've made the case that get-the-employee's-SSN SQL injection attack is relevantly different from the send-an-id case.
Okay, I'm confused by your analogy. I was thinking of the situation as having a single door at the entrance to the establishment. I don't think it makes any sense at all to treat each page as a separate household on private property.
And I meant explicit. There is explicit permission to contact the web server.
>I also don't see where you've made the case that get-the-employee's-SSN SQL injection attack is relevantly different from the send-an-id case.
If I send a non-secret ID into the system and get info back, the system is working as designed. If I use SQL injection, the system is not working as designed. I think that's important. In the former case, I may be doing something unexpected, but I am not exceeding the authority given to me.
> I don't think it makes any sense at all to treat each page as a separate household on private property.
It's certainly true that some pages on a site might be private to someone else and others not. The page/site distinction is orthogonal to the authorized/unauthorized distinction. It's not clear to me why, in your story, it was OK to ask for ID 334, but it if it were, that doesn't automatically make it OK to grab 335.
The library is itself an analogy and it's a bit broken here, because of course at a library the ISBNs and the books they correspond to aren't meant to be private, unlike the ATT/Weev case. So let's imagine that your iPad automatically looked up your email address using its ICC ID because that was why they built it (I don't actually know if that's the case or not). It doesn't follow that you have permission to look up everyone else's. That's where I was going with the doors analogy. I hope that clears that up.
> There is explicit permission to contact the web server.
I deleted my counter to this because I think it's an irrelevant semantics issue. Let's let that one go.
> In the former case, I may be doing something unexpected, but I am not exceeding the authority given to me.
We keep stumbling on this concept of authority, and this thing about design. The design part I don't get. Didn't the library software's author design the system so that it took query parameters and directly formed SQL strings out of them? So isn't it working exactly as designed? Of course not, because the designer never intended it to be used that way [1]. So their intention is exactly what matters, and the same applies to trying incremental ICC IDs--clearly not the intent of the service. That's why this design/expectation dichotomy isn't there, or at least isn't relevant (it's also why I was distinguishing the "purpose of the software" from the "design of the code" earlier).
As for authority, you continue to see it as something the webserver can provide by virtue of its technical characteristics, and I--and the law--simply don't. Authorization in the technical sense is a technological codification of an authorization policy, which may be implicit. If that policy is obvious (which I think it is here), then it's that policy that matters, not its technical enforcement. I fear we're retreading ground here, though, and this may just boil down to having different axioms.
[1] You could say that there are layers to design and that the flaw in the designs here ("don't do any access control" vs "don't sanitize strings") are at grossly different granularities. That's true, but I'm not sure how you plan to formalize the appropriate level of generality that makes such a design flaw equivalent to permission to entry as opposed to simply not working as designed. I don't think you can without resorting to the designer's intent.
Intention of use is entirely different. The high level intention of use / purpose is often opaque and contradictory. Using it as a threshold would be foolish. "it securely stores passwords but also mails you a reminder if you forget" "it sends marketing mails that don't get marked as spam" "it shows people images that they can't save" "people will stay signed up for 15 months and we will profit on the loss leader"
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.