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 ]

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.

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.

• http://msdn.microsoft.com/en-us/library/ms972976.aspx
• http://weblogs.asp.net/infinitiesloop/archive/2006/08/03/Truly-Understanding-Viewstate.aspx

Both of these articles describe what the View State really is, and more importantly, what it isn't. Applying the information presented in the articles above will go a long way towards reducing security problems with the View State. However, in the cases where sensitive data is still leaking, it may be easier to not use the View State at all. In many cases, it can be completely turned off without impacting the functionality of the application. In other cases, the View State can be disabled on a per-control basis. More good news on this front is that ASP.NET 4.0 will give developers more control over exactly how the View State is used on a page.

* 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:

• http://msdn.microsoft.com/en-us/library/ms972969.aspx#securitybarriers_topic2

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.