Re: Sanitizing text being stored in text fields - some characters cause problems
От | Tanstaafl |
---|---|
Тема | Re: Sanitizing text being stored in text fields - some characters cause problems |
Дата | |
Msg-id | 4F47FDB5.8060703@libertytrek.org обсуждение исходный текст |
Ответ на | Re: Sanitizing text being stored in text fields - some characters cause problems (Steve Crawford <scrawford@pinpointresearch.com>) |
Ответы |
Re: Sanitizing text being stored in text fields - some characters
cause problems
|
Список | pgsql-novice |
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 > >
В списке pgsql-novice по дате отправления: