HP Security Products Blog
From applications to infrastructure, enterprises and governments alike face a constant barrage of digital attacks designed to steal data, cripple networks, damage brands, and perform a host of other malicious intents. HP Enterprise Security Products offers products and services that help organizations meet the security demands of a rapidly changing and more dangerous world. HP ESP enables businesses and institutions to take a proactive approach to security that integrates information correlation, deep application analysis and network-level defense mechanisms—unifying the components of a complete security program and reducing risk across your enterprise. In this blog, we will announce the latest offerings from HP ESP, discuss current trends in vulnerability research and technology, reveal new HP ESP security initiatives and promote our upcoming appearances and speaking engagements.

HTML 5 Form Tags a Risk?

I've tried to keep up with new HTML 5 features, but Billy recently pointed out that INPUT tags have the ability to set regular expression patterns for validation directly in the markup. I think this is nifty and, at least in the demo I tried, a very user-friendly and pretty way to inform the user they've put in a bad value. There are also special types for numbers, dates, times, urls, email addresses and more.


 


However, I think there's a significant risk that we'll see many developers implementing the 'pattern' (and possibly field types) in the markup as the only form of input sanitizing for their application. That may seem ridiculous in this day and age--but you know it's not. We still regularly see people relying on client-side filtering via maxlength attributes or in JavaScript.


 


This new restriction, with its fancy-pants regular expression, may well give people a false sense of security when it comes to tainted input. As fresh developers and technologies enter the arena, old problems will be slapped with a coat of paint and sold as new. So, when talking to your clients, developers and friends, remember to reinforce the mantra:


                Never rely on client-side security.


               


What do you think? Will the 'pattern' option and field types help or hinder actual application security?

The CWE/SANS Top 25 Most Dangerous Programming Errors

This week saw the release of the “Top 25 Most Dangerous Programming Errors” list from MITRE and SANS.  At first skim, I nearly discarded it as just an effort to pad resumes—after all, do we really need another “top X” list (every group with a barely pronounceable acronym has their own)? Weighing heavily into that opinion is that of the Top 25, there is some serious overlap that, I think, won’t really help developers.

 

For example, CWE-20 is “Improper Input Validation” and CWE-116 is “Improper Encoding or Escaping of Output.”  If developers fully understand these two and the associated risks of not doing them, they will almost certainly resolve several of the other 25, including:


-          CWE-89: Failure to Preserve SQL Query Structure (aka 'SQL Injection')


-          CWE-79: Failure to Preserve Web Page Structure (aka 'Cross-site Scripting')


-          CWE-78: Failure to Preserve OS Command Structure (aka 'OS Command Injection')


-          CWE-119: Failure to Constrain Operations within the Bounds of a Memory Buffer

 

Isn’t “Failure to Preserve SQL Query Structure” just another way of saying that you didn’t properly filter and encode tainted data? MITRE’s Steve Christey, in discussing the CWE Top 25, says the following about mixed reviews on including both input validation and encoding:

 

Part of it seems to come down to different ways of looking at the same problem. For example, is SQL injection strictly an input validation vulnerability, or output sanitization/validation/encoding or whatever you want to call it? In a database, the name "O'Reilly" may pass your input validation step, but you need to properly quote it before sending messages to the database. And the actual database platform itself has no domain model to "validate" whether the incoming query is consistent with business logic.


I’m not disagreeing with Steve that they should both be included, but rather that they should be included rather than the CWE numbers listed above.  After all, the programming error is not properly filtering and/or encoding tainted data, the resulting vulnerability is SQL injecting, Cross-Site Scripting, etc.

 

One other thing struck me as odd, which is the “Remediation Cost.”  This seems like sheer nonsense—it’s not something a document can define across the board without regard to the underlying application or technology, not to mention the (corporate) environment one has to work in. Is input validation remediation cost really “Low” when you might have to first educate your developers, make sure they understand the context and application logic (to make smart decisions about proper changes), and finally go through testing to ensure nothing is broken as a result? Likely not.

 All that said—and those are things that may be changed in future versions of the list—my opinion has softened to where I’m now in “mixed bag” mode. This is a 1.0 release of a document, and while the authors certainly hope it is perfect, the first release of anything almost definitely isn’t.  

 


The truth is that any effort which gets more security knowledge into the heads of developers is a Good Thing and, hopefully, successful at causing applications to be more secure than they were. Also, any type of release that makes headlines outside of the security industry—where it may trigger a positive reaction in a programmer or developer—is definitely a win for security.  Certainly New York State took notice, now let’s hope their software suppliers do as well.

 

These are just a few issues that came to mind when reading the list. Gary McGraw wrote “Top 11 Reasons Why Top 10 (or Top 25) Lists Don’t Work,” and while I don’t agree with everything he says, there are a few that make reading the list worthwhile.  I’ll point out #8:


 



Automated tools can find bugs — let them. Teaching all developers the 700+ bad things in the Common Weakness Enumeration (or the even larger set of permutations allowed by languages like C++) is a futile exercise. We can start by using static analysis tools to remember all of the potential bugs and alert us to their presence.


