The relatively nascent field of Java  web application security has seen an explosion of interest in the past year or so from developers and security software vendors alike. Java open source projects have caught the interest of some these vendors as a means of cause marketing, a marketing technique not often seen in the software world where a commercial enterprise and a non-profit organization work together for mutual benefit. The benefit to the non-profit is that they are in some way making the world a better place. The benefit to the commercial software company is that they make more money.

 

The Java Open Review project, available at opensource.fortifysoftware.com and sponsored by Fortify, sets out to identify and root out security and quality bugs in popular Java open source projects to help improve the security of Java web applications in general. I have to commend all involved for the attempt and the mission of the project, but was surprised to see the lack of substantiated findings that was the first public release from the project’s efforts.  The report is available at: www.fortifysoftware.com/servlet/downloads/user/Java_Open_Source_Report.pdf.

 

In their review of Hibernate, Struts, Spring and Tomcat, they seemed to find nothing of substance. Instead of continuing on their quest of improving the open source code base and finding real problems, they released what they had, which consisted of three odd conclusions.

                                                                                                                                                                                                                                                        

Their first conclusion was that “Java is more reliable programming language than C/C++”. This is like announcing that electric light is more reliable than candles.

 

The second conclusion was that “Developers inadvertently incorporate open source code in an insecure manner”. Should the conclusion have read that “Developers inadvertently incorporate code in an insecure manner”. That’s kind of the root of the problem isn’t it?

 

Third conclusion: “Most common open source security vulnerability is cross-site scripting”. Not only is this the most basic conclusion of any experienced web application security auditor (that XSS is the most common problem), but the Java Open Review project found these problems in the open source sample applications, not the frameworks themselves. For example, they report that they found 8 “bugs” in Struts and its accompanying sample projects. I analyzed the Struts sample applications with SPI Dynamics web application security tools and found way more than 8 security vulnerabilities of varying severity, including multiple instances of cross-site scripting, information leakage through untrapped exceptions and server error messages, and unvalidated inputs potentially leading to buffer overflows or DOS.

 

Let’s keep working on improving developer security, especially in the use of open source technologies. But let’s do it in a transparent, collaborative, public-private partnership like DHS, Stanford U. and Coverity have been doing: http://news.com.com/Homeland+Security+helps+secure+open-source+code/2100-1002_3-6025579.html

DevInspect from SPI Dynamics (the product I manage and the company that pays me to do it) is once again a finalist for the Jolt Awards in the security category. http://joltawards.com/2007  Awards like this are meaningless to a user that is making a purchasing decision since you must make an individual decision about what tool is best for your company, environment and application, but who doesn't like to win?

Last year, DevInspect was a finalist for these awards, but due to the rules of the awards, the judging was based on the version of the product available in 2005, which was merely an approximation of the capabilities available in today's DevInspect 3.0. In the past year, DevInspect has added hybrid analysis capabilities unmatched in accuracy and efficiency in any product, tripled the number of supported developer tool integrations, expanded its analysis superiority from .NET languages to the Java world and analyzes ASP.NET AJAX applications in ways not possible with any other security tool. And it does not produce greenhouse gasses and has tremendous fuel economy for a product of its weight class and horsepower.

 

E-voting, welcome to the security vendor hysteria cycle. It's no secret to anyone that security companies benefit from security breaches and threats. If there were no hackers or insecure applications, there would be no security software. So if you sell security software, then it's natural that you would tend to play up news about the relative insecurity of the newest thing in the news. I'm not condoning that, just acknowledging it as marketing reality.

But the discourse about election security is just stupid. Newspapers, television and even a TV movie have jumped on the discovery of potential vulnerabilities in electronic voting systems to claim that our very democracy and fair elections are in peril.

According to Robert Kennedy Jr.'s article in Rolling Stone, "electronic voting machines are a hacker's dream....It is time for Americans to reclaim our democracy from private interests."

According to source code analysis vendor Fortify Software's corporate blog, "Local, state and federal governments must be held accountable for defending our right to participate in fair, unbiased elections and verifying the security and correctness of the code that is actually used to run the election is paramount to these guarantees."

Are you serious? In order for us to have fair elections and to reclaim our democracy, you need to buy a source code security tool? This is the dumbest thing I have heard since the last thing I read from Robert Kennedy, Jr. You know, the piece where he claimed that God smited Mississippi and destroyed their coastline because Haley Barbour opposes the Kyoto protocol.

