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
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
Blame it on ElGeeko De Generico [generic geek]
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.
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.
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).
--
http://www.dennistighe.com
>> 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!
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.
-- Reality checks don't bounce.
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
Why not use .NET? What security problems can you cite with the .NET architecture alone? What would you propose take its place?
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.
A Good Troll is better than a Bad Human.
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!
Inability to audit the source code.
The inability to conduct a proper audit of the code is a security problem.
An Open-Source system.
"Piter, too, is dead."
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?
The government has a defect: it's potentially democratic. Corporations have no defect: they're pure tyrannies. -Chomsky
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
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
>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!
Glonoinha the MebiByte Slayer
Would this be the same case for ASP.NET since it's managed code?
I'm Rick James with mod points biatch!
See also Building Secure Software: How to Avoid Security Problems the Right Way.
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
Dojo: defanging browsers so you don't have to
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
Since it seems like OWAPS is being Slashdotted, I have set up a mirror here.
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.
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.
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.
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.
They should check out what RFP has to say over at wire trip. He is pretty savvy when it comes to software security.
FoundNews.com - get paid to blog.,
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)
Thats a good argument if I asked why I shouldn't use Windows. But they did engineer the .NET CLR for security. It's been out for well over a year, and in betas much longer, can you point to a single vulnerability?
Java webservers are servers and server apps in java.
ASP managed code *I believe* is just the ASP app not the buggy IIS server it runs on.