Category Archives: Static Analysis

Announcing Support for PHP in WhiteHat Sentinel Source

It is with great pleasure that I formally announce support for the PHP programming language in WhiteHat Sentinel Source! Joining Java and CSharp, PHP is now a member of the family of languages supported by our static code analysis technology. Effective immediately, our users have the ability to start scheduling static analysis scans of web applications developed in PHP for security vulnerabilities. Accurately and efficiently supporting the PHP language was a tremendous engineering effort; a great reflection upon our Engine and Research and Development teams.

Static code analysis for security of the PHP programming language is nothing new. There are open source and commercial vendors already claiming support for this language and have done so for quite some time now. So what’s so special about the support for PHP in WhiteHat Sentinel Source? The answer centers on our advancement in the ability for static analysis to model and simulate the execution of PHP accurately. Almost every other PHP static code analysis offering is limited by the fact that it cannot overcome the unique challenges presented by dynamic programming languages, such as dynamic typing. With an inability to accurately model type information associated with expressions and statements, for example, users were unable to correctly capture rules needed to identify security vulnerabilities. WhiteHat Sentinel Source’s PHP offering ships with a highly tuned type inference system that piggy-backs off our patented Runtime Simulation algorithm to provide much deeper insight into source code – thereby overcoming the limitations of previous technologies.

Here is a classic PHP vulnerability that most, if not all, static code analysis tools should identify as a Cross-Site Scripting vulnerability:


$unsafe_variable = $_GET['user_input'];

echo "You searched for:<strong>".$unsafe_variable."</strong>";

This code retrieves untrusted data from the HTTP request, concatenates that input with string literals, and finally echoes that dynamically constructed content out to the HTML page. Writing static code analysis rules for any engine capable of data flow analysis is fairly straight forward… the return value of the _GET field access is a source of untrusted data and the first argument to the echo function invocation is a sink. Why is this easy to capture? Well… the signatures for the data types represented in the rules are incredibly simple. For example, the signature for the echo method is “echo(object)” where “echo” is the function name and “(object)” indicates that it accepts one argument whose data type is unknown. We assume all parameter types are the type ‘object’ to keep things simple; we cannot possibly know all parameter types for all function invocations without performing more rich analysis. Static analysis tools all have their own unique way of capturing security rules using a custom language. To keep discussions about static analysis security rules vendor agnostic, we will only be discussing rule writing and rule matching at the code signature level. Let’s agree on the format of [class name]->[function name]([one or more parameters]).

Let’s make this a little more interesting. Consider the following PHP code snippet that may or may not be indicative of a SQL Injection vulnerability:



$anonymous = new Anonymous ();

$anonymous->runQuery($_GET['name']);


This code instantiates a class called “Anonymous” and invokes the “runQuery” method of that class using unstrusted data from the HTTP request. Is this vulnerable to SQL Injection? Well – it depends on what runQuery does. Let’s assume that the Anonymous class is part of a 3rd party library for which we do not have the source or for which we simply do not want to include in the scan. Let’s also assume that we know runQuery dynamically generates and executes SQL queries and is thus considered a sink. Based on these assumptions, a manual code review would clearly indicate that yes, this is vulnerable to SQL Injection. But how would we do this with static analysis? Here’s where it gets tricky…

We want to mark the “runQuery” method of the “Anonymous” type as a sink for SQL commands such that if untrusted data is used as an argument to this method, then we have SQL Injection. The problem is we need to not only capture information about the “runQuery” in our sink rule, but we must also capture the fact that it is associated with the “Anonymous” class. The code signature that must be reflected in the security rule would look as follows: Anonymous->runQuery(object).

Unfortunately, basic forms of static analysis are unable to determine with reasonable confidence that $anonymous variable is of type Anonymous – in fact $anonymous could be of any type! As a result, the underlying engine is never able to match the security rule to the $anonymous->runQuery($_GET['name']) statement resulting in a lost vulnerability.

How does WhiteHat Sentinel Source’s PHP offering overcome this problem? it’s simple… in theory. When the engine first runs, it builds a model of the source code and attempts to compare the date sink rule against the $anonymous->runQuery($_GET['name']) method invocation. At this point, the only information we have about this statement is the method name and number of arguments producing a code signature as follows: ?->runQuery(object). Compare this signature to the signature represented in our sink rule: Anonymous->runQuery(object). Since we cannot know the type of the $anonymous variable at this point, we perform a partial match such that we only compare the method name and arguments to those captured in the security rule. Since the statement’s signature is a partial match to our rule’s signature, we mark the model as such and move on.

After processing all our security rules, the static code analysis engine will begin performing data flow analysis on top of our patented Runtime Simulation algorithm looking for security vulnerabilities. The engine will first see the expression “$anonymous = new Anonymous();” and actually record the fact that the $anonymous variable, at any point in the future, may be of type “Anonymous”. Next, the engine will hit the following statement “$anonymous->runQuery($_GET['name']);”. This statement was previously marked with a SQL Injection sink via a partial match. We now have more information about the $anonymous variable and now check if it is a full match with the original security rule. The statement’s signature is now known to be: Anonymous->runQuery(object) which fully matches the signature represented by the sink security rule. With a full match realized, the engine treats this statement as a sink and flags the SQL Injection vulnerability correctly!

Ok – that was a little too easy. Let’s make this more challenging… consider the following PHP code snippet:


$anonymous = null;

if (funct_a() > funct_b()) {
     $anonymous = new Anonymous();
} elseif (funct_a() == funct_b()) {
     $anonymous = new NotSoAnonymous();
} else {
     $anonymous = new NsaAnonymous();
}

$anonymous->runQuery($_GET['name']);

What the heck does the engine do now when it sees the runQuery statement? The engine will collect all data type assignments for the $anonymous variable and use all such types in an attempt to realize a full matching for the runQuery statement. The engine will see three different possible code signatures for the statement. They are as follows:

Anonyous->runQuery(object)
NotSoAnonymous->runQuery(object)
NsaAnonymous->runQuery(object)

The engine will take these three signatures and compare to the data type found in the signature represented by the partial match security rule. Given that the first of three signatures fully matches the signature represented by the security rule, the engine will treat the statement as a sink and flag the SQL Injection vulnerability correctly!

You may be asking yourself: “what if $anonymous was of type NotSoAnonymous or NsaAnonymous? Would it still flag a vulnerability?” The answer is a resounding yes. Static analysis technologies do not, and in my opinion should not, attempt to evaluate conditionals as such practice will lead to an overwhelming number of lost vulnerabilities. Static code analysis could support trivial conditionals, such as comparing primitives, but conditionals in real-world code require much more guesswork and various forms of heuristics that ultimately lead to poor results. Even so, is it not fair to say that at some point in the application “funct_a()” will be greater than “funct_b()”? Otherwise, what is the point of the conditional in the first place? Our technology assumes all conditionals will be true at some point in time.

Remember when I said this was easy in theory? Well, this is where it starts to get really interesting: Consider the following code snippet and assume we do not have the source code available for “create_class_1()”, “create_class_2()” and “create_class_3()”:


$anonymous = null;

if (funct_a() > funct_b()) {
     $anonymous = create_class_1();
} elseif (funct_a() == funct_b()) {
     $anonymous = create_class_2();
} else {
     $anonymous = create_class_3();
}

$anonymous->runQuery($_GET['name']);

Now what is the range of possible data types for the $anonymous variable when used in the vulnerable statement? This is where we being to stress the capabilities of the security rule language itself. WhiteHat Sentinel Source solves this by allowing the security rule writer to explicitly define the data type returned from a function invocation if such data type cannot be determined based on the provided source code. For example, the security rule writer could capture a rule stating that the return value of the create_class_3() function invocation is of type Anonymous. The engine would then take this information, propagate data types as before and correctly flag the SQL Injection vulnerability associated with runQuery method invocation.

WhiteHat Sentinel Source’s type inference system allows us to perform more accurate and efficient analysis of source code in dynamically typed languages. Our type inference system not only allows us to more accurately capture security rules, but it also allows us to more accurately model control flow from method invocations of instances to method declarations of class declarations. Such capability is critical for any real world static code analysis of PHP source code.

I hope you enjoyed this rather technical and slightly lengthy blog post. It was a blast building out support for PHP and I look forward to our Sentinel Source customers benefiting from our newly available technology. Until next time…

SAST Checklist for .NET and Agile Teams

For the last few years, the security industry has been wrestling with Agile development vis-a-vis security – specifically how Agile development can be used to help developers push more secure code, faster. More and more companies that we speak with have at least one team that is using Agile methodologies in-house. With these teams continually pushing code, it’s clear now more than ever that there’s a need for Static Application Security Testing (SAST) solutions that can continually scan applications and keep them secure.

During this same time, we have also been working on building .NET support into Sentinel Source, thanks to the extra-ordinary skill and perseverance of Eric Sheridan, Harry Papaxenopoulos, Michael Right, the entire SAST team, the exceptional rulepack researchers, and many others who know who they are! Personally, .NET and I go back quite a while. I co-authored one of the first C# database programming books to hit the market back in 2001, and I’ve been working with the platform ever since.

Support for the .NET framework in Sentinel Source is now going “GA”. While support for the .NET platform is not by itself necessarily earth-shattering news worthy of a blog post, thinking about these two topics has brought to mind what I think are several important points that developers should consider when looking at a static code analysis solution, particularly if they are working on an Agile project.

Specifically, I think it’s important for development and security teams to consider whether or not the SAST tool you’re considering meets the following criteria:

1. Does it work with the same source code you do and understand that source code? This helps you quickly fix vulnerabilities by suggesting actionable remediation. For .NET, that meant in addition to supporting ASP.NET Web Forms, ASP.NET MVC, etc., we needed to develop the ability to follow C# language semantics such as object indices, class properties, dynamic types, delegates, event handlers and lambda expressions. This level of affinity for the source code is not something that is very common, but it can be essential to quickly identifying vulnerabilities in C# code.

2. Does it integrate with your workflow? Does it get the source directly from source code repositories (Team Foundation Server, Subversion, GIT, etc.) out of the box? Conversely, does it make you build and upload, fire up a slow desktop tool and go through the painstaking process of working through a buggy thick client?

3. Does it find vulnerabilities in the source early in the process and can you perform scans at your convenience? If you’re trying to deliver code continuously or even quickly, you need a tool that performs scans quickly and continuously. If developers are notified as soon as possible that a security issue has been identified, less time and money is spent refactoring code. Being able to scan code at any stage in the development process, not just compiled applications, is a necessity for any Agile team.

4. Does it introduce false positives? If you’re trying to reduce wasted effort and time spent refactoring code, then you need to know how often your SAST solution will be introducing its own errors into the process. The only way I know of to reliably eliminate false positives is via a model such as the one adopted by WhiteHat with our Threat Research Center, where the source is scanned locally in your environment and snippets of code are sent out for verification (similar to they way consultants include snippets of code in their reports).

5. Is there something else about your SAST solution that will scare your boss? There are lots of gotchas out there. Some solutions send your company’s intellectual property offsite (compiled or not) to be scanned. Some solutions have hidden fees, limited users or limited use of reports.

Our latest Website Security and Statistics Report showed that shows that in two-thirds of organizations surveyed, developers are in some way considered a responsible party when it comes to website/application security, but they don’t have much control over fixing vulnerabilities. Our survey found that which vulnerabilities developers fix is often dictated by their managers or delayed by a pre-determined release schedule. Hopefully, the right tools for fixing applications early and often, coupled with Agile methods, will lead to more secure applications and more developers that are able to take control of the security of their own applications.

WhiteHat named a Leader in Application Security Testing in New Gartner Magic Quadrant Report

This week marks the release of the Gartner “Magic Quadrant for Application Security Testing,” the first ever to combine Dynamic and Static Application Security Testing (DAST and SAST). WhiteHat Security has been placed in the leaders quadrant. We believe this recognizes our corporate vision to provide best-in-class application security testing solutions, our work as a “pioneer” in the space, and our execution in bringing products to market that meet the needs of the enterprise and SME user.

As we and our customers know, WhiteHat has risen from being a challenger to industry veterans and is now a formidable competitor in our industry. We believe that WhiteHat’s solutions are delivering what the enterprise market is demanding: easy-to-implement, scalable, comprehensive solutions to keep ahead of web security threats.

While trendy buzzwords come and go, the facts are clear. Applications remain the easiest way for attackers to gain access to your organization’s critical data. As businesses of all sizes have become aware of application security, they have searched for solutions to a complex and seemingly insurmountable problem. The 100-person, single-site e-commerce company has very different requirements than the 50,000-employee multi-national corporation. WhiteHat understood very early on that application security is not a “one-size-fits-all” challenge, and as such we offer three tiers of service to address the breadth and depth of coverage an organization may need.

In an industry that often bemoans the fact that there a too few experts to handle the load, we built WhiteHat Sentinel from the ground up as a software-as-a-service solution. Customers receive not only a technology solution, but an extension of their application security team with WhiteHat’s world-class Threat Research Center (TRC). Unlike software-only solutions, the TRC gives remediation advice, verifies all findings, and handles all the administration of the solution, freeing in-house security staff to focus on strategic projects and remediation strategies. Additionally, technology innovations, like integration with application security firewalls on the DAST side, plus IP protection on the SAST side, make Sentinel stand out from the pack.

Ultimately, this honor belongs to WhiteHat’s incredible staff and to our customers. Our team has grown to more than 300 individuals who are passionate about application security and making Sentinel the best it can be. Our customers, many of whom have been with us for years, make us better each day. Their enthusiastic use of Sentinel, and honest feedback regarding features and functionality, have driven improvements and product direction, like the addition of Sentinel Source to our service portfolio. We are pleased with this recognition, which will further stoke our drive to innovate and bring application security solutions to market that keep our customers ahead of the evolving threats.

A full copy of the Gartner “Magic Quadrant for Application Security Testing”* can be found here.

*Gartner Inc., “Magic Quadrant for Application Security Testing” by Neil MacDonald and Joseph Feiman, July 2, 2013. Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.

Editor’s note: Portions of this blog post were updated on July 14, 2013 to comply with Gartner’s strict Copyright and Quote policy.

A Case of Unchecked Redirect

It had been a long, drawn out week for Vic. Sitting in the office late on a Friday afternoon, he found himself browsing the Internet to pass the last hour at the office (he had dutifully completed his to-do list earlier in the day). Unexpectedly, email popped into his inbox from his bank, offering a $250 credit awarded by simply taking part in a marketing survey.

At first glance Vic was incredulous… would his bank really give away $250 just for a survey? He reread the email again, and paid special attention to the link it provided.

He carefully and suspiciously inspected the URL; it definitely was from his bank.

http://www.bankoftrusty.com/login.aspx?ReturnURL=http%3A%2F%2Fis.gd%2FreoE2c

The beginning of the URL was http://www.bankoftrusty.com/ so he knew it was legitimate, but just to be extra sure he copied and pasted the link directly into his browser. As he expected, the link took him to his bank’s login page. He entered his credentials and clicked on the log in button. Upon logging in, he was presented with the reward – the five-question survey that paid out a jackpot of $250. “Wow, they must really be desperate for my feedback” thought Vic, as he smiled and filled out the form. Five clicks and he was done.

The next page asked him for 3 final pieces of information – the bank account number where he wanted the funds to be deposited, his social security number to verify his identity, and a re-entry of his password.

