Cenzic 232 Patent
Paid Advertising
sla.ckers.org is
ha.ckers sla.cking
Sla.ckers.org
Q and A on cross site request forgeries and breaking into sessions. It's one of the attacks that XSS enables and the attack of the future. For Session, fixations, hijacking, lockout, replay, session riding etc.... 
Go to Topic: PreviousNext
Go to: Forum ListMessage ListNew TopicSearchLog In
question
Posted by: lobas
Date: April 04, 2007 01:44PM

do u actually need an xss to preform a csrf attack

Options: ReplyQuote
Re: question
Posted by: Mephisto
Date: April 04, 2007 01:59PM

No, some sites might filter out the ability to enter script, such as "MySpace" (Stop laughing)...But they might allow you to enter image tags or as "MySpace" does they allow for <style > tags, then you can just set a css classes background-image to an actual url.

Options: ReplyQuote
Re: question
Posted by: SW
Date: April 04, 2007 02:19PM

CSRF is remote often. The basic idea is to find something that takes GET parameters and is vulnerable on a web app. Example, "www.thesite.com/forum/deletemyaccount.php?areyousure=yes". Now if this actually works with a GET method you make a page on your site and you put in <img src="www.thesite.com/forum/deletemyaccount.php?areyousure=yes"/>. Then you get them to view the site while logged into the victim site and suddenly their account just magically disappears. (I've actually found a few game sites that delete account like that hah.) More recently most CSRF attacks can/are performed locally though, especially on sites that allow you to post offsite images or other code. This way you don't have to try and trick someone into viewing an external site. Also you can use the htaccess redirect discussed in some other topic to do this.

But say the delete URL is actually "www.thesite.com/forum/deletemyaccount.php?areyousure=yes&myrandomcode=KLJ234KJ2KJ" where "myrandomcode" is different and unknown for all other users. If you don't supply that code it won't delete. Now you can't do CSRF unless you have an XSS hole where you can run javascript in their browser, retrieve their special code, and then forward to the URL with the proper code in it.

Options: ReplyQuote
Re: question
Posted by: rezn
Date: April 04, 2007 03:39PM

POSTed stuff is good too. All you need to do is put something on your (the malicious) site like this:

<form name=csrform method=post action=https://vuln.app.com/chpw.do>
<input type="hidden" name="postedparam1" value="blah@blah.com">
<input type="hidden" name="postedparam2" value="assword">
</form>
<script>document.csrform.submit();</script>

This isn't tested code (I just typed it), but you get the idea.

Options: ReplyQuote
Re: question
Posted by: kishord
Date: June 29, 2007 10:52PM

You need CSRF to perform XSS!

Web Application Security Journ(ey)al

Options: ReplyQuote
Re: question
Posted by: kishord
Date: June 29, 2007 11:39PM

I mean the reflected one.

Web Application Security Journ(ey)al

Options: ReplyQuote
Re: question
Posted by: Anonymous User
Date: June 30, 2007 04:00AM

CSRF doesn't need anything persee, that's the beauty of it. In the sense that it can be performed without Javascript at all in many cases. It actually has nothing to do with Javascript. You could USE Javascript as a distribution layer, but it works fine without it.

If you can insert an iframe, image, script source etc you can perform CSRF's

Simple example is:
<iframe name="0" src="telnet://somesite.com" height="1" width="1">

Which opens up a telnet window in windows, which also can be classified as a CSRF.

Just like this is:
<iframe name="0" src="http://www.somesite.com/delete.php?del=true" height="1" width="1">

Options: ReplyQuote
Re: question
Posted by: ma1
Date: June 30, 2007 01:59PM

Ronald Wrote:
-------------------------------------------------------
> CSRF doesn't need anything persee, that's the
> beauty of it. In the sense that it can be
> performed without Javascript at all in many cases.
> It actually has nothing to do with Javascript.

Not quite.
Every web developer with minimal training knows (or should know) the basics of HTTP methods semantics:
GET is for reading (i.e. search queries or regular informative pages)
POST is for writing (i.e. issuing permanent system modifications, such as database deletions, inserts or updates).

If these very simple* rules are observed, the only way to perform any meaningful CSRF attack is using JavaScript.

*compare to explaining a junior webdev how, when and where user input needs to be sanitized in order to avoid XSS or SQL injections

--
*hackademix.net*

There's a browser safer than Firefox... Firefox, with NoScript

Options: ReplyQuote
Re: question
Posted by: Anonymous User
Date: July 01, 2007 12:00AM

That is not true, it can work both ways. It all depends how the script responds to the incoming request, read => request, because it could be POST OR GET, which in PHP is $_REQUEST.

Options: ReplyQuote
Re: question
Posted by: ma1
Date: July 01, 2007 01:53AM

Ronald Wrote:
-------------------------------------------------------
> That is not true, it can work both ways. It all
> depends how the script responds to the incoming
> request, read => request, because it could be POST
> OR GET, which in PHP is $_REQUEST.

The $_REQUEST super-global is a brain-damaged shortcut that no professional developer would ever use: it not only contains GET and POST variables, but even cookies all mixed in the same array!

If you have a minimal grasp on web development, you use $_POST, $_GET and $_COOKIE in the proper places.

But the sad truth, PHP is probably the worst thing ever happened to web development because:

1. It has never been designed, it just "happened" and then underwent random cancer-like feature growth
2. It lowered the bar to enter the web development business for absolute amateurs who ignore the very basics of their job

--
*hackademix.net*

There's a browser safer than Firefox... Firefox, with NoScript



Edited 1 time(s). Last edit at 07/01/2007 02:19AM by ma1.

Options: ReplyQuote
Re: question
Posted by: Anonymous User
Date: July 01, 2007 03:17AM

I know that, it is what I just said. But it does not matter if I use GET or REQUEST or POST, all of them are vulnerable to CSRF, and that was the point.

Options: ReplyQuote
Re: question
Posted by: ma1
Date: July 01, 2007 05:19AM

Ronald Wrote:
-------------------------------------------------------
> I know that, it is what I just said. But it does
> not matter if I use GET or REQUEST or POST, all of
> them are vulnerable to CSRF, and that was the
> point.

My point was that if you properly mandate GET to read and POST to write (which is a really easy policy to enforce, unless the developer is totally ignorant), meaningful* CSRF attacks are impossible unless you use also JavaScript or some other active technology (e.g. Java or Flash) allowing either response processing (to "steal" data coming from a GET) or POST submission*.

In facts, I was just replying to your statement "[CSRF] actually has nothing to do with Javascript".

On the other hand, as soon as you add JavaScript to the mix, securing a web site against CSRF becomes much, much harder.
Thus looks like JavaScript has actually something to do with CSRF ;)

