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? ]=-
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.
bytesmythe
Hypocrisy is the resin that holds the plywood of society together.
-- Scott Meyer
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.
A Good Troll is better than a Bad Human.
That sounds suspiciously like security through obscurity, which we all know *DOES NOT WORK*. /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.
I've done some web apps that require a login, either to the standard
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.
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.
>> Access control mechanisms are a necessary and crucial design element to any application's ... Ideally, an access control scheme should protect against the unauthorized viewing, modification, or copying of data.
security....a web application should protect front-end and back-enddata and system resources by implementing access control restrictions
Yea, whatever.
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.
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!
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
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
later,
Jess
I am programmed for etiquette, not destruction!
>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.
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.
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 ).
Stop Continental Drift! Reunite Gondwanaland!
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.
... 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.
... most people expect you to be using mysql, and will attack it as such.)
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
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
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:
ÕÕ
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
T
---- It puts the lotion on its skin or else it gets the hose again. It does this whenever it's told.
We've got a mirror of the guide up (fat pipe generously donated by the wisconsin 2600 chapter)
If you're interested in helping out with the project, check out our SourceForge project page and drop me a line 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.
Dojo: defanging browsers so you don't have to
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.
DO NOT DISTURB THE SE
See also Building Secure Software: How to Avoid Security Problems the Right Way.
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.
I can spell. I just can't type.
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.
Encryption is not a magic wand. Does the web browser need to be able to decrypt traffic from the server? If so, when the web server becomes "owned", than the decryption capabilities get owned as well. What is the benefit, at best a layer of extra knowledge to find the decryption routines (security by obscurity).
Designing a cryptographic system that will help against "owned" servers (or insider fraud, say you can't trust the system administrators) is much harder. You almost always have to go with data oriented encryption, as opposed to channel oriented techniques (such as IPSEC or SSL). Hardware crypto devices are also very useful - the physical layer obviously is primarily designed to counter insider fraud in a server installation. But even more important is the ability of hardware crypto devices to control the type of operations they can perform.
Think of the "PIN" in a banking system. The hardware device does not have the ability to "decrypt a PIN" (at least in most banks, but that's a different story). Compare that with the situation where say a PIN Translate function is put on a software server and that server gets owned. It would be relatively easy to break down the PIN translate function (which consists of a decrypt followed by an encrypt) and examine the internal results to find the clear PIN.
In summary, most uses of channel encryption (clearly that was what was described in the quoted section) will provide little protection against compromised servers. Many types of database encryption have the same problems, if there is some means of the server accessing the clear data.
For another book on writing secure programs, see my "Secure Programming for Linux and Unix HOWTO" at http://www.dwheeler.com/secure-programs. It's free, and it covers both web applications and non-web applications.
- David A. Wheeler (see my Secure Programming HOWTO)