0

SQL Azure has a logic component called Threat Detection. I assume it looks for SQL Injection, but also evidence of dangerous commands like sp_exec.

I would like to expand that scope, and also inspect the following aspects of user traffic for SQL injection, and and other hacking-types of behavior...

  • HTTP GET/POST (or other verbs)
  • Client headers (that would show up in log management solutions)
  • Cookies not sent by my site

Assuming that something above triggers an alert, what is the most appropriate response:

  • Block the IP adress
  • Reauthenticate the user
  • Lock out the account
  • Flag the session?

What class of security tools would be appropriate for this type of activity (in the cloud), and where can I learn more about intelligent ways of handling the different responses/mitigation techniques?

makerofthings7
  • 50,090
  • 54
  • 250
  • 536

1 Answers1

1

The right way to act is to reject the request (fail request before starting any application code / SQL queries) and log the event with complete debugging information into the database, assign number to it and output the number to screen.

This should be not the same database as the operational one, it should be service database where you normally store logs of operations.

If it's API call, then make this number appear in the error message box. This is to deal with false positives for once, and secondly to deal with the successful attempts of injections.

However you cannot prevent "select 1;" arguments from being passed every time because it's always possible to pass "select 1;" somewhere and such request should be blocked before reaching the application code. Also, this is best implemented on dedicated "layer" where request is decoded and checked for this kind of stuff like mod_security does.

There's no way to block the user and log him out because there will be far too big impact, it's also on the wrong layer - it's application code layer and not the dedicated security layer.

Aria
  • 2,706
  • 11
  • 19