"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 ]
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.
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.
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:
- 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.