* meaningful = damaging, silent (no user interaction) and possibly multiple with different parameters. Of course, if I find a hole exploitable with a single POST request I could easily trick user into clicking a <input type="submit" style="opacity: 0; width: 100%; height: 100%, z-index: 1000; position: absolute; top: 0; left: 0" />

--
*hackademix.net*

There's a browser safer than Firefox... Firefox, with NoScript



Edited 1 time(s). Last edit at 07/01/2007 06:06AM by ma1.

Options: ReplyQuote
Re: question
Posted by: Anonymous User
Date: July 01, 2007 11:46AM

Strictly it really has nothing to do with Javascript at all, and I have no reason to doubt. :)

It is not necessary to launch an attack. And because if you say that Javascript is needed to launch a more "meaningful" attack, you raise confusion and throw it to the realm of cross site scripting. Sure, you could use it inside an XSS. But clearly, like I said before you can perfom the above vectors without Javascript, if you persist in thinking this, I can also go a little further and say that HTML injection also is not cross site scripting, and with HTML injection you could launch a Cross site request forgery like the above. And it can also be done with SQL injection.

And like WhiteAcid said: most XSS require CSRF.

Also many attacks also are launched by site owners themselfs, on sites which the users find "trusted". And there is nothing you can do about to protect yourself, you could be making requests to china when you visit the board here, who knows. That's the craziness of CSRF. ^^

Options: ReplyQuote
Re: question
Posted by: ma1
Date: July 01, 2007 01:26PM

Ronald Wrote:
-------------------------------------------------------
> [JavaScript] is not necessary to launch an attack.

It is not necessary to launch some CSRF attacks.

Specifically, it is not necessary to launch attacks to web applications which produce side-effects upon a GET request: a violation of RFC 2616 and, honestly, definitely lame (yes I know, even Google does lame things).

To launch a CSRF attack against a web application implemented with the bare minimum due diligence (i.e. respecting HTTP method semantics as defined above), you need either a further step of social engineering (tricking user into clicking your malicious submit button) or JavaScript to automatically submit your malicious form.

If you need to launch a CSRF on a web application implemented with a very little smartness extra, i.e. where forms modifying application state look like this:
<form method="POST" action="/change_password.do">
<input type="hidden" name="form_key1" value="some_unique_GUID"/>
[...]
<input type="hidden" name="form_key2" value="some_unique_GUID"/>
</form>

, then JavaScript/XSS is your only success chance.

That said, lamers are everywhere and you will find many CSRF vulnerabilities which can be exploited without JavaScript, but as you can see avoiding scriptless CSRF is much easier for junior developers than preventing injections.

>And there is nothing you can do about to protect yourself

As a web developer, I just keep doing what I already do and that's enough.
As an end-user, something is actually in the works :)

--
*hackademix.net*

There's a browser safer than Firefox... Firefox, with NoScript

Options: ReplyQuote
Re: question
Posted by: hackathology
Date: August 18, 2007 07:39PM

Nice back and forth..:)

http://hackathology.blogspot.com

Options: ReplyQuote
Re: question
Posted by: Anonymous User
Date: August 19, 2007 10:44AM

I really get the impression not many understand CSRF, how it works and how it can f*ck up the internet badly. You won't be able to stop CSRF as an end-user, malicious request can be made on your account, that might be the reason most don't talk about it since it breaks everything.

Time to write a good article about it, expect one soon.

Options: ReplyQuote
Re: question
Posted by: Anonymous User
Date: August 19, 2007 04:37PM

Can't wait to read it...

Options: ReplyQuote
Re: question
Posted by: hackathology
Date: August 21, 2007 04:20AM

same here...i wanna read it. Ronald go Ronald go:))

http://hackathology.blogspot.com

Options: ReplyQuote
Re: question
Posted by: rsnake
Date: December 10, 2007 09:21AM

Did you ever finish this, Ronald?

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

Options: ReplyQuote
Re: question
Posted by: Anonymous User
Date: December 10, 2007 11:44AM

Yeah I did wrote about it a couple of times.

http://www.0x000000.com/index.php?i=423
http://www.0x000000.com/index.php?i=382
http://www.0x000000.com/index.php?i=309

Options: ReplyQuote


Sorry, only registered users may post in this forum.