IBM Application Security Insider

Have you scanned your mobile site for vulnerabilities yet?

Mobile sites - Resurrecting security risks

In today's world any self respecting web site must provide access to its services through a desktop browser as well as a mobile device. This basically means that there are two versions to every site, one for desktop users and one for mobile users. Are both secure? How do we know for sure?

First, let's take a quick look at some of the reasons why companies would prefer to have mobile users visit a mobile-based site instead of directing them to the original desktop site.

• Technologies - There are certain technologies that are not supported on a mobile device (e.g. Flash on iOS) that would have to be re-designed to meet smartphone requirements.
• User experience - The user experience is completely different. For example, take the hover action, a desktop user can hover over a certain area and have menus sliding this way and that. But on a mobile device hovering does not exist.

A spotlight on JSA, the amazing hybrid security analysis for JavaScript

By now you have probably heard about JSA. Introduced in AppScan Standard 8.0 in Oct '10, and now included in AppScan Enterprise 8.6, JSA is a component that does static analysis of JavaScript to detect a range of client-side security issues. Issues such DOM-based XSS, Open Redirect, and many others.

Why is this significant? 

Client-side code percentage in web applications grew from around 5% five years ago, to an amazing 25% today. Driven by the Web 2.0 explosion, JavaScript is now everywhere, on every web page. And guess what -- it's painfully full of security holes. Evil, nasty ones, that are particularly difficult to catch.

We were really surprised when we discovered that nearly 1 in 6 of the Fortune 500 websites have serious, exploitable security issues in their JavaScript code. You can imagine this got a lot of attention when we shared these news with the world. It quickly become the #1 downloaded whitepaper in IBM Rational.

CWE (Pie Chart) is in the Eye of the Beholder

A few days ago, I was sitting down at my desk, doing my daily blog reading session, when I stumbled upon a post at the Matasano Chargen blog. The post (which quotes Mark Curphey) mentions a presentation that Jeff Williams gave at a New York OWASP chapter meeting, in which Jeff uses the following slide:

Jeff took some information that was posted by MITRE, and used it to demonstrate that if you take all automated security tools, and use them all together against something, the tools will only cover 45% of the known vulnerability types enumerated by the MITRE CWE project. 

Since I was an active participant in the CWE project (on behalf of Watchfire), I know a thing or two about the CWE project. Specifically, I know that:

1. The CWE project includes input from many different types of sources, such as Source Code Scanning vendors, Web Application Scanning vendors and all sorts of preliminary taxonomies. This super-set-input, includes numerous entries that are not what you would call a vulnerability per-se.
2. If you look at the CWE project as a tree of 600+ vulnerability types, there are 104 (non-leaf) nodes, which describe categories, and not vulnerabilities.
3. Many of the CWE vulnerability types, are design issues, or business logic issues.

So, using the CWE information as-is, without digging deep into it, and understanding its structure and nature, will get you to the same conclusion, that automated tools only cover 45% of the CWE vulnerability types, while in reality, things are not as simple and bleak as they seem (check out the CWE full dictionary page, and you'll understand why I say it is not simple)

However, I do agree (and I did state this in this blog before) that automated tools have a lot of room for improvement, and that some things cannot be fully automated, but I certainly can't say (based on the current statistics) that they cover 45%, 65%, 75% or any other percentage of the vulnerabilities in the world.

In addition, I do believe that the CWE project is super-important, and will supply us with great statistics (that's why I was happy to participate in the project), which end users will be able to use for their benefit (evaluating tools, building proper testing processes), and tool vendors will be able to use for improving their products.

To wrap things up, you can read MITRE's official response to the whole CWE Pie Chart evolution, which they kindly posted on the Matasano Chargen blog, after I've raised my concerns to them about the validity of the pie chart that was circulating in the blogosphere.

Threat Classification

or: How I Learned to Stop Worrying and Love Web Application Threat Classifications

While working on the WASC Threat Classification v2.0 project, I got to think about the subject of classifying web application threats once again… You see, I have been dealing with Web Application Security Threat Classification since I started working on AppScan, approximately 7 years ago. back then (the Sanctum days), things were a lot simpler, the threat classes that were used in the product and in presentations, were proprietary, and were invented mainly for educational and marketing purposes.