Putting politics aside, if you're reading security blogs you understand how important it is for any software development to address security early and often through tools, process and people. Electronic voting machines are no different. But making these far reaching associations and pinning security software to such absurd hysteria and conspiracy theories violates the trust that people put in their technology and business partners. Fair elections are such a bigger issue that source code security. If you want to truly understand the security issues in something as important as electronic voting, turn to security professionals that aren't trying to sell you software, like Avi Rubin and Bruce Schneier, and skip the self-serving vendors and inflammatory activists.

In the interest of full disclosure, I'm a self-serving vendor of security software.

If you have been working with previous distributions of Microsoft's Atlas framework, you probably noticed a nice feature related to the ease by which you could call Web services from client code. The problem was that it was also a bit of a potential security hole. Thankfully, in the production version of the now-named ASP.NET AJAX, they've tightened things up but probably have (temporarily) broken your Atlas applications as you migrate them to the production release.

When you created an Atlas application with earlier CTP versions of the technology, essentially all Web services in your project marked with WebMethod were callable by the client-side JavaScript proxy. You likely have authentication in place for anything sensitive on the Web services side of things, but it's not generally a good idea to give JavaScript willy-nilly access to all of your Web services if it's not absolutely necessary that you call them directly from the client.

In the latest public beta leading up to the final release of ASP.NET 2.0 AJAX Extensions 1.0, Microsoft has removed the ability for the client JavaScript proxy to call any Web service in your project. Web services now must be explicitly enabled for client access by adding the ScriptService attribute in the asmx. So only the Web services that you really want exposed are reachable from the client, removing any chances of nefarious access to them from modified or injected JavaScript.

And if you’re like me, when you migrated your early Atlas code to the ASP.NET AJAX beta drop, you didn’t pay attention to this change and spent time trying to figure out why all of your Web services stopped working! Essentially, the Web services that you want to be called from the client side of ASP.NET AJAX should look like this, with the new changes in green:

<%@ WebService Language="C#" Class="HelloWorld" %>

using System;

using System.Web;

using System.Web.Services;

using System.Web.Services.Protocols;

using Microsoft.Web.Script.Services;

 

[ScriptService]

[WebService(Namespace = "http://tempuri.org/")]

[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]

public class HelloWorld  : System.Web.Services.WebService {

 

    [WebMethod]

    public string Hello() {

        return "Hello World";

    }

}

Thanks to the ASP.NET AJAX team for a simple fix with nice security dividends.

 

Those of you interested in adding AJAX interactivity and responsiveness to your .NET Web applications are doubtlessly aware of the 'Atlas' framework that Microsoft has been working on for most of this year. Scott Guthrie has just made product plans and naming official, with initial release slated for the end of the year. http://weblogs.asp.net/scottgu/archive/2006/09/11/_2200_Atlas_2200_-1.0-Naming-and-Roadmap.aspx

I'll cover more in the future about why ASP.NET AJAX Extensions prove to be the best way to develop secure AJAX applications.

The three pillars of information security in your applications are integrity, confidentiality and availability. Protect private information, keep people from damaging your system and make sure that proper users are not interrupted. The most important thing that you can do to protect the integrity, confidentiality and availability of your system is to authenticate users to and restrict access to only those that should be allowed. In a Web application, if you provide a mechanism that guarantees that only known, safe users can access the system, you have nothing to worry about, right? Well, not exactly.

Once a user authenticates with a Web application, which is stateless by nature, the user’s authenticated credentials are persisted in the client, usually with a cookie. If the user’s authentication weren’t persisted somehow, they would have to login again on every page and with every AJAX request. After authenticating, when the user does anything in the browser that results in a request to the server, like clicking a link, the browser automatically appends the authentication cookie to the request. Authentication token persistence is a necessary evil to support the user experience you need and can’t be avoided. None of this is news to you.

But an emerging type of attack known as cross site request forgery is leveraging this and turning the trust that your server has in an authenticated user into an attack vector. All the attacker has to do is to trick a user into making bad requests from their browser to a site with which they have authenticated. The browser conveniently attaches the user’s cookie to the requests and the server lets the attacker's request do anything the user was allowed to do, like transfer money or change their password. Attackers can accomplish this through phising e-mails or script injection through cross site scripting. This adds a new dimension to your requirements for properly authenticating requests and deserves your attention. This paper from iSEC partners provides the best available background on the problem and some suggestions countering it: http://isecpartners.com/documents/XSRF_Paper.pdf

Thanks to everyone that attended the Dr. Dobb's Architecture and Design World in Chicago last week and brought great questions about developer security issues. Here is a quick list of all of the tools that I mentioned that can help you root out and fix security bugs in development. Most of these are open source.

