The 80/20 Rule for Web Application Security
"Increase your security without touching the source code"
By Jeremiah Grossman
Last Modified: 1/31/2005
[TEXT] size: 18k (MD5 SUM: 52bea5a847f5efc1dfb86cbf4714b6f1)
[HTML] size: 22k (MD5 SUM: 0a1556205c5bdfce7ffc7d3d813e13db)
After performing hundreds of web security assessments you're bound to encounter many frighteningly
insecure websites. Websites so badly protected you could literally make off with the credit card
numbers in a way reminiscent of the movie Gone in Sixty Seconds. On the other hand there are many
websites frustratingly impervious to attack. What I'll describe below are the subtle variations
between the security "haves" and "have-nots". Using the age old "80/20 rule", we'll look at a few
techniques anyone can use to decrease the risk of their website being hacked. And to make it really
easy you won't have to alter a single line of code! But before jumping too far ahead lets first
discuss the 80/20 rule.
At the beginning of 20th century, the Italian economist Vilfredo Pareto created a mathematical
formula for describing his country's unequal distribution of wealth. He observed that 80% of the
wealth was owned by 20% of the population. Following Pareto's observation, many others noticed
similar phenomena in their own areas of expertise. In the 1930s and 1940s, Quality Management pioneer
Dr. Joseph Juran observed what he described as the "vital few and trivial many". Juran's identified
that 20% of the defects caused 80% of the problems. This has long since been known as Pareto's
Principle or "The 80/20 Rule". In the web application security environment, I've noticed similar
trends with regard to security safeguards.
The quest for developing perfectly secure code is a noble pursuit. Let the heavens smile down if
anyone is actually successful at the endeavor. In the course of managing website security, there's
often many occasions where fixing vulnerabilities in the source code is not an available course of
action. For example, you might have inherited a website where the original developers are gone and
no one is familiar with the application. Your development staff is already heavily burdened by other
pressing projects. Maybe you simply have too many websites on your plate to spend quality time securing.
Whatever the particular situation fixing the code is just not an option due to time, money, or the lasting
benefit. A few security purist may disagree with me on this point, but I think we should have access to
alternative security solutions not embedded within the code.
We'll now begin applying Pareto's Principle to certain areas within web application security.
Specifically identifying the "vital few" security solutions essential to protecting a website,
according to the WASC Threat Classification (http://www.webappsec.org/threat.html), without
touching any of the application code. These solutions guard against the most common issues such
as SQL Injection, Cross-Site Scripting, worms and more! From this point forward I'm going to
assume the security basics have been taken care of. The web server and underlying operating system
is up-to-date on patches, and a properly configured firewall is guarding the perimeter.
Disclaimer: The following is a compilation of well-known techniques that should be used in
combination with secure coding practices or as a short-term solution towards a more permanent
The Vital Few
1) Default server error messages
Typically when hackers are looking to exploit websites, they look for the easiest route to take.
This usually manifests by testing for Cross-Site Scripting, SQL Injection, OS Commanding, and a
few other weaknesses. These issues are the most commonly found type of vulnerability in websites
today. Take a look at BugTraq (http://www.securityfocus.com/archive/1)
if you're interested.
To test for these problems, hackers will lace URL's and post-data requests with certain meta-characters
(single quotes, semicolons, less-than-greater-than signs, etc.) in attempts to elicit some type of error
message. Standard system error message are the most revealing sign of weakness and invaluable during a
Take the following URL's for example...
The result may produce the following error message:
Microsoft OLE DB Provider for SQL Server error '80040e14'M
Unclosed quotation mark before the character string '; ORDER BY PageNumbers'.
/articles.asp, line 152
When the error message is received, it's a dead giveaway that there is probably a
SQL Injection problem. Further, the error is helpful to the point that it describes
the nature of the problem and on which specific line. What the hackers are trying to
do is reverse engineer the system to understand the backend SQL query. Once they
understand the structure of the query, this specific vulnerability can lead to complete
data compromise. This error message makes SQL Injection attacks 10-times easier to exploit.
Suppressing error message can be accomplished at two locations, the web server and application server.
When a web server encounters a processing error it should respond with a generic web page,
devoid of any revealing debug information. Redirecting to a standard location works equally
Apache (version 1.3x and 2.0x are effectively identical)
Syntax: ErrorDocument <3-digit-code>
Example: ErrorDocument 500 /webserver_errors/server_error500.txt
The various software versions have GUI configuration interfaces. Consult these following
resources for proper assistance:
For completeness, error codes of 4xx and 5xx should all be handled in the same fashion.
Application servers, such as ColdFusion or WebSphere, may install with certain error messages
or debug settings enabled by the default configuration. These features should be suppressed to
everyone except perhaps the administrator.
Consult your vendor's documentation for how to lock-down and turn off its specific administrative
Macromedia ColdFusion (mode=debug)
This security technique will increase the difficulty for most of the common Command Execution
category attacks from actually succeeding. Including SQL Injection, LDAP Injection, OS Commanding,
SSI Injection, XPath Injection, etc. Our goal is to increase the difficultly of hacker
reverse engineering the backend system. Without access to informative error messages,
the hacker is forced to perform the attack while blind to the system internals. This
defense makes these classes of vulnerabilities many times harder for a hacker to detect
and further exploit.
2) Remove or protect hidden files and directories
Many times web administrators or developers will leave files on the server not intended
for the public. These could be default files, log files, backup files, administrative
directories, temporary files, backdoor functionality, press releases, etc. The administrator's
assumption is if the location of the file is secret and not directly linked to the contents
are safe because no one will ever find it. This is a very dangerous assumption to make
with sensitive data at risk.
Most of the time these hidden files have easily guessable names (/admin/, /logs/, /includes/,
WS_FTP.LOG, etc.) or common naming conventions (*.bak, *.orig, *.zip). In days long past,
hackers hunted for these files by typing directly into the browser location bar. Being a
manual process it limited the number attempts a person could make it a given amount of time.
Today through a process known as "Forced Browsing" or "Predictable File Location" (WASC Glossary:
widely available scanners of the commercial or open source variety have become very adept at
testing for tens of thousands of filename variants making the attack much more exhaustive
and likely to succeed.
To solve the problem, there are few alternatives to choose from:
a) If the number of web servers or publicly available files is not exceedingly large, you
could go through the document root tree by hand. Using find, search for any file not ending with
one of your commonly used extensions. (*.html, gif, jpg, etc.). Then proceed directory-by-directory
removing any sensitive or non-essential files wherever possible.
If the number of websites or file directories is just too numerous to go through by hand, consider
using a scanner. Open source scanning such as Nikto, Paros, Wikto and others can help cut the
workload. Commercial scanning products including AppDetective, AppScan, NTOSpider, ScanDo, and
WebInspect also do the job well.
b) If the private areas need to remain on the web server, Apache and IIS can be configured to
password-protect and/or IP restrict the resources. Even using something as simple as http basic
authentication can significantly increase the level of security.
c) If your filesystem (NTFS, EXT2/3, etc.) supports "last access" timestamps, you can also
locate files that haven't been accessed in an extended period of time. If you don't need
these files, remove them.
d) In your web server configuration turn off Apache "Directory Indexing". Or IIS "Directory Browsing"
This feature is commonly used to create web pages on the fly for directories without index files
(index.html, default.htm, etc). But this feature can also aid an attacker in locating sensitive
files on the web server.
Syntax: Options -Indexes
Within the IIS console, turn off Directory browsing in the web site properties.
e) Google is a powerful resource for identifying many kinds of sensitive data in your
website. A few simple searches can reveal a lot. Consult the Google Hacking Database
(http://johnny.ihackstuff.com/index.php?module=prodreviews) for information on the
various types of searches you can try.
3) Web server security add-ons
IIS Lockdown, URL Scan, mod_security, and SecureIIS are web server security add-ons
designed to guard against attacks before being processed further by the web application.
Of the many great features within these products, which would take too long to fully
explore here, I'll focus on a few of the recommended highlights. At a high level, these
add-ons are again great for preventing many of the common attacks like SQL Injection,
Cross-Site Scripting, Worms, and Buffer Overflows you're likely to endure.
IIS Lockdown, designed for Microsoft's Internet Information Server (IIS), assists by allowing
administrators the ability to easily turn off unnecessary features that might pose a security
risk. With IIS Lockdown you can disable unnecessary services, un-map unused file handlers,
un-map unused sample scripts and directories, modify permissions, etc. And making configuration
a breeze, a GUI-Driven interface and security templates are made available as well.
IIS Lockdown and Urlscan
URL Scan, again designed for IIS, picks up where IIS Lockdown leaves off by focusing
on the http request specifically. Attacks on websites are usually achieved by using
specially crafted URL's. These URL's may contain special characters, be overly long,
or even cleverly encoded to disguise an attack. URL Scan helps by using rules to
interrogate several facets of an http request. If anything looks out of the ordinary,
an exception can be raised.
If you're already using IIS 6.0, Microsoft recommends you evaluate the need to use URL
Scan at all. Most of the important functionality of URL Scan is already included in the
IIS Lockdown and Urlscan
Mod_Security is the Apache equivalent of URL Scan. By working in conjunction with
Snort rules, Mod_Security can be used to analyze the legitimacy of an incoming http
request. Simple rules can be configured to stop many forms of SQL Injection, Cross-Site
Scripting and a host of other undesirables. But, this is only the beginning. The tool
has loads of power when you really dive into it.
Web Security Appliance With Apache and mod_security
A commercial product by Eeye, SecureIIS is a specifically designed as an IIS ISAPI
filter to block incoming attacks. Using specially crafted filter rules (no signatures
to update), SecureIIS sits between the Internet and the web server SecureIIS to protect
against buffer overflows, parser evasions, directory traversal and other attacks. Another
good add-on to have.
4) Add httpOnly flag to sensitive cookies
When a hacker Cross-Site Scripts one of your users, cookies are a popular target to steal.
Cookie theft can lead to account compromise (session-hijacking) and beyond to outright fraud.
A user depends on security practices of a website for protection against Cross-Site Scripting.
Users simply can't protect themselves alone. If the latest rounds of Phishing Scam emails that
exploit Cross-Site Scripting are any indication, these attacks are bound to happen to everyone
sooner or later. While many Cross-Site Scripting defenses revolve around data validation and
sanitization, there is another powerful alternative that is not utilized nearly enough. Microsoft
created "httpOnly" cookie flag.
Set-Cookie: VAL=012; expires=Monday, 09-Nov-99 23:12:40 GMT; httpOnly
value. Meaning, when a Cross-Site Scripting attack occurs, the hacker gets an empty value
from the cookie and stealing it becomes a pointless exercise, thereby making a session hi-jacking
attack via Cross-Site Scripting much harder.
Because setting cookies can be done at multiple levels (web server, application server,
web application, etc.), I may have to break my promise of "without touching the code".
Often times a simple configuration is all that's required with web servers and application
servers depending on your distribution. But if a code edit is required, it shouldn't amount
to more than editing a single line. Sorry.
At the moment, the httpOnly feature is only supported by recent versions of Internet Explorer
(90% market share). The word is the Mozilla Project should be adding the support soon.
Mitigating Cross-site Scripting With HTTP-only Cookies
As we began this discussion, the goal was to decrease the risk of a website being hacked without resorting
to source code updates. Using the various techniques above, the difficultly level of a hacker exploiting a
website has been increased. Maybe even by as much as 80% (per the 80/20 rule), but it's hard to be certain
exactly. Keep in mind though, if a security issue remains present, the website can still theoretically be
hacked. This much has not changed. Either by fixing the code or removing the website entirely, any problems
still need to be permanently corrected. Whatever your particular situation, these tips can assist websites
with even the most secure application code.
At this point you may be wondering, 80% sounds great, but what about the other 20% of attacks left out? What
attacks still threaten a website? The answer is "logical flaws" and also certain varieties of "technical
vulnerabilities" (http response splitting). In other articles I've published, I described what's called "logical
flaws" or flaws in business logic. An example would be when someone changes the sale price of a product during
the checkout process. Often these are the most damaging type of attack since they directly circumvent business
controls. Predominantly, logical flaws are not protected by the measures I've described. So if your business
depends on the integrity of business control functions, there is little choice but to identify and fix logical
flaws at a code level. In the meantime, hopefully this article has helped you implement additional layers of
website protection and given access to a larger set of solutions for consideration.
About the Author
Jeremiah Grossman is the founder and Chief Technology Officer of WhiteHat (http://www.whitehatsec.com) Security where he
is responsible for web application security R&D and industry evangelism. As a 7-year industry
veteran and world-renowned security expert, Mr. Grossman is a frequent conference speaker at
the Blackhat Briefings, ISSA, ISACA, NASA, and many other industry events. Mr. Grossman's
research, writings, and discoveries have been featured in USA Today, VAR Business, NBC, ZDNet,
eWeek, etc. Mr. Grossman is also a founder of the Web Application Security Consortium (WASC) as
well as a contributing member of the Center for Internet Security Apache Benchmark Group. Prior
to WhiteHat, Mr. Grossman was an information security officer at Yahoo! responsible for performing
security reviews on the company's hundreds of web applications.
The current copy of this document can be here:
Information on the Web Application Security Consortium's Article Guidelines can be found here:
A copy of the license for this document can be found here: