71–80 of 117 posts
It's pretty scary that you can go to jail (for a long time!) for something as simple as: > ~curl http://example.com/att/[1-100].html I understand what the lawyers are saying, but this is just beyond common sense. There should be liabilities for deploying software that publicly gives out information you do not intend to.
Earlier quoted context omitted.
> From a technical point of view the very nature of HTTP includes asking for permission. A web server isn't an agent of the company and has no capacity to grant or deny permission. Think of it as a security system you install in your home. Now, if the security system is malfunctioning and you notice that it is malfunctioning ... do you call up the owner and let them know or do you go inside and look through their stu…
> A web server isn't an agent of the company and has no capacity to grant or deny permission. Imagine I send a company a polite letter, requesting permission. The CEO hand-writes a letter (with his quill pen) telling me that I may access the information. After doing so, some critics on the internet start complaining that "A letter isn't an agent of the company and has no capacity to grant or deny permission." Your cl…
I'm not trying to argue that guessing sequential IDs in a URL is morally the same as picking a lock. I'm arguing that in both cases, there's no human in the loop, so it's not at all obvious to what extent a human should be assigned responsibility. In your example, the letter does not have agency, but the CEO certainly does; and if weev had written 110,000 letters to AT&T that were read and responded to by humans, I can't imagine how there would be any case against him.
See also: the debates surrounding Google's autonomous cars, or the Do-Not-Track header.
Earlier quoted context omitted.
No, it wouldn't expose Google to that liability, because Google would have no intent to access information of any sort, let alone information that Google would have reason to believe it shouldn't have access to. The crimes charged here aren't strict-liability; the prosecution is required to prove intent. Also: the authorization "built into" HTTP is used by a tiny minority of all web applications. Clearly, if you brea…
I'm guessing that sneak wasn't referring to HTTP Basic Auth, but rather the fact that when an HTTP client says "GET", the server effectively says "HOW MUCH?" (A crude allusion to the classic "jump/how high?") I think sneak is arguing that receiving a response to an isolated GET request implies that the GET request was "authorized." Edit: after reading selections of IRC logs and e-mails from the indictment, my sympath…
Earlier quoted context omitted.
That is perhaps not the same as "capacity" in the legal sense. Is a web-server legally competent?
The blame would rest on the admin who set the permissions. You can't blame a lock for not being locked, but you can blame the night watchman for not locking it. This doesn't remove blame from the intruder though.
Earlier quoted context omitted.
No, it wouldn't expose Google to that liability, because Google would have no intent to access information of any sort, let alone information that Google would have reason to believe it shouldn't have access to. The crimes charged here aren't strict-liability; the prosecution is required to prove intent. Also: the authorization "built into" HTTP is used by a tiny minority of all web applications. Clearly, if you brea…
I'm guessing that sneak wasn't referring to HTTP Basic Auth, but rather the fact that when an HTTP client says "GET", the server effectively says "HOW MUCH?" (A crude allusion to the classic "jump/how high?") I think sneak is arguing that receiving a response to an isolated GET request implies that the GET request was "authorized." Edit: after reading selections of IRC logs and e-mails from the indictment, my sympath…
As a matter of law, the onus is not on the operators of web applications to ensure that their defenses are effective. If you do something stupid in your web app, but it remains clear to me that I'm not meant to access whatever your stupid app failed to prevent me from accessing, I can still be charged with a felony for doing it.
Now, if whatever it was that you tried and failed to protect wasn't obviously protected, so that I can argue in court that a reasonable person would have believed they did have permission to interact with it, I'll probably win in court. The prosecution will no doubt collect all my emails and any other piece of evidence it can find to build a case that I knew I wasn't supposed to hit your site that way. If you were especially dumb, and built an application that not only exposed sensitive information, but did so in a way that any normal person would just have assumed that sensitive information was theirs for the taking, the prosecution will have a hard time making their case.
Earlier quoted context omitted.
> No, it wouldn't expose Google to that liability It wouldn't expose Google to that liability because Google is a large US corporation. If it were a single greyhat individual with a history of unpopular speech, the argument would probably go something along the lines of "any reasonable person wouldn't spider the whole web, because they'd know they'd eventually get SOMETHING they're not authorized to access..."
I'm just stating facts. The prosecution is required to prove that the defendant not only exceeded their authorization to the application in question, but that they did so knowingly.
From my understanding all you had to do was pass the ICC-ID to a script on AT&T's servers to get back the user data. I can see the court interpreting the ICC-ID as a form of access control since you'd have to guess them similarly to passwords. What isn't quite clear to me is what they did with this data. It seems they reported the hole to AT&T who then fixed it. That's good. It also seems they passed the data off to…
It's pretty scary that you can go to jail (for a long time!) for something as simple as: > ~curl http://example.com/att/[1-100].html I understand what the lawyers are saying, but this is just beyond common sense. There should be liabilities for deploying software that publicly gives out information you do not intend to.
If you've never deployed software without security flaws, it means you have never deployed software.
We live in a tech-filled world without a reliable means for responsible disclosure, no way to hold a company accountable for reacting to attempts of responsible disclosure, and any whistle-blowers are immediately branded as "criminals" and "hackers". This whole process, or lack thereof, needs some serious disruption. Edit: My comment is intended to be a general observation and not specifically about this case
>> We live in a tech-filled world without a reliable means for responsible disclosure There are many avenues for responsible disclosure, Google that phrase.
Earlier quoted context omitted.
I'm just stating facts. The prosecution is required to prove that the defendant not only exceeded their authorization to the application in question, but that they did so knowingly.
[deleted]
However, I believe it remains black-letter illegal to "test" websites for security flaws in such a way where you actually exploit flaws and gain access to internals or sensitive data.
Either way, don't do it. If you don't have permission (Google, for instance, gives blanket permission for testing), don't fuck with other people's web apps. It's very difficult to ensure that any kind of security testing, outside of really basic stuff like CSRF, won't disrupt the site; even silly XSS vectors can get cached in backends and replayed to other customers. You're unlikely to pick up a felony charge for doing this, but you can be sued.