At FundApps we run a regular SkipFish scan against our application as one of our tools for monitoring for security vulnerabilities. In order for it to test beyond our login page, we need to provide a valid .ASPXAUTH cookie (you’ve renamed it, right?) to the tool.
Because we want to prevent Cross-site request forgeries to our login pages, we’re using the AntiForgeryToken support in MVC. This means we can’t just post our credentials to the login url and fetch the cookie that is returned. So here’s the script we use to fetch a valid authentication cookie before we call SkipFish with its command line arguments:
I hit this issue a while back, and someone else just tripped up on it so thought it was worth posting here. If you’ve got loginUrl in your Forms Authentication configuration in web.config set, but your ASP.NET Forms or MVC app has suddenly started redirecting to ~/Account/Login for no apparent reason, then the new simpleMembership(ish) provider is getting in the way. This seems to happen after updating the MVC version, or installing .NET 4.5.1 at the moment.
Try adding the following to your appSettings in the web.config file:
<add key="enableSimpleMembership" value="false"/>
which resolved the issue for me. Still trying to figure out with Microsoft why this is an issue.
We recently re-designed Developer Fusion and as part of that we needed to ensure that any external links were not broken in the process. In order to monitor this, we used the awesome LogParser tool. All you need to do is open up a command prompt, navigate to the directory with your web site’s log files in, and run a query like this:
"c:\program files (x86)\log parser 2.2\logparser" "SELECT top 500 cs-uri-stem,COUNT(*) as Computed FROM u_ex*.log WHERE sc-status=404 GROUP BY cs-uri-stem order by COUNT(*) as Computed desc" -rtp:-1 > topMissingUrls.txt
And you’ve got a text file with the top 500 requested URLs that are returning 404. Simple!
If you’re thinking of upgrading to MVC 2.0, and you take advantage of the AntiForgeryToken support then be careful – you can easily kick out all active visitors after the upgrade until they restart their browser. Why’s this?
For the anti forgery validation to take place, ASP.NET MVC uses a session cookie called “__RequestVerificationToken_Lw__”.
This gets checked for and de-serialized on any page where there is an AntiForgeryToken() call. However, the format of this validation cookie has apparently changed between MVC 1.0 and MVC 2.0.
What this means is that when you make to switch on your production server to MVC 2.0, suddenly all your visitors session cookies are invalid, resulting in calls to AntiForgeryToken() throwing exceptions (even on a standard GET request) when de-serializing it:
[InvalidCastException: Unable to cast object of type 'System.Web.UI.Triplet' to type 'System.Object'.]
System.Web.Mvc.AntiForgeryDataSerializer.Deserialize(String serializedToken) +104
[HttpAntiForgeryException (0x80004005): A required anti-forgery token was not supplied or was invalid.]
System.Web.Mvc.AntiForgeryDataSerializer.Deserialize(String serializedToken) +368
System.Web.Mvc.HtmlHelper.GetAntiForgeryTokenAndSetCookie(String salt, String domain, String path) +209
System.Web.Mvc.HtmlHelper.AntiForgeryToken(String salt, String domain, String path) +16
So you’ve just kicked all your active users out of your site with exceptions until they think to restart their browser (to clear the session cookies).
The only work around for now is to either write some code that wipes this cookie – or disable use of AntiForgeryToken() in your MVC 2.0 site until you’re confident all session cookies will have expired. That in itself isn’t very straightforward, given how frequently people tend to hibernate/standby their machines – the session cookie will only clear once the browser has been shut down and re-opened.
Hope this helps someone out there!
Visual Studio 2010 includes much improved deployment tools – but by default it only includes files “needed to run this application”. If you’re using the Spark view engine for ASP.NET MVC, then the Spark views aren’t considered one of them!
The trick is to ensure your .spark views have a build action of “Content” instead of the default “None”. Clearly remembering this each time would get somewhat tedious, so instead you can add the following registry entries:
Windows Registry Editor Version 5.00
(just add this to a .reg file and run it)