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

Comments

Open Source Needs People to Reuse code

[Anonymous Coward]

One thing I notice is the large numbers of people who keep making the same require() or include() mistakes in php which allow attackers to run remote code. If you look at the relevant full disclosure lists there are several of these posted every week - Scanning tools like the Qualys Scanner spend a large amount of time looking for these easily preventable bugs - there must be thousands of these.

Make open source more secure, share your experience, police each other, make M$ security look bad. When you make a security fix in code make sure you comment it - someone is probably going to copy it as an example. Don't let mistakes or inexperience spread.

Re:Open Source Needs People to Reuse code

[oliverthered]

I aggree, but what need to hapen first is good use of design patterns (Active X/Com on linux would make code easy to reuse).

Most people write their own code because either
1: the interface to somone else code is clumsy.
2: They can't find the code there looking for
3: The codes poorly documented, both inters of design and API.
4: Because of the above potential hastles it's quicker.

As a good exmaple there are two UHCI implementations in the 2.4 kernel usb-uhci which has crap code but works and uhci which has nice code and doesn't work that well.
A lot of the functionality is re-implemented in the OHCI module (another USB protocol).

This has been fixed in 2.5 though (but not fully intergrated with things like usnfs yet).

Re:Open Source Needs People to Reuse code

[ProfKyne]

Even though PHP doesn't enforce it, it is always good practice to initialize your variables in any language. That stops the URL-based attack cold (though register_globals can help you remember the namepaces of your variables).

Re:Open Source Needs People to Reuse code

[oliverthered]

OK, Com is very complex.
You can access it in many ways and when done well you can improve threading models.

I should have said com-like
KDE uses dcop, Mozilla uses XPCOM, and there Corba in Gnome.

COM(likes) provide a good interface definition model (with inheritance), and are quite easy to use. god knows what interfaces libgif, libpng, libjpeg etc... use, i hope it's the same.

Re:Open Source Needs People to Reuse code

[The Snowman]

An even better solution is to configure Apache via httpd.conf or .htaccess not to serve those files. I am meticulous about deleting backup (.php~) files, and Apache is configured to return 403 Forbidden on *.inc. Even if you know the names of my include files, you cannot view them. This is a better solution than instructing Apache to parse them as PHP. You'll wind up with a broken page that way.

The beauty of configuring Apache to disallow these files is PHP can still access them locally, but any remote script or browser will not be able to use them.

Summary

[robbyjo]

1. Unvalidated Parameters
2. Broken access control
3. Broken account and access management
4. Cross-site scripting (XSS) flaws
5. Buffer overflows
6. Command injection flaws
7. Error Handling problems
8. Insecure use of cryptography
9. Remote administration flaws
10. Web and application misconfiguration

Re:Summary

[bwalling]

Err, #1, #5, and #6 can be summarized as: Don't trust user input.

Re:Summary

[The Snowman]

Don't hear too much about anyone using these 'sploits, and they've been around forever. Anyone out there running a PHP site been whacked around this way?

I run two sites with PHP and to test security, I use a few common sense computer science techniques:

• Bad GET data: I tried manipulating variable via the URL line. POST data is a bit tougher, as I need a UA that can manipulate it and don't know of one.
• Register Globals: since I don't have control over the physical server, I cannot turn this option off. However, I always use the full names, i.e. $_GET['data'] instead of $data. This helps with namespace collisions, for example, having POST and COOKIE variables with the same name. I used gvim's search feature since it highlights matches, and manually checked each variable to ensure it adheres to this standard. Whenever I use a global variable, I make sure I set it myself first just in case.
• Taint checking: this is one Perl feature I sorely miss in PHP. I do a lot of manual grunt work to "emulate" it though. I thoroughly validate each variable the user can directly or indirectly manipulate. Usually I use the contents of a user variable to set a separate internal variable, flagging error conditions such as data that cannot be entered on a form. Who knows, maybe this will prevent buffer overrun errors in MySQL too.
• Code Review: I remember reading a while ago about the unmatched security of OpenBSD, and that it was because of aggressive code reviews and tightly controlled release schedules. While my web sites don't mean a damn compared to OpenBSD, I still take after the OpenBSD team and review my code on a regular basis. I cannot tell you how many times I have caught bugs and errors that I did not see just the day before. You cannot find bugs if you do not look for them!

