jquery-ujs icon indicating copy to clipboard operation
jquery-ujs copied to clipboard

data-method whitelist to block adding CSRF

Open bwillis opened this issue 10 years ago • 8 comments
trafficstars

If an attacker has the ability to create link tags and attributes they have the ability to intercept the CSRF token, even if CSP is enabled. By setting the href to another site and adding data-method='post' the CSRF token will automatically be added to the request and sent to an attackers site. It is important to note that this is only applicable to handleMethod (data-method) call as when done through handleRemote (data-remote) the CSP will block the request to the attackers domain.

This fix adds a configurable whitelist of hrefs to verify the link against before adding the CSRF token. The default is to allow everything to avoid break existing clients.

bwillis avatar Feb 16 '15 19:02 bwillis

Should we be checking for the raw href here, or might there be a way to check for the domain of the href?

RSO avatar Feb 16 '15 21:02 RSO

@RSO that's a good point, maybe we can make it user friendly whitelisting domains instead of hrefs, I'll try this out and update the diff.

bwillis avatar Feb 16 '15 22:02 bwillis

:+1:

RSO avatar Feb 16 '15 23:02 RSO

We got external feedback from a security researcher, the way action, name and value attributes are being set can also be used for unsafe injection. I'll be updating the PR accordingly.

bwillis avatar Feb 18 '15 02:02 bwillis

@bwillis Just to clarify (and unless I'm misunderstanding), this potential exploit only works if the application developer is allowing their users to submit raw HTML links with arbitrary attributes and passing it directly through to other users without doing any sort of escaping or sanitization, right? As in, you'd have to be calling html_safe on the arbitrary user input in order for their data-method attribute to actually make it through to other users (or have some sort of custom sanitization that allows the attribute to pass through unescaped).

JangoSteve avatar Feb 18 '15 03:02 JangoSteve

@JangoSteve You're right. The reason we spend time on actually fixing this was because of a recent XSS that was discovered in our markdown parsing (https://hackerone.com/reports/46072). Without the fix in this pull request every XSS in our markdown parser would be turned into a full-blown CSRF (through CSP bypass).

Do you have any hesitations that makes you doubt landing this fix?

RSO avatar Feb 18 '15 05:02 RSO

@RSO Not at all. Just wanted to make sure I had a good understanding of the issue and sense of the severity.

JangoSteve avatar Feb 18 '15 06:02 JangoSteve

Cool!

RSO avatar Feb 18 '15 19:02 RSO