Slashdot Mirror

← Back to Stories (view on slashdot.org)

A Guide to Building Secure Web Applications

Posted by michael on from the much-needed-little-heeded dept.

some-guy writes "The Open Web Application Security Project has released A Guide to Building Secure Web Applications, Version 1.1 "While this document doesn't provide a silver bullet to cure all the ills, we hope it goes a long way in taking the first step towards helping people understand the inherent problems in web applications and build more secure web applications and Web Services in the future...""

13 of 126 comments (clear)

  1. For those of you using PHP in particular... by angst7 · · Score: 5, Informative

    As a supplimentary reading assignment, this months Linux Journal is running an similar, interesting article on Programming PHP with Security in Mind.

    ---
    Jedimom.com, choo choo choosing you...

    --
    StrategyTalk.com, PC Game Forums
    1. Re:For those of you using PHP in particular... by Anonymous Coward · · Score: 1, Informative

      While a generally very good article, I just had to laugh at the authorize example. OK, so using safe variables like $_SESSION is a good solution, how about INITIALIZEING YOUR FRIGGIN VARIABLES?!?! All one needs to do to fix the original 'broken' example is add "$authenticated = false;" at the top. Problem solved. Depending on defaults is just asking for trouble. Sure, $authenticated is PROBABLY defaulted to 'false', but, uhm, would it kill you to initialize it and get the peace of mind?

      Sometimes the simplest solutions are the best, and doing more is just overkill. For example, suppose your 1000 php file project depends on register_globals being on. Instead of 'fixing' all the code so that it uses $_POST, or $_GET, or $_SESSION or $_COOKIE (and you will ALWAYS have to test all of them if input can come from either), you can just stick a couple of loops in a top level include file that iterate through those globals and register the named variables themselves (with a couple of small checks, of course, hehehe).

  2. "click through" by Conare · · Score: 5, Informative

    Any security mechanism should be designed in such a way that when it fails, it fails closed. That is to say, it should fail to a state that rejects all subsequent security requests rather than allows them

    This is one of my favorites. Most browsers fail SSL connections with a warning that allows the user to just "click through" if the certificate is expired, does not match the DNS name of the site, or is issued by an untrusted authority. Only the last of these should be a warning (since you may want to trust it anyway. The other two should be connection failures. I am glad they included this.

    --
    Stop Continental Drift! Reunite Gondwanaland!
  3. Re:Security - Why there is ignorance MONEY! by TheOste · · Score: 3, Informative

    >Why is there so much ignorance about security?

    Project Manager: Make it work as quick as possiable, this just a demonstration.
    Devloper: It works, but it isn't secure.
    Project Manager: Next project, we do not have more features to add. Put security on the puch list of things to do if it goes production.
    Devloper(Next week after site goes into production without speaking to the devloper): You know that site that was just supposed to be a demonstration, it has security problems.
    Project Manager: Is it working?
    Devloper: Yes.
    Project Manager: Is the flaw easy to find?
    Programmer: Not by your average user, but by someone looking yes.
    Project Manager: I do not see a reason to spend the money to secure this application at this time. It seems to be in production just fine, you are a better devloper than what I thought.

    Six Months down the road, the devloper gets strung up when someone accesses all of the inforamtion at the site. I have seen this happen far to many times in the real world.

  4. Re:Secure Web Applications by Wizard+of+OS · · Score: 3, Informative

    Found the document: http://members.rogers.com/razvan.peteanu/

    Or a direct link: http://members.rogers.com/razvan.peteanu/best_prac _for_sec_dev4.pdf

    --

    --
    If code was hard to write, it should be hard to read
  5. Re:What bugs me by PhilipMatarese · · Score: 2, Informative

    Actually, this is a very common problem. There might not be many unknowns if a SQL execution error gets displayed in the middle of a page response.

    IIS by default will throw the SQL error into the response (making it easier for developers to debug). If a developer doesn't trap/handle this and a user sees the error come up, they can find out a lot about the system. Then the user adds some quotation marks in with there inputs, and they could pass SQL instructions direct to the database.

    This is a very real problem that occurs. Of course, the user would probably not be able to do meaningful damage without knowing the backend of the system, but they could still screw up your data tables.

  6. Re:What bugs me by pVoid · · Score: 2, Informative
    that's where you're wrong.

    Security vulnerabilities aren't a person going "mirror, mirror, oh randomness mirror, give me a random string to hack this site".

    it's all tied in together. For example securely failing is part of it. I personally will almost always check if a website can handle single quotes in HTML fields. Some of them do, some of them don't. Others don't and give away some such glarringly compromising error message that you can actually see the SQL statement.

    here's a very simple one, take it home, think of it...

    my user name is :

    "Adam' \n go \n sp_addlogin 'myhaxx' , 'yourpass' \n go \n select '' = '" This statement might not even fail if the orginal statement is:

    EXISTS( SELECT * FROM myUsers WHERE UserName = $UserName )

    It's not as hard as you think it is, and just because you can't think of something, don't go thinking nobody else can.

    Security is about being humble really.

  7. Re:Sloppy samples by russcoon · · Score: 2, Informative

    I'm one of the guys running the project that's producing the Guide, and I can assure you that v2.0 will include language-specific examples and pitfalls.

    --
    Dojo: defanging browsers so you don't have to
  8. another resource by tommck · · Score: 3, Informative
    There's also a decent book out called Quality Web Systems (I know... amazon! here it is at bookpool) that might be useful to some. It talks about lots of aspects of securing (and testing that security) web sites.

    T

    --
    ---- It puts the lotion on its skin or else it gets the hose again. It does this whenever it's told.
  9. Mirror by russcoon · · Score: 2, Informative

    We've got a mirror of the guide up (fat pipe generously donated by the wisconsin 2600 chapter)

    If you're interested in helping out with the project, check out our SourceForge project page and drop me a line if you'd like to contribute or have suggestions or patches. The whole thing is now in DocBook format, so diff's are always appreciated.

    --
    Dojo: defanging browsers so you don't have to
  10. Book that covers similar topics by PaschalNee · · Score: 3, Informative

    See also Building Secure Software: How to Avoid Security Problems the Right Way.

  11. DOWNLOAD SITE FIXED by Anonymous Coward · · Score: 1, Informative

    I host the main download. Had some server issues along with 7.5mbit of bandwith being pulled through. Sorry about the download problems my generic fbsd couldn't handle it. Had to up max memory requests to 30k from 4k. - zeno@cgisecurity.com

  12. Re:Version 1.2 by russcoon · · Score: 2, Informative

    We've put a mirror up.

    --
    Dojo: defanging browsers so you don't have to