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

Dinis Cruz dinis.cruz at owasp.org
Thu Oct 29 21:25:05 UTC 2015


ok, but how do we detect those errors in SQL Server?

On 29 October 2015 at 20:56, Eoin Keary <eoin.keary at owasp.org> wrote:

> 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>
> 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 listOWASP-Leaders at lists.owasp.orghttps://lists.owasp.org/mailman/listinfo/owasp-leaders
>
>
> --
> Jim Manico
> Global Board Member
> OWASP Foundationhttps://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/6ba20084/attachment-0001.html>


More information about the OWASP-Leaders mailing list