Owl for IIS identifies SQLs just before those are being executed in runtime. That is by implementing Runtime Application Self-Protection (RASP) module.
Your web application is getting input via query and post parameters. The input can produce cross-site scripting, SQL injection and other security breaches. By now we know WAF has limitations as it does not run in the process but in the network: 1. Some may be dependent on SSL keys when the traffic is encrypted. Those cannot handle the DH case 2. It cannot be sure which user is responsible for which SQL statements as the process may use a different user to run the SQLs 3. Sophisticated URL tampering may fool the WAF 4. Developer setting a backdoor in the application (activated by extra query parameter to finally run dedicated malicious code). How WAF can figure that out?
Take the following example: user browser is sending this HTTP request to get a list of users in the department http://applicationHost/getData.aspx?code=derpatment. But the user can also change manually into a different code value like http://applicationHost/getData.aspx?code=company. In addition to that lets say that the SQLs are being executed by a thread pool that authenticated using some generic user. 1. Database tool cannot tell who originated the request. 2. WAF need to be sophisticated to figure out something is wrong with the URL.
The only option you have to correlate user details (name and IP) with exact SQL statement that the application is executing is by being at the point where the application is sending the SQL statement out of the process. That is the real SQL after the application complete the input processing. No heuristics, no false positive. Owl for IIS is aiming to expose all SQL statements.
What is new in this release:
Version 1.3:
- audit file now include user name
- integration with IBM Guardium to pass application user name
Comments not found