Secure Web

Reflections on our Q1 2007 Application Security Trends Report

Now that our Application Security Trends Report Q1 2007 is out the door I want to discuss some of the major challenges we faced in putting it together and also give our audience a sense of our vision for the future of the report. Our goals for the quarterly trends report were three-fold, and some of the these goals we were able to achieve better than others: to discuss major events that affected application security during Q1 time-frame, to compile relevant and accurate statistics for the period, and to give a sense of attack patterns and events in the so-called underground.  These were lofty goals to begin with, but we did our best. That being said, our first Trends Report was still our first report, and we didn't get to do everything we wanted to do. Below are a some of the areas that we hope to improve upon in the future.

1. Level of Abstraction: Its a challenge to strike a balance between an appropriate high-level overview of the vulnerability data verses a very low-level and comprehensive categorization. The more detailed your categorization system the more risk you run of confusing your audience or producing a final work that's more convoluted than informative.The  OWASP Top 10, for example has 10 categories for web application vulnerability types, whereas WASC has 6 top level threat classes with 24 subcategories. Future versions of our report will utilize a list of Web Application Risks that we think strikes the best balance between detail and breadth. In other words, we were not entirely satisfied with either of the major web application vulnerability taxonomies, so we're going to come up with our own.

2. Definition of a Web Application verses Web-enabled technology. As the web becomes more diversified and dynamic in the types of applications that interact to deliver its functionality and content, web application vulnerabilities will become more diversified. This time around we used a working definition of a web application: those server-side technologies that provide for infrastructure and functionality for delivering web content to the user, plus the web browser. While I won't go into our motivation for including browser vulnerabilities in the report, its clear that when one begins to categorize things this way you have departed from a strict definition of a web-application as a pure server-side technology that you assess or scan from a black-box perspective when doing an assessment. This can cause some confusion since its a departure from the ordinary way we think of web applications.

We're ok with this departure because it makes sense, but it also doesn't go far enough or do justice to very large amounts of vulnerability data relevant to web application security. In future reports you can expect us to broaden our definition of a web application even further, which will lengthen the report, but also pull in additional security information that is important for web users. This doesn't mean that we will treat traditional web application vulnerabilities with any less importance, it means that the definition of a traditional web application is showing signs of stress, and a broader definition will be a better overall fit for the vulnerability data. To keep things clear we will create categories for types of web application vulnerabilities that exist in non server-side technologies, and detail this broader picture as vulnerabilities disclosed in web-enabled technologies. Web Applications and Web-enabled technologies will be covered in separate sections to avoid confusion. Here are a few examples:

*A cross-site scripting vulnerability in Poodle-cart 1.0 would be categorized as a web application vulnerability.

*A cross-site scripting vulnerability in Adobe Acrobat Reader would be categorized and counted under the web-enabled technology section. (This time around we did not include or count any of these types of web-enabled technology vulnerabilities).

*A web-exploitable vulnerability in Quicktime would be categorized under the web-enabled technology section.

*A Web-exploitable vulnerability in the Super-Slurp Desktop Buddy ToolBar would be categorized under the web-enabled technology section.

*Vulnerabilities in web browsers will be categorized under the web-enabled technology section.

*Web-exploitable vulnerabilities in ActiveX controls for web applications will be categorized under the web-enabled technology section.

*Vulnerabilities in web servers, web application servers, etc., will be included among web application vulnerabilities, as a subcategory (i.e. the web application pie chart will have two slices).

By covering both traditional web application vulnerabilities as well as web-enabled technology vulnerabilities we can avoid leaving out information that will help to inform and protect our readers, while at the same time keeping a clear distinction between traditional server-side applications and client-side technologies with web-based vulnerabilities.

Why do things this way? Why all the craziness? Well, (to quell the conspiratorial types) we're not trying to pad the report for length so that we can win the my Trends Report is bigger than your Trends Report contest. We're not trying to out-Symantec Symantec. Rather, its our viewpoint that all technologies which use HTTP, and have HTTP exploitable vulnerabilities, should get coverage in our Application Security Trends Report. We want to provide this coverage while still keeping traditional web application vulnerabilities front and center.   

