Java Reference
In-Depth Information
Lack of input validation
Error handling laws
Improper authorization rules on database
10.3.1.1 Dynamic Use of Data to Construct SQL Query
Ordinarily SQL statements are used by applications to query databases for CRUD operations. he
statements are something like this:
“SELECT * FROM USERS where USER =” + request.getParameter(txtUsername) +
“AND PASSWORD =” + request.getParameter(txtPassword)
his usage is unsafe because it allows the attacker to perform injection attacks. he data entered
by the user is dynamically used to generate the statement and query the database. For instance, the
attacker can just use the following statement to bypass the authentication defenses of the applica-
tion and gain access to the application. he attacker can enter “anything” OR “1” = “1” in the
input ield where the user enters a username and type in a random password in the password ield.
he statement generated because of this is as follows:
SELECT * FROM USERS where USERNAME = 'anything' OR '1'='1' AND PASSWORD =
'nonsenseValue'
he query generated from the above statement means that if the username is anything OR if
1=1, which is a true condition, then the query is successful and the user is authenticated into the
application. his is so because 1=1 is always a true condition and since the statement contained an
OR, the statement achieves its objective and allows the attacker to authenticate to the application.
Let us now explore a more dangerous example. For instance, applications usually contain a ield
where a user enters the email address he/she has registered with the application for the application
to verify and send the forgotten password of a user. he query used by the vulnerable application
to access the database is as follows:
“SELECT username, password, full_name, email from USERS where email = '”
+ userEmail
he attacker looking at creating maximum damage can write the following query:
anon@anon.com'; DROP TABLE USERS; --
his constructs the following SQL statement:
SELECT username, password, full_name, email FROM USERS where email =
'anon@anon.com'; DROP TABLE USERS; --';
If the database is not read only and database input is not sanitized, then the entire table, USERS,
would be dropped and the application would lose its USERS table.
We can clearly see from the above examples that generating SQL queries from dynamically
generated user input can be very dangerous and is one of the leading causes of SQL injec-
tion attacks being perpetrated. All the database calls of the application should be based on
Search WWH ::




Custom Search