Slashdot Mirror

← Back to Stories (view on slashdot.org)

A Developers Security Bugs Primer

Posted by CmdrTaco on from the important-stuff-here-people dept.

CowboyRobot writes "ACM Queue's current issue on Open Source Security includes a short article by Eric Allman of Sendmail on how to handle security bugs in your code. "Patch with full disclosure. Particularly popular in the open source world (where releasing a patch is tantamount to full disclosure anyway), this involves opening the kimono and exposing everything, including a detailed description of the problem and how the exploit works... Generally speaking, it is easier to find bugs in open source code, and hence the pressure to release quickly may be higher.""

2 of 35 comments (clear)

  1. Priority... by Architect_sasyr · · Score: 4, Insightful

    Something I have noticed with the development team at my current place of work (I'm not on the team thankfully) is that they tend to do jobs in the order they were received... it make's the KPI's look damn good (all jobs are knocked over within x time frame) when in reality they should be setting a priority on each of these jobs.

    We recently (1 month ago) had a form in an easily accessible place vulnerable to SQL Injection due to a failure to validate ANY of the data passed to it. This job was only just patched this past week (and all updates have been run). This time frame, as far as I am concerned, is entirely unacceptable for a job that was so easy to fix yet so dangerous to our business.

    On disclosure: Add it to the release notes. If you roll out a patch for one problem, then the problem will be described in the release notes. If the release is internal then the problem will (SHOULD) also be documented in the testing plan and proceedure.

    My $0.02.

    --
    Me failed English...
    FreeBSD over Linux. If my comments seem odd, this may explain...
    1. Re:Priority... by --daz-- · · Score: 2, Insightful

      Why are people still generating SQL? Don't all the major DB engines favor prepared statements anyhow? Note: prepared statements =/= Stored Procedures, though in some engines, stored procedures are just another FORM of prepared statements. Using prepared statements (or parameterized queries, etc, etc) pretty much eliminates all SQL injection problems.

      Parsing is messy business and there's usually ways to thwart it by a determined h4x0r.