Category Archives: Web Application Security

What the InfoSec Skills Gap Means for the Future

One of the biggest challenges – if not the biggest challenge – facing information security is the lack of skilled talent. As yet another proof point in a long line of reports all saying the same thing, Cisco’s 2014 Annual Security Report says, “it’s estimated that by 2014, the [IT Security] industry will still be short more than a million security professionals across the globe.” You ask any hiring manager, and they’ll agree. And here’s the thing, we might be able to make a dent in the skill gap with education programs, but by-and-large, the information security skills shortage isn’t going to get solved any time soon.

This says to me…

  1. Breaches will continue at least at the current clip resulting in increased industry and government regulations, which will lead to compliance job openings.
  2. Compensation for competent information security personnel will continue to rise and globalize, regardless of whether the person is experienced or not.
  3. Organizations in the best position to hire, train, and retain security talent will carry the day. Education isn’t going to come in the form of reading or certification, but on the job in a more “trial by fire” way.
  4. Organizations will continue to outsource their security needs to where security talent can be best centralized and scaled.
  5. People with limited background in security will be increasingly tasked with performing security jobs – or at least managing the processes.
  6. Super easy-to-use security products and services will be preferred over the more technically sophisticated and feature rich.
  7. The information security skill shortage is actually going to get worse as the economy improves.

Everyone get busy automating!

6 Reasons Why ‘Security Guarantees’ Are Good For The Security Community

Since Sentinel Elite was announced, we’ve experienced an exciting amount of interest in it’s money-back guarantee and $250,000 financial coverage for damages suffered if a customer is breached via a vulnerability that we should have discovered but missed. Over the last few weeks, the security community has been buzzing with chatter about software liability, cyber-insurance, and security guarantees. There is an opportunity here for the information security industry to up its game. When done right, security guarantees are going to be really good for the security community. Here’s why:

  1. Truly effective security products become easier for customers to differentiate from those that are…less effective. Similar to how we look at the purchase of cars, electronics, and more, some products have better warranties than others, which signals less purchase risk for the buyer and an increase in perceived quality.
  2. The credibility of the security industry, or individual vendor, is improved because we hold ourselves accountable for the performance of our products. Let’s face it. Security vendors don’t always have a great reputation when viewed by those outside the industry. One argument for why this is, is that when our advice or products fail, we’re not on the hook. Many vendors even profit when disaster strikes, yet the victims – our customers – are left cleaning up the mess. By making ourselves accountable in the event of a breach we can turn this perception around and prove that our goals do align with our customers.
  3. We receive performance and actuarial data that can be directly used to increase the effectiveness of our products. The upside on having to pay-out on a failure to live up to a security guarantee is that we get hard data on what really went wrong. This data is helpful because it tells us why the security control didn’t stop the bad guy. This data is pure gold for product development.
  4. It gives us the ability to quantify and convey the value of security products in dollars and cents. Most often business owners really don’t get the value of what it is that a security product does. We speak in esoteric terms about ‘vulnerability,’ ‘risk,’ ‘threat,’ ‘zero-day,’ and so on – very rarely do we speak in business terms or in dollars and cents that the business owner can truly understand. With security guarantees we can give stakeholders – those who pay for our solutions – a way to understand the value we bring to the business in language they understand and can plug into their financial spreadsheets.
  5. The business interests of a security company are in line with the customer and decisions are made accordingly. One of the most frustrating things for a security professional is encountering situations when what a customer really needs to be more secure is not necessarily what is beneficial for the security vendor. Customers want to spend money on products that help them protect against getting hacked. When vendors provide security guarantees, the highest priority is doing exactly that, which creates a true partnership between the vendor and the customer.
  6. Security guarantees enable defense-in-depth strategies to transcend the concept of simply buying multiple security products to protect the business in the event of financial loss. We know security products are not perfect or all-encompassing, so multiple solutions are needed to guard against breach under this eventuality. With a security guarantee, when all is said and done, the customer is still protected in the event that everything fails – which is more common than not these days.

We continue to appreciate the feedback on this topic and are very much interested in what our customers and the rest of the industry has to say about this. What other reasons are there – positive or negative – for having security guarantees? We would welcome your suggestions in the comments below.

Security Guaranteed: Customers Deserve Nothing Less

WhiteHat Security Sentinel Elite

