Thanks very much Steve for the candid response, and more importantly the
links to get us started down the straight and narrow...
I will be taking this all to heart, and have already scheduled a 'come
to Jesus' meeting for Monday for the Project Manager.
Simon
On 2012-02-24 2:33 PM, Steve Crawford <scrawford@pinpointresearch.com>
wrote:
> On 02/24/2012 09:58 AM, Tanstaafl wrote:
>> As you may have surmised, I am not a programmer, I'm simply trying to
>> get some pointers for our developers. Like I said in my last email,
>> they are not very well versed in postgresql yet
>
> I have to expand a bit on my prior email. I'm trying to be charitable,
> but validating and properly escaping inputs is a basic mandatory part of
> professional software development. No TODO later. No "when I get time."
> No exceptions. The manager of your developers may need to pull a
> Khrushchev and pound the table with his shoe to get everyone's
> attention. Certainly no unvalidated inputs should get through a
> code-review.
>
> Sadly, you are in good company. Sony Pictures, PBS, HBGary Federal (a
> security company no-less) and even mysql.com made the news in the last
> few months due to breaches tied to SQL injection vulnerabilities.
>
> One of my standard interview questions is "what are two or three of the
> top 10 software security-flaws/programming-errors." SQL injection has
> been #1 on the CWE/SANS most-dangerous software error list
> (http://cwe.mitre.org/top25/) for so many years that I assume the
> question is a softball. Unfortunately I often just get blank stares.
>
> Given the situation you described related to SQL there is a reasonable
> chance you are at risk of OS command injection, buffer-overflow and
> cross-site scripting attacks (#s 2, 3 and 4) as well. Fortunately,
> proper validation and escaping is the common theme for all of them.
>
> Don't assume that nobody will notice or figure out the vulnerability.
> Automated SQL-injection vulnerability scanners are a dime a dozen.
>
> Cheers,
> Steve
>
>