54

Hypothetical situation: before I hire a web development company I want to test their ability to design secure web apps by viewing their previous client's websites.

Issue: this situation raises a big red flag: with regards to viewing a website, what is and is not within the breadth of the law? Or in other words: at what point does poking around a website become illegal?

  • View Source with Firebug? Naturally that would be legal.
  • But what if I change HTML (like a hidden form value before submission)?
  • Perhaps I then edit or remove JavaScript, like a client side validation script. Would that be legal?
  • What if I put %3Cscript%3Ealert(1)%3C/script%3E at the end of the URL.
  • Or perhaps I type the URL: example.com/scripts/ and I'm able to view their directory due to faulty permission settings?
  • What if I manipulate data passed in HTTP headers, for instance a negative product qty/price to see if they do server side validation (naturally, I wont complete the checkout).

To me, all of this seems perfectly harmless because:

  1. I'm not causing undue stress to their server by spamming, mirroring the site with wget, or injecting potentially dangerous SQL.
  2. I'm not causing any potential loss or monetary damages, because I wont ever exploit the vulnerabilities, only test for their existence (proof of concept).
  3. None of my actions will have any implication for user data privacy. In no way would any of my actions potentially reveal confidential or private information about anyone.
  4. If I did find anything I would immediately notify the webmaster of the potential exploit so they could patch it.

But even though I am logically able to justify my reasons for testing the site, that does not necessarily make my actions legal. In fact, cyber laws are notoriously backwards in the United States, and even the most laughably trivial actions can be considered hacking.

Questions: Is there a defined line in the sand that separates illegal hacking from "testing without permission"? Or is this whole scenario a grey area that I should avoid (likely the case). Are there any linkable online resources that could expand my knowledge in this wholly grey area? What are the specific acts or laws that handle this?

Please keep in mind that the number one most logical choice would be to simply: ask for permissions. However, due to heavy time constraints, by the time I would get permission it would all be for naught.

  • 5
    It doesn't answer your question directly, but I think you should read my answer on the Is it ethical to hack real systems. Part of the problem with messing around with something like changing the data that is sent is that you may cause damage to a system. If a site is broken, and you are the person that sent the request that deleted the main database, do you really think they will care that you only changed something minor that anyone else could change? – Zoredache Aug 17 '11 at 18:22
  • 3
    The law depends on where you are and where your 'mark' is (and also changes with time). Which country are you in? – user185 Aug 18 '11 at 11:14
  • @Moses please add at the start of your question the name of the countr(ies) where your work will be carried out. All legal systems differ. – Steve Dodier-Lazaro Mar 9 '15 at 9:25
  • Just to add without submitting a full answer; consider whether a real attacker would perform the same step in the course of actually attempting to hack the service. If yes, why should the company believe you aren't attempting to hack the service? A lot of infosec doesn't try to see from the company's perspective; unless you have permission from them, you are in fact attempting to make the service do something the owners do not intend. – Angelo Schilling Jan 4 at 21:16
42

Don't do it! Don't do it! If you are in the US, the law is very broad. You don't want to even tiptoe up to the line.

The relevant law is the Computer Fraud and Abuse Act (18 U.S.C. 1030). In a nutshell (and simplifying slightly), under the CFAA, it is a federal crime to "intentionally access a computer without authorization or exceed authorized access". This language is very broad, and I imagine an ambitious prosecutor could try to use it to go after everything on your list except #1 (view source).

Orin Kerr, one of the leading legal scholars in this area, calls the statue "vague" and "extraordinarily broad", and has said that "no one actually knows what it prohibits".

And, as @Robert David Graham explains, there have been cases where folks were prosecuted, threatened with prosecution, or sued for doing as little as typing a single-quote into a textbox, adding a ../ to a URL, or signing up to Facebook under a pseudonym. It's pretty wild that this alone constitutes a federal offense, even if there is no malicious intent. But that's the legal environment we live in.

I'd say, don't take chances. Get written authorization from the company whose websites you want to test.

  • 2
    What exactly does the addition of ../ to a URL do? – nitrl Jun 7 '13 at 2:34
  • 1
    @nitrl, in some cases (very poorly coded web applications), it may allow bypassing access control restrictions or accessing content that the developer didn't intend/expect for you to be able to access. See also the notion of a path traversal vulnerability. – D.W. Jun 7 '13 at 4:56
  • 6
    @D.W., Thanks, couldn't find it on my own. Linked below for anyone else who might come across this. en.wikipedia.org/wiki/Directory_traversal_attack – nitrl Jun 7 '13 at 6:49
  • 1
    Great answer! Just to add a little to it. By posting this question on a public website if you were to "Hack" this site now even this post could be used against you to show intent to willfully perform an illegal act. If you had already gone through with it and then asked if what you had done was illegal then at least you could claim negligence and lack of understanding what you did. – Eddie Studer Jan 28 '16 at 14:09
  • "everything on your list except #1 (view source)" -- I'm not confident we won't start seeing "by using this website you agree not to view the source, and permission to use this website is withdrawn if you do". That way it's unambiguous that as soon as you "view source" the inention of the site owner is that you've exceeded authorized access. Whether it'll stand in court as an effective withdrawal of permission is another matter. But deCSS taught us that many people use legal remedies when they expose their valuable IP to their customers, and client-side scripts represent a largeish body of IP. – Steve Jessop Jan 10 '17 at 13:40
