|
|
|
Technical Overview
What is a SQL Injection Attack?
SQL Injection attacks are based on hackers modifying queries to execute SQL commands. This allows them to delete data or access data that they are not supposed to access (e.g. customers’ credit card numbers or social security numbers).
For example,
http://www.store.com/?login.cgi?u=johnsmith&password=opensesame
could be replaced with
http://www.store.com/login.cgi?u=johnsmith&password’+OR+1=1--
This would effectively add +OR+1=1—to the end of the statement sent to the database.
Because 1 is always equal to1, the statement is always true, allowing the hacker to rewrite the logic of the original query in order to avoid having to supply a valid password for the user.
This strategy can be used to make any number of SQL attacks on this query. Moreover, these attacks are polymorphic, making it necessary to defend against many potential attacks. A hacker can use
‘
“
or representations of these characters such as
%0x27 (the ASCII representation of the ‘)
SQL Injection attacks are especially dangerous because of the capability they provide to the attackers. SQL is a rich language for querying information from a database. When an attacker can rewrite the query that an application makes to a database, then arbitrary data like passwords, credit card numbers, or personal information can be extracted – often regardless of the original intent or design of the application.
Because all of the standard SQL attacks are based upon inserting additional language as a part of SQL queries, they can be tested for using a finite set of tests. These test injections return errors when successful and they indicate that the application is likely vulnerable to SQL injection attacks with a slight modification of the query. This is the methodology used by NTOSpider and has two advantages: 1) these “attacks” produce errors but do not risk altering database records and 2) these “attacks” represent the common denominator of all of the more dangerous attacks and as a result, they will discover vulnerability to the entire range of known dangerous attacks as well as undiscovered ones.
For more information on SQL, Blind SQL Injection and testing for these vulnerabilities, download NTOBJECTives’ annotated slideshow "Understanding SQL Injection: Safely Testing Your Production Site" by NTOBJECTives’ CSO, Mike Shema.
|
|
What is a Blind SQL Injection Attack?
Blind SQL Injection attacks exploit the application even when simple input validation filters are in place that block the more common SQL Injection attacks. If the input filters only block quote characters, the attacker can still rewrite a successful exploit. These attacks highlight failures in securing the database query rather than just showing failures with input filters.
Blind SQL attacks avoid the use of ‘ or “ characters and create semantically identical SQL queries with syntactically different content. Unlike normal SQL injection attacks that attempt to generate an error by creating an invalid query, these attacks attempt to create an alternate query that preserves the original logic.
Vulnerability to Blind SQL attacks is not identified by attempting to obtain error messages. Instead, the safe methodology is to attempt to create identical queries by executing instructions at the application.
For example, if the query
http://website/viewitem.cgi?n=21
Returns the same as
http://website/viewitem.cgi?n=10%2b11
Which is distinct from
http://website/viewitem.cgi?n=10
Then the site is likely vulnerable to Blind SQL Injection. The key to this example is that two values for n, 21 and 10+11, return the same results. This implies that the raw values were sent through the application to the database because the database reduced the mathematical expression 10+11 to 21. Thus, no error messages are generated nor are they required to determine if the application is vulnerable.
Even such a simple technique as the addition of two numbers can be used to identify a vulnerability. Yet more advanced queries can be created that exploit the database in order to access, modify, or delete information. Blind SQL injection vulnerabilities are especially high risk because they are not immediately evident from tests that rely on signatures or patterns to identify SQL injection problems.
For More information on SQL, Blind SQL Injection and testing for these vulnerabilities, download NTOBJECTives’ annotated slideshow "Understanding SQL Injection: Safely Testing Your Production Site" by NTOBJECTives’ CSO, Mike Shema.
|
|
What is a Cross-Site Scripting Attack?
Cross-Site scripting attacks leverage poor input validation to create pop-up windows in applications that ask for user data, which can be sent to computers accessible by hackers. This is commonly (though not necessarily) combined with E-Mails instructing users to click on the link and to the site. When users arrive at the site, the URL is the actual URL of the site that the user patronizes. The hacker will generally embed a JavaScript function in the link which will often pop up a JavaScript window instructing the user to enter sensitive data (please enter your username and password) which is sent to a computer for later retrieval by the hacker.
Detecting susceptibility to this attack involves attempting to embed JavaScript in HTML pages and seeing if the application filters them out. Unfortunately, these vulnerabilities can cause false positives because some defenses against Cross-Site Scripting can allow the JavaScript to be embedded in the HTML page but block the pop-up window by commenting it out. Advanced Cross-Site Scripting detection methodologies, such as those used by NTOSpider, account for this to eliminate false positives.
|
|
What is a Cross Site Tracing Attack?
Cross-Site tracing is a hybrid of Cross-Site scripting in that it tests the server to see if it may be vulnerable as a vector for Cross-Site scripting attacks.
|
|
How Can Hackers Hijack User Sessions?
HTTP is inherently stateless. As such, in order to eliminate the requirement for users to log in to each page, web applications keep track of them using cookies. This creates an opportunity for hackers to impersonate users if they can guess these cookies.
For example, if the cookies can be observed to be
9476505132
9476505133
9476505134
the hacker could guess that the next cookie is 9476505135 and effectively impersonate the next user. The web application would give him access to the victim’s account and allow him to do anything that user would do (including order products).
Testing for this vulnerability is challenging. Most first generation web scanners attempted to make a limited number of guesses of cookies using a technique called cookie poisoning. Given the relatively large number of digits in session cookies, the likelihood that this technique would succeed would be very limited. NTOSpider emulates the behavior of a sophisticated hacker by performing a statistical analysis of a series of cookies. This is designed to see if a hacker would be able to predict cookies using statistical tools and then use programmed guessing tools to increase his likelihood of success.
|
|
|
|
