Difference between revisions of ".Net CSRF Guard"

From OWASP
Jump to: navigation, search
(New page: {{Template:Stub}} This page, like the tool, is a work in progress. Questions? Contact Jason Axley (~~~) or use the Talk page. == Problem Overview == A realization that I just had toda...)
 
Line 60: Line 60:
 
* No tight coupling to the application required (but may be useful to support for optimizing performance or integration)
 
* No tight coupling to the application required (but may be useful to support for optimizing performance or integration)
 
* Allow non-security code to be overridden by another implementation (e.g. use your own Logger class, use your own Config file class, support additional response mechanisms, etc.)
 
* Allow non-security code to be overridden by another implementation (e.g. use your own Logger class, use your own Config file class, support additional response mechanisms, etc.)
* Ability to run in a partial trust environment (hat tip to Dinis Cruz)
+
* Ability to run in a [[.Net_Full_Trust|partial trust]] environment (hat tip to [[User:Dinis.cruz]])
 
* Ability to optimize the configuration to just where you most expect to have CSRF vulnerabilities (e.g. avoid work for no security gain)
 
* Ability to optimize the configuration to just where you most expect to have CSRF vulnerabilities (e.g. avoid work for no security gain)
 
* Not just a straight code port from J2EE version
 
* Not just a straight code port from J2EE version
Line 66: Line 66:
 
=== Differences between this and the J2EE version (to be resolved) ===
 
=== Differences between this and the J2EE version (to be resolved) ===
  
 +
<blockquote>
 
TODO
 
TODO
 +
</blockquote>
  
 
== Implementation ==
 
== Implementation ==
  
 +
<blockquote>
 +
TODO
 
Insert UML / Class diags and discussion of design
 
Insert UML / Class diags and discussion of design
 +
</blockquote>
  
 
== Related work ==
 
== Related work ==
  
J2EE CSRF Guard
+
* [[PHP CSRF Guard]]
PHP CSRF Guard
+
* [[CSRF Guard|J2EE CSRF Guard]]
Javascript CSRF
+
* [http://www.thespanner.co.uk/2007/10/19/jsck/ Javascript Cross Site Request Forgery Protection Kit]
OWASP Enterprise Security API
+
* [[ESAPI|OWASP Enterprise Security API]]
  
 
== TODO ==
 
== TODO ==
Line 85: Line 90:
  
 
<!-- categories -->
 
<!-- categories -->
 +
[[Category:OWASP_CSRFGuard_Project]]
 
[[Category:OWASP_Validation_Project]]
 
[[Category:OWASP_Validation_Project]]
 
[[Category:Countermeasure]]
 
[[Category:Countermeasure]]
 
[[Category:OWASP_.NET_Project]]
 
[[Category:OWASP_.NET_Project]]

Revision as of 23:59, 18 November 2007

This article is a stub. You can help OWASP by expanding it or discussing it on its Talk page.


This page, like the tool, is a work in progress. Questions? Contact Jason Axley (Jaxley) or use the Talk page.

Contents

Problem Overview

A realization that I just had today was that it seems that the root cause of CSRF is cookie-based session IDs that get auto-sent by the browser with each request. What CSRFGuard (Java and this .Net version) therefore try to do is to allow one to continue using Cookie-based sessions by layering on top of this yet another session token that isn't sent in a cookie to essentially attempt to authenticate the HTML page contents and links as belonging to a legitimate session.

ASP.Net specific concerns

CSRF can actually be prevented in .Net already -- but you have to be using ViewState. In fact, ViewState prevents many other attacks as a happy coincidence, such as several data input validation attacks for non-text-form fields.

There are problems with relying on ViewState however:

  • Developers can disable ViewState per-page or on an entire ASP.Net application. They can also forget to enable it on a key page. Knowing you have protection becomes a laborious code-and-configuration-review-problem.
  • ViewState can result in hugely bloated page content if it is not cared for properly during development
  • Developers can inadvertently divulge sensitive date in ViewState that may go unnoticed since ViewState is Base64-encoded in the page content

There are also those out there who think that ASP.Net is immune to CSRF already, probably because ViewState is enabled by default so if you try CSRF attacks without knowing this key fact, you may be lulled into a false sense of security (or at least may not appreciate why CSRF doesn't work in a default setup). You can try it yourself easily enough (and I will probably include a demo of ViewState CSRF protection in my sample test web application when the code is released).

Try to submit a CSRF form post to a page with ViewState enabled. Notice that it does not work. Now, edit the Web.config and add:

<pages enableViewState="false" />

Threat Model

TODO

How it works

Incoming Requests: Protection

The module hooks the YYYYYY event and calls on the CSRFGuard object to check the contents of the request for whether to even bother validating the request or not. There are several cases (many configurable) where it makes sense to skip the request (meaning that it doesn't represent a CSRF attack risk)

  • case 1
  • case 2
  • case n

If it determines that the request needs checking, then it compares the passed CSRFGuard Session Token to the one stored in the user's ASP.Net session. If they do not match, or if the token is not present, then we've got a CSRF attempt.

When a CSRF attempt is detected, the Module then decides what to do about it, based in large part to the configuration. There are likely to be many, many possible cases so an attempt will be made to design high-level generic mechanisms that can support various use cases.

Outgoing Responses: Page Rewriting

The module also hooks the ZZZZZZ event and provides a custom Request Filter that interrogates the outgoing HTML so that we can inject our CSRFGuard Session Token

Implementation Approach

This project takes an analagous approach to the J2EE CSRF Guard J2EE Filter in the ASP.Net world: an ASP.Net HTTP Module / Filter.

Design Goals

  • Threat-modeled design and implementation
  • Fully test-driven (will be using nunit2)
    • And very high code coverage for unit tests (using ncover)
  • Automated build (will be using nant)
  • Highly configurable
    • Allow for flexibility to support all different kinds of applications.
  • Highly modular code
    • Bulk of the decision-making is done automagically in objects who can then be interrogated for access decisions
    • Small classes and methods for clarity and avoiding overly-complex code.
    • Ease potential rolling multiple utilities like this into a single uber-HTTP-Module framework later (need to check out status of the mod_security port to .Net)
  • No tight coupling to the application required (but may be useful to support for optimizing performance or integration)
  • Allow non-security code to be overridden by another implementation (e.g. use your own Logger class, use your own Config file class, support additional response mechanisms, etc.)
  • Ability to run in a partial trust environment (hat tip to User:Dinis.cruz)
  • Ability to optimize the configuration to just where you most expect to have CSRF vulnerabilities (e.g. avoid work for no security gain)
  • Not just a straight code port from J2EE version

Differences between this and the J2EE version (to be resolved)

TODO

Implementation

TODO Insert UML / Class diags and discussion of design

Related work

TODO

  • Finish this wiki page
  • Investigate threats of bad applications that leak ASP.Net session info from HTTPS to HTTP. This module right now is implicitly assuming that the session is trustworthy which it would be nice if we could have some programmatic basis for believing this.