Answers: Don't get blindsided by blind SQL injection attacks

1. Answer: c. WHERE clause.
"Web applications commonly use SQL queries with client-supplied input in the WHERE clause to retrieve data from a database. When a Web application generates such queries without checking or preprocessing the user-supplied data to ensure it's valid, a SQL injection attack can occur. By sending unanticipated input, an attacker can create and submit SQL queries to pass commands directly to a database…"

To learn more about how SQL injection attacks occur, read the rest of our Threat Monitor tip: Preventing blind SQL injection attacks, or listen to our Threat Monitor podcast.


























































2. Answer: False
"Many system administrators respond to SQL injection attacks by suppressing the display of database server error messages. However, that doesn't tackle the core problem, which is poor coding. Hiding error messages is really just 'security by obscurity'…"

To learn more about blind SQL injection attacks, read the rest of our Threat Monitor tip: Preventing blind SQL injection attacks, or listen to our Threat Monitor podcast.


























































3. Answer: a. An attacker can take advantage of error messages from the server or other sources of information about the application.
"This is called a blind SQL injection attack, because the attacker cannot take advantage of detailed error messages from the server or other sources of information about the application. Getting the SQL syntax right is usually the trickiest part of the blind SQL injection process and may require a lot of trial and error. But, by adding more conditions to the SQL statement and evaluating the Web application's output, an attacker will eventually determine whether the application is vulnerable to SQL injection…"

To learn more about blind SQL injection attacks, read the rest of our Threat Monitor tip: Preventing blind SQL injection attacks, or listen to our Threat Monitor podcast.


























































4. Answer: b. Don't escape input values
"Unless you disallow all special characters in your input validation, you will need to make sure you properly escape or in some other way, account for special characters in the target subsystem..."

To learn more about secure coding practices mentioned in our Threat monitor tip, read our tip: Ten dos and don'ts for secure coding.
























































5. Answer: c. PreparedStatements and stored procedures
"If SQL statements must be generated on the fly, use PreparedStatements, as both PreparedStatements and stored procedures compile the SQL statement before the user input is added, making it impossible for user input to modify the actual SQL statement…"

To learn why these tools are recommended and to receive preventative measures, read the rest of our Threat Monitor tip: Preventing blind SQL injection attacks, or listen to our Threat Monitor podcast.



































This was first published in June 2006

Dig deeper on Emerging Information Security Threats

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchConsumerization

SearchEnterpriseDesktop

SearchCloudComputing

ComputerWeekly

Close