-Tom

 

Cooking with Security

In case you hadn't realized it quite yet, I'm big on analogies. It makes understanding things so much easier. I'm also big on drawing weird connections between things but that's a topic for another blog entry. This time I'm discussing black box testing versus white box testing.

I was making myself tacos for dinner the other night when I realized the comparison. I had pulled out the cheese, immediately saw the mold all over it and realized it wasn't good. I was essentially white box testing the ingredients for my tacos. My "source code scanner" (me) found the one bad "function" (the cheese) in what would be the "entire program" (the taco). And as would be expected with a white box test, it saved me time and effort by replacing the cheese before it ended up on the final product.

From this little bit, it sounds like a white box tester is all that would be needed, something to validate the ingredients / parts. But as everyone can tell you with food, it's the final product that matters. You need that final black box test to look at the product as it is deployed to take all the factors into account. You need to crunch into that taco and discover if too much hot sauce was deployed or if the meat was cold or if the cheese was bad. Or maybe there is an extra ingredient (like honey) that your white box testing said was not spoiled but your black box testing would reveal as not a good fit for the final product. Comparably you need to see how the web application functions in the final environment to know if it is secure. Is there a problem with how two functions are interacting? Does one page not call the right sub-procedure? Is it deployed on a faulty or insecure web server?

There are advantages to testing from both perspectives: white box testing will help save efforts of implementing a faulty component, black box testing will validate the deployed product. But if I had to choose only one method of testing, I know I would pick black box testing. Only after that crunch into the taco can you know the final result is good.

- Mike Kazmierczak, Cenzic, Inc.

Q1 2007 Application Security Trend Report

Cenzic's CIA Labs has recently finished up its Q1 2007 Application Security Trend Report. I thought I would drop a line here to give you the highlights. You can get the full report from Cenzic (you should see a link to the file from the homepage). You can also try to get it here via a direct link.

In preparing the report we drew on a number of sources including SecurityTracker, Bugtraq, Full-Disclosure, as well as various academic and private sector studies. Citing the sources we overtly used though isn't enough to give full credit where it is due though, as our work was inspired by Symantec's Internet Security Threat Report. A few remarks are in order.

I am a huge fan of Symantec's Internet Security Threat Report, currently on volume 11 (cf. ISTR Volume XI). Ever since I first got my hands on this report I've always thought of it as the very best in its class, a work of art even. Rather than a veil through which to spew forth marketing data, its a robust research product that gives accurate, informative, and useful data to the security professional. I've plugged Symantec's Threat Report in every talk/presentation I have given for the last two years. Two things have always come to my mind when reading it: I wish it were more focused on application security rather than security in general (yes, it was a selfish wish), and I always wanted more detail regarding the attack data discussed in the reports. Monthly breakdowns, more details, and a backdrop against which to correlate the data.

So you can imagine my happiness when I approached Cenzic's Management about us doing our own trend report, a report focused on application security that delved into the details I always felt were missing in the ISTR, and was given the go ahead. Off the bat we faced a major hurdle. Unlike Symantec we didn't have a global network of thousands of intrusion sensors that we could tap into as a data feed. So I turned to the SANS Internet Storm Center and Dshield as the source of raw data, and queried these organizations for their Q1 probe and attack data as it related to port 80. I am not sure if all our readers are familiar with the concept of collaborative security models, so I will discuss how this data is collected. Thousands of users submit their firewall, IDS, router, and ACL logs to these organizations and the statistics on blocked traffic are crunched daily. This information gives a picture of probing and attack activity and is very useful when looking at high-level trends and patterns. The drawback is that the data is raw and uninterpreted.