Security is not something that you can rely on other people to do for you: you will be let down. No matter how secure the tools are, you need to check things yourself.

This is news?

[Quasar1999]

Come on, Microsoft has listed these problems for years now... in the form of Service packs and hot fix descriptions... Sure it wasn't in a bullet form list... but each description had at least one thing from the list...

The real problem is lack of time to properly test code. Somehow in modern businesses, very little time is allocated to GOOD, extensive, useful testing for vulnerablities in apps.

Re:This is news?

[m0rph3us0]

Testing shouldn't be an end phase part of development. If you design your application to be testable and test each component rigorously as development progresses the end result is a much more secure piece of software. If you allocate 6 months at the end of dev to secure your software you will be looking at a nightmare.

The Biggest Issue

[sickboy_macosX]

"Hey this application is being run through a firewall, it must be safe" Thats the problem, if you are going to build applications for the web that are useful, you need to build it so it is Safe to run and you dont have worry the end user about what could happen That and we need to kill all the script kiddie hackers.....

Re:The Biggest Issue

[m0rph3us0]

People complain about script kiddie hackers but what does it say about us developers if those script kiddie idiots can defeat our security? I think if we are as brilliant as we think we are that we can easily find ways of defeating script kiddies.

quick reminder..

[Anonymous Coward]

..to those who didnt bother to read the article, it has these lines in it:

This security document is not about firewalls, encryption and patching. It's about common, highly exploitable errors made by the application programmers.

which means every post thats about IIS, Micro$oft, m$, microshaft and god knows what other words you use to make you look like an idiotic open source fanatic with no sense of reality are offtopic.

Re:Nice Start

[Slorf]

The only problem with that idea is that you'd need to have someone do that for every language used for web development. The top ten document is actually a much better approach, because it is not language specific. It important to understand the problem, no just follow a checklist. By becoming educated on these particular vulnerabilities, you'll gain a better understanding of web security in general, and may be able to recognize other potential security flaws when you stumble across them.

Not exactly new news

[Badgerman]

Though I think this is useful information, anyone whose been doing web app development for awhile knows these by heart, and by a few other organs as well.

I can't really get worked up over this announcement, what can I say?

Re:Not exactly new news

[Anonymous Coward]

Amen to that. These are not news to me either. The interesting thing, though, is that it probably is news to developers of ASP or PHP.

Relevant to everything:

[White Shade]

"The underlying reality is shameful: most system and Web application software is written oblivious to security principles, software engineering, operational implications, and indeed common sense."

I think a lack of common sense is a problem which applies to almost everything. Judges, certain chip-manufacturing companies, certain companies preventing sales of their better (*cough*alpha*cough*) products, etc, all seem to suffer from this affliction.

Another facet which the article may have neglected to mention is programmers who feel that they're better than the rest of their fellow programmers and so as a result they 'assume' that their software is inherently bug free, because obviously they could never write a buggy applcation.

In the recent case of HP and the Alpha, it seems as though both conceit ('our new chips are better', while quietly ignoring the facts) and a lack of common sense ('hey, how bout we not sell our better and more lucrative product, cuz thatll be fun!') and a dose of good ol' fashioned stupidity are involved...

Lack of common sense, conceit, and stupidity.. While the specifics of this article are clearly about web design, the overall lessons to be learned can, and should, be applied to technology, and life in general.

It's about time common sense became a bit more deserving of the title, and maybe once that happens we won't have to read articles like this one.

a "a must read"?

[farnsworth]

This is far from a "must read", it's good introduction to common mistakes junior developers/admins make with webapps. There's nothing in there that hasn't been covered before or is well-known to anyone who has even the least bit of real-world experience.

It seems like good information and it's well-written, but it's hardly anything ground breaking.

Re:a "a must read"?

[ergo98]

Totally agreed. Indeed in some ways it's redundant: Point #1 is "unvalidated parameters" while point #6 is "command injection" (which is via "unvalidated parameters"). Of course most troubling of all is the link on the right for "WebGoat": I suspect this must be some sort of automated goatse trolling system (humor).

Re:a "a must read"?

[sverrehu]

My experience is different than yours. I've spent the two last years giving courses and lectures on exactly these topics to approximately 700 programmers in everything from small, 10-person companies, via banks, to large, international consulting companies. Far less then half of these experienced developers knew about SQL Injection. Next to none fully understood Cross-site-Scripting-based session hijacking.

