Tell me more ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.
up vote 0 down vote favorite

I was reading up on OWASP's page on CSRF and in their example they use a request where the sensitive parameters are stored in the query string:

http://bank.com/transfer.do?acct=MARIA&amount=100000

On my site I make a request where nothing sensitive is stored in the query string:

http://mysite.com/accounts/delete

But if you look at the raw request you can see the sensitive information:

POST /ajax/deletion/account HTTP/1.1
Host: www.mysite.com
Connection: keep-alive
Content-Length: 15
Accept: application/json, text/javascript, */*; q=0.01
X-Requested-With: XMLHttpRequest
Content-Type: application/json; charset=UTF-8
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Cookie: X-Mapping-fjhppofk=B8BFE26CD0B3A37348ECC6FFE3948274; connect.sid=s%3A4t4wfMTR6kCPRfwe5OEmYbse.Y%2FOfSmt%2Bo5JWDWglvUHIufOOFvfebr86CLiUcgdW6j8; 

{"account_id":35653}

What I'm wondering is if I am safe from CSRF attacks since I do not include any parameters in my query string? If I'm not safe from CSRF, how would a malicious user submit a forged request?

share|improve this question

3 Answers

up vote 3 down vote accepted

CSRF does not require query parameters.

In that same article you linked, under the section: "Prevention measures that do NOT work":

Only accepting POST requests
Applications can be developed to only accept POST requests for the execution of business logic. The misconception is that since the attacker cannot construct a malicious link, a CSRF attack cannot be executed. Unfortunately, this logic is incorrect. There are numerous methods in which an attacker can trick a victim into submitting a forged POST request, such as a simple form hosted in attacker's website with hidden values. This form can be triggered automatically by JavaScript or can be triggered by the victim who thinks form will do something else.

Basically, since with CSRF you can't make any assumptions about the originating site, it might be the attacker's own site - he might simply have a regular HTML form on his site, that submits to your bank's website. When you are viewing the attacker's site, the CSRF form gets submitted to the bank... launching the attack.
No query string necessary.

share|improve this answer
up vote 1 down vote

POST requests can indeed be forged cross-domain, however it depends on the kind of data you're trying to POST.

It looks something like this: http://haacked.com/archive/2009/04/02/anatomy-of-csrf-attack.aspx

<form name="badform" method="post"
 action="http://bank.com/money_transfer">
    <input type="hidden" name="destinationAccountId" value="2" />
    <input type="hidden" name="amount" value="1000" />
</form>
<script type="text/javascript">
    document.badform.submit();
</script>

If an attacker creates an HTML page with this in it, and lures a victim (with Javascript enabled) to that page, then that POST request will be sent and the transfer will be executed if the client is currently logged into bank.com and if they're not using CSRF tokens.

However, in your specific example, it is JSON data that is being POSTed, not traditional HTTP parameter POSTing.

For that, you could use one of the following techniques: http://blog.opensecurityresearch.com/2012/02/json-csrf-with-parameter-padding.html

As @Patrick says, though, you will not be able to impersonate the content type. So if the server is checking that the POST has a content type of application/json and only allowing it in such cases, and/or if the X-Requested-With: XMLHttpRequest header is checked, then it won't be possible. But if they are not checked, then it's not hard to do.

So short answer: in many cases, yes it is possible even if there is no query string, and CSRF tokens should always be used regardless of the form's HTTP method or the kind of data being sent.

share|improve this answer
 
Interesting. Would it be possible to craft a request using jQuery's post or something similar that included the JSON? –  Abe Miessler Aug 21 at 17:54
 
@AbeMiessler No, due to something called the Same-Origin Policy. You can only use jQuery's $.ajax or $.post (or any Ajax/XMLHttpRequest) from the same domain that you are sending the POST to. This is what prevents arbitrary sites from, say, scraping your Gmail username after you visit them; such things are only possible if the site has an XSS flaw (XSS lets you break the Same-Origin Policy, which is why it is dangerous). More details here: en.wikipedia.org/wiki/Same-origin_policy –  Anorov Aug 21 at 17:57
 
Ok, so you are saying that if the site was vulnerable to XSS I could use that to inject the javascript necessary to craft a request that submitted JSON, correct? –  Abe Miessler Aug 21 at 18:10
2  
You can easily post JSON data cross-site, you just can't set the content type. Your site would need to reject posts that don't have a content-type of 'application/json' to avoid the CSRF in this situation. –  Patrick Aug 21 at 18:13
 
@Patrick Yep, excuse me, I was quite wrong. I've revised my answer. –  Anorov Aug 21 at 18:19
up vote 0 down vote

CSRF is about making the victim's browser send a request to a server, such that the server will somehow "act" on the request, on virtue of it coming from the victim's browser specifically. In many sites, the victim's browser will send a cookie value that was previously sent by the site, and this cookie value incarnates the authentication. In brief, the target sites believes the request to come from the victim (and, technically, it does) and to represent the actual will of the said victim user (and that one is completely wrong).

It is this cookie value which prevents the attacker from doing the request himself; since the cookie is stored in the victim's browser, the request must be sent from the victim's browser, hence the CSRF.

The request contents entirely depend upon the way the target site is designed, and what the attacker tries to achieve. In the OWASP example, the request is for some bank site and the request parameters encode a money transfer, but that's merely illustrative. It is conceivable that a specific site may accept requests which do not include a '?' character and still have some effect that is beneficial to the attacker, in particular if the attacker's goal is disruption (e.g. a "delete my account" link: no parameter, but still a non-negligible effect).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.