Slashdot Mirror
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...""
I wonder if they are going to cover Project Managment which is the leading cause of poor security. When the project runs short on time security tends to be left till last and when your short on time, functionality out-ranks security (After all what good is the security of the app doesn't work? Right?)
-=[ Who Is John Galt? ]=-
A Guide to Designing Web Applications That Will Survive a Slashdot DoS Attack.
Unix is user friendly, it's just selective about who its friends are.
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.
As a supplimentary reading assignment, this months Linux Journal is running an similar, interesting article on Programming PHP with Security in Mind.
---
Jedimom.com, choo choo choosing you...
StrategyTalk.com, PC Game Forums
Any security mechanism should be designed in such a way that when it fails, it fails closed. That is to say, it should fail to a state that rejects all subsequent security requests rather than allows them
This is one of my favorites. Most browsers fail SSL connections with a warning that allows the user to just "click through" if the certificate is expired, does not match the DNS name of the site, or is issued by an untrusted authority. Only the last of these should be a warning (since you may want to trust it anyway. The other two should be connection failures. I am glad they included this.
Stop Continental Drift! Reunite Gondwanaland!
I work at a web application security consulting company and do pen-tests on large corporations web applications regularly. I can tell you from experience that the hype *is* real. I have *never* seen a medium to large sized web application infastructure that does not have holes in it. I have always found a way to get customer records, administrate the site, or some other essential flaw. People do not know how to program securely, or even know that they have to. Guides like this are an excellent. If I were a manager, I would have all of my developers read it.
As far as your "there is no such thing as security" argument, I think it's pretty silly. Yes, if a hacker is ultra hardcore and is going to spend an inordinate amount of time breaking into your ISP's domain server to conduct man in the middle attacks or use advanced 0-day techniques, it is difficult to defend against. But a well designed, programmed, administered and protected (think Snort) system is an incredibly difficult thing to break into. A good IDS will stop unknown buffer overflows. A good administrator will not leave backup files out on the webserver. There is a lot that can be done to improve security to the point where you can be reasonably certain that you are secure. What would you have people do, say "Oh, a really great hacker can get into my system anyway, so I'm not going to bother with security anyway."
I think that one of the bigger problems is the amount of self-started developers who rely on bad examples. When I first started programming Perl (and later PHP), I relied heavily on samples or articles online. In other cases, I picked apart common but easy programs.
As a result of this, my initial coding was functional, but crap. Over 3 months I picked up a better coding style, and on looking back at my initial code I was surprised at how badly it had been written. While there are many good resources for starting to code in a particular language, many of these use shortcut-code to get the message across.
For instance, PHP code that relies on "register_globals" is a bad example. For one thing, it doesn't work on all systems. For another, it can lead to programmers leaving holes or vulnerabilities in their sites. While it may be a pain to use $HTTP_POST_VARS["something"] every time, it's also nice to set an example of the most compatible method for coding.
Crap code is like a virus. If you make crap samples, and then somebody else makes crap samples based on the knowledge gained from your samples... pretty soon you have crap^2. A good thread might be for everyone to list the best known sites for PHP/Perl/etc sample, as well as known coding baddies/goodies.
"AND password=$password", not a good idea - phorm
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.