Common Web Security Anti-Patterns

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:

http://www.cgisecurity.com/articles/xss-faq.shtml

http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/cross-site-malicious-content.html

Youth culture killed my dog

Common Web Security Anti-Patterns

Nice quote

Seaside gets DHTML

Reflections on reflection - Henk Barendregt