Proxies/HTTP Editors - The SPI Proxy and HTTP Editor that I showed are available as part of SPI Dynamics' security testing tools WebInspect and DevInspect. Free trials of those are available: http://www.spidynamics.com/products/index.html. Popular free tools that do similar things are:

• Fiddler - http://www.fiddlertool.com/fiddler/
• WebScarab - http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project
• Paros - http://www.parosproxy.org/

Thread Modeling Tool - http://msdn.microsoft.com/security/securecode/threatmodeling/acetm/

Firebug JavaScript debugger - http://www.joehewitt.com/software/firebug/

FindBugs Java Source Code Analysis - http://findbugs.sourceforge.net/

FxCop .NET IL Anlaysis - http://blogs.msdn.com/fxcop/

 

If you read much about security, you've most likely heard the term "google hacking". Google hacking is not attempting to hack the world's most popular search engine, although I’m sure there are plenty that try it. Google hacking refers to the process of hackers’ using Google to find Web sites that are vulnerable to the types of attacks that they are looking to pursue. Because Google crawls millions of Web sites and creates a handy inventory of virtually all of your public files and content, hackers use obscure Google operators to find all the sites out there that look like a likely target.

Now a brief tutorial. Let’s say I’m a hacker particularly interested in XML bombing poorly written Web services (which sends the Web service into a fatal recursive parsing loop). But in order to do this, I need to find tons of Web services to try it on. How could I anonymously find tons of potential targets? Just ask Google for all the WSDL files that it knows about by searching for:

            filetype:WSDL WSDL

Like so:

http://www.google.com/search?hl=en&lr=&safe=off&q=filetype%3AWSDL+WSDL

Just like that, I have thousands of possibilities. You can imagine that I could pretty easily write a script that parses this enormous list of results and probes the services, looking for the little entry point that I need. If I want to look at a specific domain, restrict it like so:

            site:domain.com filetype:WSDL WSDL

Using these Google operators, I can find much more than just file types and names. Google has become an absolutely indispensible tool for hackers and developers need to know about what can easily be disclosed about their sites just by allowing Google to index them.

So how do you prevent vulnerabilities to Google hacking? You can prevent your site from being indexed, but that’s stupid because your business needs to be found on Google. Secure your applications during development and test their security afterwards. If your applications are secure, then hackers that find you through these Google techniques cannot hurt you.

Do not rely on products that claim to find “Google hacks” on your site to prevent your security holes from being found. This is classic obscurity over security because if you have vulnerabilities, they will be found whether it’s by Google or some other means.