Ever notice how everything in the information security industry is sold “as is”? No guarantees, no warrantees, no return policies. This provides little peace of mind that any of the billions that are spent every year on security products and services will deliver as advertised. In other words, there is no way of ensuring that what customers purchase truly protects them from getting hacked, breached, or defrauded. And when these security products fail – and I do mean when – customers are left to deal with the mess on their own, letting the vendors completely off the hook. This does not seem fair to me, so I can only imagine how a customer might feel in such a case. What’s worse, any time someone mentions the idea of a security guaranty or warranty, the standard retort is “perfect security is impossible,” “we provide defense-in-depth,” or some other dismissive and ultimately unaccountable response.

Still, the naysayers have a valid point. Given enough time and energy, everything can be hacked, including security products, but this admission does not inspire much confidence in those who buy our warez and whose only fear is getting hacked. We, as an industry, are not doing anything to alleviate that fear. With something as important as information security is today, personally I think customers deserve more assurance. I believe customers should demand accountability from their vendors in particular. I believe the “as is” culture in security is something the industry must move away from. Why? Because if it were incumbent upon vendors to stand by their product(s) we would start to see more push against the status quo and, perhaps, even renewed innovation.

At the core of the issue is bridging the gap between the “nothing-is-perfect” mindset and the business requirements for providing security guarantees.

If you think about it, many other industries already offer guarantees, warrantees, or 100% return policies for less than perfect products. Examples include electronics, clothing, cars, lawn care equipment, and basically anything you buy on Amazon. As we know, all these items have defect rates, yet it doesn’t appear to prevent those sellers from standing behind their products. Perhaps the difference is, unlike most security vendors, these merchants know their product failure rates and replacement costs. This business insight is precisely why they’re willing to reimburse their customers accordingly. Security vendors by contrast tend NOT to know their failure rates, and if they do, they’re likely horrible (anti-virus is a perfect example of this). As such, vendors are unwilling to put their money where their mouth is, the “as is” culture remains, and interests between security vendor and customer are misaligned.

The key then, is knowing the security performance metrics and failure rates (i.e. having enough data on how the bad guys broke in and why the security controls failed) of the products. With this information in hand, offering a security guarantee is not only possible, but essential!

WhiteHat Security is in a unique position to lead the charge away from selling “as is” and towards security guarantees. We can do this, because we have the data and metrics to prove our performance. Other Software-as-a-Service vendors could theoretically do the same, and we encourage them to consider doing so.

For example, at WhiteHat we help our customers protect their websites from getting hacked by identifying vulnerabilities and helping to get them fixed before they’re exploited. If the bad guys are then unable to find and exploit a vulnerability we missed, or if they decide to move on to easier targets, that’s success! Failure, on the other hand, is missing a vulnerability we should have found which results in the website getting hacked. This metric – the product failure rate – is something any self-respecting vulnerability assessment vendor should track very closely. We do, and here’s how we bring it all together:

  1. WhiteHat’s Sentinel scanning platform and the 100+ person army of Web security experts behind it in our Threat Research Center (TRC) tests tens of thousands of websites on a 24x7x365 basis. We’ve been doing this for more than a decade and we have a larger and more accurate website vulnerability data set than anyone else. We know with a fine degree of accuracy what vulnerabilities we are able to identify – and which ones we are not.
  2. We also have data sharing relationships with Verizon (and others) on the incident side of the equation. This is to say we have good visibility into what attack techniques the bad guys are trying and what they’re likely to successfully exploit. This insight helps us focus R&D resources towards the vulnerabilities that matter most.
  3. We also have great working relationships with our customers so that when something unfortunate does occur – which can be anything from something as simple as a ‘missed’ vulnerability, to a site that was no longer being scanned by our solution that contained a vulnerability, all the way to a real breach – we’re in the loop. This is how we can determine whether something we missed and should have found actually results in a breach.

Bottom line: in the past 10+ years of performing countless assessments and identifying millions of vulnerabilities, there have been only a small number of instances in which we missed a vulnerability that we should have found that we know was likely used to cause material harm to our customers. All told, our failure rate is far less than even one percent (<.01%), which is an impressive track record and one that we are quite proud of. I am not familiar with any other software scanning vendor who even claims to know what their failure rate metric is, let alone has the confidence to publicly talk about it. And it is for this reason that we can confidently stand behind our own security guarantee for customers with the new Sentinel Elite.

Introducing: Sentinel Elite

Sentinel Elite is a brand new service line from WhiteHat in which we deploy our best and most comprehensive website vulnerability assessment processes. Sentinel Elite builds on the proven security of WhiteHat Sentinel, which offers the lowest false-positive rate of any web application security solution available as well as more than 10 years of website vulnerability assessment experience. This service, combined with a one-of-a-kind security guarantee from WhiteHat gives customers the confidence in both their purchase decisions as well as the integrity of their websites and data.

Sentinel Elite customers will have access to a dedicated subject matter expert (SME) who expedites communication and response times, as well as coordinates the internal and external activities supporting your applications security program. The SME will also supply prioritized guidance support, so customers know which vulnerabilities to fix first… or not! Customers also receive access to the WhiteHat Limited Platinum Support program, which includes a one-hour SLA, quarterly summaries and exploit reviews, as well as a direct line to our TRC. Sentinel Elite customers must in turn provide us with what we need to do our work, such as giving us valid website credentials and taking action to remediate identified vulnerabilities. Provided everyone does what they are responsible for, our customers can rest assured that their website and critical applications will not be breached. And we are prepared to stand behind that claim.

If it happens that a website covered by Sentinel Elite gets hacked, specifically using a vulnerability we missed and should have found, the customer will be refunded in full. It’s that simple.

We know there will be those in the community who will be skeptical. That’s the nature of our industry and we understand the skepticism. In the past, other security vendors have offered half-hearted or gimmicky guarantees, but that’s not what we’re doing here. We’re serious about web security, we always have been. We envision an industry where outcomes and results matter, a future where all security products come with security guarantees, and most importantly, a future where the vendors’ best interests are in line with their customers’ best interests. How amazing would that be not only for customers but also for the Internet and the world we live, work and do business in? Sentinel Elite is the first of many steps we are taking to make this a reality.

For more information about Sentinel Elite, please click here.

A Security Expert’s Thoughts on WhiteHat Security’s 2014 Web Stats Report

Editor’s note: Ari Elias-Bachrach is the sole proprietor of Defensium LLC. Ari is an application security expert. Having spent significant time breaking into web and mobile applications of all sorts as a penetration tester, he now works to try and improve application security. As a former developer who has experience with both static and dynamic analysis he can work closely with developers to try and remediate vulnerabilities. He has also developed and taught secure development classes, and can help make security part of the SDLC. He is a regular speaker on the field of application security at conferences. He can be found on Twitter @angelofsecurity. Given his experience and expertise, we asked Ari to review our 2014 Website Security Statistics Report which was announced yesterday to get his thoughts which he has shared as a guest blog post.

The most interesting and telling chart in my opinion is the Vulnerability class by language chart. I decided to start by asking myself a simple question: can vulnerabilities be dependent on the language used, and if so which vulnerabilities? I did a standard deviation on all vulnerability classes to see which ones had a high degree of variance across the different languages. XSS (13.2) and information leakage (16.4) were the two highest. In other words, those are the two vulnerabilities which can be most affected by the choice of programming language. In retrospect info disclosure isn’t surprising at all, but XSS is a little interesting. The third one is SQLi, which had a standard deviation of 3.8, and everything else is lower than that.

Conclusion 1: The presence or absence of Cross-site scripting and information disclosure vulnerabilities is very dependent on the environment used, and SQLi is a little bit dependent on the environment. Everything else isn’t affected that much.

Now while it seems that frameworks can do great things with respect to security, if you live by the framework, then you die by the framework. Looking at the “Days vulnerability open by language” chart, you can see some clear outliers where it looks like certain vulnerabilities simply cannot be fixed. If the developer can’t fix a problem in code, and you have to wait for an update to the framework, then you end up with those few really high mean times to fix. This brings us to the negative consequences of relying on the framework to take care of security for us – it can limit our ability to make security fixes as well. In this case the HTTP response splitting issue with ASP are both problems that cannot be fixed in the code, but require waiting for the vendor to make a change, which they may or may not judge necessary.

Conclusion 2: Live by the framework, die by the framework.

Also interesting is that XSS, which has the highest variance in occurrence, has the least variance in terms of time to fix. I guess once it occurs, fixing an XSS issue is always about the same level of effort regardless of language. Honestly I have no idea why this would be, I just find it very interesting.

Conclusion 3: Once it occurs, fixing an XSS issue is always about the same level of effort regardless of language. I can’t fathom the reason why, but my gut tells me it might be important.

