Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Five Tips for Thwarting Data Input Attacks Against Your Web App

The Web is a battleground where data input attacks are a real danger. Michael Howard illustrates how attackers can gain access to your Web apps and how best to stop them.




Full Text Search: The Key to Better Natural Language Queries for NoSQL in Node.js

n my previous "Best Defense" article, I discussed creating secure Win32 applications. Now I turn my attention to another important battlegroundthe Web, where data input attacks are a real danger.

Although many sysadmins have undying faith that their firewalls will protect their systems from all known and unknown attacks, data input attacks come straight in through port 80. Meanwhile, Web site developers often take input from users assuming it is clean, well formed data. Most of the time it is, but a small percentage of bad, often malicious data can cause serious problems.

The Attacker's User Authentication Workaround
Imagine a simple login screen that takes a username and password from the user, posts the data to the server, and performs a database lookup to authenticate the user. This is a very common scenario. Many developers have code like the following ASP sample to validate the username and password:

<HTML> <%@language=javascript%> <% if (isPasswordOK(Request.form("name"),Request.form("pwd"))) { Response.write("Authenicated!"); // Do stuff } else { Response.write("Access Denied"); } function isPasswordOK(strName, strPwd) { var fAllowLogon = false; try { var oConn = new ActiveXObject("ADODB.Connection"); var strConnection="Provider=Microsoft.Jet.OLEDB.4.0;Data
Source=c:\\auth\\auth.mdb;" oConn.Open(strConnection); var strSQL = "SELECT count(*) FROM client WHERE " + "(name='" + strName + "') " + " and " + "(pwd='" + strPwd + "')"; var oRS = new ActiveXObject("ADODB.RecordSet"); oRS.Open(strSQL,oConn); fAllowLogon = (oRS(0).Value > 0) ? true : false; oRS.Close(); delete oRS; oConn.Close(); delete oConn; } catch(e) { fAllowLogon = false; } return fAllowLogon; } %> </HTML>

Notice that the username and password are taken straight from the post and passed into the evaluation functionan unsecure procedure. The SQL string used to query the database is built directly from data passed from the user. Normally, a well formed SQL string where the account is "mikey" and the password is "&y-)4Hi=Qw8" would look like this:

SELECT count(*) FROM client WHERE (name='mikey') and

For this account, the user is authenticated and allowed access to the resource when count(*) returns the number of rows that satisfy the query. If the result is zero, then no data was found that matched the query.

So how would an attacker get around the authentication phase? First, most attackers will assume you have a SQL statement like this, and they'll try to send bogus names and passwords that adjust the logic of the SQL statement. For example, an account named " x' or 1) or ('1" with the password " anyoldpassword" results in the following SQL statement:

SELECT count(*) FROM client WHERE (name='x' or 1) or ('1')
and (pwd='anyoldpassword')

If you understand SQL (and I hope you do if you're writing security-related SQL statements), you know that this always returns at least one row, so the value of count(*) will always be one or greater. The attacker is authenticated because count(*) returned >0, even though they don't know a valid username or password. Ouch!

Use the following five tips will help you to thwart unauthorized access to your Web apps.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date