Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

A Guide to Building Secure Web Applications

michael posted more than 11 years ago | from the much-needed-little-heeded dept.

The Internet 126

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

cancel ×

126 comments

Sorry! There are no comments related to the filter you selected.

Security (-1, Redundant)

Anonymous Coward | more than 11 years ago | (#4328444)

Why is there so much ignorance about security?

Who put all that confusion in there?

Re:Security (0)

Anonymous Coward | more than 11 years ago | (#4328458)

I read that as "Hey, let me post something that makes me sound smart as fast as I can! Cause I WANT FIRST POST!"

Re:Security (-1)

CmdrStkFjta (565570) | more than 11 years ago | (#4328603)

And then you replied to it! HAHAHAHAHAHAHAHAHAHAHA! Whoooooo! Good one.

Re:Security (0, Troll)

Synonymous Howard (611424) | more than 11 years ago | (#4328775)

Why else?

Security by obscurity.

Just because we don't agree with the concept doesn't mean that it doesn't exist.

Re:Security (0)

Anonymous Coward | more than 11 years ago | (#4329605)

Security by obscurity provides security in the same way false hope provides hope.

Re:Security - Why there is ignorance MONEY! (3, Informative)

TheOste (413117) | more than 11 years ago | (#4329008)

>Why is there so much ignorance about security?

Project Manager: Make it work as quick as possiable, this just a demonstration.
Devloper: It works, but it isn't secure.
Project Manager: Next project, we do not have more features to add. Put security on the puch list of things to do if it goes production.
Devloper(Next week after site goes into production without speaking to the devloper): You know that site that was just supposed to be a demonstration, it has security problems.
Project Manager: Is it working?
Devloper: Yes.
Project Manager: Is the flaw easy to find?
Programmer: Not by your average user, but by someone looking yes.
Project Manager: I do not see a reason to spend the money to secure this application at this time. It seems to be in production just fine, you are a better devloper than what I thought.

Six Months down the road, the devloper gets strung up when someone accesses all of the inforamtion at the site. I have seen this happen far to many times in the real world.

Re:Security - Why there is ignorance MONEY! (2)

Pfhreakaz0id (82141) | more than 11 years ago | (#4329466)

Amen, brother. That's why you do all of the above exchange in email. In writing. bcc'ing your personal home account. I bcc everything like the above.

Always CYA.

Re:Security - Why there is ignorance MONEY! (2)

RhetoricalQuestion (213393) | more than 11 years ago | (#4330101)

Project Manager: Is the flaw easy to find?
Programmer: Not by your average user, but by someone looking yes.

Respond with a different answer. Multiple choice time.

Question: Is the flaw easy to find?

Answer 1: Yes.
Answer 2: For a hacker, yes.
Answer 3: For anyone who intends to harm our systems, yes.
Answer 4: For someone who uses this with malicious intent, yes.
Answer 5: Anyone who wants to harm our systems will find this.

If the project managers pushes for details about the average user, then you can patiently explain that average users isn't the issue to begin with. It's malicious users who are the problem because they are trying to find flaws, and this flaw will soon be obvious to them.

If you don't want the project manager to pick the cheapest and easiest way out, don't start out by giving them a cheap and easy way out.

Your project manager is probably getting their quarterly bonus based on how fast and how cheap they can get this project out the door. If you have a significant concern about security, don't automatically give them a justification for saving time and money in the short-run by ignoring it.

In the example you provide, you do this by immediately making it seem like the the probability of bad things happening is really low. Remember, when the shit hits the fan and the developer got strung up for bad security, it's because the developer made it easy for the PM to ignore security. Make a big fuss about it -- even if it gets ignored, you've at least covered your ass by voicing your concerns loudly.

Re:Security (1)

grumpygrodyguy (603716) | more than 11 years ago | (#4329184)

Why is there so much ignorance about security?

Who put all that confusion in there?


Businesses aren't prioritizing thier IT budgets anymore. So the only way IT people can keep thier jobs nowadays is by jumping on the "terrorist" paranoia bandwagon.

It's called employment through FUD. Isn't it amazing how quickly we've degenerated into this? Do you security bigots remember the kinds of projects you were working on 3 years ago? Does it make you cry when you think about it?

phrist poast (-1, Troll)

Anonymous Coward | more than 11 years ago | (#4328452)

fp, bitch

EAT IT!!!!!

booyaahh and all dat schiznidt!

peace out an' word to yo momz and propz to all ded homiez!.

yeah!!!

-ac

FISRT PSOT (-1, Troll)

Anonymous Coward | more than 11 years ago | (#4328456)

I win, I win!

Secure Web Applications (5, Insightful)

kenp2002 (545495) | more than 11 years ago | (#4328491)

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 (1)

broken_bones (307900) | more than 11 years ago | (#4328533)

I agree. Bad management and bad planning lead to many errors (not just security). When I worked in web development (intranet) I was amazed that the developers for the external stuff didn't do any security planning until after their code was audited. Then they just fixed anything that the audit turned up. It has been said before and should be said again: If you want something to be secure you have to build it that way from the ground up.

Re:Secure Web Applications (3, Insightful)

bytesmythe (58644) | more than 11 years ago | (#4328591)

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.

Re:Secure Web Applications (2)

Wizard of OS (111213) | more than 11 years ago | (#4328986)

As far as I can see from the document index, it doesn't cover it. Around a year ago I did quite some research on this topic and I found one document that covered all aspects (including the management part) very well. Unfortunately I lost the link (i'll reply to this if I happen to find it again).

The first few chapters of that document described how you should see security in your entire company. Be realistic: if loosing creditcard-information is not going to harm your stock, why should you put effort in securing it? On the other hand, if it means your credibility as a trustworthy company diminishes, you (as a developer) will be more likely to have budget to set things up in a secure way.

Bottomline: explain to your boss how much $$$ is involved with certain choices, let him do the math in Excel (they are really good at that). If they understand that they will loose money when a webapp is compromised, they will be very likely to give you the opportunity to write decent software.

Re:Secure Web Applications (3, Informative)

Wizard of OS (111213) | more than 11 years ago | (#4329052)

Found the document: http://members.rogers.com/razvan.peteanu/

Or a direct link: http://members.rogers.com/razvan.peteanu/best_prac _for_sec_dev4.pdf

Security? No Such Thing! (-1, Redundant)

Anonymous Coward | more than 11 years ago | (#4328505)

I think it was hellen keller that said (dunno the real quote, but here's the basic idea):
There is no such thing as true security. It doesn't happen in nature.

Entrepreneurship Opportunity (-1, Funny)

Anonymous Coward | more than 11 years ago | (#4328506)

1. Write Free Secure Web Applications
2. ???
3. Profit!!!

MOD PARENT UP!!! (-1, Flamebait)

Anonymous Coward | more than 11 years ago | (#4328612)

That was the funniest thing I've read in ages. It's just like the South Park episode with "Underwear Gnomes" but applied to Free Software. Of course, around here I'm sure no one will get the joke and probably mod it offtopic or a troll or some damn thing only because it attacks the very ideas this site is founded on. Well, in conclusion, Slashdot sucks ass, everyone who reads it is either gay or wants to be and if you read this post this far down you are a fucking moron.

Re:MOD PARENT UP!!! (0)

Anonymous Coward | more than 11 years ago | (#4328684)

Wow! You must have special ESP powers. I am gay and I am a fucking moron. Very perceptive.

Re:Entrepreneurship Opportunity (0)

Anonymous Coward | more than 11 years ago | (#4328674)

What's better?
1. Writing free software?

-or-

2. Sex with a mare?

Re:Entrepreneurship Opportunity (0)

Anonymous Coward | more than 11 years ago | (#4328713)

What type of a mare? Like, a Pinto or a Clydesdale?

DOGSHIT!! (0)

Anonymous Coward | more than 11 years ago | (#4328828)

I'll slap the shit out of you bitch.

Aaaaaaaaaarrrrrghhhh!!! (0)

Anonymous Coward | more than 11 years ago | (#4328747)

Someone help me please I can't get out of here this place sucks more than anything i've ever seen before it is os retaded i just need to leave and get home before i am trapped here forever oh my i am afraid that is going to happen why do you people keep me here i don't even like any of you you asll suck ass just let me go i wont' tell anyone ever please ahdafasdfa

TOC (3, Funny)

bytesmythe (58644) | more than 11 years ago | (#4328543)

Chapter 1 - Fdisking your machine
Chapter 2 - Installing linux
Chapter 3 - Updating OpenSSL libraries

What else do you need? Oh, yeah...

Chapter 4 - Unplugging your network connection
(That should lock it down from outside pretty well.)

Chapter 5 - Removing your harddrive and pounding it with a big ass sledgehammer.
(Now it's secure from the INSIDE, too.)

See? Good network security really isn't so hard.

You forgot some (1)

Glonoinha (587375) | more than 11 years ago | (#4329485)

>Chapter 1 - Fdisking your machine
>Chapter 2 - Installing linux
>Chapter 3 - Updating OpenSSL libraries
>Chapter 4 - Unplugging your network connection
>Chapter 5 - Removing your harddrive and pounding it with a big ass sledgehammer.

Chapter 6 - ???
Chapter 7 - Profit!

Re:TOC (1)

catch23 (97972) | more than 11 years ago | (#4329499)

I think the cheapest (and undoubtly best) security is to take your computer to the nearest bank and stick it in their safety deposit box!

Re:TOC (1)

tdegruyl (536375) | more than 11 years ago | (#4329954)

chapter n: digging a hole in your backyard (or whatever passes for a backyard), filling it halfway with concrete mix, placing pc in concrete mix, then covering with more concrete mix.... Now we can't even tell what kind of computer was in there (... was there a computer in there?)

Re:TOC (0)

Anonymous Coward | more than 11 years ago | (#4329546)

Chapter 1. PC Magazine [pcmag.com]

Chapter 2. The Register [theregister.co.uk]

Chapter 3. Security Focus [securityfocus.com]

Chapter 4. Webopedia [216.239.53.100]

Chapter 5. ibas [ibas.com]

My $1.50 (1)

Breity (611411) | more than 11 years ago | (#4328558)

If security was Easy, it would be less secure. For something to be secure, it needs to be sufficiently different and obscure to prevent 95% of all attacks. there is not a "inpenetrable" fortress, but i do believe you can make steps to come closer to a goal of keeping most attackers out. If there was an end all secure solution, i would be out of a job

Re:My $1.50 (2)

Nos. (179609) | more than 11 years ago | (#4328651)

If security was Easy, it would be less secure. For something to be secure, it needs to be sufficiently different and obscure to prevent 95% of all attacks

That sounds suspiciously like security through obscurity, which we all know *DOES NOT WORK*.
I've done some web apps that require a login, either to the standard /etc/password (/etc/shadow) or to a database of some sort. Sure I could make it very obscure, but if instead of validating that username and password everytime a page loads and instead passing a variable saying LOGGED_IN="TRUE", I defeat my own security by making it vary easy to bypass my login.

As the article says, validating input, and failing securely are two of the most important things you can do. If you're expecting a phone number, don't accept anything except numbers (and possibly -) as input. And make sure that if the system fails, it doesn't leave you wide open, it actually shuts down.

Re:My $1.50 (1)

Breity (611411) | more than 11 years ago | (#4328992)

I did mention DIFFERENT befor OBSCURE. Micro$oft is a great example of insecurity by obscurity... the list of flamebait could go on, but you get my picture.

Re:My $1.50 (1)

buswolley (591500) | more than 11 years ago | (#4328746)

Make it to obscure and you might intrigue the hacker witht the challenge.. unless its some young script kiddie

Re:My $1.50 (1)

buswolley (591500) | more than 11 years ago | (#4328811)

i am a phonetic speller. Ill correct the parent.

Make it too obscure and you might intrigue the hacker with the challenge...Unless it is some young script kiddie.

Re:My $1.50 (1)

Breity (611411) | more than 11 years ago | (#4328883)

the goal is to prevent the script kiddies flat out. really good hackers are never going to be stopped. just eta for hack lengthened

Re:My $1.50 (2)

tomhudson (43916) | more than 11 years ago | (#4328864)

I don't think so.

A big-ass deadbolt in a solid metal frame is secure without being obscure.

Bringing a gun to a knife fight is more secure - especially when everyone else sees your piece

The US's fighting stance vis Iraq is certainly not "security through obscurity"

I could go on, but you get the idea.

Now - on-topic - There wasn't much at the site that wasn't covered better elsewhere IMHO.

Regards, Tom

Re:My $1.50 (0, Flamebait)

pVoid (607584) | more than 11 years ago | (#4329033)

Wow. That is some of the most ignant shit I've ever heard.

I'll tell you what is secure, and it's easy too: take a building, cover it with 10 feet thick walls of concrete. It's now secure.

It's even more ignant just thinking that 90% of security vulnerabilities these days come from 'script kiddy exploitable' no-brainer-to-fix buffer overrun bugs.

I generally try not to go out flaming people, but... god, you suck.

Re:My $1.50 (1)

Hormonal (304038) | more than 11 years ago | (#4330183)

OK, given the fact that you misspelled 'ignorant' the same way twice in the same post, I'm making the assumption that you're intentionally doing so. I'm replying in case you're not.

Your point is good; the other guy was way off base, but giving the impression of the inability to spell a word like 'ignorant' doesn't generally lend credibility to your argument.

Sorry to be pedantic. I had a roommate that insisted on pronouncing the word incorrectly while using it as a synonym for 'stupid', and it made my teeth curl every time he did it. i guess seeing it in print rubbed me the wrong way.

Building Secure Web Apps (0, Troll)

I_am_Rambi (536614) | more than 11 years ago | (#4328582)

Easy... Don't use IIS as your server.

Do NOT Feed This Troll, MOD IT DOWN! (0)

Anonymous Coward | more than 11 years ago | (#4328737)

See subject...

Re:Building Secure Web Apps (0)

Anonymous Coward | more than 11 years ago | (#4328804)

This is asinine and off-topic. It's not clever or funny either. This guide deals with the construction and security implications of *custom* web applications, not how to set up your server. Web application security holes are just as common in PHP or Perl as they are in ASP.

i've got a guide (0, Redundant)

Anonymous Coward | more than 11 years ago | (#4328588)

its called install linux, that way no one can hack you!

Re:i've got a guide (1)

borg05 (161991) | more than 11 years ago | (#4328685)

I can't believe you're ignorant enough to believe that installing linux will stop people from "hacking" you. Sure, it may keep the script kiddies out, but anyone with actual knowledge of computer security will probably know linux just as well as any other operating system. Especially considering linux has a decent sized server market share (which are the boxes that need to be secured the most, imho).

Easy, use Java Web Application Servers (0)

Anonymous Coward | more than 11 years ago | (#4328605)

Using Tomcat/Jboss combo you can elegantly avoid

o buffer overruns. These CANNOT happen with Java.

o execution of arbitrary code. You CANNOT execute foreign code in a properly configured JVM.

The only vulnerabilities I'm aware of were tricks to display the JSP source instead of the generated page, but that's about it.

Re:Easy, use Java Web Application Servers (1)

huge (52607) | more than 11 years ago | (#4328837)

o buffer overruns. These CANNOT happen with Java.
o execution of arbitrary code. You CANNOT execute foreign code in a properly configured JVM.
Never say Never again. I have heard this too many times =)

Re:Easy, use Java Web Application Servers (1)

Proc6 (518858) | more than 11 years ago | (#4329547)

Would this be the same case for ASP.NET since it's managed code?

Re:Easy, use Java Web Application Servers (1)

tdegruyl (536375) | more than 11 years ago | (#4329992)

Choosing the right programming language is clearly an important decision, but it is still possible to create reasonably secure software in c/c++/perl/etc. It just takes some knowledge of what potential problems could come up and good programming practices.

And of course testing (!!!!), code review, and good design with security built in from the beginning.

**security** (3, Insightful)

buswolley (591500) | more than 11 years ago | (#4328642)

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** (1)

LordFlower (606949) | more than 11 years ago | (#4328697)

Obscurity. Work. yes yes.

But also this: If a hacker's probe reveals an interesting security method, wouldn't that just make that hacker more interseted in defeating it; for the challenge, and fame?

Re: **security** (4, Insightful)

Anonymous Coward | more than 11 years ago | (#4328778)

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

Re: **security** (0)

Anonymous Coward | more than 11 years ago | (#4328937)

A good IDS will stop unknown buffer overflows

Care to point me at such an IDS? IDS won't stop squat unless it's hooked into a feedback loop to your firewall. Expect something more along the lines of this:

2:13am : Oversided HTTP header detected
2:13am : Shell prompt on port 80 detected
2:17am : 'id' command returned root
2:18am : Lame twelve year old script kiddie slang detected
2:33am : Detected outgoing IRC connect
2:35am : Detected incoming floodbot command

and so on. IDS won't help, I'm increasingly getting the feeling that the only thing what will do the trick is rounding up loads of script kiddies and sending them off to a juvenile correction centre. These turds don't get cloaking devices and C4 explosives in the real world, why should it be excuseable if they do it online... heck, there isnt even a danger of blowing your fingers off online.

Re: **security** con't (1)

buswolley (591500) | more than 11 years ago | (#4328949)

And you are right. There is a lot of holes. And you can make it really hard for a hacker to get inside the system.

My point was that a dedicated and talented hacker still can do it in most cases. In this sense, true 100% security is hard if not impossible.

But good security implementation is still a must.

Like this:An experienced car-thief might be able to break into my car and drive it away in under a minute. But that doesn't mean I should leave the keys in the door or joe average smo can take it.

But you are right in everything you say about security. I don't think we were really disagreeing.

Re: **security** con't (2)

Conare (442798) | more than 11 years ago | (#4329120)

Security should be layered:

So once you've made it hard for the hacker to get into the system, also make it pointless. If the data that resides on the system is also strongly encrypted, than obtaining valuable information is not only hard it is a collossal pain, and beyond the capability of anyone except maybe NIST. BTW SSL as implemented by Web servers and browsers can't maintain encryption of data through to the back end, you need a third party product for that ( Yes they exist [entrust.com] ).

Version 1.2 (5, Funny)

Shagg (99693) | more than 11 years ago | (#4328669)

A Guide to Designing Web Applications That Will Survive a Slashdot DoS Attack.

Re:Version 1.2 (2)

tempest303 (259600) | more than 11 years ago | (#4329600)

Speaking of which, did anyone manage to actually grab the PDF of this before their server got utterly nuked by /. ?

Re:Version 1.2 (2, Informative)

russcoon (34224) | more than 11 years ago | (#4329833)

We've put a mirror up [wi2600.org] .

Re:Version 1.2 (2)

tempest303 (259600) | more than 11 years ago | (#4329921)

Got it, thanks!

Examples are a must (4, Interesting)

Photon Ghoul (14932) | more than 11 years ago | (#4328673)

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.

Re:Examples are a must (1)

Photon Ghoul (14932) | more than 11 years ago | (#4328716)

or even better a spellchecker for me.

For clarity, "comentizing" is "componentizing".

examples often become crutches (2, Insightful)

Provincialist (572648) | more than 11 years ago | (#4328976)

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:Examples are a must (1)

pVoid (607584) | more than 11 years ago | (#4329105)

There's an excellent book called "Writting Secure Code" (by Microsoft Press would you believe it), that talks about security in great depth.

I recommend anyone shooting their mouth off here to read it before they do.

But on topic with the parent post, it says "adopt the idea that examples are actually templates" (or something along those words). What he means is that writting an example that doesn't check for error return codes (or memory overrun issues) will most probably end up in insecure code being written.

Seriously though, anyone talking about security should read such a book before they do.

Ignores the wiki (2)

sphix42 (144155) | more than 11 years ago | (#4328694)

>> Access control mechanisms are a necessary and crucial design element to any application's
security....a web application should protect front-end and back-enddata and system resources by implementing access control restrictions ... Ideally, an access control scheme should protect against the unauthorized viewing, modification, or copying of data.

Yea, whatever. [wikipedia.com]

This document does seem to be pretty good, but documents like this really need to be peer reviewed. Personally, I think a document like this would be better as a wiki than a pdf.

Re:Ignores the wiki (-1, Troll)

Anonymous Coward | more than 11 years ago | (#4328803)

Fuck you and your stupid "wikipedia" toy. Maybe when you geeks can create something that ADULTS wouldn't mind saying, you might win some mindshare.

Hint: Names like OGG, WIKIPEDIA [goatse.cx] , and GNU/ANYTHING aren't working. So please gently rim my aszho)l3.

Re:Ignores the wiki (1)

russcoon (34224) | more than 11 years ago | (#4329905)

It's available (and being developed) as DocBook [sourceforge.net] . You can grab a copy and send me patches. Or you could join the project and help us out if you feel that strongly. Send me mail [mailto] if you're interested.

For those of you using PHP in particular... (5, Informative)

angst7 (62954) | more than 11 years ago | (#4328726)

As a supplimentary reading assignment, this months Linux Journal [linuxjournal.com] is running an similar, interesting article on Programming PHP with Security in Mind [linuxjournal.com] .

---
Jedimom.com [jedimom.com] , choo choo choosing you...

"click through" (5, Informative)

Conare (442798) | more than 11 years ago | (#4328736)

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.

classic 1) 2) ??? 3) profit (0)

Anonymous Coward | more than 11 years ago | (#4328816)

1) Make a guide to building secure web applications
2) People come onto your site and don't click the banner ads
3) ???
4) Profit

Re:classic 1) 2) ??? 3) profit (0)

Anonymous Coward | more than 11 years ago | (#4330124)

3) Chicks!!

It's very good topical (1)

eastshores (459180) | more than 11 years ago | (#4328831)

I have perused the WASP security guide and they do a good job of covering the most common exploitation methods. I have decided to use the WASP paper as a foundation document for the security practices of our team. The security of your web application, like many other things has dependancies like the OS and web server software. The saying that security is only as strong as your weakest link comes to mind, but the important thing to note here is that the WASP paper concentrates on the realm of web applications only. Concepts like failing closed when you encounter errors are important logical conventions to implement in order to make your application secure. EVERY web application developer needs to understand the material covered by the WASP.

Sloppy samples (5, Insightful)

phorm (591458) | more than 11 years ago | (#4328865)

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 (0)

Anonymous Coward | more than 11 years ago | (#4329159)

That is why you store the MD5 hash of the password and compare with that.

bad password checking (Re:Sloppy samples) (1)

phorm (591458) | more than 11 years ago | (#4329272)

Indeed, I was using this as an example of many samples which demonstrate using plain
WHERE USERNAME='$uname' PASSWORD='$pword'
This is common and quite foolish. I prefer to use:

SELECT COUNT(username) as SuccessCount FROM users WHERE username='" . $username . "' AND password=PASSWORD('" . $password . "')"

Where $username and $password have already been checked for funky input, and the PASSWORD function could be substituted for MD5 easily enough.

SELECT * FROM idiots WHERE username='admin' AND password='admin' - phorm

Quick useful SQL string (Re:Sloppy samples) (2)

phorm (591458) | more than 11 years ago | (#4329392)

Another thing that may be useful to run every so often. If you have a large password database, and foolish users, there's a good chance that you'll get some changes from this (unless you run something to check for dumb password import).

UPDATE users SET password=PASSWORD('$somerandomvalue') WHERE password=PASSWORD(username)
Substitute as needed:
password (possibly for MD5)
fields: password, username
table: users
Oh, and don't forget to set $somerandomvalue beforehand, otherwise the users get no password - which is even worse!

$somerandomvalue=iamadumbasswithaneasypassword - phorm

Re:Sloppy samples (2, Informative)

russcoon (34224) | more than 11 years ago | (#4329368)

I'm one of the guys running the project that's producing the Guide, and I can assure you that v2.0 will include language-specific examples and pitfalls.

Re:Sloppy samples (2)

phorm (591458) | more than 11 years ago | (#4330023)

If you need any help let me know (phormix at phormix dot com). I'd be more than happy to lend some examples of good and nightmarish coding.

Oh, and kudos for this work. I was at one time working on a simple PHP manual, but ran out of time before it even really got started. I'd be happy to start it up again, and get assistance from the slashdot crowd. It can be found at: phpmanual.phormix.com

Time for my server to get slashdotted? - phorm

Re:Sloppy samples (3, Insightful)

cowboy junkie (35926) | more than 11 years ago | (#4329915)

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.

Security... (0, Troll)

Eric_Cartman_South_P (594330) | more than 11 years ago | (#4328869)

1) Don't use .NET

2) ???

3) Secure!

Re:Security... (1)

eastshores (459180) | more than 11 years ago | (#4328931)

Why not use .NET? What security problems can you cite with the .NET architecture alone? What would you propose take its place?

Re:Security... (1)

chris_mahan (256577) | more than 11 years ago | (#4329180)

Inability to audit the source code.

The inability to conduct a proper audit of the code is a security problem.

An Open-Source system.

Thankyou... (2)

Eric_Cartman_South_P (594330) | more than 11 years ago | (#4329808)

Bingo... you saved me some typing.

Re:Security... (1)

eastshores (459180) | more than 11 years ago | (#4330293)

As long as it would be understood what the trade offs were as there is no open source platform equivilant to the .NET platform. That's not an argument. Looking back, the comment was reffering to something out of the scope of what the WASP paper covers, so I won't comment further on this.

But waht about Linux? (-1)

slashuzer (580287) | more than 11 years ago | (#4328903)

Please note that the plural of application is NOT applications.

It's applicationii.

Developers, developers, developers, developers! (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#4328904)

Developers, developers, developers, developers!

Thanks... (0)

Anonymous Coward | more than 11 years ago | (#4329026)

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

Could the be more non-committal?

Re:Thanks... (1)

russcoon (34224) | more than 11 years ago | (#4329694)

Hi,

I'm one of the people responsible for the Guide (editor, author, whatever you want to call it). This being the case, I'd like to clarify what we're saying there.

Those of us that do security for a living must understand that there is no such thing as "secure". There is only "secure against some class of attackers for some period of time". That's the best anyone (DOD included) can ever assure about a system. Take the example of a bank vault. Bank vaults are not un-assailable, nor are they designed to be. Instead, they are designed to withstand some form of attack for some period of time. There will always be some form of attack that will work against said vault, espically if what it's in the vault is valuable enough.

So what's a defender to do? First, those designing systems must realize that there will always be holes, and that designing those systems in ways that that minimize the impact of penetration of any layer is the only sane thing to do. Secondly, one must understand that it's not about making something "secure", it's about managing the risk involved in whatever enterprise you're about. There will always be risk, and the constant patch-and-pray cycle we see in computing is just validation of this principle. Instead of insisting that something be "secure", it's better that the risk/cost ratio for protecting that asset be favourable.

So can we commit to providing a silver bullet? It would be irresponsible of the authors of the Guide to do any such thing. Instead, we are attempting to present some strategies for understanding, quantifying, and managing risk.

HTH

What bugs me (3, Interesting)

Boss, Pointy Haired (537010) | more than 11 years ago | (#4329031)

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.

Re:What bugs me (3, Insightful)

Boss, Pointy Haired (537010) | more than 11 years ago | (#4329085)

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.

Re:What bugs me (2, Informative)

PhilipMatarese (609325) | more than 11 years ago | (#4329218)

Actually, this is a very common problem. There might not be many unknowns if a SQL execution error gets displayed in the middle of a page response.

IIS by default will throw the SQL error into the response (making it easier for developers to debug). If a developer doesn't trap/handle this and a user sees the error come up, they can find out a lot about the system. Then the user adds some quotation marks in with there inputs, and they could pass SQL instructions direct to the database.

This is a very real problem that occurs. Of course, the user would probably not be able to do meaningful damage without knowing the backend of the system, but they could still screw up your data tables.

Re:What bugs me (2, Informative)

pVoid (607584) | more than 11 years ago | (#4329226)

that's where you're wrong.

Security vulnerabilities aren't a person going "mirror, mirror, oh randomness mirror, give me a random string to hack this site".

it's all tied in together. For example securely failing is part of it. I personally will almost always check if a website can handle single quotes in HTML fields. Some of them do, some of them don't. Others don't and give away some such glarringly compromising error message that you can actually see the SQL statement.

here's a very simple one, take it home, think of it...

my user name is :

"Adam' \n go \n sp_addlogin 'myhaxx' , 'yourpass' \n go \n select '' = '" This statement might not even fail if the orginal statement is:

EXISTS( SELECT * FROM myUsers WHERE UserName = $UserName )

It's not as hard as you think it is, and just because you can't think of something, don't go thinking nobody else can.

Security is about being humble really.

random attacks? what for? (2, Insightful)

Unordained (262962) | more than 11 years ago | (#4329295)

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

Re:What bugs me (1)

MillerAH (240692) | more than 11 years ago | (#4329331)


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.

Which, with SQL server admins, might actually work!

Re:What bugs me (1)

russcoon (34224) | more than 11 years ago | (#4329747)

Fuzzers, proxies, stupid apps, and the limited number of SQL dialects in use today make this attack not just theoretical. In theory, yes, there are a lot of variables in play, but the intelligent attacker can quicly whittle this down. Are they hosted on IIS? Yes? Then the odds are pretty high they're using MSSQL too. It's not rocket science (or skiddies wouldn't be the ones doing it).

SQL injection is only one problem, but the results of it's success (given the poor defensive posture of most web apps) are usually catastrophic. It's not the root cause of most problems, but it's something that we can't just ignore. Like it or not, it's dangerous. The authors of the Guide (myself included) would be remiss in not including it.

More generally, canonicalization of input and sanity checking external inputs is the root cause of most security problems (not just in web apps) today. Calling it "clever indeed" ignores the severity of the situation and the truly atrocious state of security (which directly is related to code quality) of most deployed apps.

We're not trying to be clever. We're trying to be practical.

Remember Me? (2, Interesting)

duplicate-nickname (87112) | more than 11 years ago | (#4329360)

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.

another resource (3, Informative)

tommck (69750) | more than 11 years ago | (#4329409)

There's also a decent book out called Quality Web Systems [amazon.com] (I know... amazon! here it is at bookpool [bookpool.com] ) that might be useful to some. It talks about lots of aspects of securing (and testing that security) web sites.

T

Mirror (2, Informative)

russcoon (34224) | more than 11 years ago | (#4329455)

We've got a mirror of the guide up [wi2600.org] (fat pipe generously donated by the wisconsin 2600 chapter [wi2600.org] )

If you're interested in helping out with the project, check out our SourceForge project page [sourceforge.net] and drop me a line [mailto] if you'd like to contribute or have suggestions or patches. The whole thing is now in DocBook format, so diff's are always appreciated.

Re:Mirror (0)

Anonymous Coward | more than 11 years ago | (#4329609)

Thank you, thank you!!! Trying to download the PDF from the original URL was pathetically slow (averaged around 0.2KByte/sec). Are they serving the files off of an Apple II? :)

Re:Mirror (1)

russcoon (34224) | more than 11 years ago | (#4329778)

no, but OWASP is run off of donated hardware and bandwidth, so we have limited resources to deal with the likes of a slashdotting.

DOWNLOAD SITE FIXED (1, Informative)

Anonymous Coward | more than 11 years ago | (#4329795)

I host the main download. Had some server issues along with 7.5mbit of bandwith being pulled through. Sorry about the download problems my generic fbsd couldn't handle it. Had to up max memory requests to 30k from 4k. - zeno@cgisecurity.com

Mirror (1)

Door-opening Fascist (534466) | more than 11 years ago | (#4329874)

Since it seems like OWAPS is being Slashdotted, I have set up a mirror here [earlham.edu] .
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>