I used to spend some late evenings looking for symptomes of SQL Injection and Cross-site Scripting (two of the vulnerabilities most easily detected from the outside without doing something really intrusive). I have a list of 170 sites, including banks and web shops that have symptoms on these problems. That's about half of the sites I've checked.

I've skimmed book upon book on "building E-commerce solutions", and every single one of them contains examples with unintended security holes in them. Even books on web application security contains examples that are vulnerable.

So, I strongly disagree with you. In my experience, most web application programmers know next to nothing about these problems.

READ THE PDF!

[Wakkow]

Don't just scan the summary.. There's nothing that special about the top 10. Read the PDF which actually explains each item, giving examples and what to do about it. That is what makes the site worth looking at.

Well known, but not easy to do . . . .

[djembe2k]

Yes, all of these vulnerabilities are well known, but the reason that they are common mistakes is because it is so much easier to make them than to avoid them. Making people aware of them isn't the same as instructing people in how to avoid them.

While the list is (appropriately) in OS-neutral and scripting language-neutral terms, the way to correct these problems is specific to the OS, webserver and scripting langauge you are using. So the next question is: what are the resources for addressing these issues, specifically, for particular OSes, webservers and languages?

For those taking the MS approach (and flame it if you want, but IIS isn't about to stop being the #2 web server overnight, so it might as well be done as securely as possible), I can recommend the following two guides from SANS:

Securing Internet Information Server

and

Windows 2000/XP Scripting For Security

These are listed as "course books" on their site, but they stand alone as guides for those who already have some background and knowledge. And if you don't have much background and knowledge, SANS courses are very good. (In fact, just about everything at the SANS website is valuable for the IT professional who wants to know more about security -- which ought to be all of us.)

So, stop just posting that these 10 problems are old news, and post the resources you use (or learned from) to avoid these problems yourself on your platform of choice, so the many (majority?) still making these mistakes can learn to avoid them too.

I think the next wave of viruses...

[callipygian-showsyst]

...will be spread in JPEGs, GIFs, PDFs, .txt files, etc.

I don't think anyone has spent too much time looking for buffer overflows in the most common decoders for these filetypes; and I'm sure they exist.

As soon as someone figures out how to the Microsoft's LZW decompressor to overrrun its stack, or how to get a stack corruption in Adobe's Acrobat reader, it will be possible to spread viruses easily, becuase most people aren't afraid to open .GIF or .PDF files.

Re:I think the next wave of viruses...

[huh_]

Of course as soon as a virus comes out of these filetypes, people will stop opening them up pretty quickly.

Yeah, I'm sure.. Just like people stopped opening unknown executable attachments in their email.

Re:Nice Start

[Skidge]

Here's a (somewhat old) document detailing some common PHP exploits and vulnerabilities.

A Study in Scarlet

It was written with PHP 4.0.something in mind, but a lot of the stuff can still be applied to the latest versions out there.

Re:Here's an Example

[GigsVT]

WHERE messageID = form.messageID AND userID = cookie.userID

Yeah, it's a good thing users can't edit the cookies that are stored on their hard disk..... oh wait.

To do something like this securely, give the user a unique session ID and put only that in the cookie. Then manage all their session data on the server side. That's what PHP does.

It's a mindset

[ryochiji]

>include($theme . "theme.php");

It's really a matter of mindset and habit. It's an easy problem to avoid if you get to the point where a little flag goes off in your head every time you see an unchecked variable passed to a function that accesses files (i.e. include(), fopen()).

The problem: web programming is easy

[Anonymous Coward]

I've read it here many times: "web programming is easy, it's not like real programming". The problem is that managers and decision makers also read this kind of un-informed statement.

The truth is that it is easy to get something going on a website, but it is hard to get something that works well and is secure. The amount of time it takes to transform an interesting web demo to a well executed web application is staggering. It is also very hard to explain why all that time is needed. What happens is that web application get launched half-baked. If a company is lucky, the application will only annoy the users, if a company is unlucky, someone will walk right in through a common security hole and comprimise the whole application.

Moral to managers and project planners: believe your programmers when they tell you that there is more then meets the eye in developing web applications.

also dangerous:

[Fuzzums]

- having foo.php.bak files.
if these files access databases or contain other passwords they're likely to be visible in the .bak file.

- .inc files.
same probmen if .inc isn't parsed or blocked in any way.