[Owasp-leaders] Detecting SQL Injection at SQL Server level
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
> 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
> 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.
> 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).
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OWASP-Leaders