Security Controls and Measures For SQL Injection Attack (TASK 4)
Security Controls and Measures For SQL Injection Attack (TASK 4)
Injection Attack
Most modern websites and applications connect to databases
programmed using Structured Query Language (SQL). SQL injection
(SQLi) vulnerabilities arise when websites do not adequately screen,
filter, or control the queries from the website, which permits attackers
to attempt to inject fragments of SQL code into database queries to
extract information.
1. Filter database inputs: Detect and filter out malicious code from
user inputs.
2. Restrict database code: Prevent unintended database queries
and exploration by limiting database procedures and code.
3. Restrict database access: Prevent unauthorized data access,
exfiltration, or deletion through access control restrictions.
4. Maintain applications and databases: Keep databases fully
patched and updated. Upgrade when possible.
5. Monitor application and database inputs and
communications: Monitor communication to detect and block
malicious SQLi attempts.
Each method can be accomplished through various techniques that
we explore in more detail below.
http://www.store.com/Search.php?product="<SCRIPT>alert(‘Hi…
’) </SCRIPT>"
For databases that do not parse user input to check for HTML and
javascript tags, this extended URL will reply to the attacker with:
$id = (int)$_POST[“id”]
While typecasting can be very useful, it is more limited in application
and will not be as commonly used.
2. Restrict Database Code
Input filtering is a good starting point, but attackers can find other ways
to bypass inputs using zero-day vulnerabilities, credentials
compromise, and more. Organizations can restrict the code available to
a database to further control and limit the ability of attackers to exploit
SQL injection vulnerabilities.
While this action alone won’t stop SQLi attackers, it is an added barrier
to a common fact-finding tactic for SQL injection attacks.
However, they may not be suitable for all needs, especially those that
require dynamic SQL. In these situations, SQLi vulnerabilities must be
accepted as a possibility for code instructions and other tactics (such as
whitelisting, user input sanitization, etc.) must be used.
Limit Read-Access
The read-access configuration of the database implements a form of
least-privilege to protect against SQLi. A compromised credential or
unknown SQLi vulnerability will have more limited ability to extract
information when the associated access is managed and limited to a
subset of database tables.
Ideally, any linked servers, storage area networks (SANs), or cloud data
buckets should have minimal access to the target server and access is
limited strictly to mission-critical data. All linked assets should have
distinct logins from any process on the target server.
• BBQSQL
• Blind-SQL-Bitshifting
• Blisqy
• Damn Small SQLi Scanner (DSSS)
• explo
• Leviathan
• NoSQLMap
• Tyrant-SQL
• Whitewidow