[Owasp-leaders] Detecting SQL Injection at SQL Server level
bill at pointweb.net
Thu Oct 29 23:50:25 UTC 2015
The SQL Server is doing what is asked of it. That's why it is injection.
You can guess, put in logic that says "If you see these commands together,
but that would probably cause more problems than you would solve. The job
of the database is to run SQL commands. The job of the application is to
send those commands. It is on the sender to send the right commands.
On Thu, Oct 29, 2015 at 5:25 PM, Dinis Cruz <dinis.cruz at owasp.org> wrote:
> 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
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OWASP-Leaders