CSRF browser protection

I like the topic of CSRF because it’s such a difficult problem to solve, I was thinking about ways a browser can prevent CSRF and I’ve come up with the following solutions:-

1. After a domain name any image/object/frame etc request is truncated by a user definable setting.

Limiting the amount of data an attacker can use helps provide damage limitation or makes it more difficult for an attacker to inject malicious code. Of course a determined attackers can always find ways around these limitations but making their life more difficult is always good.

2. Any image/object/frame url containing & or ? characters is flagged for user confirmation before the item is loaded.

Normal images/frames rarely need these characters for normal operations and most CSRF attacks do so it makes sense to block/confirm these requests. Some web sites user dynamic images, in this case I would suggest a per domain allow/deny option.

3. Any script generated object that performs a request always requires user authorisation.

Again this is another good defensive measure because forms/iframes etc can be dynamically created and hidden from the user, requiring confirmation can alert the user of something nasty going on.

4. Window name and other named objects/values should be truncated to prevent hidden data being passed across domains.

For the same reason as mentioned item 1, this is another good security measure.

5. All moz binding and CSS expressions require user confirmation before executing.

More often than not this functionality would be used for bad and it makes sense for the user to confirm these requests or deny them completely.

6. Malicious keyword matching

Some web sites use “pretty” urls which allow get parameters to be sent using slashes etc, even worse these sites perform operations through the GET request which normally should be reserved for POST in this case a browser could check that certain keywords aren’t used within the URL for example action=delete in iframes/images/objects.

Of course any of these features could impact on the browsing experience but to provide better security you sometimes have to sacrifice some features. Any other suggestions are welcome or problems with my suggestions.

5 Responses to “CSRF browser protection”

  1. Shahar Evron writes:

    The way I understand it, (C|X)SRF is not a client side issue – it’s a server side issue, hence a real solution is only possible from the server side, and only solvable in the application, and by someone that is well familiar with the desired behavior of the application.

    CSRF, and even POST-based CSRF can be triggered from other sites (and even by fooling the trusted user into visiting the attacker’s site) and not necessarily from the attacked site using an XSS vulnerability.

    I’ve always found using single-request disposable tokens when any form is submitted to be a good solution for CSRF, and it’s also easy to implement.

    In general, I think programmers should be aware of this, just like they should be aware of Session Hijacking attacks – both problems should be solved in the application itself by the programmer and not in the client side.

  2. Gareth Heyes writes:

    Yep I understand this is a server side problem but if the requests don’t reach the server from the user’s browser then the attack cannot be accomplished.

    The browser is acting as a Firewall for the requests in this instance, it isn’t foolproof but it could prevent most CSRF attacks.

  3. .mario writes:

    Just in case someone wants to know: We have gone live with this tool one week ago and no bad surprises yet 🙂



  4. Gareth Heyes writes:

    Cool stuff Mario! The more protection we can have against CSRF the better as far as I’m concerned.

  5. Iehrepus writes:

    heh,’Active Defense’ for browser?
    your idea like me?

    CSRF attacks not only a server side problem,bcz
    the attacks start from clint 🙂