Version 1 of WASSEC (Web Application Security Scanner Evaluation Criteria) is (finally) out! I'm not going to say which section I wrote, but the document is (as far as I know) the first attempt to comprehensively list the features that should be considered when evaluating appsec scanning tools. Check it out. It's worth a read.
The WASSEC document be found here in both wiki and PDF formats:
http://projects.webappsec.org/Web-Application-Security-Scanner-Evaluation-Criteria
ColdFusion and the Practice of Explicit Variable Definitions
There are well-known coding practices about defining and using variable scopes carefully and explicitly. While this is always an important principle for developers to understand and apply, this is even more important when coding in frameworks that do not definitively separate usable variable scopes. In recent application assessments conducted by our team at Security PS, we have encountered several instances where this simple practice would have avoided some serious vulnerabilities.
In the recent cases we encountered, the code was written in Adobe ColdFusion. Adobe ColdFusion has a feature that will search a list of variable scopes at runtime when the code refers to a variable that has not been explicitly defined. Since the language itself also doesn't require you to initialize variables before using them, this can result in confusion about which variable is actually used. In some cases, this can allow users to inject variables into scopes that ColdFusion will search and be evaluated within the program logic, which was the case in the recent assessments.
So let's provide a bit more explanation. When ColdFusion application code references a variable that has not been defined, ColdFusion will first search several different variable scopes for a variable of that name. These scopes are searched in the following order.
So far, that's just a hard-to-track-down bug. It becomes a security problem because ColdFusion includes user-controlled scopes in the search. Here's an example. Consider the following code:
This simplified code snippet is supposed to check whether a username and password exists in the database before setting a variable called "authenticated" to "yes". Later on, it checks whether the variable is set before allowing the user to continue. This type of construction, while not best practice coding, is fairly common in languages like PHP (where it doesn't cause a security flaw). However, given the interworkings of ColdFusion as described above, this code would enable an attacker to simply send a request such as http://somesite.com/login.cfm?authenticated=yes and modify the outcome of logic. Because the "authenticated" variable was never initialized in the Variables scope, ColdFusion would search until it reached the URL scope, it would find a variable by that name, and return the value "yes". Thus, an attacker could be accepted as authenticated without a username or password.
The following code example shows one of the ways that this problem could be avoided.
By ensuring that variables are properly initialized before they are used, developers can prevent ColdFusion from searching different variable scopes for the value.
Thus far, the example has been relatively simple. A malicious user can leverage the automatic search behavior to substitute a value for a variable which has not been properly defined. This gets more interesting when scopes are added to the equation. For instance, assume a developer is requesting the fully qualified variable“Application.bob” which has not first been declared in the code. As expected, ColdFusion will search the “Application” scope for a variable named “bob”. Since “bob” was not found in the “Application” scope, ColdFusion will treat the scope portion as part of the variable name and search for “Application.bob” in the various scopes. Imagine a malicious user adding “application.bob” in the URL or the page request. As “URL” is one of the scopes ColdFusion searches for undefined variables, the application will utilize the user defined “URL.Application.bob” in place of the programmer requested “Application.bob”. The end result is both fully scoped and non scoped variables can be affected when not first properly initialized.
As a closing comment, it’s interesting that the above construct works fine in a language such as PHP without serious consequence. However, since ColdFusion searches through scopes for variables, this allows ambiguity that can lead to security (and functional) bugs. If ColdFusion did not search for variables, or allowed us to turn off this auto-search functionality, then this kind of mistake would not be an issue. Since this functionality can’t be disabled, coders need to be aware of this difference in ColdFusion and should diligently hold to the practice of using explicitly defined variables and scopes to keep the code secure.
Each framework has different sets of functionality and quirks that developers should understand to avoid security (or functional) pitfalls. In future posts, we’ll point out other gotcha’s that we encounter in assessments and code reviews.
In the recent cases we encountered, the code was written in Adobe ColdFusion. Adobe ColdFusion has a feature that will search a list of variable scopes at runtime when the code refers to a variable that has not been explicitly defined. Since the language itself also doesn't require you to initialize variables before using them, this can result in confusion about which variable is actually used. In some cases, this can allow users to inject variables into scopes that ColdFusion will search and be evaluated within the program logic, which was the case in the recent assessments.
So let's provide a bit more explanation. When ColdFusion application code references a variable that has not been defined, ColdFusion will first search several different variable scopes for a variable of that name. These scopes are searched in the following order.
- Arguments
- Variables
- CGI
- URL
- Form
- Cookie
- Client
So far, that's just a hard-to-track-down bug. It becomes a security problem because ColdFusion includes user-controlled scopes in the search. Here's an example. Consider the following code:
<l!---check authorization --->
<cfif IsDefined(“form.Username”) AND IsDefined(“form.Password”)>
<!---perform authorization checks against database--->
<cfset authenticated=”yes”>
</cfif>
<!---perform site logic if user is authenticated --->
<cfif authenticated is ”yes”>
. . .
<cfif IsDefined(“form.Username”) AND IsDefined(“form.Password”)>
<!---perform authorization checks against database--->
<cfset authenticated=”yes”>
</cfif>
<!---perform site logic if user is authenticated --->
<cfif authenticated is ”yes”>
. . .
This simplified code snippet is supposed to check whether a username and password exists in the database before setting a variable called "authenticated" to "yes". Later on, it checks whether the variable is set before allowing the user to continue. This type of construction, while not best practice coding, is fairly common in languages like PHP (where it doesn't cause a security flaw). However, given the interworkings of ColdFusion as described above, this code would enable an attacker to simply send a request such as http://somesite.com/login.cfm?authenticated=yes and modify the outcome of logic. Because the "authenticated" variable was never initialized in the Variables scope, ColdFusion would search until it reached the URL scope, it would find a variable by that name, and return the value "yes". Thus, an attacker could be accepted as authenticated without a username or password.
The following code example shows one of the ways that this problem could be avoided.
<cfset authenticated=”no”>
<!---check authorization --->
<cfif IsDefined(“form.Username”) AND IsDefined(“form.Password”)>
<!---perform authorization checks against database--->
<cfset authenticated=”yes”>
</cfif>
<!---perform site logic if user is authenticated --->
<cfif authenticated is ”yes”>
. . .
<!---check authorization --->
<cfif IsDefined(“form.Username”) AND IsDefined(“form.Password”)>
<!---perform authorization checks against database--->
<cfset authenticated=”yes”>
</cfif>
<!---perform site logic if user is authenticated --->
<cfif authenticated is ”yes”>
. . .
By ensuring that variables are properly initialized before they are used, developers can prevent ColdFusion from searching different variable scopes for the value.
Thus far, the example has been relatively simple. A malicious user can leverage the automatic search behavior to substitute a value for a variable which has not been properly defined. This gets more interesting when scopes are added to the equation. For instance, assume a developer is requesting the fully qualified variable“Application.bob” which has not first been declared in the code. As expected, ColdFusion will search the “Application” scope for a variable named “bob”. Since “bob” was not found in the “Application” scope, ColdFusion will treat the scope portion as part of the variable name and search for “Application.bob” in the various scopes. Imagine a malicious user adding “application.bob” in the URL or the page request. As “URL” is one of the scopes ColdFusion searches for undefined variables, the application will utilize the user defined “URL.Application.bob” in place of the programmer requested “Application.bob”. The end result is both fully scoped and non scoped variables can be affected when not first properly initialized.
As a closing comment, it’s interesting that the above construct works fine in a language such as PHP without serious consequence. However, since ColdFusion searches through scopes for variables, this allows ambiguity that can lead to security (and functional) bugs. If ColdFusion did not search for variables, or allowed us to turn off this auto-search functionality, then this kind of mistake would not be an issue. Since this functionality can’t be disabled, coders need to be aware of this difference in ColdFusion and should diligently hold to the practice of using explicitly defined variables and scopes to keep the code secure.
Each framework has different sets of functionality and quirks that developers should understand to avoid security (or functional) pitfalls. In future posts, we’ll point out other gotcha’s that we encounter in assessments and code reviews.
Press Release: Security PS Expands to Austin
Security PS has continued to pursue plans for growth in 2009 by expanding and strengthening their presence in the Midwest and Southern regions in the US. As key part of this plan, Security PS announced the creation of a local presence in Austin, TX.
"While we do business across the US, our clients continue to place a high value on our local presence as they partner with us for application security services." commented Kris Drent, President and CEO of the firm. "This expansion allows us to provide that level of partnership with business in Austin and in the surrounding areas." he concluded.
Heading up the firm's Austin expansion is manager and consulting veteran Tom Stripling. According to Drent, Stripling's accomplishments and business knowledge made him the perfect team member to spearhead and manage the new location.
While Stripling will continue to serve key clients in the Midwest, his relocation to Austin has enabled him to take a more active role in the regional market. "Given the level of technology in this area, there is a significant need for experienced application security services here. I'm excited that we can be provide a local presence to clients in Austin and better support this region." Stripling said.
In conjunction with the expansion, Security PS continues to expand their reach in the Midwest from their headquarters in the Kansas City area and announcing new application services designed to meet emerging needs.
[ View the original press release from the Security PS website: Security PS Announces Expansion To Austin ]
"While we do business across the US, our clients continue to place a high value on our local presence as they partner with us for application security services." commented Kris Drent, President and CEO of the firm. "This expansion allows us to provide that level of partnership with business in Austin and in the surrounding areas." he concluded.
Heading up the firm's Austin expansion is manager and consulting veteran Tom Stripling. According to Drent, Stripling's accomplishments and business knowledge made him the perfect team member to spearhead and manage the new location.
While Stripling will continue to serve key clients in the Midwest, his relocation to Austin has enabled him to take a more active role in the regional market. "Given the level of technology in this area, there is a significant need for experienced application security services here. I'm excited that we can be provide a local presence to clients in Austin and better support this region." Stripling said.
In conjunction with the expansion, Security PS continues to expand their reach in the Midwest from their headquarters in the Kansas City area and announcing new application services designed to meet emerging needs.
[ View the original press release from the Security PS website: Security PS Announces Expansion To Austin ]
Mozilla to release Content Security Policy
Robert Hansen (RSnake) and others have been working with Mozilla for years to develop a working solution to the problem of user-submitted active content. Well, they're finally close to a solution. Mozilla is releasing their Content Security Policy in version 3.6 of Firefox, which will help to "prevent the creation of JavaScript code from potentially tainted strings", among other things. Basically, this means that if you're a site like eBay that wants to allow users to enter certain "safe" HTML, but not run scripts, you will be able to use Mozilla's Content Security Policy to help ensure that (at least in Firefox).
I sincerely hope other browser vendors follow suit. If this type of thing can become the standard, it will provide a powerful tool for interactive, customizable sites to protect their users.
I sincerely hope other browser vendors follow suit. If this type of thing can become the standard, it will provide a powerful tool for interactive, customizable sites to protect their users.
CSRF Tokens
One of the many interesting discussions at Defcon recently was a discussion of CSRF by Mike Bailey and Russ McRee. They talked about a variety of real-world CSRF attacks and pointed out that a lot of companies simply accept CSRF vulnerabilities because they don't understand the risks they pose. To help people prevent this attack, frameworks like ESAPI have implemented CSRF token generators that produce a long random value to be included as a hidden field in each sensitive form. This value is then checked when the form is submitted, preventing attacks like CSRF from working.
While I was reading about this, I came across an interesting attack against CSRF tokens that was published last month. It's a cool idea. He uses the CSS properties of the browser's history to brute force token values. This works a little better than previous techniques because it generates no traffic to the server and likely isn't detectable by server-side defenses.
As other authors have already pointed out, this doesn't doom CSRF tokens to uselessness. They're still the most effective defense against CSRF attacks as long as they have a sufficient key space to prevent brute force attacks. Just make sure you use a long random value for your CSRF tokens and you'll be fine.
A Quick View State Review
It's been seven years now since the release of the first .NET framework. Throughout all that time there are few aspects of the framework that have been continually misunderstood like the View State. It's a common thread throughout many of the ASP.NET applications that I assess; the View State is misused a lot.
View State misuse leads to a few different problems. Bloat is a common one, and so is accidental disclosure of sensitive data. Every once in a while I'll even see an application with the View State message authentication code (MAC) disabled, allowing attackers to manipulate the View State's values. Of course, the problems with information disclosure and manipulation can be easily solved by turning on View State encryption (and hopefully, setting the ViewStateUserKey* as well). But that's not really addressing the problem at its source.
These problems seem to arise from a basic misunderstanding of the purpose and function of the View State. The standard statement that everyone hears about the View State is that it persists state across postbacks. This simply means that programmatic changes to the properties of any controls will be stored and persisted in the View State across postbacks. Changes to the default properties that are made declaratively or before the control is added to the page's control hierarchy will not be tracked. This means that, ideally, control properties should be set in the ASP code itself instead of in the code-behind file. That way, they won't have a chance to pollute the View State.
This is a pretty key idea and the following two articles, by Scott Mitchell and Dave Reed, respectively, should be required reading for understanding the whole concept.
* Setting the ViewStateUserKey can help protect against POST-based cross-site request forgery (XSRF) or one-click attacks. However, in order for the ViewStateUserKey to work, the View State MAC must be enabled. Depending on the application, this feature alone may be worth leaving the View State enabled. More information on the ViewStateUserKey property can be found at the following site:
View State misuse leads to a few different problems. Bloat is a common one, and so is accidental disclosure of sensitive data. Every once in a while I'll even see an application with the View State message authentication code (MAC) disabled, allowing attackers to manipulate the View State's values. Of course, the problems with information disclosure and manipulation can be easily solved by turning on View State encryption (and hopefully, setting the ViewStateUserKey* as well). But that's not really addressing the problem at its source.
These problems seem to arise from a basic misunderstanding of the purpose and function of the View State. The standard statement that everyone hears about the View State is that it persists state across postbacks. This simply means that programmatic changes to the properties of any controls will be stored and persisted in the View State across postbacks. Changes to the default properties that are made declaratively or before the control is added to the page's control hierarchy will not be tracked. This means that, ideally, control properties should be set in the ASP code itself instead of in the code-behind file. That way, they won't have a chance to pollute the View State.
This is a pretty key idea and the following two articles, by Scott Mitchell and Dave Reed, respectively, should be required reading for understanding the whole concept.
- http://msdn.microsoft.com/en-us/library/ms972976.aspx
- http://weblogs.asp.net/infinitiesloop/archive/2006/08/03/Truly-Understanding-Viewstate.aspx
* Setting the ViewStateUserKey can help protect against POST-based cross-site request forgery (XSRF) or one-click attacks. However, in order for the ViewStateUserKey to work, the View State MAC must be enabled. Depending on the application, this feature alone may be worth leaving the View State enabled. More information on the ViewStateUserKey property can be found at the following site:
Defcon Wrapup
The team has returned from Defcon unscathed. Well, maybe only slightly scathed. We caught several really great presentations. Watch this space for summaries of our favorites. The conference was not without its usual hacker stupidity, though. Some highlights:
- A fake ATM was found in the lobby of the hotel and quickly carted away. There are claims that this was the work of credit card scammers not affiliated with the conference. If so, it was very poorly timed.
- Someone attempted to bungee jump from the roof of the Riviera. He was stopped by hotel staff before he was stopped somewhat more abruptly by the wall of the building.
- One person decided to try to hack an elevator and got himself and 14 other people stuck for an hour.
- And a large number of people connected to the wireless network and logged in somewhere. Or brought something to the conference with an RFID tag in it. Or left Bluetooth enabled on their phone. All of them ended up on the Wall of Sheep.
Subscribe to:
Posts (Atom)
Posts