I found the “Remediation rate by vulnerability class” chart to be perhaps the most surprising (at least to me). I would have assumed that the remediation rates per vulnerability would have been more closely correlated to the risk posed by each vulnerability, however that does not appear to be the case. Even more surprisingly, the remediation rates do not seem to be correlated to the ease of fixing the vulnerability, as measured by the previous chart on the number of days each vulnerability stayed open. Looking at SQLi for example, the remediation rate is high in asp, ColdFusion, .NET, and Java, and incredibly low in PHP and Perl. However PHP and Perl were the two languages where SQLi vulnerabilities were fixed the fastest! Why would they be getting fixed less often than other environments? XSS likewise seems to be easiest to fix in PHP, yet that’s the least likely place for it to be fixed. Perhaps some of this can be explained by a single phenomena – in some environments, it’s not worth fixing a vulnerability unless it can be done quickly and cheaply. If it’s a complex fix, it is simply not a priority. This would lead to low remediation rates and low days to patch at the same time. In my personal (and purely empirical non-scientific) experience, perl and php websites tend to be put up by smaller organizations, with less mature processes and a lesser emphasis on security and a greater focus on continuing to create new features. That may explain why many Perl and PHP vulnerability are either fixed fast or not at all. Without knowing more, my best guess is that many of the relationships here, while correlated, do not appear to be causal. In other words, some other force, like organizational culture, is driving both the choice of language and the remediation rate.

Conclusion 4: Remediation rates do vary across language, but the reasons seem to be unclear.

Final Conclusions
I started off with a very basic question “does choice of programming language matter”, and the answer does seem to be yes. While we all know that in theory there is no vulnerability that can’t exist in a given environment, and there’s no vulnerability that can’t be fixed in any given environment, the real world rarely works as neatly as it should “in theory”. Certain vulnerabilities are more likely in certain environments, and fixes may be easier or harder to apply, which impacts their likelihood of ever being applied. There has been a lot of talk lately about moving security into the framework, and this does provide evidence that this approach can be very successful. However it also shows the risks of this approach if the framework does not implement the right security controls and in the right way.

Relative Security of Programming Languages: Putting Assumptions to the Test

“In theory there is no difference between theory and practice. In practice there is.” – Yogi Berra

I like this quote because I think it sums up the way we as an industry all too often approach application security. We have our “best practices” and our conventional wisdom of how we think things operate, what we think is “secure” and standards that we think will constitute true security, in theory. However, in practice — in reality — all too often we find that what we think is wrong. We found this to be true when examining the relative security of popular programming languages, which is the topic of the WhiteHat Security 2014 Website Statistics Report that we launched today. The data we collected from the field defies the conventional wisdom we carry and pass down about the security of .Net, Java, ASP, Perl, and others.

The data that we derived in this report puts our beliefs around application security to the test by measuring how various web programming languages and development frameworks actually perform in the field. To which classes of attack are they most prone, how often and for how long? How do they fare against popular alternatives? Is it really true that the most popular modern languages and frameworks yield similar results in production websites?

By examining these questions and approaching their answers not with assumptions, but with hard evidence, our goal is to elevate conversations around how to “build-in” security from the start of the development process by picking a language and framework that not only solves business requirements, but security requirements as well.

For example, whereas one might assume that newer programming languages such as .Net or Java would be less prone to vulnerabilities, what we found was that there was not a huge difference between old languages and newer frameworks in terms of the average number of vulnerabilities. And when it comes to remediating vulnerabilities, contrary to what one might expect, legacy frameworks tended to have a higher rate of remediation – in fact, ColdFusion bested the whole field with an average remediation rate of almost 75% despite having been in existence for more than 20 years.

Similarly, many companies assume that secure coding is challenging because they have a ‘little bit of everything’ when it comes to the underlying languages used in building their applications. in our research, however, we found that not to be completely accurate. In most cases, organizations have a significant investment in one or two languages and very minimal investment in any others.

Our recommendations based on our findings? Don’t be content with assumptions. Remember, all your adversary needs is one vulnerability that they can exploit. Security and development teams must continue to measure their programs on an ongoing basis. Determine how many vulnerabilities you have and then how fast you should fix them. Don’t assume that your software development lifecycle is working just because you are doing a lot of things; anything measured tends to improve over time. This report can help serve as a real-world baseline to measure against your own.

To view the complete report, click here. I would also invite you to join the conversation on Twitter at #2014WebStats @whitehatsec.

Aviator Status – 100k Downloads and Growing!

