Questions about this topic? Sign up to ask in the talk tab.

SQL injection/countermeasures/environment

From NetSec
Revision as of 03:17, 10 August 2012 by AlizaLorenzo (Talk | contribs) (Created page with "<noinclude>:<font size="-2">SQL injection > Countermeasures > Environment </font></noinclude> Due to certain [[vulnerability|vulnerabilitie...")

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
SQL injection > Countermeasures > Environment

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.