Twitter

Entries in SPF (7)

Thursday
Aug132009

SPF Moves to CodePlex

Just a quick post to let everyone know that with the release of v1.0.5, SPF has officially gone open-source.  The code (and most recent binary distribution) are now available from CodePlex and have been released under the GPL license. 

The decision to open-source SPF was an easy one.  The biggest factor preventing several companies from implementing SPF in their production environment was the fact that it was neither commercially supported nor open source.  By moving SPF to an open source licensing model, more companies will have the option to experiment and hopefully use SPF to protect their web applications. 

The CodePlex platform also provides public issue tracking and a discussion forum that will hopefully benefit the SPF user base going forward.  Enjoy!

Tuesday
Mar172009

Source Boston IIS7 Slides Posted


My slides from the Source Boston conference last week have been posted for public consumption. The talk discussed some of the cool new built-in features of IIS7, like the Integrated Request Pipeline and Request Filtering. Additionally, it covered the new modular architecture of IIS7 and discussed custom modules (like SPF) and various other new add-on modules that the Microsoft IIS team has released for free.

Those of you not familiar with various extensions that the IIS team has released over the past several months should check out IIS.NET. My two favorites are the URL Rewriter for IIS7 (think mod_rewrite for IIS) and Dynamic IP Restrictions Extension, an add-on that dynamically blocks IP addresses that violate connection threshold and timing limits (great for slowing down CGI and App Scans). 

Overall, the conference was great...hats off to Stacy and the crew for a job well done. They will be posting videos of the talks on the Source Conference site over the next few weeks, so certainly worth keeping an eye out.

Thursday
Feb052009

.NET StockTrader from MSDN: The new WebGoat?

As an application security consultant, I always like to have a vulnerable sample application handy for demonstrating web application attacks to clients. The irony is that other than contrived vulnerable sample applications, like FoundStone's Hacme Applications or OWASP WebGoat, good vulnerable demo applications are actually hard to find.

Luckily the folks at Microsoft recently developed a new sample application, .NET StockTrader, that fills this gap nicely. The best thing about .NET StockTrader is that it was not intentionally designed to be an insecure application. It is worth mentioning that the primary purpose of the .NET StockTrader application is to showcase the performance and interoperability of .NET Enterprise Application Server technologies like Windows Communication Foundation (WCF) and NOT a model for web application security. That being said, for Microsoft to publish a sample application of any kind that has such obvious security bugs is interesting and would seem to be an oversight.

For those interested in seeing a live demo of the application, you can find a live instance of .NET StockTrader on one of our GDS Demo Sites. The items below just scratch the surface of this application as they were all quickly identified within about 10 minutes of playing around with the application. While there are surely more issues to be found, here are some highlights:

Failure to Restrict Authenticated URLs

Not surprisingly, the .NET StockTrader application uses ASP.NET Forms Authentication for restricting access to protected pages. Unfortunately, only the pages directly linked from the main navigation bar have been defined as protected resources within the web.config. What does this mean? Well, pages such as /PortfolioBySymbol.aspx (used to display your portfolio holdings) can be directly browsed without providing proper authentication credentials. You'll notice that a NullReferenceException gets thrown when accessing this page anonymously. This is not by design, but due to the fact that the page attempts to read the ASP.NET forms authentication cookie and it's missing. Luckily the NullReferenceException saves the day here, but still a very sloppy configuration error (not to mention a code-level failure to anticipate and safely handle scenarios where the ASP.NET Forms Authentication cookie is empty).

Password Disclosure

This issue highlights two major problems with the application. As an authenticated user, try browsing to the Account Profile page. Aside from the normal account profile data one would expect to find here, something will probably jump out at you (at least if you are a security person). There are two form fields, appropriately marked "Password" and "Confirm Password", which are pre-populated. The problem here is that the actual user's password is rendered back within two form fields. Even though the browser masks the values from plain-sight, they can easily be revealed by viewing the HTML source (aka Right-Click -> View Source). As I hinted at before, there are actually two issues here. The second problem is that these passwords are actually stored in plain-text within the back-end database table used for storing profile data. As you can see, things are starting to get ugly.

Cross-Site Request Forgery

The next issue is a classic Cross-Site Request Forgery (aka a one-click attack). These attacks are certainly common, but this one is especially ugly as you will see in a moment. Keep in mind that the premise for this sample application is an on-line stock trading web application, like eTrade. Unfortunately, the page used to execute all BUY and SELL transactions passes all of its parameter via a single GET request similar to the following:

/Order.aspx?action=buy&symbol=s:0&quantity=122

The reason this is especially dangerous is that it can even be exploited through a malicious IMG or other HTML tag as shown below, so forcing a POST request is not necessary for exploit:

<IMG SRC="/Order.aspx?action=buy&symbol=s:0&quantity=122" HEIGHT="0" WIDTH="0" />

FormsAuthenticationToken Manipulation

Now this one is arguably the worst of the lot. As I mentioned towards the beginning of the post, the .NET StockTrader application uses ASP.NET forms authentication. What I didn't mention was that the Authentication section of the web.config actually has cookie protection disabled (aka protection="None"). As you can imagine, this makes it trivial for anyone to decode the ASP.NET Forms Authentication Token and manipulate its contents to impersonate any, yes any, user. Ironically this is one of those issues that does not immediately jump out at you if just viewing the cookie since the Forms Authentication Token is always HEX encoded irrespective of the protection setting . Let's take a look at an example:

signinform=BC970F782904ECCF027500690064003A0039000000316F04304A80C90100318975484C80C90100002F000000

The one thing that does jump out is the unusually short length of the encoded string and the abundance of NULL (00) values. Run this string through a HEX decoder and you can quickly see the wheels come off (Hint: 75 69 64 3A 39 == U I D : 9)

Arbitrary URL Redirection

Last but not least, I'll point out a less severe but equally interesting URL that caught my eye when browsing the application:

/StockTrade.aspx?action=sell&return=Portfolio.aspx&holdingid=5434

Any time you see a URL or file name being passed to the application there is usually something fishy going on. As it turns out, the "return" query string value on this page is directly assigned to the .PostBackUrl property of a LinkButton control on the page. The result is an arbitrary URL redirection exploit when the user clicks the link button. Ironically this bug is also dangerously close to being a Cross-Site Scripting (XSS) bug, however there appears to be some built-in escaping taking place thanks to the .NET framework (although I am sure with some further testing this could be turned into an exploitable XSS bug).

So What?

I think we all would agree that the insecure code examples and sloppy configuration settings highlighted above are pretty common and easily fixed, however that's no excuse for Microsoft publishing a sample application riddled with flaws (even if it isn't intended to be a showcase for application security). As many of us know, developers often rely on sample code and reference applications like the ones published on MSDN when writing code, so mistakes like these could easily make their way into a real-world scenario. Pretty scary.

Ironically, ALL of these issues can be mitigated with Secure Parameter Filter (SPF) for IIS, which can be seen live in action protecting the same sample application at http://trade-spf.gdsdemo.com. Also, for those interested in continuing the bug hunt, the .NET StockTrader sample application can be downloaded for free from MSDN.

Friday
Dec192008

Tamper Proofing Web Applications at Run-Time

Earlier this week we presented at the OWASP NY/NJ chapter meeting on "Tamper Proofing Web Applications at Run-Time". The talk presented some strategies and free solutions for protecting web applications from input driven attacks. The goal is to harden web applications so their non-editable inputs cannot be manipulated, which when left unchecked are a root cause of authorization bypass vulnerabilities such as parameter manipulation, forceful browsing, business logic flaws, etc. You can download the presentation slides here.

Non-editable inputs are those that end-users do not need to modify directly ' hidden form fields, URIs and QueryString parameters, cookies, etc. Traditional approaches to protecting this data ' black list and/or white list validation ' are insufficient as they cannot normally prevent authorization flaws within the context of a user's session.

Our talk demonstrated two freely available solutions that provide this type of protection for existing web applications without the need to modify the underlying application source code. In general, they both operate on the theory that the application should only permit users to perform those actions that the UI has rendered to them. The idea is to leverage HTTP responses at run-time to identify all legitimate requests (forms and links), collect the state of each possible request, and then validate subsequent requests against the stored state information. Specifically, we cover HDIV (HTTP Data Integrity Validator) for J2EE web applications and SPF (Secure Parameter Filter) for .NET web applications. The implementation details of each are discussed as well as related pros and cons.

You can download the presentation slides here.

Thursday
Dec042008

OWASP Boston Slides and SPF Public Demo Site

The slide deck from the "Tamper Proofing Web Applications at Runtime" talk I gave last night at the OWASP Boston meeting are now available for download.

We also released version 1.0.1 of SPF earlier this week and have a public SPF demo site running .NET PetShop v4 from MSDN. More information on SPF can be found on its official page.