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