[Owasp-leaders] Detecting SQL Injection at SQL Server level

Eoin Keary eoin.keary at owasp.org
Thu Oct 29 20:56:38 UTC 2015


Yep, column size overload would cause SQL errors. -poor parser boundary validation.
Query record set overload in badly designed systems can also cause SQL /JDBC/ODBC errors.
 - no SQL injection in either of the above.



Eoin Keary
OWASP Volunteer
@eoinkeary



> On 29 Oct 2015, at 8:48 p.m., Jim Manico <jim.manico at owasp.org> wrote:
> 
> It might just be a lack of validation where (sloppy or weak) query parametrization is still in play, a (debatably) fairly minor bug.
> 
> Suppose you have an old site with no validation and string concatenation based dynamic SQL. This is terrible and is of course massive SQL injection.  Suppose this site went through a remediation process where all the queries were turned to parametrized queries to stop SQL injection. This is great! Nice work. Even without good validation, the query parameterization will fix the SQL injection. But suppose is was done a little sloppy where the variables were binded with "setString" and validation was never done.
> 
> This kind of site would be fairly immune to SQL injection, but would have a good number of endpoints that could cause SQL query errors. This pops up especially in the world of legacy remediation.
> 
> Aloha,
> Jim
> 
> 
>> On 10/29/15 10:33 AM, Dinis Cruz wrote:
>> Hi, anybody here has experience on detecting SQL injection on an high-volume SQL Server by looking at the SQL Queries errors?
>> 
>> I know some guys (like ETSY) are doing this, but when I was talking with the DBAs today they couldn't find an easy way to do it at the SQL server.
>> 
>> The logic is that there should be no SQL compilation errors in the Production SQL server, so any errors that occur should either be:
>> 
>> a) a nasty bug
>> b) an SQL Injection being triggered by accident
>> c) an SQL Injection attack
>> 
>> Since it is really hard for an attacker to perform an SQL Injection without triggering an SQL Error ONCE, monitoring for SQL errors is a great way to proactively detect attacks (which is what Dan and Zane talk about in this video https://www.youtube.com/watch?v=jQblKuMuS0Y)
>> 
>> Ideally this should be detected at SQL Server level since that will make sure that all possible scenarios are covered. The alternative is to try to detect it via AppDynamics, or on the server logs, or at the Java code (which will require code changes).
>> 
>> Dinis
>> 
>> 
>> _______________________________________________
>> OWASP-Leaders mailing list
>> OWASP-Leaders at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
> 
> -- 
> Jim Manico
> Global Board Member
> OWASP Foundation
> https://www.owasp.org
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20151029/26a22bc4/attachment.html>


More information about the OWASP-Leaders mailing list