Difference between revisions of "SQL injection/Countermeasures/Infrastructure"
(Created page with "<noinclude>:<font size="-2">SQL injection > Countermeasures > Infrastructure</font></noinclude> Web application firewalls usually operate a...") |
|||
| (One intermediate revision by one other user not shown) | |||
| Line 1: | Line 1: | ||
| − | <noinclude>:<font size="-2">[[SQL injection]] > [[SQL injection/Countermeasures|Countermeasures]] > Infrastructure</font></noinclude> | + | <noinclude>:<font size="-2">[[SQL injection]] > [[SQL injection/Countermeasures|Countermeasures]] > Infrastructure </font></noinclude> |
| − | + | Due to certain [[vulnerability|vulnerabilities]] requiring the use of [[boolean enumeration]] or timing attacks, many [[HTTP]] requests may be needed in order to successfully determine [[database]] contents, making the process of arbitrarily accessing data quite time consuming and noisy. Different [[Databasing engine|databasing engines]] have different configuration settings, but usually include some form of maximum number of connections, maximum query size, maximum results size, maximum number of connections per user or client, and other resource restrictive options. Simply distributing a time consuming attack may only hinder the attacker by exhausting resources. | |
| + | |||
| + | Database permissions and role-based-access control integration for the [[web applications|application]] may also play a large role in the amount of data an attacker may gather, as SQL injection only exploits in the context of the active connection to the SQL server that the [[Vulnerability|vulnerable query]] executes within (ie. the username and password that the application is using for the query being exploited). [[Programming language|Programming languages]] have different configurations for runtime as well, such as memory limits and maximum execution time when configured to run in conjunction with a webserver. Older versions of database servers may not have an information_schema database and may require a privileged user (like the database server administrator) to access any schema information. | ||
| + | |||
| + | === [[IDS]], [[IPS]], and [[Web applications|web application]] [[Firewall|firewalls]] === | ||
| + | |||
| + | {{:SQL_injection/Countermeasures/Infrastructure/Defenses}} | ||
| + | |||
| + | === Common web application firewall HTTPD modules === | ||
| + | |||
| + | {{:SQL_injection/Countermeasures/Infrastructure/WAF}} | ||
Latest revision as of 05:43, 19 July 2012
- SQL injection > Countermeasures > Infrastructure
Due to certain vulnerabilities requiring the use of boolean enumeration or timing attacks, many HTTP requests may be needed in order to successfully determine database contents, making the process of arbitrarily accessing data quite time consuming and noisy. Different databasing engines have different configuration settings, but usually include some form of maximum number of connections, maximum query size, maximum results size, maximum number of connections per user or client, and other resource restrictive options. Simply distributing a time consuming attack may only hinder the attacker by exhausting resources.
Database permissions and role-based-access control integration for the application may also play a large role in the amount of data an attacker may gather, as SQL injection only exploits in the context of the active connection to the SQL server that the vulnerable query executes within (ie. the username and password that the application is using for the query being exploited). Programming languages have different configurations for runtime as well, such as memory limits and maximum execution time when configured to run in conjunction with a webserver. Older versions of database servers may not have an information_schema database and may require a privileged user (like the database server administrator) to access any schema information.
IDS, IPS, and web application firewalls
Web application firewalls usually operate at the same layer as the HTTP server or web applications, and thus monitor the protocol and input layers. This is different than normal IDS, which are stand-alone pieces of software or hardware that inspect the network and the host layer. Most intrusion detection mechanisms built for web applications operate using signature-based detection. Therefore, as long as an attack does not match a signature, it will slip by most of them.
Common web application firewall HTTPD modules
- Mod_Security (Apache)
- Naxsi (Nginx)
- ISAPI Filters (Microsoft IIS)
Common signatures use regular expressions that will match (and block) many common or simple testing techniques.
