In Scotland and northern England, a "waff" is a gust or puff of air, or a passing glimpse. It is also a verb meaning to flutter or cause to flutter. In this post I want to avoid hot air, waffle and waggish comments to highlight guidance on the deployment and use of web application firewalls (WAFs).

WAFs can be controversial in that they can be a blunt instrument to add some protection to web applications, may not be well understood, are often not configured well, can be expensive to acquire, require an ongoing resource commitment, may cause problems with valid business functionality, could lead to the delegation of responsibility for application security primarily to operations, and if not integrated with other software assurance activities, can lead to the mistaken assumption that applications are secure. These issues need to be considered, but WAFs are a valid tool to have in your arsenal of defences.

Some more recent, and older long-standing, viewpoints and uses are described in the sources listed in alphabetical order below:

• Defending Against Denial of Service Attacks
  Securosis, November 2012
  The applicability of WAFs as a measure to contribute to the defence of applications against denial of service attacks
• Effectiveness of Web Application Firewalls
  Larry Suto, November 2011
  An evaluation of some commercial and open source web application firewalls
• ModSecurity Blog
  Trustwave
  Interesting articles on techniques that can be implemented using a WAF such as this, this and this
• Pragmatic WAF Management: Giving Web Apps a Fighting Chance
  Securosis, September 2012
  Issues, WAF management process, policy management, application lifecycle integration and protecting WAFs
• Protocol-Level Evasion of Web Application Firewalls
  Ivan Ristic, July 2012
  Discussion of the challenges of implementing WAFs and the types of evasion issues seen in production WAFs
• Use of Web Application Firewalls
  OWASP Germany local chapter, September 2008
  Characteristics, benefits, risks, selection criteria and best practices
• Web Application Firewall Evaluation Criteria
  WASC, January 2006
  A solid resource due to be updated in conjunction with OWASP

If you have, or are thinking of using WAFs, do read all of the above and subsequent discussions about some of those papers, as well as listening to suppliers/vendors. Then make up your own mind.

Another recent paper from Securosis addresses defending against denial of service (DoS) attacks.

Defending Against Denial of Service Attacks examines the types of attacks prevalent currently, and methods to maintain availability and minimise the adverse economic effect. The paper begins by identifying the threats‐protection racketeers, hacktivists, cyber war, exfiltrators, competitors, and business success itself.

The types of attack are described and defences for networks and applications are described. For applications, building security into the software development life cycle, web application firewalls (WAFs), anti-DoS devices and service providers, content delivery networks (CDN) are described. The need for a multi-faceted approach to application DoS protection is recommended in the paper.

I think some applications will just be more problematic than others and avoiding security vulnerabilities, minimising the attack surface and building in application-specific attack detection and response will help here too.

The paper includes links to further insightful sources of information, and recommends that to be effective, the process for defending against denial of service attacks needs to include activities before, during and after an attack.

Further to my previous notes about HTML 5 security, a superb reference document was published earlier this month.

Michael Schmidt (Compass Security) wrote his master's thesis about HTML5 security in May 2011 and has published an extract for everyone to access.

HTML5 Web Security describes issues, vulnerabilities, threat & attack scenarios and countermeasures across 80 pages including numerous well thought-out diagrams, and is backed up with detailed references and an appendix full of attack details.

The main sections are:

• 2.2 Cross-origin resource sharing
• 2.3 Web storage
• 2.4 Offline web application
• 2.5 Web messaging
• 2.6 Custom scheme and content handlers
• 2.7 Web sockets API
• 2.8 Geolocation API
• 2.9 Implicit relevant features of HTML5
  Web workers, new elements, attributes and CSS, Iframe sandboxing and server-sent events

If you are already developing HTML, or planning to, read this document as soon as possible and update your requirements documents, specifications, design documents, coding standards, and test plans to incorporate the knowledge.

The document would be worth buying if it were a book, but it has generously been made available publicly. Yes, I am still reading the document, and so far have only one very minor complaint — it would be good to have a content list. Maybe in version 1.1?

Application information gathering such as enumeration of directories, files and other resources are a type of forced browsing and which may be made easier by using predictable resource locations.

Some requested URLs are likely to be an attacker exploring the application or trying to find a published vulnerability:

• /.htaccess
• /index.php?file=../../../../../../../../../etc/passwd
• /plugins/editors/tinymce/jscripts/tiny_mce/plugins/tiny...
• /statistik/usage_201007.html
• /sumthin
• /FormMail.pl

If these do not exist, they may raise a 404 status error, and be listed in web and application error logs.

As part of my presentation at AppSec Washington DC in two weeks time, and the related guidance document, I wanted to provide examples of URLs which publicly exposed web applications may receive for non-existent resources (and thus generate a 404 status error), but which are not necessarily malicious and probably not even suspicious. This is important because one of the primary benefits of application level intrusion detection and prevention is its very low false positive rate (falsely identified attacks).

If URLs are requested which do not form part of the allowable entry points to the application, what does that mean? An attacker might be undertaking reconnaissance, testing defences or looking for vulnerabilities—just the types of things an intrusion detection system should be looking for. However, they may be benign requests.

In the tables below, I have set out 20 common types of non-malicious unexpected missing file URLs which most public web sites could receive. If the site is not exposed to search engines and external parties, this list will need to be shortened.

Type A: URLs that Should Not Exist

The first type is URLs that are requested with the premise the page/file does not exist.

Type B: Assumed Valid URLs

In this type, URLs are wrongly assumed to exist but are requested nevertheless.

Type C: Incorrect URLs

Some URLs are not, and never have been, valid entry points but are requested normally due to a user's mistake of some sort such as a transcription error.

Type D: Testing

Your own functionality and security testing, or testing services performed on your behalf, will request URLs that do not exist. These might also be considered benign if the scanning is authorised and from a known source.

Some of these could be being requested by an attacker, but they are usually not enough to identify one—Type D from an unknown source, or unauthorised, should not be assumed to be benign. Items such as incorrect case, truncation and mis-spelling (Type C) cannot be predicted in advance, but if they occur it may be necessary to add custom redirections to the correct URLs.

If you have further suggestions and examples, please share them. Tomorrow, I will extend the discussion of benign URLs to valid (non-missing) URLs.

Update 8th November 2010: Following a direct message, I have added /trackback and URLs referenced by client-side style and code libraries. Link to 'Tomorrow' enabled in last paragraph.

Web users should be very familiar with challenge-response CAPTCHA test which are also known as Human Interactive Proofs (HIPs).

A lot of time is spent devising CAPTCHAs and trying to break CAPTCHAs in an automated manner. They are used where website owners want to try to ensure a real person is undertaking a transaction such as logging in or submitting content. Now, most web sites don't need to use CAPTCHAs and there can be accessibility problems, but they are often needed for more high-profile sites or when targetted automated attacks are occurring.

A new paper Attacks and Design of Image Recognition CAPTCHAs examines image recognition CAPTCHAs (IRCs) and analyses the effectiveness and security of the schemes considering:

• ease of use by humans
• difficulty to automate
• universality
• reistance to no-effort attacks
• scalability
• use of a secret database.

The authors describe the lessons learned, some fundamental guidelines for IRCs and propose an alternative IRC which relies on recognising an object by exploiting its surrounding context. This requires the user (hopefully a human) to select an item from a set of objects detached from the original image, and then place it back at its original position in the image. Its usability, robustness and copyright issues are discussed.