In this article, the second in our series of articles on website security attacks, we look at the hows and whys of SQL injection.

SQL injection involves compromising the security of an application by insertion or injection of an SQL query via the input data from the client to the application. This can happen when the input data is not correctly filtered for string literal escape characters. Successful SQL exploits can read data from the database and DBMS files, make modifications to it and execute administrative functions on the database.

How does this work? Let’s take a simple query:

Select * from user_details where username = ;

The web page probably has something similar to the following to capture the username and pass it on to the  backend:

{ …

string userName = field.getUserName();

string query = “Select * from user_details where username = ‘” + userName + “’”;

…}

If a malicious user wanted to obtain the contents of the entire table (and the application is vulnerable to SQL injection attacks), instead of just typing in a username, he’d input <m_user’ OR ‘x’='x>. When this gets inserted into the query, the query gets transformed into:

Select * from user_details where username = ‘m_user’ OR ‘x’='x’;

Because ‘x’ always equals ‘x’, the condition is always true and the query, which essentially converts into ‘Select * from user_details;’ returns the entire contents of the table user_details.

Hackers can make use of this vulnerability to obtain data and perpetrate malicious attacks on websites. Some databases allow multiple SQL statements separated by semicolons to be executed as a batch, allowing the attacker to execute arbitrary commands on the database.

How can you avoid such an attack on your website? A simple approach is to accept characters only from an allowed list of safe characters. This provides a first layer of security for the application. Another way is to use parameterized statements and stored procedures. Also, it must be ensured that the account with the least privileges is used for all user interactions. These precautions will go a long way in preventing your site from being hacked.

References: http://www.owasp.org/index.php/Guide_to_SQL_Injection; http://en.wikipedia.org/wiki/SQL_injection; http://www.owasp.org/index.php/SQL_injection

This article takes a look at Cross Site Request Forgery (XSRF or CSRF), and what you, as a user or as an application owner, can do to avoid it.

CSRF is an attack from that enables an attacker to send HTTP requests from a victim’s computer without his/her knowledge. To elaborate: Assume that you checked the ‘Keep me signed in’ box when you logged in to your blog. This means that your security credentials are stored on your computer and sent by the browser to the site every time you make a request. You trust that the website will not impinge on your privacy and security, while the website trusts that any request coming with your credentials embedded in it actually comes from you. With this being the situation, it is very easy for an attacker to make unauthorized actions on the website while pretending to be you. Let’s see how.

Let’s assume that Jane generally uses the website examplestocks.com to trade in stocks. Since she uses the website quite frequently, she clicks on the ‘Keep me signed in’ box while logging in the first time to avoid having to key in her credentials every time she wants to look at the stock price. A malicious attacker wants to make use of this fact to sell some of Jane’s shares without Jane knowing about it. The attacker knows that the request to buy/sell is sent to the website in the form ‘http://examplestocks.com/sell.php?uid=Jane&symbol=XYZ&sharestosell=100’.

Before we proceed, some background of how a webpage is generated by a browser: When a browser makes a request, it receives a bunch of HTML code, which it then parses to render the page to the user. Attackers commonly use the tags that are used to include images on a webpage. The image tag is as follows: <img src=”http://examplestocks.com/stock.gif”> . When the browser comes across this tag, it sends a request to the server, and uses a standard ‘Get’ request to do so. It is impossible for the browser to differentiate between requests for different resources.

The attacker embeds the sell request within a blank image, i.e., the image tag will look like this: <img src=” http://examplestocks.com/sell.php?uid=Jane&symbol=XYZ&sharestosell=100″>, and makes the image part of, for example, an email. When Jane opens the email to read it, the html in it is parsed, and the request embedded in the email is sent to the website examplestocks.com, and the 100 stocks belonging to Jane in company XYZ are sold, all without Jane being aware of it.  Since the browser automatically supplies the required credentials (remember, Jane is logged in), the server has no way to validate whether the request has, in fact, come from Jane.

You, as a user, do not really have any control over this, since security is defined by the application; however, it may make sense to not keep yourself signed into important accounts like the one in the example above.

You, as an application owner, can take some precautions to ensure that your website is not prone to such attacks. One simple way of doing this is to append user session tokens, which expire after a set time, with each request. The malicious attacker will have no way to replicate this token, thus ensuring that there is no simple way for a non-user to access the site. For example, if you do your bank transaction over the Internet, you may see a ‘Session Expired, Please Login Again’ message if you take too long to input the wire transfer details after logging in. This does not offer complete protection, since an attacker could use complex Cross Site Scripting (XSS) or make use of browser vulnerabilities to perpetrate the attack. The only way to avoid such attacks on your application is by following rigorous coding and security processes to ensure that there are no loopholes in the code that can be exploited.

Source: http://shiflett.org/articles/cross-site-request-forgeries, http://www.cgisecurity.com/csrf-faq.html, http://www.owasp.org/index.php/Cross-Site_Request_Forgery, http://www.debian-administration.org/article/Improving_website_security