views:

182

answers:

1

So I have an interesting problem... I'm required to get my webapp to pass through an IBM app scanning appliance before I can push my changes to production. My latest changes include the AntiForgeryToken in ASP.NET MVC. Every browser I've tested this on works just fine, no issues. But when the appliance tries to submit the form, it gets a validation error. Looking at the verification token, the appliance is doing an html encode on the form value on the post, so the strings don't match up... this is what they look like:

cmiuJRHizXLPvlu9zHKmTwdJiHvq+n87CSJZkixkf/BLHayCPVITJhRCsWWirPWg - pulled from the cookie cmiuJRHizXLPvlu9zHKmTwdJiHvq%2Bn87CSJZkixkf%2FBLHayCPVITJhRCsWWirPWg - form value

So it's translating + to %2B and / to %2F... has anyone seen this before? Is this an issue for client browsers? And is there have AntiForgeryToken generate a string that has no special characters so I can get my app through this scan? Thanks!

+1  A: 

Looking at the MVC code it appears that its using the RNGCryptoServiceProvider to create the token. Interestingly they have a method which replaces characters that are unsafe for cookie names (basically the "+" and "/" as you indicated in your question) but it is marked as private and I don't see where it gets used.

Unfortunately you cannot derive your own class from AntiForgeryData class because it is sealed. This is very sad because it was the obvious solution to your question.

You could possibly create a new attribute based on the MVC code and utilize the safety method yourself. It will violate DRY but I dont see a way around that since Microsoft sealed the class.

Sailing Judo
Microsoft sealed a great number of classes in the MVC framework that probably should not have been. I always found that to be rather odd.
Nathan Taylor
I'm tempted to just leave it... I haven't had an actual browser have issues with this yet, my guess is the ibm appliance is doing something goofy that's non-standard.
Arthurdent510