A Guide to Building Secure Web Applications

some-guy writes "The Open Web Application Security Project has released A Guide to Building Secure Web Applications, Version 1.1 "While this document doesn't provide a silver bullet to cure all the ills, we hope it goes a long way in taking the first step towards helping people understand the inherent problems in web applications and build more secure web applications and Web Services in the future...""

Examples are a must

[Photon Ghoul]

I like where they are goign with this, but....

Does anyone really think that telling a developer that "they must validate input", for example, is really going to do any good? If the developer is lazy or even better (since laziness is no excuse) a newbie , perhaps they would be better served with some example code. A few brief snippets in popular languages covering common circumstances would go a long way to help reduce widespread security holes.

For example, a Perl snippet showing how to check for the validity of an email address. A VBScript snippet providing an example of comentizing for the sake of seperating out privelages. PHP snippets demonstrating resuse of trusted components.

Just a thought.

What bugs me

[Boss, Pointy Haired]

is the number of web application security prophesies who go on about SQL injection through form fields.

Yes, it's all good and dandy in theory and makes you look very clever indeed, but count how many unknowns you have to know before you can attack a site in this way, do some basic probability math and your chance of success is so low you might as well phone the web master and ask them what the password is.

Remember Me?

[duplicate-nickname]

Something that is a very serious issue but is just brushed over in that paper is a method to remember who users are, long term....the "Remember Me" feature.

Personally, I have left this "feature" out of my web-apps, but users are really demanding it, so how should it be handled?

Obviously storing a username and password, or a user id number in a cookie is a problem. I am already generating session GUIDs, so it would be possible to store the GUID in a cookie, and then do a look up when they return to match the user account (which is already done on every page for state managment). This almost has the same problem as storing the username/password, as a malicous user would just need to find someone else's GUID and stuff it in their own cookie.

So, was is the most secure method for remembering a user assuming you are already doing form-based authentication with SSL?

Here's all this OWASP document has to say:

Session tokens that do not expire on the HTTP server can allow an attacker unlimited time to guess or brute force a valid authenticated session token. An example is the "Remember Me" option on many retail websites. If a user's cookie file is captured or brute-forced, then an attacker can use these static-session tokens to gain access to that user's web accounts. Additionally, session tokens can be potentially logged and cached in proxy servers that, if broken into by an attacker, may contain similar sorts of information in logs that can be exploited if the particular session has not been expired on the HTTP server.

URL modification and multiple SQL statements.

[tetranz]

Whenever I see something like http://mydomain.com?id=1234 I can't resist inserting a semicolon in the number. Its very common for this to create an error exposing the SQL statement and leaving me wondering what http://mydomain.com?id=1234;DELETE * FROM mytable (url encoded) would do. I would never do something like that but something like http://mydomain.com?id=1234 OR 1=1 often yields interesting results.