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

Jon Passki jon.passki at owasp.org
Wed Mar 6 04:06:17 UTC 2013


(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