[Owasp-leaders] The OWASP Periodic Table Project

Tue Mar 5 21:29:39 UTC 2013

You need both. 

Eoin Keary
Owasp Global Board
+353 87 977 2988

On 5 Mar 2013, at 22:28, Jim Manico <jim.manico at owasp.org> 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. 
> 
>> * 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.
> 
>> * Full SQL statements probably should have access-controls and anti-CSRF protections in place. (hopefully!)
> 
> You are hopping topics, but fair.
> 
>> * 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. 
> 
> Cheers,
> Jim
> 
>> 
>> 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
>>> 
>>> _______________________________________________
>>> OWASP-Leaders mailing list
>>> OWASP-Leaders at lists.owasp.org
>>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
> 
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders