Software and web application security

April 23, 2007

I18N input validation whitelist filter with System.Globalization and GetUnicodeCategory

Filed under: software security — chrisweber @ 10:48 pm

Maybe you’re building internationalized code and wondering how to build a whitelist filter that will support all the different character sets your planning to support. If you support more than ten, especially some of the larger east Asian sets, this might seem like an unwieldy or tricky process.
Well luckily it’s easier than most people would think. Building a good input validation filter can be simplified with .Net’s GetUnicodeCategory. But use the method from the System.Globalization namespace as the other one in System.Char looks like it may become the subordinate.

With GetUnicodeCategory you can simply build a whitelist supporting the character categories you want to allow. So get away from thinking you have to write a regEx filter and list out all the character ranges you want to allow in each character set, it’s much simpler than that!

The Unicode standard assigns ever character to one of about 31 categories. They make sense too, for example Other Control charactes (Cc) , Lowercase Letter (Ll), Uppercase Letter (Lu), Math Symbol (Sm). So for example you might want to only allow letters, numbers, and punctuation in your whitelist. This could be achieved with the following snippet:


char cUntrustedInput; // the untrusted user-input
UnicodeCategory cInputTest = CharUnicodeInfo.GetUnicodeCategory(cUntrustedInput);
if (cTestCategory == UnicodeCategory.LowercaseLetter ||
cTestCategory == UnicodeCategory.UppercaseLetter ||
cTestCategory == UnicodeCategory.DecimalDigitNumber ||
cTestCategory == UnicodeCategory.TitlecaseLetter ||
cTestCategory == UnicodeCategory.OtherLetter ||
cTestCategory == UnicodeCategory.NonSpacingMark ||
cTestCategory == UnicodeCategory.DashPunctuation ||
cTestCategory == UnicodeCategory.ConnectorPunctuation)
{
// character looks safe, continue
}
else
{
// character is not allowed, fail
}

Not too bad eh.

Advertisements

April 4, 2007

Fortify JavaScript Hijacking Vulnerability Detected

Filed under: web, web apps — chrisweber @ 2:47 pm

Rather scary issue regarding evil.com’s ability to rewrite javascript constructs such as the fundamental Object.  This means that evil.com can change the AJAX/JSON behavior of scripts run through good.com.

http://www.fortifysoftware.com/advisory.jsp

ScottGu from Microsoft responds as to why ASP.NET AJAX is not so vulnerable to this issue.  Doesn’t look like the best solution (basically the server requires an HTTP header Content-Type: application/json or it ignores the request).

http://weblogs.asp.net/scottgu/archive/2007/04/04/json-hijacking-and-how-asp-net-ajax-1-0-mitigates-these-attacks.aspx

Hardening Stack-based Buffer Overrun Detection in VC++ 2005 SP1

Filed under: general — chrisweber @ 9:33 am

The recent Windows .Ani file stack overflow has a lot of people asking the same question.  How did Microsoft’s SDL process miss or punt this bug?  Why did the compiler’s /GS not protect the function?

Michael Howard gives explanation as to why /GS did not protect this type of function, and how it can actually be made to.

http://blogs.msdn.com/michael_howard/archive/2007/04/03/hardening-stack-based-buffer-overrun-detection-in-vc-2005-sp1.aspx

Blog at WordPress.com.