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...""

Comments

Secure Web Applications

[kenp2002]

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?)

Re:Secure Web Applications

[bytesmythe]

Aside from project management, I would also consider project specifications as being a contributing factor.

I know security can suffer heavily if a project starts to get into a time crunch, but in how many projects was security even a consideration in the first place?

If anyone starts working on a network-based project on a base install of any operating system (Windows, Linux, even OpenBSD), then there are problems well before the project's deadline approaches.

**security**

[buswolley]

Companies that develope security related products surely spend a portion of their budget on promoting security fears.(Especially easy with M$).. The average business manager is easily scared when a big security firm issues a warning about impending viruses, security holes etc.

My experience is there is much less out there than the hype may lead you to believe..

And there is no such thing as security when a talented hacker wants your network bad.

So..Just don't make yourself an easy target. If the average networked business provides itself with enough security to make a hacker actually have to WORK!! at it to get in, then you will filter out most attacks; unless the hacker has a specific interest in your company's network.

Re: **security**

[Anonymous Coward]

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."

Sloppy samples

[phorm]

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

Re:Sloppy samples

[cowboy junkie]

The problem is that global variables made coding PHP easier, which was one of the big selling points of the language. They've finally set register_globals to off by default now, but the damage is done. So many PHP apps require it to be on that it can be a major pain in the ass to fix.

examples often become crutches

[Provincialist]

Security is an area of programming in which examples can actually harm the quality of code. I don't mean to defend STO, but rather to point out that it's unlikely that the toy system used in a guide will be identical to the system under development by the reader of the guide. Both the inexperienced and the lazy face a terrible temptation to copy-and-paste whatever snippet they can find that they can convince themselves is applicable to the situation. A programmer is better served by being informed of the issues involved, and then forced to work out for himself what those issues mean for his code.

later,
Jess

Re:What bugs me

[Boss, Pointy Haired]

That said of course, this is no reason _not_ to create safe queries from form input, that's just (or should be unless you're in the wrong career) common sense, but that's not the point.

These people make it out like it is easy to attack a site like this.

I don't think it is.

random attacks? what for?

[Unordained]

remember that most of us deal with open-source code: if someone can see your code, whether it be in C or in PHP, they can look for holes. injection throught SQL is a big problem -- if someone's feeling malicious, they just have to figure out what you're running (and if it's one of the popular php-forums, that's not hard) and download the code ... and start having a look around for potential security flaws. doesn't take much.

it's irritating to write as much code as it takes to be secure, but i'm glad i did it with my project -- it doesn't allow anonymous stuff at all, but there are still risks involved ... so every single page, whether creating forms or accepting input from forms, re-verifies absolutely everything about what you're allowed to do, etc. there's no reason for create_object.php to make sure you can, and create_object_confirm.php not to.

and there's no reason not to make sure your SQL is secure. (although not using the most-used server also helps -- i use firebird/interbase ... most people expect you to be using mysql, and will attack it as such.)