.NET版的WebGoat

Brian Holyfield 在文章 《.NET StockTrader From MSDN: The New WebGoat?》 中介绍了微软的样例程序 - StockTrader，堪称.NET版的WebGoat，在文章中，作者列举了几个常见的安全漏洞，这些漏洞都可在StockTrader中发现，.NET程序员（尤其是那些喜欢按照sample抄抄改改完成任务的初级程序员）可要注意了，安全测试人员则可用这个sample来练手。

原文：

.NET StockTrader From MSDN: The New WebGoat?

http://blog.gdssecurity.com/labs/2009/2/5/net-stocktrader-from-msdn-the-new-webgoat.html

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 athttp://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.