Slashdot Mirror
Top 10 Vulnerabilities in Web Applications
sverrehu writes "The Open Web Application Security
Project (OWASP) has released a well-written document that is a
must read for every web programmer out there. This security document
is not about firewalls, encryption and patching. It's about common,
highly exploitable errors made by the application programmers. Pick
up your copy of "The Ten Most Critical Web Application Security
Vulnerabilities" from the OWASP web site."
It's a nice start and definately points out some things developers should be aware of. But how about someone puts together a more specific checklist/tutorial for each point and write it around their favorite development language (PHP, ASP (cough), etc.). Who's not busy?
- "That don't make no sense!"
This seems to be a moving target, though with the first vendor or platform that jumps to mind regarding vulnerabilities is a given. I'd say the root class is MicrosoftVulnerability and subclasses are Windows, Explorer, Outlook, Office, etc, all of which should be behind a firewall and virus/worm filters. Exposing an MS workstation to the internet is asking for it. However...
On unixes (including BSD and Linux) there's been the danger of unexpected post commands on webservers, directory access, etc. When I coded a perl search engine, years ago I found I had to absolutely lock down what was accepted as parameters and subsequent values. Frequenly processes ran with root authority, to access all resources. Granted this was probably the fault of the admin, not wanting to devote time and effort to make all necessary resources available to a special account for scripts to run in. Does this hold true today? (Obviously directories are still frequently available, even on CNN :o)
A feeling of having made the same mistake before: Deja Foobar
www.cgisecurity.com/lib
I guess that you can break these down but to me it seems that the top vulnerabilities are:
.
Crappy Code - Some of the people that are writting applications today either never learned about security or just don't care. This spans both the closed and open source world (there are examples in both).
Bad Configuration - How many times do we hear about Joe (no offense if your name is Joe and you are an admin) admin configure a webserver (or application) and leave some huge wide open hole because they either couldn't understand the directions in the README or never bothered to look. Then they whine about it when they get 0wn3d
one of my favorites is index.php?p=blah.php where you can easily replace blah.php with something a little more interesting, such as /etc/passwd
I've emailed several people notifying them of this problem but not one single person changed their code.
Unfortunately, they forgot:
.jpg, the application allows the user to upload a file of any name.
-Application allows user to upload a file (attachment, image, etc) somewhere into the webroot.
-Instead of sending a
-User uploads "mail_me_your_sources.php", or similar
-This upload becomes executable, user has control of server
S
- Buffer overflows
- Buffer overflows
- Buffer overflows
- Buffer overflows
- Buffer overflows
- Buffer overflows
- Buffer overflows
- Buffer overflows
- Buffer overflows
- Buffer overflows
My list is based on 15 years of watching the industry. Things may change for the better, in that buffer overflows decrease and thus other problems become more clear, but I haven't seen that yet.It certainly is true that there are more tools and languages out there that make it easier to avoid buffer overflows than there were fifteen years ago. Problem is, most folks are still writing application code just like it was fifteen years ago, with fixed-size buffers and system calls that allow you to overflow them, even when the tools permit far more robust stuff to be done.
"While this is stuff that matters, it certainly isn't news. Folks have been making the same sloppy mistakes and careless oversights since AOL was trading at $140/share. (And that's a long time ago.)"
/. babbles on and on about security and rarely goes into detail like this about what we can do about it. I only picked up PHP a year ago and just from reading some of the posts here, I've gone back over code I've written to make sure I didn't make those mistakes.
I'm gonna haveta defend Slashdot here. It may not be news, but
Just because it's not a new topic doesn't mean it's not new to some people. Frankly, I'd rather read old articles like this than the usual finger pointing at Microsoft.
A number of these are just common sense, applicable to all programming.
I found a small software vendor who included the price in the URL of theproduct you are ordering. I was able to modify the prices in the shopping cart at will, of course I did not try to exploit that, but I e-mailed both the vendor and the people who made the shopping cart.
Neother seemed particularly concerned. The vendor responded that all orders are eyeballed by people, problems wouldn't occur. I suppose if you changed all the prices to 1 cent, sure. But what if you just gave yourself a nice little discount?
The fact of the matter is that a lot of developers (and even users) don't seem really concerned (at least until someone screws them over...).
You are in a maze of twisty little passages, all alike.
The same thing goes for backup file extensions, such as .php~. The first thing I do when I set up Apache is to make it parse those files as PHP just in case. You'd be amazed at how many peole have vulnerable files like that just lying around. Try looking for index.php~ and you can often find all kinds of stuff from there.
So this begs the question:
What is a good way to handle the (IMO required) ability for users to click a checkbox so they don't have to enter their login information all the time.
Yes, of course, any access to sensitive data should prompt for a password again even if they're logged in, and SSL is manadatory for some information.