Rule suggestions

Coordinator
Dec 21, 2010 at 5:06 AM

Which rules would you like to see added?

Aug 5, 2011 at 4:28 PM

Hi Sacha,

I'm trying out the new rules and notice that through Visual Studio 2010 Premium SP1, the new rulesets are only inside the Microsoft All Rules set found at C:\Program Files (x86)\Microsoft Visual Studio 10.0\Team Tools\Static Analysis Tools\Rule Sets\AllRules.ruleset.

However, some of the rules are not defined, in particular the one for CSRF that I was really wanting to try out. The rules you mentioned on the Home page of this site say that:

EnableViewStateShouldBeTrue
Verifies if the EnableViewState directive is not set to false on a certain page.

ViewStateUserKeyShouldBeUsed
Verifies if the Page.ViewStateUserKey is being used in the application to prevent CSRF.

They are supposed to be in the ruleset, but I can't find them. I opened up the ruleset definition from Visual Studio 2010 Premium and in the list of rules under ASP.NET.Security there are only 4 items:

CA5327, CA5328, CA5329, CA5330

In ASP.NET.MVC.Security (which doesn't apply in my case as my project is a WebForm Web Application (not a WebSite)) there are 2 rules: CA5332 and CA5333

In the ASP.NET.Security.Configuration set there are 20 rules numbered sequentially from CA5400 to CA5419.

I don't know how many more rules are missing, but the 2 mentioned above are certainly not here. I also tried a search on the keyword "viewstate" and didn't find them either.

Please let me know what happened to those rules and why they don't show up.

Thanks!

Andre

Aug 8, 2012 at 10:44 AM

These rules are a really great start.

1.  I would like to validate the encryption method and keysize used in the machinekey, it's great ensuring viewstate and cookies are encrypted but if it's using SHA with a 56bit key then it's pretty trivial to decrypt.

2. Slightly trickier one but I would like to ensure that session.abandon is used when a logout is invoked, often I find apps just remove cookies but do not end the session on the server.

3. To prevent session fixation, logging in should generate a new session key rather use the one provided to the anonymous user.  A check for that kind of event would be great, again trickier to automatically check for.