[Owasp-leaders] SQL Contexts and Developer Guidance (Was: The OWASP Periodic Table Project)

Jon Passki jon.passki at owasp.org
Wed Mar 6 13:59:41 UTC 2013


Jim,

I concur that we do agree on a lot. To close my thoughts on this, I think OWASP needs to provide actionable remediation guidance for developers regardless of viewpoints on the defect intrinsically. I'm happy to contribute some free cycles to help update wiki cheat sheets. (I still owe Dave W some cycles on XXE, haven't forgotten about it Dave!)

Before that, I'm looking at the leaders list to see if this is a quixotic battle with the "Thou shalt not" mindset. If so, I'll reframe from tilting and go chase other giants elsewhere. I've seen that mindset twice on this thread already and am somewhat hesitant. If we're up for some adventure, then I'll tilt away :)

Warm Regards,

Jon

On Mar 6, 2013, at 7:44 AM, Jim Manico wrote:

> Reply and CC leaders, I'm just trying to behave, I've been using leaders way to much lately and am trying to moderate my usage.
> 
> Aloha!
> - Jim
> 
> 
> 
> On 3/6/13 1:39 PM, Jon Passki wrote:
>> 
>> On Mar 6, 2013, at 5:28 AM, Jim Manico wrote:
>> 
>>> ( off list ).
>>> 
>>> Jon,
>>> 
>>> Fair perspective. I like this debate a lot - and it's important one. But I promised to minimize my leaders spam, so I'm taking it off list.
>> 
>> Fair. Do you know if there is another list where we can have open debates like this?
>> 
>>> I think the point I was making is crucial. You only need to validate table and column names if that input comes from untrusted data. This is fairly large design flaw. But for legacy remediation, validation or even better indirection (a lookup table to hide table names) is needed.
>> 
>> Concur with validating and look up tables fully.
>> 
>>>> * SQL identifiers ought to be validated from a known list of acceptable values.
>>> 
>>> This may be good for IDS/IPS - but in terms of SQL Injection, parametrize and this need goes away.
>> 
>> I'm not talking about detection or inline prevention. I'm focused on remediation in code.
>> 
>>> Every language on the web provides a query parametrization API. We are debating a very fine point, but personally think it serves developers to preach query parametrization as the primary SQLi defense.
>>> 
>>> Good conversation, and especially when dealing with legacy remediation, your points carry a lot more weight.
>> 
>> I'm coming from this as a vendor that needs to provide actionable advice to developers, regardless of my viewpoints on the defect intrinsically. I think there's a need at some level to describe what to do even though it may be a potential design flaw. (I agree exposing internals of a table or column name seems dirty. However, it's not my code, so I need to check my opinion.) This description, whatever this is , is what I'm lobbying for. I don't care if there's a qualifying box above it that points out issues w/ this approach. I want developers to have something to remedy their code.
>> 
>> Warm Regards,
>> 
>> Jon
>> 
>>>> (Changing the subject for a new thread.)
>>>> 
>>>> Hey Jim,
>>>> 
>>>> 
>>>> On Mar 5, 2013, at 4:28 PM, Jim Manico wrote:
>>>> 
>>>>> Good thoughts, Jon. My feedback inline.
>>>>> 
>>>>>> * SQL table names possibly could be escaped, depending upon the dialect in use. They still might need some type of filtering / IV.
>>>>> 
>>>>> Untrusted data landing into a table name, column name or similar space in a query is a design flaw in multiple dimensions. Your query is no longer paramerizable in most languages, and you are exposing system internals to users. 
>>>> 
>>>> I am sidestepping the discussion on the belief it's a design flaw. It's unrelated to my previous point about a remediation approach when data is concatenated within a SQL table name context. You are correct that a query doing this cannot be parameterized (at least in most Java query flavors, good point on different language support).
>>>> 
>>>>>> * SQL identifiers ought to be validated from a known list of acceptable values.
>>>>> 
>>>>> Can you give me an example? I still think this is a design flaw.
>>>> 
>>>> 'DROP TRIGGER foo.bar'
>>>> 
>>>> Where 'bar' is an identifier. Similar to tables in that table names are identifiers but identifiers don't need to be table names.
>>>> 
>>>>>> * Full SQL statements probably should have access-controls and anti-CSRF protections in place. (hopefully!)
>>>>> 
>>>>> You are hopping topics, but fair.
>>>> 
>>>> Point taken and it was a hop. Just things seen.
>>>> 
>>>>>> * Other odd ball contexts need their own love, probably along the lines of IV.
>>>>> 
>>>>> Would love to see some examples. 
>>>>> 
>>>>> And in general, input validation is great secure coding hygiene practice and does indeed stop some injection (like when validating numeric input that lands in a query). But to stop SQL Injection, it's all about query parametrization (and proper design) for complete defense. 
>>>> 
>>>> I understand your point but respectfully disagree. I think OWASP is better served to provide developers sound advice when developers are doing something risky versus telling them not to do something because it's risky (the "Thou shalt nots"). If there aren't safe API choices like parameterization, then it's up to security professionals to provide actionable guidance to developers.
>>>> 
>>>> If you agree, how would you see providing this guidance? The cheat sheets seem effective. However, the current SQL one seems more about contexts that can be parameterized. Would it be helpful to make it more general? Or how about code samples? Better messaging? I don't know. I'm interested to see what you think is effective in your experience.
>>>> 
>>>> If you disagree, why?
>>>> 
>>>> Regards,
>>>> 
>>>> Jon
>>>> 
>>>>>> On Mar 5, 2013, at 3:47 PM, Jim Manico wrote:
>>>>>> 
>>>>>>> Input validation is not the right control for SQL Injection, Dennis. https://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet
>>>>>> 
>>>>>> Input validation (IV) isn't right most of the time. However, if the tainted data is going into a context like a table name, an identifier, or other non-parameterizable contexts then something needs to occur:
>>>>>> * SQL table names possibly could be escaped, depending upon the dialect in use. They still might need some type of filtering / IV.
>>>>>> * SQL identifiers ought to be validated from a known list of acceptable values.
>>>>>> * Full SQL statements probably should have access-controls and anti-CSRF protections in place. (hopefully!)
>>>>>> * Other odd ball contexts need their own love, probably along the lines of IV.
>>>>>> 
>>>>>> 
>>>>>>> But otherwise you are right on. What you describe below is the direction I think James will be taking this.
>>>>>>> 
>>>>>>> Definitely a project to watch in my opinion.
>>>>>>> 
>>>>>>> Aloha,
>>>>>>> 
>>>>>>> - Jim Manico
>>>>>>> @Manicode
>>>>>>> 
>>>>>>> 
>>>>>>>> On 5 Mar 2013, at 20:35, Eoin wrote:
>>>>>>>> 
>>>>>>>>> So the periodic table is a list of vulns right? Best we share the work
>>>>>>>>> we did on the owasp common numbering system?
>>>>>>>> 
>>>>>>>> Not a list of vulns, the periodic table is a taxonomy of similarities.
>>>>>>>> Gases, liquids, solids etc… I imagine a taxonomy of vulns: input
>>>>>>>> validation, authorisation, access control, etc.. (the top 10 controls?)
>>>>>>>> Within the taxonomy of gasses are air, and helium for example. I further
>>>>>>>> imagine that input validation will have XSS & SQLi for example. I would
>>>>>>>> further imagine that the OWASP periodic table has its own shape that
>>>>>>>> doesn't much resemble the actual periodic table…
>>>>>>>> 
>>>>>>>> so I see it as a project to group known issues according to related root
>>>>>>>> causes.
>>>>>>>> 
>>>>>>>> Is this how others view this project?
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Dennis
>>>>>>>> 
>>>> 
>>> 
>> 
> 
> 
>> 
>> On Mar 6, 2013, at 5:28 AM, Jim Manico wrote:
>> 
>>> ( off list ).
>>> 
>>> Jon,
>>> 
>>> Fair perspective. I like this debate a lot - and it's important one. But I promised to minimize my leaders spam, so I'm taking it off list.
>> 
>> Fair. Do you know if there is another list where we can have open debates like this?
>> 
>>> I think the point I was making is crucial. You only need to validate table and column names if that input comes from untrusted data. This is fairly large design flaw. But for legacy remediation, validation or even better indirection (a lookup table to hide table names) is needed.
>> 
>> Concur with validating and look up tables fully.
>> 
>>>> * SQL identifiers ought to be validated from a known list of acceptable values.
>>> 
>>> This may be good for IDS/IPS - but in terms of SQL Injection, parametrize and this need goes away.
>> 
>> I'm not talking about detection or inline prevention. I'm focused on remediation in code.
>> 
>>> Every language on the web provides a query parametrization API. We are debating a very fine point, but personally think it serves developers to preach query parametrization as the primary SQLi defense.
>>> 
>>> Good conversation, and especially when dealing with legacy remediation, your points carry a lot more weight.
>> 
>> I'm coming from this as a vendor that needs to provide actionable advice to developers, regardless of my viewpoints on the defect intrinsically. I think there's a need at some level to describe what to do even though it may be a potential design flaw. (I agree exposing internals of a table or column name seems dirty. However, it's not my code, so I need to check my opinion.) This description, whatever this is , is what I'm lobbying for. I don't care if there's a qualifying box above it that points out issues w/ this approach. I want developers to have something to remedy their code.
>> 
>> Warm Regards,
>> 
>> Jon
>> 
>>>> (Changing the subject for a new thread.)
>>>> 
>>>> Hey Jim,
>>>> 
>>>> 
>>>> On Mar 5, 2013, at 4:28 PM, Jim Manico wrote:
>>>> 
>>>>> Good thoughts, Jon. My feedback inline.
>>>>> 
>>>>>> * SQL table names possibly could be escaped, depending upon the dialect in use. They still might need some type of filtering / IV.
>>>>> 
>>>>> Untrusted data landing into a table name, column name or similar space in a query is a design flaw in multiple dimensions. Your query is no longer paramerizable in most languages, and you are exposing system internals to users. 
>>>> 
>>>> I am sidestepping the discussion on the belief it's a design flaw. It's unrelated to my previous point about a remediation approach when data is concatenated within a SQL table name context. You are correct that a query doing this cannot be parameterized (at least in most Java query flavors, good point on different language support).
>>>> 
>>>>>> * SQL identifiers ought to be validated from a known list of acceptable values.
>>>>> 
>>>>> Can you give me an example? I still think this is a design flaw.
>>>> 
>>>> 'DROP TRIGGER foo.bar'
>>>> 
>>>> Where 'bar' is an identifier. Similar to tables in that table names are identifiers but identifiers don't need to be table names.
>>>> 
>>>>>> * Full SQL statements probably should have access-controls and anti-CSRF protections in place. (hopefully!)
>>>>> 
>>>>> You are hopping topics, but fair.
>>>> 
>>>> Point taken and it was a hop. Just things seen.
>>>> 
>>>>>> * Other odd ball contexts need their own love, probably along the lines of IV.
>>>>> 
>>>>> Would love to see some examples. 
>>>>> 
>>>>> And in general, input validation is great secure coding hygiene practice and does indeed stop some injection (like when validating numeric input that lands in a query). But to stop SQL Injection, it's all about query parametrization (and proper design) for complete defense. 
>>>> 
>>>> I understand your point but respectfully disagree. I think OWASP is better served to provide developers sound advice when developers are doing something risky versus telling them not to do something because it's risky (the "Thou shalt nots"). If there aren't safe API choices like parameterization, then it's up to security professionals to provide actionable guidance to developers.
>>>> 
>>>> If you agree, how would you see providing this guidance? The cheat sheets seem effective. However, the current SQL one seems more about contexts that can be parameterized. Would it be helpful to make it more general? Or how about code samples? Better messaging? I don't know. I'm interested to see what you think is effective in your experience.
>>>> 
>>>> If you disagree, why?
>>>> 
>>>> Regards,
>>>> 
>>>> Jon
>>>> 
>>>>>> On Mar 5, 2013, at 3:47 PM, Jim Manico wrote:
>>>>>> 
>>>>>>> Input validation is not the right control for SQL Injection, Dennis. https://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet
>>>>>> 
>>>>>> Input validation (IV) isn't right most of the time. However, if the tainted data is going into a context like a table name, an identifier, or other non-parameterizable contexts then something needs to occur:
>>>>>> * SQL table names possibly could be escaped, depending upon the dialect in use. They still might need some type of filtering / IV.
>>>>>> * SQL identifiers ought to be validated from a known list of acceptable values.
>>>>>> * Full SQL statements probably should have access-controls and anti-CSRF protections in place. (hopefully!)
>>>>>> * Other odd ball contexts need their own love, probably along the lines of IV.
>>>>>> 
>>>>>> 
>>>>>>> But otherwise you are right on. What you describe below is the direction I think James will be taking this.
>>>>>>> 
>>>>>>> Definitely a project to watch in my opinion.
>>>>>>> 
>>>>>>> Aloha,
>>>>>>> 
>>>>>>> - Jim Manico
>>>>>>> @Manicode
>>>>>>> 
>>>>>>> 
>>>>>>>> On 5 Mar 2013, at 20:35, Eoin wrote:
>>>>>>>> 
>>>>>>>>> So the periodic table is a list of vulns right? Best we share the work
>>>>>>>>> we did on the owasp common numbering system?
>>>>>>>> 
>>>>>>>> Not a list of vulns, the periodic table is a taxonomy of similarities.
>>>>>>>> Gases, liquids, solids etc… I imagine a taxonomy of vulns: input
>>>>>>>> validation, authorisation, access control, etc.. (the top 10 controls?)
>>>>>>>> Within the taxonomy of gasses are air, and helium for example. I further
>>>>>>>> imagine that input validation will have XSS & SQLi for example. I would
>>>>>>>> further imagine that the OWASP periodic table has its own shape that
>>>>>>>> doesn't much resemble the actual periodic table…
>>>>>>>> 
>>>>>>>> so I see it as a project to group known issues according to related root
>>>>>>>> causes.
>>>>>>>> 
>>>>>>>> Is this how others view this project?
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Dennis
>>>>>>>> 
>>>> 
>>> 
>> 
> 



More information about the OWASP-Leaders mailing list