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 read that as "Hey, let me post something that makes me sound smart as fast as I can! Cause I WANT FIRST POST!"
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]
Easy... Don't use IIS as your server.
its called install linux, that way no one can hack you!
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.
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.
What's better?
1. Writing free software?
-or-
2. Sex with a mare?
Wow! You must have special ESP powers. I am gay and I am a fucking moron. Very perceptive.
>> 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.
What type of a mare? Like, a Pinto or a Clydesdale?
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!
See subject...
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
Why else?
Security by obscurity.
Just because we don't agree with the concept doesn't mean that it doesn't exist.
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
I'll slap the shit out of you bitch.
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.
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
2) ???
3) Secure!
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.
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?
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!
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
Security by obscurity provides security in the same way false hope provides hope.
See also Building Secure Software: How to Avoid Security Problems the Right Way.
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.
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.
number 1: do not use any microsoft products at all.
Exactly my point! I wasn't attempting to troll back there, I was attempting humor. Sadly, I failed. Miserably.
Doesn't matter. The web browser only has to maintain an encrypted connection to the server. The server then can have its own encrypted connection to the DB (eg, via PostgreSQL's hostssl setting.)
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.,
Your custom regex will probably miss a lot of valid addresses otherwise...
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)