Home page logo
/

bugtraq logo Bugtraq mailing list archives

Re: Cross-Site Request Forgeries (Re: The Dangers of Allowing Users to Post Images)
From: "Chris Lambert" <bugtraq () whitecrown net>
Date: Fri, 15 Jun 2001 02:09:57 -0400

----- Original Message -----
From: Peter W <peterw () usa net>
Subject: Cross-Site Request Forgeries (Re: The Dangers of Allowing Users to
Post Images)

| I hope you don't mind if I expand on this a bit. You've come across the
| tip, in my opinion, of a rather large iceberg. It's another
| Web/trust-relationship problem. Many Web applications are fairly good at
| identifying users and understanding requests, but terrible at verifying
| origins and intent.

Yes, and oddly enough, its an iceberg thats been floating all around us for
ages.

| The problem isn't the IMG tag on the message board, it's the backend app
| you seek to attack via the IMG tag. And I suspect lots of Web apps are
| vulnerable. Lots. I've been to training on highly-regarded, widely-used,
| expensive Web app development frameworks, and none of the classes taught
| how to avoid the problems I will attempt to describe. In fact, they all
| seem to teach the "easy way" of handling what look like user requests,
| which is, of course, the vulnerable way.

Yes, you're correct that its the target of the exploit which needs to be
protected. However, the reason we originally related it to message boards
was because the source and the target were tightly related. I could use an
image on a message board to, as you suggested, make an online transaction at
an online store. However, only users who had registered and logged in at
that store would be effected. With message boards, or any other script with
cookie based authentication AND inline image support, the exploit will
suceed every time.

In PHP especially, the ability to access variables via $theirname regardless
of whether they are POST, GET, COOKIE, or SERVER creates a problem. Its
easily fixed, though, by simply referencing the respective predefined array
for the element ($HTTP_POST_VARS[], $HTTP_GET_VARS[], etc...) but the
problem will remain simply because its what makes PHP easy for the beginner.

| Right. There's something much larger going on here. Darnit, I wanted to
| make a nice formal paper out of this, but you're forcing my hand. :-) The
| problem is what I call CSRF (Cross-Site Request Forgeries.

You going to the O'Reilly Conference in San Diego? We should meet up to
discuss this further...maybe setup a BOF to brainstorm the far reaching
effects of "CSRF" and all the possible solutions for it.

|  <img src="https://trading.example.com/xfer?from=MSFT&to=RHAT&confirm=Y";>
|  <img src="https://books.example.com/clickbuy?book=ISBNhere&quantity=100";>

Eek! While its a problem, the user exposed WOULD have to be registered on
the target site, and unless the target site is the source site, its not as
much of an issue as inter-system attack would be. Inter-system being, for
example, an image referenced on an EBay product page which bids on the item
featured on the page.

| Since HTML documents are popping up everywhere (even in corporate email
| systems!!!), and it's impossible to discern what IMG or HREF values might
be
| direct CSRF attacks, or redirect users to unwittingly do dangerous things
| via CSRF redirects, the fix has to be in the applications that do the
| interesting things.

Exactly.

| That's it. When your client requests /logo.gif -- exposing no cookies --
the
| example.net server redirects you to a URL like the one you show, above. So
| the end result us the same as if the attacker had embedded the more
obvious
| URL inside the IMG tag.

Opera lets you disable automatic 302 redirection. Probably a good idea if
the redirect takes you off site.

| If an attacker wants, he can also use a simple, innocent looking hyperlink
| and hope the victim clicks on it (http://example.net/kyotoanalysis.htm).
You
| don't allow hyperlinks? Well, someone might copy/paste the link, and be
| stung that way. They'd notice? Maybe not -- the URL could be a mostly
useful
| page, with a tiny frameset sliver that loads your attack URL.

This has always been a problem, and as you mentioned above, the target site
has to implement the fix. However, with the many scripting tricks available
today, we're not being left with many options.

| The fix MUST be implemented on the backend that's being attacked. In your
| example, newreply.cgi needs to be intelligent enough to detect and stop
CSRF
| attacks.

| We've talked about how an attacker can post a message to the messageboard
| with innocent looking URLs. But an attacker can also simply send the
| victim a piece of HTML email including the full attack IMG URL. No amount
| of IMG tag filtering in your messageboard posting system can stop that.

We haven't implemented any <img> tag filtering, IIRC. John just wanted to
throw out a bunch of ideas as to what was possible.

| ** The 90% solution: Referer tests

This would work, but not all clients pass referers. For referer checking,
I'd suggest validating the form if the referer matches correctly, or if no
referer exists. Although not the perfect solution, I think that it'd be a
safe bet. Let's say 1% of all clients don't pass referers. The 1% would be
validated, therefore preventing them from getting an error when simply
interacting as usual. Its just the 1% who are compromised (which could be
.0001%) that would slip through.

| <snipped> Passing tokens or tokenized field names </snipped>

Good idea, looks to be the best solution yet.

| ** Attacking sites behind corporate firewalls
|  <img src="http://intranet/admin/purgedatabase?rowslike=%2A&confirm=yes";>

| security to many apps relatively easily. But Referer headers can also leak
| information about "private" sites if those sites use non-anonymized
| hyperlinks and external document references.

Thats why more and more sites are using "proxy-out" links which parse out
all links to external sites and append them to a URL.

http://our.intranet.application/bye.php/http://www.2600.com/

| I'm afraid CSRF is going to be a mess to deal with in many cases.
| Like trying to tame the seas.

I'm in the process of launching a company that will "secure" web enabled
applications from these, and other, types of attacks. CSRF seems to be one
of the more generic types of holes which can be exploited, but there are
certainly plenty more when dealing with user input, file handling, and
database access.

| Most of us probably depend on applications that won't be fixed
| anytime soon. So what can you do to prevent a CSRF attack from making
| your browser request something without your approval?
| <list snipped>

Basically, inconveince the hell out of yourself until the sites you use are
fixed. ;)

| My apologies for the somewhat rambling nature of this post; I may yet
| clean this up and put it in a proper paper, and do some real editing...
| but I hope even in this rough form it makes some sense, and helps folks
| design better, safer applications.

Thanks Peter, you've brought out several problems I didn't even imagine when
I stumbled across the concept. Let me know if you do work on a paper, I'd
appreciate not only obtaining, but possibly contributing a few ideas as
well.

--
WhiteCrown Networks - Web Application Security
www.whitecrown.net - services () whitecrown net
 ______________________________
/ Chris Lambert - cjlambert () home com
|-> ICQ #: 16435685 - AIM: ClipperChris
`-> Cell: (401) 743-2786 - http://sms.clambert.org/


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault