Youth culture killed my dog 4 of 4 articles Change bannerposts rsscomments rss

Common Web Security Anti-Patterns   16 Jan 05
[print link all ]

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

Nice quote   24 Jul 04
[print link all ]
        Methodologies do not succeed because they are aligned with some platonic
        Right Way to build software. Methodologies succeed because people make
        them succeed.
www.testing.com/cgi-bin/blog/2004/07/24#methodology-and-ontology
|

Seaside gets DHTML   24 Jul 04
[print link all ]
I knew that things like autocomplete on text fields were possible, but I thought they would be clunky in practice. Even after seeing gmail in action I still didn’t get it. Well, I get it now. Try typing some things in the "Live Search" box on the right side of this page.

And now it comes to Seaside:

        What this means, effectively, is that invoking this handler makes a
        request in the background, which the webserver can respond to by
        returning a new version of any part of the current page that it likes.
        That part of the page gets swapped out seamlessly for the new version.
        The thing I like about this is that it gives all the power to the server
        side: only after having processed the request does the decision have to
        be made about what parts of the page are affected and need to be
        redrawn, and those parts can be sent back to the client.

www.cincomsmalltalk.com/userblogs/avi/blogView?showComments=true&entry=3268075684

So now I would like to get this going in Borges. If I don’t have something posted by Monday, call me out on it.


|

Reflections on reflection - Henk Barendregt   13 Jul 04
[print link all ]
lambda-the-ultimate.org/node/view/91
|

 

Copyright © 2024 Leslie A. Hensley