How to Break Web Software
Functional and Security Testing of Web Applications and Web Services, by Mike Andrews and James A. Whittaker Published 2006
Contains recipes for 24 different hacks. Most of them are supposed to be common knowledge in the field by now. They are actually pretty common defects. Frameworks are getting better at weeding out a lot of these, but these concepts are still ‘required reading’ in my mind. I have reviewed several systems by startups that suffer from one or more of these holes. Junior programmers sometimes look at me like I’m nuts when I bring this stuff up.
The book covers basic types of hacks that everybody should know:
- SQL Injection: Back end code converts paramaters supplied from outside (like form values) directly into SQL. This means hackers can run arbitrary SQL. Read more on the kid named Bobby Tables here: http://bobby-tables.com/
- Cross Site Scripting: XSS, site redisplays data blindly to other users, so arbitrary JavaScript can be executed on others machines. This one’s my personal favorite:
<IMG SRC = " j a v a s c r i p t : a l e r t ( ' X S S ' ) " >
- Buffer Overflows: overflowing memory by passing too much data to a method – could destabilize server, or cause unexpected behavior. I think this one is less common in most web applications. Checking for max length of fields is one solution. Network devices are more prone to this one.
- Weak cryptography: relying on an in-house hash, or common hash can easily be broken. Security through obscurity is stupid.
- Other more interesting hacks are:
- URL jumping (eg, switch to /admin/delete_all/ directly)
- Cookie poisoning – eg, inject loggedin=true into a cookie
- Session hijacking – steal a URL that has ?sessionID={somehash}
- WSDL attacks (attacking exposed SOA interfaces, injecting XML designed to send server into infinite loop, command based XML, etc).
The basic solution is do not trust ANYTHING that comes in from outside. Validate, validate, validate everything that comes in for length, data type, corrupt characters, encoding,
Always escape quotes and slashes on incoming data. Make sure your framework does it for you. Write a unit test that attempts SQL injection attacks in version 0.1 of your software!
PHP Magic quotes does this automatically, and that is the underpinning if security for thousands of PHP websites that use the ball of mudd design pattern (http://www.laputan.org/mud/).
With PHP 6 magic quotes is gone, and when hosting providers upgrade, there will be a mydrid of newly opened security holes on the internet.
I prefer to validate all incoming data at the UI (javascript), web action layer (PHP, Java, etc), business layer (add throws InvalidArgumentException to all methods, and unit tests for bad cases), and database layer (if using stored procedure).
In terms of web services, validation with XSD is common, and the same rules as above apply to the subsequent chain of objects processing the data.
For protecting users:
- Use https, it is ubiquitous now
- Re-filter content for nasty data when displaying it (do not assume the data store is clean).
For protecting the server:
- Shut off directory indexing, which when enabled reveals all files on the server.
- Disable the server signature. Knowing what version the server is running means a hack is only a google search away if the server is not patched.
- Code all data access methods with a buffer – eg, use LIMIT and OFFSET. If you ask for all records, and there are millions there, it will gladly take them all at once and crash the server.
Granted, this is an idealistic view, and must be applied where security requirements are high.
Audiences who will find this book useful:
- Web developers
- QA engineers working on a web site
- QA Managers
- Software Development Managers
- Junior Programmers
- Network / Security professionals
- SOA developers and architects. As more and more infrastructure is exposed by services, and in particular web services, many of these principles apply.