52

The law is unclear. Anything you do, no matter how innocent, could be considered a crime. All the website owner has to do is say "I didn't want that to happen", and you could be convicted of a crime.

Before donating to a tsunami relief website, Daniel Cuthbert typed in ../../../ in the URL. He was convicted of "intent to hack" (in the UK).

Lori Drew was convicted of hacking MySpace, because she violated MySpace's terms-of-service by creating a fake account, that was later used by her 14 year old daughter to harass another girl, who later committed suicide. The convictions were overturned later, and the government decided not to appeal - but it's still an experience to avoid.

Andrew "weev" Auernheimer was found guilty of identity theft, because AT&T provided customer account info for early iPad owners on their website, and he wrote a script that just enumerated the URLs and download them.

Brian K. West was threatened with prosecution because he clicked on a button labelled "Edit" on a newspaper website -- and was surprised to discover that this allowed him to edit the actual web page. After reporting the problem to the newspaper, the FBI investigated him (including searching West's workplace and seizing some materials) and a prosecutor apparently threatened him with a felony prosecution.

In a recent case, it's been found that when you cause an inbox to fill up with spam, thus DoSing it, you are guilty of "hacking" it as defined by the Computer Fraud and Abuse act.

I do all the things you describe. There are lines I won't cross: I'll test for SQL injection, but I won't access the database. But I do this because I can afford high-priced lawyers to defend me. Also, I won't do things that are stupid. For example, Daniel Cuthbert was convicted of "intent to hack" because he kept changing his story when asked why he did it, so the court didn't believe any story.

  • 2
    Apparently some people check logs reaaally often if they noticed someone typing ../../../etc/passwd in the url bar :P – Arin Dec 17 '16 at 5:16
  • 1
    @JonathanReez: since Ross Ulbricht was arrested, how many of us really still believe that "use a reliable anonymous proxy" is a practicable strategy? Extreme case, of course, since the authorities were extremely well-motivated to find him in particular. – Steve Jessop Jan 10 '17 at 13:32
  • 1
    @Arin: btw, yes, they were checking their logs really often. According to The Register at the time, "This action set off an Intruder Detection System in a BT server room and the telco contacted the police". That is to say, they in effect (although not knowing for sure in advance that it would work) created a tarpit URL that anyone visiting it is convicted of an offence. – Steve Jessop Jan 10 '17 at 13:46
  • 1
    @JonathanReez: "if he was careful enough". Right, but how confident can a person be that they will always be careful enough, if they're even asking this question online via an account they use habitually? ;-) You're right though, they probably will be careful enough for the occasional SQL injection probe. Just know your limits. "Hack whatever you want" can lead to extradition. – Steve Jessop Jan 10 '17 at 13:51
  • 1
    @usr-local-ΕΨΗΕΛΩΝ: right, but my point is that when people say "use an anonymous proxy and you'll be fine", that's like saying to someone worried about illegal data they have, "use strong encryption and you'll be fine". If your sole problem is people trying to trace you from IP addresses captured in logs, then sure, JonathanReez has provided a solution. But that's not your sole problem if you plan to "hack whatever you want" on an ongoing basis. Ulbricht was caught when he did something his proxy didn't help with. – Steve Jessop Jan 14 '17 at 19:35
11

The one constant across many jurisdictions seems to be that the only safe action on your list is number 1.

In some areas you would be okay with modifying data, but really you shouldn't risk it.

I would go so far as to say you are approaching this in entirely the wrong way.

Better approach:

Inform the web development company that if they want your business they must provide proof that the application has been tested to a particular standard. In the UK you could do this by requiring a test by a CREST or CHECK approved individual or team. Or you may gain assurance by using one of the Big-4 audit firms. If they have had a test, you could request visibility of the methodology and results.

Best approach:

Ask them to demonstrate the security and governance controls in their development lifecycle. An organisation that is mature in security will use a full SDLC which will reduce the likelihood of vulnerabilities, and even remove whole classes of vulnerabilities. Penetration testing is almost just a confirmation at the end of the process.

10

Caveat: I am not a lawyer, just a geek suggesting caution.

Is there a defined line in the sand that separates illegal hacking from "testing without permission"? Or is this whole scenario a grey area that I should avoid (likely the case). Are there any linkable online resources that could expand my knowledge in this wholly grey area? What are the specific acts or laws that handle this?

No. There isn't even agreement on which jurisdictions apply much less which laws within those jurisdictions apply. Even ignoring criminal penalties you should avoid doing this just because of civil penalties.

If you do half of the things on that list you are likely violating terms of service, and any non-good-faith use of computer resources can put you in danger of civil suits. Your arguments that you are not using undue resources are based on speculation about how reasonable engineers would design/deploy systems. You may very well be right but you have not and cannot verify those assertions before-hand or insure against them. If a meltdown in their server room merely coincides with your probing, you don't want to be in the position of proving that you did not cause it.

Seemingly innocuous payloads can become a problem when multiplied by many visitors. For example, your injected alert(1) payload may seem innocuous but if you find a persistant XSS vuln and it manifests on the home page where it is seen by x potential customer for d days. For some values of x and d it is not innocuous and you do not have the power to mitigate those variables.

Even contract pen-testers should have liability insurance when they're working with permission according to "Penetration Testing: The Third Party Hacker"

All penetration testing service providers should have liability insurance sufficient to cover the costs associated with the risk of losing a client’s proprietary information and any potential loss in revenue that might result from unexpected downtime caused by their activities. If the service provider does not have a liability insurance, pay attention how they specify the liability in their ‘Terms and Conditions’. Management must also assure that it can recover from a loss of data during testing by having in place adequate incident response and disaster recovery plans that have been developed and verified before testing begins.

If you were contracted by the company, you could be liable for loss of data/business when your probing takes down production systems. If you act without either contract or prior relationship, and for your own benefit, you're even more at risk of suit if their systems (which they didn't know to backup before you started your probing) have flaws that you tickle.

Let's say that you go ahead, and it does result in a civil lawsuit. If they want to pressure you to settle they might raise the spectre of criminal penalties or try to get punitive damages by likening your actions to ones for which there are criminal penalties. Judges and juries might be susceptible to the following argument based loosely on "Cyber Vandalism and Internet 'Hacktivism'":

"Imagine a locksmith wants to decide which lock to buy, so he asks a lock-maker for a list of customers. The locksmith goes to a convenience store that uses his locks and finds the store closed for the night. He fiddles with the lock, and damages it. The store owner arrives the next morning to find the lock broken so he can't open it and so sells no coffee that morning. Most jurisdictions have laws against vandals and they could be used against the locksmith. Punitive damages should apply to the locksmith because society has an interest in punishing vandals."

Regardless of whether you find the locksmith who wants to buy a lock a good analogy for you, judges and juries might, and there is a meme among the non-tech-savvy that "hackers" (loosely defined) are vandals as described in the link above.

TLDR: Do not set yourself up for an expensive lawsuit by going cowboy.

5

Assuming that you are hiring the web development firm on behalf of your company, I would ask your company's legal department for advice. If you are investigating security on behalf of your company and someone wanted to sue, they would almost certainly sue the deeper pockets of your company rather than you personally. You definitely want your legal department to stand behind you if that were to happen.

Your company's legal department is also in a much better position to know what your national and state laws allow. If there is any sort of criminal investigation, the fact that you had consulted with your legal council wouldn't indemnify you but it would definitely be a point in your favor.

5

This doesn't answer your particular question, but for your hypothetical situation if you have permission to test their application's security then all of the above are 100% legal. Even better would be to ask the candidate to setup a test system (not their real website), and then try attacking that test system. This way if your tests accidentally bring down a live system (or someone notices the threat and brings the system down), you are not liable for damages.

For systems you are not affiliated with that aren't requesting penetration testing; I wouldn't go around testing security flaws. Yes, you won't be able to really know that company XYZ's website is protected against SQL injection attacks without testing, but unless they have agreed that you should test it -- its not your job to test it, and if you get caught doing so that can and should prosecute you.

Its like asking, is it ok to try check and see if my neighbor's house is locked? Or see if I could easily pick the lock (without ever opening the door and going inside)? Or testing to see if you could open a window that you could squeeze through? If your neighbor or the police notices you doing any of those things and feels compelled to press charges, you're screwed unless you have a legitimate reason (I heard screaming for help inside; I was dropping something off at their house and didn't want to leave it outside in the rain; so tried to see if I could open the door).

  • The test system could be set in a virtual machine or developed on spot. That way you can do whatever you want to it without breaking any law. – lepe Jul 5 '16 at 1:32

protected by Community Feb 17 '17 at 1:06

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.