I wholeheartedly agree with the second part of this one, and not just because I work for a company that sells automated security tools. With the complexity and sheer volume of code in existence these days, automated tools used throughout the dev lifecycle are a cost effective way to catch these issues.

 

I disagree with Gary that educating developers is a futile exercise—in fact it should be a requirement in every shop and school. Even if the developers are still not great at avoiding the problems in the first place, when the automated tool spits out a list of potential issues, an educated programmer will need to determine if/how/where to make a code change to fix the issue. Improper fixes have lead to dozens of incomplete bug remediations, and in some cases, additional vulnerabilities.

 

Anyway, to summarize (since I rambled on), I think the CWE Top 25 Programming Errors list is a little flawed, but given the attention it has received this week I can only applaud the efforts of MITRE and SANS for drawing more attention to security. After all, we’re all (ok, mostly) working toward the same goal: secure applications.

 

 

Digging into ASP.NET RegEx Validators


RegEx Validators are handy for implementing Whitelist input validation (our DevInspect product has a library of a hundred or so) so it pays to see what they  actually do under the covers. The following code is from the class
System.Web.UI.WebControls.RegularExpressionValidator which implements the RegEx Validator in ASP.NET. I'm looking at version 2.0 of the .NET framework. The EvaluteIsValid() function is what actually determines if an input matches the allowed regex:



protected override bool EvaluateIsValid()
{
string controlValidationValue
= base.GetControlValidationValue(base.ControlToValidate);

if ((controlValidationValue == null)
|| (controlValidationValue.Trim().Length == 0))
{
return true;
}
try
{
Match match = Regex.Match(controlValidationValue,
this.ValidationExpression);
return ((match.Success && (match.Index == 0))
&& (match.Length == controlValidationValue.Length));
}
catch
{
return true;
}
}

Lets look at the first if statement closely. The conditional is a logical OR, so we can treat each part as individual if statements. The code says "if the control value is null, the input passes this validator." The control value can only be null if the control doesn't exist, and chances are you would have had a compile error. Either way, I don't really care about this statement.



The second part of the if statement is interesting. If the trimmed value of the input has no length, the input passes validation. This is a little weird. Trim() removes all leading and trailing whitespace from a string. Things like tab, carriage return, linefeed, etc. The full list is in the .NET String Class documentation. So input consisting of nothing but whitespace passes any ASP.NET RegEx Validator, regardless of the regex. This is counter-intuitive. If I set a RegEx validator to use + whitespace-only input should not get through. More interesting is that characters like vertical tab, CR, LF, and form feed are often interpreted as delimiters, so input with nothing but whitespace could in fact do some weird things in a backend app.


Moving along, we see that the input is matched against the supplied patterned. If a match is found and that match begins with the first character of the input and the length of the matched text is the same as the length of the input, then the input passes the validator. Essentially, this is saying that the entire input must match the regex defined. This is good and bad. Its good because I often see developers define a whitelist and forget to use the the "start position" and "end position" characters (^ and $ respectively). Consider an simplified regex for valid email address +@+\.{3}. (This RegEx excludes valid email addresses and is just to illustrate the point). This RegEx matches email addresses like billy@hp.com. It also matches email address like <script>alert("XSS")</script>billy@hp.com because the regex doesn't force that the entire input must match the regex pattern, but merely some subset of the input matches. The RegEx should be ^+@+\.{3}$ where ^ and $ force the entire input to match.


I often see developers make this mistake and in a way Microsoft is solving the problem by saying "Developers are stupid we will also match the entire string so they don't have to." Ok, I like erring on the side of caution, but this prohibits advanced users from using $ and ^ appropriately. Microsoft completely usurps the developer and removes the choice from their hands. You have to use a CustomValidator class to implement RegExs which utilize just ^ or $. However I can live with this because it undoubtedly saves the Internet for silly mistakes.


A final thing that caught my eye was the try ... catch ... block. If the Regex.Match() call throws an exception, the validator returns true indicting the input is safe. This means in event of an error, the validator fails open instead of failing closed! Deciding when applications/appliances/software/hardware/structures should fail open or fail closed is way beyond the scope of this post and the answer is almost always circumstantial based on the individual situations. Quick, should firewalls fail open or closed? Fail open? Well then an attacker knocks out your firewalls and its open seasons on the FTP servers and Samba shares inside your organization. Fail closed? Thats a nifty DoS you built into your network infrastructure now isn't it? when should input validation fail open or fail closed? Again depend, but my gut tells me it should fail closed more often than it fails open.


Ignoring how it should fail is moot if you can't make it fail. How can we make Regex.Match() throw an exception? Null strings would do it, but a brief glance at the code paths in ASP.NET seems to prevent that from occuring. Invalid RegEx syntax would do it, but you get compile-time problems or an immediate runtime error during the Page_Load event, long perform input is validated. So RegEx Validators in ASP.NET fail open if there is an exception, but I can't seem to get it to exception in an exploitable way to sidestep input validation. Perhaps someone else can take a swing at it :-)

Search
Showing results for 
Search instead for 
Do you mean 
About the Author(s)
Follow Us


HP Blog

HP Software Solutions Blog

Labels
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation