[Owasp-leaders] Stop blaming developers on Sql Injection

Calderon, Juan Carlos (GE, Corporate, consultant) juan.calderon at ge.com
Thu Dec 4 10:05:50 EST 2008


> Hello Leaders
> 
> I liked a lot the mentality of Jeff Williams related to our Industry is not doing enough about security. 
> 
> We have seen Sql injection for many years now on every top X list of every single list about common security problems. We have see massive sql injections and robots on the wild and now many people, even not technical is aware of "the problem" but the increasing trend has not changed. 
> 
> So what it takes to stop this? to train every single old school, expert and newly graduated and amateur developer? fight back every single misrecomendation on the blogs of the world? I think no, a technology oriented solution is required. 
> 
> So my proposal today is to change how DBRM process Query languages and do not allow string literals that do not represent an object in the database in the Query string but as attached values. So 
> 
> Select * from table where id = 'something' when lastdate = #01/02/2007# 
> 
> Would be an invalid query as 'something' and #01/02/2007# would not be allowed by DBRM processor. Yet 
> 
> Select * from table where id = anothercolum and field2 = @@identity 
> 
> is valid, as we are comparing columns vs. columns and vs. internal variables (there are some room for security issues on this area of variables, but I am assuming that would me much less than the current threat) 
> 
> So, we would be forced to use parameterized queries to feed literal values in a DB information request for information or action. With the additional benefit of performance (less probability of another security problem - DoS) 
> 
> I know the change acceptance is a big deal as well, many existent applications would break or they will be forced to run old vulnerable version of RBDM until they are migrated, but once this becomes the new status quo we can think on how to use technology to avoid XSS and other security "plagues" in the same technology oriented way. 
> 
> You might realized this already but this could be applicable to any interpreter in a harder or easier way including LDAP, system functions, XPath,  etc etc 
So if the industry is not doing anything should we add something to enforce this on ESAPI?
> Regards, 
> Juan Carlos 


More information about the OWASP-Leaders mailing list