I realize it’s only been a handful of days since we launched the Windows version of Aviator, but it’s been an exciting ride. If you’ve never had to support a piece of software, it feels a bit like riding an unending roller coaster — you’re no longer in control once you get on the ride put your software out there. People will use it however they use it, and as the developer you simply have to adapt and keep iterating to make the user experience better and better. You can never get off the ride, which is a wonderful feeling – if you happen to like roller coasters! Okay, enough with that analogy.

When we released Aviator for Mac in October, we felt we were onto something when people started – almost immediately – emailing us asking us for features. We were sure we were on the right track when the media started writing articles. And when the number of downloads climbed from the thousands to tens of thousands to close to 45,000 Mac OSX downloads in just five months, we thought we were getting pretty incredible traction. But none of that prepared us for the response we received in just the handful of days since we launched Aviator for Windows. In just 5 days since the Windows launch, we have already hit a total number of 100,000 Aviator users – and that is without spending a single dime on advertising!

We were also pleasantly surprised that a huge chunk of our users came from other regions – as much as 30% of our new Windows user base was from Asia. This means that Aviator is already making a difference in every corner of the world. We’re extremely excited by this progress, and are very encouraged to continue to iterate and deliver new features. I think this really shows how visceral people’s reaction to security and privacy is. It’s no wonder – we’ve never given this kind of control to users before. Either that or our users got wind of how much faster surfing without ads and third-party tracking can be. :) Ever tried to surf the Internet on in-flight wireless? With Aviator you will find that websites are actually usable — give it a try!

We may never know why so many people chose Aviator, but I do hope more people share their user stories with us. We want to know our successes as well as the challenges that remain before us as we continue on this unending roller coaster ride. We really do appreciate all of your feedback and we thank you for helping to make Aviator such a huge success, right out of the gate. We’re just getting started!

Download WhiteHat Aviator for Windows or Mac here: http://www.whitehatsec.com/aviator

Re: Mandated Third Party Static Analysis: Bad Public Policy, Bad Security

Mary Ann Davidson wasn’t shy making her feelings known about scanning third-party software in a lively blog post entitled “Mandated ThirdParty Static Analysis: Bad Public Policy, Bad Security“. If you haven’t read it and you are in security, I do recommend giving it a read. Opinionated and outspoken, Mary Ann lays out her case for not scanning third-party software. In this case, although I don’t totally agree with each individual point, I do agree with the overall conclusion.

Mary Ann delineates many individual reasons organizations should not scan third-party COTS (Commercial Off The Shelf) software. The reasons include non-standard practice, vendors already scan, little-to-no ROI, harm to the product’s overall security, increased risk to other clients, uneven access to security information, and risks to IP protection. I think the case can actually be greatly simplified. Scanning COTS software is simply a waste of time because that is not where most organizations are going to find and reduce risk.

Take web applications, which is at the top of every CISO’s usual list of suspects for risk. Should every organization on the web perform a complete security review of every single layer in this technology stack? Or how about mobile? Should an organization perform a complete review of iOS and Android before writing a mobile app or allowing employees to use mobile phones? I’m sure the consulting industry would love this, but this is simply not feasible for organizations of any size.

So what are we to do? In my opinion, a security team should strive to measure and mitigate the greatest amount of risk to an organization within it’s budgetary and time limitations, enabling business to innovate with a reasonable amount of security assurance. For the vast majority of applications, that formula is going to lead directly to their own custom-written or custom outsourced software; specifically, their web applications.

Most organizations have a large number of web apps, a percentage of which will have horrific vulnerabilities which put the entire organization at risk. These vulnerabilities are well-known, very prevalent, and usually straightforward to remediate. A security program that provides continuous assessment for all the code written and/or commissioned by your organization both during development and deployment should be the front line of security for nearly every organization with a presence on the web, as it normally finds a trove of preventable risk that would otherwise be exploitable to attackers on the web.

So what is the problem with scanning our custom code and third-party COTS software? It is a misallocation of resources. Unless you have unlimited budget and time, you are much better off focusing and evaluating your custom-written source code for vulnerabilities, which can be ranked by criticality and mitigated by your development team.

Again, that is not to say there are no risks in using COTS software. Of course there are. All software has vulnerabilities. Risks are present in every level of a technology stack. For example, a web app may depend on a BIOS/UEFI, an OS, a web server, a database server, an application server, multiple server-side frameworks, multiple client-side frameworks, and many other auxiliary programs.

But the likelihood of your organization performing yet another evaluation of software that has most likely already gone through a security regimen is exponentially less effective in managing risk than focusing more of your security resources on building a more robust security program around your own in-house custom software.