The solution is to secure your code and let it rip. Know what Google can tell people about you (http://johnny.ihackstuff.com/ has numerous examples) and then rest easy that your code is secure and you have nothing to fear from Google (unless of course you’re a search engine or a newspaper or paypal).

I may be behind the times on this one, but if you're a JavaScript developer of any sort, you need FireBug. http://www.joehewitt.com/software/firebug/  FireBug is a add-in for Firefox that provides the best script debugging and DOM examination environment I've seen. Even if you're an IE user or developer, it's worth adding Firefox to your machine just to use this tool because it blows away even Microsoft's development toolbar and certainly any scripting support in Visual Studio. It's a must for AJAX development and comes in handy for trying to hack your (and maybe other people's) JavaScript. Check it out and get it here:  https://addons.mozilla.org/firefox/1843/

See if you can spot the SQL injection vulnerability in the C# code below:

SqlDataSource1.SelectCommandType = SqlDataSourceCommandType.StoredProcedure;
SqlDataSource1.SelectCommand = "LoginSP";
SqlDataSource1.SelectParameters.Add(new SqlParameter("UserID", TextBoxUserID.Text));
SqlDataSource1.SelectParameters.Add(new SqlParameter("Password", TextBoxPassword.Text));
IEnumerable results = SqlDataSource1.Select(DataSourceSelectArguments.Empty);


Give up? Actually, this was a trick question: there is no SQL injection vulnerability in this code. But this application may still be vulnerable to SQL injection due to an incorrectly written "LoginSP" stored procedure in the database. If your stored procedures create and execute ad-hoc SQL statements, it's no more secure than if you create and execute ad-hoc SQL statements in your page code. A source code analysis tool would never detect this vulnerability. You need an analysis tool that makes actual requests to the page, and analyzes the actual responses, in order to detect it.

1. I don’t have to spell check my code comments anymore.
2. It’s fun to make my code generate call graphs that look like fancy clouds and animals.
3. They take long enough to legitimize my three hour lunches because “I’m running a test and my CPU’s pegged for like 4 hours”.
4. Their reports with thousands of warnings and false positives make attractive packing material at Christmas time.
5. They can’t read JavaScript so I don’t have to try to debug it.
6. Pie charts are the most optimal way for me to look smart in meetings.
7. Like television commercials, when they’re annoying I just ignore them. And now with Tivo I can skip them altogether.
8. I enjoy paying for open source technology.

No one denies the utility and popularity of the AJAX programming model and associated technologies, but few acknowledge the inherent security danger in an application model that more or less promotes more logic and decision making on the client. And not just any client, but a Web client that can establish trust with your server and communicate with asynchronous requests that might circumvent your traditional validation and authorization mechanisms. AJAX applications can be just as secure as any other Web application, but the uninformed that are plunging into this relatively new approach that doesn’t benefit from established standards and secure frameworks are at risk of setting Web application security back a few years.

If you are building Web apps with some brand of AJAX and will be at Microsoft’s TechEd 2006, come see SPI Dynamics founder and CTO Caleb Sima discuss how AJAX is exciting hackers. Caleb’s TechEd Chalk Talk entitled “A Study of AJAX Vulnerabilities and Hacking Techniques” is on June 15^th from 5 to 6:15 p.m.

Come find out if your AJAX app is one of Caleb’s examples.

Law enforcement realized long ago that the best way to catch a criminal is to learn how to think like one. Taking the concept further, crime prevention depends on understanding how a criminal thinks to know where to invest your time and money on defenses. You can spend thousand of dollars on a home alarm system, but if you don't realize that a burglar only has to cut off the phone line at the side of your house to disable the callback to the alarm company, you've wasted thousands on useless defense.

This same concept applies to developers thinking about security. Sit the average developer down with your code for a code review, they're going to think about how to break it, how to cause exceptions that aren't trapped properly and how well did you follow company standards for variable and method names. Sit a hacker down with your code or application and you'll be surprised at how differently they look at your code. They're going to think about ways to get to your methods that you never imagined. They're going to think about how they can make your code do things you didn't imagine. They're going to try to figure out how to use your code to impersonate a good user to access another site and hack it.

Try thinking like a criminal the next time you do a code review or test your team's application. How can you steal something with it? How can you escalate privileges to do things you're not supposed to? How can you use the feedback form to spam your cubemates with 7,000 e-mail messages? How can you steal your test analyst's MySpace login and do fun things with it? How can you use backdoors left open?

Don't just try to break it, try to be a criminal with it. Only then will you find vulnerabilities that other developers couldn't dream of.

For some impressively comprehensive guidance on building and deploying secure ASP.NET Web applications and Web services, check out the Microsoft patterns & practices team's security guidance site at http://msdn.com/securityguidance. The site is the official home of the team's content, but you can always get fresher versions and potentially additional content on the team's security wiki at http://channel9.msdn.com/security. You won't find more accurate, comprehensive and timely advice on secure coding on the .NET platform on any other site, blog or book.

Most security testing tools available to developers today are based primarily on a security testing technique known as source code analysis. Many might recall freeware tools like lint as a means for doing this in the past. Source code analysis involves parsing the source code files of an application to identify the method calls and potential flow of data through an application. These products produce a call graph, either logically or graphically, that represents the possible paths that data may take through the application.

 

Source code analysis products then use a technique called variable tracing to inject test data into the application and study its potential values and behaviors through the call graphs. By injecting test data in this way, the source code analysis product is able to infer what behavior may occur for a certain scenario and variable value, hence the reason this technology is often referred to as an inference engine.

 

The danger of this source code analysis approach is that it is only able to infer, or guess, at what the actual system behavior will be during runtime and production configuration conditions. Source code analysis can only determine what security vulnerabilities might be possible in the application, resulting in the potential for very high false positive rates. Trusting inferred results of such an analysis is analogous to trusting that when an application compiles cleanly it will function according to design. If all code is syntactically and semantically correct, then it will compile. But do you have any confidence that it will meet the functional requirements just because it compiled? Similarly, developers who rely on source code analysis to infer security problems in the application must also perform additional security testing to validate the application’s real runtime behavior with respect to the potential vulnerabilities identified by the source code analysis.

 

In short, these products can be valuable in reviewing your source code for security problems, but they should be just one component of your security assurance strategy in development. See Michael Howard’s recent post on the utility and danger of these tools for another perspective: http://blogs.msdn.com/michael_howard/archive/2006/01/26/517975.aspx