After the survey was complete, he was a bit miffed to discover the funds would “take up to 4 weeks to process.” Minutes later, he was out the door heading home for the weekend, and the attackers who had tricked Vic into giving up his personal identification and other account information were already busy using Vic’s information for illicit gain. Months later, Vic still wouldn’t understand what happened. He had checked the link carefully, and it had been to his bank. How had the criminals stolen his information?

Falling Victim to Unchecked Redirect

Unfortunately Vic fell prey to a type of web vulnerability called Unchecked Redirect. Unchecked Redirect, or “Unvalidated Redirect,” can be exploited when an attacker manipulates redirection functionality found in most web applications. The attacker then crafts a malicious URL which abuses the redirect functionality by hiding a malicious website address in a legitimate URL. The poisoned URL is passed as a parameter, which the application retrieves and then forwards the user to. This attack leverages the trust users have in the target domain.

Analyzing the Code

In Java, an Unchecked Redirect vulnerability may look something like this:

public class ForwardingServlet extends HttpServlet {
  protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
    String forwardUrl = request.getParameter("forwardUrl");
    response.sendRedirect(forwardUrl);
  }
}

Using URL references instead of direct URLs could be implemented as follows:

public class ForwardingServlet extends HttpServlet {
  protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
    String urlKey = request.getParameter("urlKey");
    String forwardUrl = getRealURL(urlKey);
    if (null != forwardUrl) response.sendRedirect(forwardUrl);
  }
}

The following example shows how to safely use actual URLs from user input by checking whether the user is authorized for this URL and whether the URL is permitted:

public class ForwardingServlet extends HttpServlet {
  protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
    String forwardUrl = request.getParameter("forwardUrl");
    String userId = session.getAttribute("USER_ID");
    if (canRedirect(userId, forwardUrl)) // check the URL against the whitelist
      response.sendRedirect(forwardUrl);
    else
      logger.warn("An unauthorized redirect URL submitted.");
  }
}

ASP.NET

In C#, an Unchecked Redirect vulnerability may look something like this:

string forwardUrl = Request.QueryString["forwardUrl"];
Response.Redirect(forwardUrl);

Using URL references instead of direct URLs could be implemented as follows:

string urlKey = Request.QueryString["urlKey"];
string forwardUrl = GetRealURL(urlKey);
if (null != forwardUrl) {
  Response.Redirect(forwardUrl);
}

PHP

In PHP, a Unchecked Redirect vulnerability may look something like this:

<?php

  $forward_url = $_GET['forwardUrl'];
  header("Location: " . $forward_url);

Using URL references instead of direct URLs could be implemented as follows:

<?php

  $url_key = $_GET['urlKey'];
  $forward_url = get_real_url($url_key);

  if (! is_null($forward_url) {
    header("Location: " . $forward_url);
  }

Explanation of the Defense Against Unchecked Redirect

Typically you can avoid the risk of Unchecked Redirect by using direct URLs instead of redirects and forwards. If complete avoidance of redirects is not feasible, make sure that any user input used to form a URL for redirect is thoroughly validated and does not send the user to an untrusted domain.

The best way to implement redirects is to map actual URLs to reference keys and process user input as a key rather than a real URL. If there is a business need in passing actual URLs in the request, the validation process should include a check as to whether a URL from the input is a trusted URL – this can be accomplished by maintaining a “whitelist” of permitted URLs.

It is also a good practice to display a warning page to let users know that they are leaving your domain, if applicable, and allow them to choose whether to follow the link or stay on the current website.

All that being said, had Vic’s bank had some of these precautions in place, his experience may very well have been different. His Friday afternoon might have led to a fantastic weekend and he would not have had to worry that his attempt at a $250 credit would lead to the compromise of his personal information.

WhiteHat Sentinel Source is Born!

June 1st 2012 was the official one-year mark since WhiteHat Security and Infrared Security decided to join forces to create WhiteHat Sentinel Source. After a significant amount of hard work from a lot of great people, WhiteHat Sentinel Source has gone public! I’m going to use this opportunity to write up a bit of a nostalgic blog post… while still keeping my Don Draper game face on of course. Having been an application security consultant for years, I’ve developed a pretty big chip on my shoulder as it relates to existing static analysis tools. I said to myself time and time again… “There has to be a better way to do this!” I put that energy to good use and infused our technology and service offering with the following core static analysis values that truly separate WhiteHat Sentinel Source from the competition:

1. Invest in Performance:

In order to support an Agile-paced development world, performance of both scan time and verification turnaround time are critical to success. We are constantly investing in our core technology and processes to ensure we get the fastest turnaround time possible!

2. Support Modern Programming Paradigms:

Development teams have adopted various modern programming paradigms and technologies that throw existing static analysis tools for a loop. Such paradigms and patterns include: Object-Oriented Programming, Aspect-Oriented Programming, Inversion of Control, Dependency Injection, etc. We are constantly striving to ensure that our technology has the ability to support these paradigms to accurately model modern source code!

3. Strive for Actionable Results:

Reviewing 100+ “findings” is a complete burden and dilutes the value of the technology. We are striving for quality over quantity throughout our core engine and RulePack development processes! “No grep-like rules” is something you’ll hear me say frequently.

4. Provide Feedback Early:

Performing source code scans at the end of a development initiative or even when the project distributable can be built is too late! Teams are constantly requesting feedback during the development phases, not at the end. We are constantly striving to ensure our ability to integrate with source code repositories such that we can provide feedback early in the development phase. This coupled with our core technology performance makes daily scans a possibility!

5. Leave Security to Security:

Putting a large static analysis report in front of a developer expecting them to triage and fix the results is a complete waste of time and energy. We are constantly striving to ensure that we enable developers to more effectively remediate significant vulnerabilities by performing the triage ourselves.

While the success of WhiteHat Sentinel Source is attributable to many individuals, there are a few folks who really stand out:

Jerry Hoff (VP, Static Analysis Division):

Jerry is an incredibly well-rounded application security expert and a long-time friend. Jerry played a critical role in disseminating our static analysis strategy to the rest of the team and really bootstrapped our ability to talk about static analysis in a way that actually makes sense to people. I always thought I had a great ability to make application security topics digestible until I met this guy. Very much a forward-thinking person, I refuse to have strategic discussions without his input. Jerry has been helping me push static analysis since day 1 at Infrared Security, and now at WhiteHat. We would have not even gotten half this far without his efforts… thank you Jerry!

Siamak Pazirandeh (Senior Software Architect):

Siamak is an incredibly talented developer, architect, and leader. The benevolent development dictator, Siamak (a.k.a. Max) was responsible for spearheading the integration of static analysis into WhiteHat’s existing DAST service model. This large effort involved designing and building a persistency model for evolving codebases optimized for the purpose of verification, scalability design, service delivery architecture, middleware integration, and overall project leadership. He’s already solved challenges with DAST, why not solve SAST too… thank you Max!

John Melton (Senior Application Security Researcher):

John too is an incredibly well-rounded application security expert with serious technical depth in Java. With his astounding work ethic, attention to detail, and everlasting pursuit of perfection, John Melton has become the lead of the Sentinel Source Java engine and RulePack R&D. His abilities and core values around product development provide me with the confidence I need so that I can focus energies on other development initiatives. He is also one of fewer than five people in the world who can very directly and bluntly call me out on my mistakes without me feeling insulted. I think it has to do with his southern accent… thank you John!

With the core technology in place and our integration with the Sentinel interface, WhiteHat Sentinel Source is ready! We fully intend to shake up this market and will continue to push forward with real innovation. We are making the pledge to strive for accuracy, timeliness and usability with our solution. We look forward to other vendors stepping up to our plate… competition will only make us work harder!!