Well, what should we do to mitigate third-party risk? The most overlooked and basic security precaution is to have a full manifest of all third-party COTS and open-source code running in your environment. Few, if any organizations have a full listing of all third-party apps and libraries they use. Keeping an account of this information, and then doing frequent checks for security updates and patches for this third-party code is obvious and elementary, but almost always universally overlooked.

This basic security formula of continuous scanning of custom applications, checking third-party libraries for security updates, and using this information to evaluate the biggest risks to your organization and working to mitigate the most severe risks would have prevented most of the successful web attacks that make daily headlines.

WhiteHat Aviator Beta for Windows

Since launching the Mac version of WhiteHat Aviator in October, the number one most-asked-for feature was a Windows version of the browser. Today we hit a major milestone: our Labs team is excited to announce that we are launching the Windows beta. If you want to try it, please download Aviator for Windows here.

Outside of keeping our blog and Twitter followers up-to-date since it’s release in October, we have done little-to-nothing to get attention for Aviator. There has been no marketing or sales resources invested in Aviator. Despite this, we’ve gotten tens of thousands of downloads with our Mac OSX version, and that number has been growing rapidly as the world takes notice.

Now the obvious next question everyone will ask is: “when do I get a version for XYZ operating system?” While we know this is highly important to a lot of our users, we have to balance that with a number of other features — which leads us to perhaps the second most-asked question: “how are you making money on Aviator?” The answer is, right now we aren’t. Therefore, some of our efforts will also be directed towards determining how to sell this in a way that does not involve profiting from our users’ information as many other browsers are in the unfortunate business of doing. As the saying goes, “if you aren’t paying for it, you’re the product.”

That said, we want to make sure that all of our existing users of WhiteHat Aviator know that they will continue to get the browser for free, forever. That’s right! Once we have determined how to monetize it, only new users will need to pay for a license. So, by all means encourage your friends to download it now, so they can enjoy Aviator for free, forever. This is our small way of thanking early Aviator adopters: if you’re one of them, you will never have to pay. A safer browser with free lifetime technical support? It’s unheard of, I know!

Don’t worry, we have a lot of exciting features on the horizon, and we do plan on supporting a number of additional operating systems. One thing at a time! We are thrilled with the hundreds of people who have written encouraging emails, made suggestions, offered feedback and sent us bug reports. We know we’ve hit a nerve and we’re excited by the prospect of a better, faster browser that works for the masses.

Lastly, a special thanks to all of our Windows Alpha testers and Mac Beta testers, without whom we surely wouldn’t have had such a well thought-out product. Please keep your feedback coming! Your input is critical for improving future Aviator versions.

iCEO

As many of you know, I started WhiteHat Security more than 10 years ago with the mission to help secure the Web, company by company. It has been an incredible roller coaster ride over the past decade, both at WhiteHat Security, which has experienced phenomenal growth, as well as within the industry itself. By that I mean that we have come a long way: organizations and companies are now more aware of how critical their presence is on the web, and therefore how crucial it is that they ensure that presence is secure. I am proud to say that we now manage more than 30,000 websites today, but with more than 900 million websites on the Internet today, we clearly still have a long way to go. And with that, I am pleased to announce that I have accepted the WhiteHat Security Board of Director’s invitation to step in to the role of interim CEO of WhiteHat Security.

I am very proud of what this company has achieved since 2001: we have grown from a team of one to more than 350 passionate contributors in all areas of the business, including the world’s largest army of hackers; we have received some of the highest industry accolades and awards out there; WhiteHat Sentinel is now a leading web application security solution for nearly 600 of the world’s best-known brands, and we continue to experience exponential growth. All of this success is due in large part to the leadership and direction of our former CEO Stephanie Fohn who took a leap of faith with us more than 8 years ago and who will remain one of the company’s biggest supporters. I would be remiss if I did not acknowledge the work and dedication that she has put in to this company and I wish her the best as she takes time to be with family.

The Internet is a continuously evolving space. New websites launch every day and new threats emerge constantly. As such, web security is complex even for some of the most seasoned security practitioners. My focus will remain on ensuring that our customers – both current and future – have the best product and technology experience and that they get the highest levels of support that such a fast-paced market dictates. We will continue to lead on the fronts of innovation and customer success, and we will do that with a team of some of the most talented application security technologists, business executives, practitioners and contributors that this industry has to offer.

I look forward to leading WhiteHat Security into this next chapter.

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…