Rather than trying to build a story around every peak and curve on a graph of such data, we decided to give readers a backdrop against which to consider the observed activity. After each month's probe and attack data we provided a list of major events that occurred during the same time-frame, as well as information from US-CERT. This gives a canvas against which the reader can look at the trends and draw their own conclusions. It also serves to highlight significant application security events that occurred during the Q1 2007 period.

Next we engaged in the herculean task of hand counting and categorizing all of the application vulnerabilities disclosed during the Q1 period.  Here are some of the highlights from our work:

• Roughly 67% of the vulnerabilities affected Web servers, Web applications and Web browsers.

• Applications written in PHP comprise roughly 30% of all vulnerabilities.

• Vulnerabilities within the PHP programming language versions 4 and 5,including wrappers, extensions, and bundled components comprised 3% of total vulnerabilities.

• Roughly 63% of the Web application vulnerabilities can be accounted for by 4 vulnerability classes: file inclusion, SQL injection, cross-site scripting, and directory traversal.

• Roughly 71% of the reported vulnerabilities are classified as easily or trivially exploitable.

• Vulnerabilities in Web Server or Web Application Server technologies comprised around 7% of the total reported Web application vulnerabilities.

• Remote file inclusion vulnerabilities in PHP comprise 17% of the reported Web application vulnerabilities and were reported in roughly equal proportion to SQL injection vulnerabilities.

• 19% of all reported Web application vulnerabilities involved cross-site Scripting.

In addition to the probe and attack data we also polled data from our ClickToSecure service on the types of vulnerabilities we found to be most prevalent in the wild. Above all we hope that we have provided our readers with an informative and thought provoking trend report for the Q1 2007 period.

-Tom Stracener

Are Agile Web 2.0 Frameworks Secure ?

New lightweight frameworks for building three-tier MVC ( Model, View, Controller ) web applications, have been emerging and are becoming very popular. They combine a HTML templating framework with an ORM (object/relational mapping ) layer, and rely strongly on conventions about what things like variable and class names should be called, and where things should be stored. This enables you to, very quickly create, test, and deploy sophisticated web applications with just a few lines of code. Ruby on Rails is one example of this framework. However, does the speed in developing these applications compromise on security? This is the big question, and my initial efforts in using these applications have raised some alarms.

This is the first, in a series of postings that deal with how easy it is to overlook the security aspects when using these frameworks. We will look at Ruby on Rails in particular.

Cross Site Scripting and Rails Scaffolds
Model: The model maintains the state of the application. It represents data, and all the business logic that applies to that data. It generally represents a table in the database, and determines which table based on a naming convention. For example a model named product represents a database table named products.

Controller: controllers are used to coordinate actions between the view and the model. The framework provides you a mechanism to create the controller using a command line interface.

Scaffolds: Rails Scaffolds allows you to manipulate the model in the application. It is auto generated and provides a default view, that you can use to view and manipulate the model. The form generator created by the scaffold asks the model for information on the fields in the model and uses this information to create an appropriate HTML form.

Cross Site Scripting.
The Html form and corresponding server side code created by the scaffold is vulnerable to cross site scripting. No input validation is done on the data, that is input using this autogenerated form. This un validated data is stored in the database that can potentially lead to persistent cross site scripting. This can lead to the usual exploits that can be achieved with cross site scripting like, stealing authentication credentials etc.

Impact:
Since the developer is accustomed to write minimum code when working with these frameworks, it becomes easy to overlook security issues described above. The developer expects the framework to create the view and corresponding server side code to accept input. The developer focuses on building the data model. This leads to a security hole that can be easily exploited.

Remediation:
Ideally developers using these frameworks should write their own server side validation code. Rails provides a helper function h(string) that sanitizes all data inside the function before displaying it. This prevents execution of code in the view when displaying data. However again no filtering is done on accepting the data and potentially dangerous data may make its way into the database. If another view or another application is ever used to view this data, the attack vector may execute and cause the vulnerability to be exploited.

                                                                                                                        

-Avinash Shenoi