[OWASP.NET] [Owasp-dotnet] is the .Net CSRF Guard production ready ?

[Russell Wilson]

Hi all

I would like some advice on reducing the scope of CSRF in an asp.net application, specifically I would like to know if others are using the .Net CSRF Guard http://www.owasp.org/index.php/.Net_CSRF_Guard in production environments? or if it is not yet ready ?

Regards

- Russ

[Jason Axley]

I wrote it and last I left it, it was close but I would not say it is production ready.  I had intended to perform a full threat model on the mechanism behind it but have not done so.  I'm going to be looking at the Microsoft ASP.Net MVC model as well and will be doing at least a cursory threat model on that mechanism for comparison.  I'm also wondering if there is a way to use the same mechanism with forms-based applications.  CSRF guard is plugin-based so it may even be feasible to implement a plugin that used the same API on the backend...  The MVC token model uses a cookie to store the token as well as hidden form fields, but it only works for POST.  If you have any non-idempotent GETs in your application, you're out of luck.  That was something I didn't assume in the design of CSRF guard.

One issue with larger sites with CSRF guard is that it has a dependency on asp.net session state, so if you have a farm of webservers for your application and you don't have sticky sessions, you're going to have a lot of things break if users are redirected to another server that does not have the server-side session state data for the user to look up the token.  So, it requires a centralized SQL session store or similar mechanism if you are not using sticky sessions.

Since I had my daughter and with the failure of my former employer Wamu it's been a bit tumultuous of a year so I haven't been able to get back to this.  But I would like to reinvigorate it if there is not a better alternative out there for asp.net CSRF protection.

I've also learned a thing or two since the implementation of CSRF guard, and don't think it needs to maintain ASP.net 1.1 compatibility anymore either so the code can probably use a good cleanup here and there.

-Jason

_______________________________________________
Owasp-dotnet mailing list
Owasp-...@lists.owasp.org
https://lists.owasp.org/mailman/listinfo/owasp-dotnet
  

[Mark Curphey]

I don’t know if Barry is on this list but the new WPL has CSRF protection and is OSS via an MS-PL license (OSI approved)

 

http://blogs.msdn.com/securitytools/archive/2010/03/24/the-web-protection-library-plans-and-processes.aspx

[Barry Dorrans]

He is, but under his home address. The WPL has *plans* for it, but there’s nothing there as yet, I’ve got a shed load of internal bugs to fix now I’ve opened up a plug-in model (which will get pushed to the source tree on codeplex in a few weeks as soon as I can figure out what processes I need to put in place for that).

 

As you’re all aware GET tokens are somewhat contentious, as is trying to parse the output of a request to look for links to mangle. My plan is to take the approach from AntiCSRF (http://anticsrfcodeplex.com/) as a starting point when we do start to implement, which uses cookies rather than session, but I’m still in two minds about GETs, plus we’ll only ever protect anything in a webforms runat server form. I simply don’t want to get into regular expressions over binary streams. Non-idempotent GETS? I’m tempted to say you get what you deserve here -however someone I know well who works for a rather large bank has asked if I can look at it.

 

Other fun questions include what happens in protocol transition, although this isn’t limited to GET requests of course J

 

Actually it would be interesting to get feedback on the plug-in approach. Basically I’m trying to get the Security Runtime Engine from the WPL as just a holding and reporting harness on which you can write your own plug-ins, avoiding the strain of having multiple HttpModules and opt-out mechanisms.

 

I blogged about the potential approach http://idunno.org/archive/2010/05/03/further-work-on-wpl-plugins.aspx - the configuration bit has changed a little to make it more testable, and of course it may all change once I’ve gathered the feedback. If you have any then emails here, or blog comments, or to me directly, either at home, or at ms (bdorrans@) will all be taken into account.

 

Barry

[Jason Axley]

Thanks for the pointer.  BTW, the software is on the MS connect site that you have to register to download.  https://connect.microsoft.com/site734

Aside from making the software open source, is anyone documenting the mechanisms it will use or does use for encoding, CSRF, etc. for evaluation?  One of my pet peeves in the security community is when people jump to writing tools to solve problems but don't start by sharing the design so people can evaluate it or reimplement it. 

It looks like CSRF protection is not yet available in the 1.0 CTP from 11/10/2009 though.  Would love to collaborate about the planned CSRF protection mechansim(s) supported by WPL and whether CSRF guard code could find a home there or at least the design and features that have been thought through.  It also keeps parity somewhat with the features in the OWASP java CSRF guard that was the original inspiration for the project at an OWASP conference at eBay many moons ago.

-Jason

[Barry Dorrans]

Its open source already, it’s just the source tree has only ever been updated with a full release. I’ll look at how I update connect and make that download vanish, it’s very out of date.

 

This month’s planned CTP code only drop, which will appear on http://antixss.codeplex.com/ (which I ought to rename at some point) will not have CSRF protection – it’s there to show the new model and gather feedback, along with a few simple plugins and a rewrite of the existing Encoding and Sql Injection bits. It needs a lot more tests before I’m happy to even label it beta. And as a bunch of you are no-doubt aware testing ASP.NET is not the easiest thing in the world – although you will see I took a dependency on .NET 3.51 SP1 so I can use System.Web.Abstractions in order to make unit testing possible.

 

Basically ignore what’s on codeplex and connect right now, because I rewrote the SRE part and exposed points with which you can write your own plugins (hence the blog post). This will appear as a zip, and an update to the source tree in a few weeks’ time. I’ve only been at MS for a few months, so I’m discovering the processes for this as I go along *grin*

[testacct tan]

Is there a CSRF Guard for ASP.NET Web Application(Not MVC)?