Validation of the Validators

Microsoft .net framework has rich libraries for validation aka .net validators which provides both client side and server side validation in a neat fasion. However, there are some serious security pitfalls. There are built in validators for known problems (e.g. required paramters, regex, ..etc) Also, the developer can create a custom validator which gives more power over the validation process, yet more complication.

This is a good article talking about various aspects of .net validation. Built in validators performs client side validation to enhace user experience and server side validation for security purposes. In custome validators, you have to write your own validation code for both server side and client side.

Although .net validators are very useful to increase the overall security posture of applications, the real problem is that developers take them for granted! Unfortunately, validators are not called all of the time. There are certain scenarios where the validation event is not raised.

For example, when calling Server.Transfere(), the destination page does not raise the validation event, hence, one can bypass validation all along in the second page. Also, validation is caused only when the validated control has the property "CausesValidation" set to true which is not the default value for all controls. Another issue rises if you consider custom controls which may be developed by "not very security aware" developers who forgot to set the valdiation flag.

Another fatal misconception is the timing for the validation event firing. The validation event is fired AFTER page_load event, so any logic in page_load is done prior to any validation. To force the validation event, "IsValid()" function has to be called on the concerned object before using it.

Bottom line, .net validators are very useful, but developers should not take them for granted. Validation events has to be manually checked to be functioning in all pages and manually triggered when needed .

Update 0x01: In addition to not being called all the time, .net validators filters are not perfect and can be evaded. Check this excellent paper on reverse engineering .net filters.

Update 0x02: In a discussion on a reputable application security list, it was suggested to add traps on server side validators to detect client side validation was bypassed; Hence a probable hacking attempt.

Bookmarklet Exploitation

A lot of websites now provide a Bookmark button which does actions directly. For example share onfacebook bookmarklet, read it later boomkarklet & share in google reader bookmarklet. This feature is very handy because you just visit any website, click on the bookmark and something get posted on your account!

Technical speaking, what happens is:
Assume that there's a bookmarklet button B which when clicked, the current page link is saved on my account for mylistOfURLs.com

1. User visits page x
   
2. User Presses B
3. What actually B contains is a javascript that will run as if the javascript was written in the location bar.
4. The javascript code under the B button actually sends the current location to mylistOfURLs.com to be saved there.
   

Am I the only paraniod person here? I see a major security threat. Isn't this just like a universal cross site scripting vulnerability? What if I can manage to change the code of the bookmark button to post the cookie to my website before posting the location to mylistOfURLs.com! Even better, what if I can lure the victim into adding my button which if clicked, all the info of the active page is sent to me. It's terrifying!

Also, there are privacy issues here. If mylistofURLs.com is not very trusted website, I might be afraid to click on their bookmarklet. What if they steal my cookie (conspiracy theory)? What if they steal my referer (for AD purposes)?

Anyway, My suggestion is: Never click on a bookmarklet on a page that has your personal information or that you're logged in to.