The following is from a handout I used for a presentation to a group
of Java programmers. In retrospect I don't think I like the anti-pattern format, but hopefully you will find it helpful in spite of that.
Name: Trusting form data
Problem: Preserving state across a series of web pages and form
submissions.
Supposed Solution: Store information in hidden form fields.
Exploit: The values of the hidden fields can be easily changed
by an attacker to subvert the application. The application will then
use the altered data in calculations that should only performed with
trusted data.
Example: The data stored in the hidden field is the price of an
item in an ecommerce system. A criminal organization exploits this to
purchase a large number of expensive items at a 100% "discount".
Alternative Solutions:
- Only accept data from forms when it doesn't matter if it is tampered
with. For example instead of storing the price in an ecommerce system,
only store the product id then look up the price using the product id as
a key.
- Use a framework such as Lakeshore that abstracts away the problem of managing state across pages.
- In cases where sensitive data must stored on the client side (e.g. a price quote) the sensitive data must be cryptographically signed. A signature can be generated by concatenating the sensitive data with a secret and calculating a one way hash. This signature is then always passed with the sensitive data allowing any tampering to be detected.
Name: SQL Injection
Problem: User supplied data must be used in queries against a
database.
Supposed Solution: Just substitute the user input into an SQL template
and execute it.
Exploit: An attacker can carefully craft the supplied data to
execute arbitrary SQL. The details vary by database vendor, but for
Oracle the key concept is starting the SQL to be inserted with a single
quote.
Example: An ecommerce system allows the catalog of products to be
to searched based on a user supplied string by simply inserting the user
supplied string into a query. The attacker enters the following as a
search criteria:
x' UNION SELECT table_name FROM user_tables WHERE
'x'='x. This will allow the attacker to obtain the name of the table
that credit card information is stored in then use the same technique to
retrieve all of the credit card numbers stored in the system.
Alternative Solutions:
- Don't execute SQL using raw JDBC calls. Use a library such as
SQLProcessor that always uses
prepared statements. This is sufficient for applications that use
Oracle databases, but may not be for other databases.
- Escape single quotes in user input before using it in an SQL
statement.
Further reading:
http://www.securityfocus.com/infocus/1644
Name: Cross Site Scripting (xss)
Problem: User supplied data is displayed to other users
Exploit: An attacker can carefully craft the data so that it
does a wide variety of malicious things when another user views the
data.
Example: An ecommerce system displays the names and addresses of
problem orders on a screen accessible by an administrative user. The
attacker enters javascript for his address that will steal the viewing
user's JSESSIONID cookie and post it to a logging URL controlled by the
attacker. When the administrator views the attacker's order his
JSESSIONID is stolen and the attacker can then impersonate the
administrator.
Alternative Solutions:
- Filter out dangerous characters from user supplied input before
storing it.
- Encode all user supplied input before displaying it to other
users
Further reading: