Web Application Security Testing

Go back to Tutorial

While web applications offer convenience to businesses and customers alike, their ubiquity makes them a popular attack target for cybercriminals. As a result, web application security testing, or scanning and testing web applications for risk, is essential.

Types of Web Application Security Testing

Dynamic Application Security Testing (DAST): A DAST approach involves looking for vulnerabilities in a web app that an attacker could try to exploit. This testing method works to find which vulnerabilities an attacker could target and how they could break into the system from the outside. Dynamic application security testing tools don’t require access to the application’s original source code, so testing with DAST can be done quickly and frequently.

Static Application Security Testing (SAST): SAST has a more inside-out approach, meaning that unlike DAST, it looks for vulnerabilities in the web application’s source code. Since it requires access to the application’s source code, SAST can offer a snapshot in real time of the web application’s security.

Application Penetration Testing: Application penetration testing involves the human element. A security professional will try to imitate how an attacker might break into a web app using both their personal security know-how and a variety of penetration testing tools to find exploitable flaws. You can also outsource web application penetration testing services to a third party if you do not have the resources in-house.

Web application hacking requires the attacker to uncover applications and understand their logic. The best way to start is by just clicking through the site and spending some time examining its look and feel. Various web application attacks are discussed.

Web-Based Password Cracking

An unlimited number of tools are available for the attacker to attempt to break into web-based applications. If the site does not employ a lockout policy, it is only a matter of time and bandwidth before the attacker can gain entry. Password cracking doesn’t have to involve sophisticated tools; many times password guessing works well. It can be a tedious process, although human intuition can beat automated tools. The basic types of password attacks are

• Dictionary attacks A text file full of dictionary words is loaded into a password program and then run against user accounts located by the application. If simple passwords have been used, this might be enough to crack the code.
• Hybrid attacks Similar to a dictionary attack, except that hybrid attacks add numbers or symbols to the dictionary words. Many people change their passwords by simply adding a number to the end of their current password. The pattern usually takes this form: First month’s password is Mike; second month’s password is Mike2; third month’s password is Mike3; and so on.
• Brute force attacks The most comprehensive form of attack and the most potentially time-consuming. Brute force attacks can take weeks, depending on the length and complexity of the password.

Cookies Attack

Cookies have a legitimate purpose. HTTP is a stateless protocol. For example, this presents real problems if you want to rent a car from rent-a-car.com and it asks for a location. To keep track of the location where you want to rent the car, the application must set a cookie. Information, such as location, time, and date of the rental, are packaged into a cookie and sent to your Web browser, which stores it for later use. Various tools allow to view cookies include CookieSpy, Karen’s Cookie Viewer, etc.

If the attacker can gain physical access to the victim’s computer, these tools can be used to steal cookies or to view hidden passwords. You might think that passwords wouldn’t be hidden in cookies, but that is not always the case. It’s another example of security by obscurity. Cookies used with forms authentication or other remember me functionality might hold passwords or usernames. Here’s an example:

Set-Cookie: UID= bWlrZTptaWtlc3Bhc3N3b3JkDQoNCg; expires=Fri, 06-Jan-2006

The UID value appears to contain random letters, but more than that is there. If you run it through a Base64 decoder, you end up with abc:abcpassword. It’s never good practice to store usernames and passwords in a cookie, especially in an insecure state.

URL Obfuscation

It is possible to hide addresses in URLs so that they can bypass filters or other application defenses that have been put in place to block specific IP addresses. Although web browsers recognize URLs that contain hexadecimal or binary character representations, some web filtering applications don’t. Here is an example of an encoded binary IP address: http://8812120797/. Does it look confusing? This decimal address can be converted into a human readable IP address. Convert the address into hexadecimal, divide it into four sets of two digits, and finally convert each set back into decimal to recover the IP address manually.

XSS

Cross-site scripting (XSS) enables attackers to inject client-side script into Web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same-origin policy. Cross-site scripting carried out on websites accounted for roughly 84% of all security vulnerabilities documented by Symantec as of 2007. Their effect may range from a petty nuisance to a significant security risk, depending on the sensitivity of the data handled by the vulnerable site and the nature of any security mitigation implemented by the site’s owner.

Security on the web is based on a variety of mechanisms, including an underlying concept of trust known as the same-origin policy. This essentially states that if content from one site (such as https://mybank.example1.com) is granted permission to access resources on the system, then any content from that site will share these permissions, while content from another site (https://othersite.example2.com) will have to be granted permissions separately.

Cross-site scripting uses known vulnerabilities in web-based applications, their servers, or plug-in systems on which they rely. Exploiting one of these, attackers fold malicious content into the content being delivered from the compromised site. When the resulting combined content arrives at the client-side web browser, it has all been delivered from the trusted source, and thus operates under the permissions granted to that system. By finding ways of injecting malicious scripts into web pages, an attacker can gain elevated access-privileges to sensitive page content, session cookies, and a variety of other information maintained by the browser on behalf of the user. Cross-site scripting attacks are therefore a special case of code injection.

The term “Cross-Site Scripting” was introduced by Microsoft in the year 2000. The expression “Cross-Site Scripting” originally referred to the act of loading the attacked, third-party web application from an unrelated attack site, in a manner that executes a fragment of JavaScript prepared by the attacker in the security context of the targeted domain (a reflected or non-persistent XSS vulnerability). The definition gradually expanded to encompass other modes of code injection, including persistent and non-JavaScript vectors (including ActiveX, Java, VBScript, Flash, or even HTML scripts), causing some confusion to newcomers to the field of information security.

XSS vulnerabilities have been reported and exploited since the 1990s. Prominent sites affected in the past include the social-networking sites Twitter, Facebook, MySpace, YouTube and Orkut. In recent years, cross-site scripting flaws surpassed buffer overflows to become the most common publicly reported security vulnerability, with some researchers in 2007 viewing as many as 68% of websites as likely open to XSS attacks.

Types

There is no single, standardized classification of cross-site scripting flaws, but most experts distinguish between at least two primary flavors of XSS: non-persistent and persistent. Some sources further divide these two groups into traditional (caused by server-side code flaws) and DOM-based (in client-side code).

Reflected (non-persistent) – The non-persistent (or reflected) cross-site scripting vulnerability is by far the most common type. These holes show up when the data provided by a web client, most commonly in HTTP query parameters or in HTML form submissions, is used immediately by server-side scripts to parse and display a page of results for and to that user, without properly sanitizing the request.

Because HTML documents have a flat, serial structure that mixes control statements, formatting, and the actual content, any non-validated user-supplied data included in the resulting page without proper HTML encoding, may lead to markup injection. A classic example of a potential vector is a site search engine: if one searches for a string, the search string will typically be redisplayed verbatim on the result page to indicate what was searched for. If this response does not properly escape or reject HTML control characters, a cross-site scripting flaw will ensue.

A reflected attack is typically delivered via email or a neutral web site. The bait is an innocent-looking URL, pointing to a trusted site but containing the XSS vector. If the trusted site is vulnerable to the vector, clicking the link can cause the victim’s browser to execute the injected script.

Persistent – The persistent (or stored) XSS vulnerability is a more devastating variant of a cross-site scripting flaw: it occurs when the data provided by the attacker is saved by the server, and then permanently displayed on “normal” pages returned to other users in the course of regular browsing, without proper HTML escaping. A classic example of this is with online message boards where users are allowed to post HTML formatted messages for other users to read.

For example, suppose there is a dating website where members scan the profiles of other members to see if they look interesting. For privacy reasons, this site hides everybody’s real name and email. These are kept secret on the server. The only time a member’s real name and email are in the browser is when the member is signed in, and they can’t see anyone else’s.

Suppose that Mallory, an attacker, joins the site and wants to figure out the real names of the people she sees on the site. To do so, she writes a script designed to run from other people’s browsers when they visit her profile. The script then sends a quick message to her own server, which collects this information.

To do this, for the question “Describe your Ideal First Date”, Mallory gives a short answer (to appear normal) but the text at the end of her answer is her script to steal names and emails. If the script is enclosed inside a <script> element, it won’t be shown on the screen. Then suppose that Bob, a member of the dating site, reaches Mallory’s profile, which has her answer to the First Date question. Her script is run automatically by the browser and steals a copy of Bob’s real name and email directly from his own machine.

Persistent XSS can be more significant than other types because an attacker’s malicious script is rendered automatically, without the need to individually target victims or lure them to a third-party website. Particularly in the case of social networking sites, the code would be further designed to self-propagate across accounts, creating a type of a client-side worm.

The methods of injection can vary a great deal; in some cases, the attacker may not even need to directly interact with the web functionality itself to exploit such a hole. Any data received by the web application (via email, system logs, IM etc.) that can be controlled by an attacker could become an injection vector.

Server-side versus DOM-based vulnerabilities – Historically XSS was first found in applications that performed all data processing on the server side. User input (including an XSS vector) would be sent to the server, and then sent back to the user as a web page. The need for an improved user experience resulted in popularity of applications that had a majority of the presentation logic (maybe written in JavaScript) working on the client-side that pulled data, on-demand, from the server using AJAX.

As the JavaScript code was also processing user input and rendering it in the web page content, a new sub-class of reflected XSS attacks started to appear that was called DOM-based cross-site scripting. In the DOM-based XSS, the malicious data does not touch the web server. Rather, it is being reflected by the JavaScript code, fully on the client side.

An example of DOM-based XSS is the bug found in 2011 in a number of JQuery plugins. Prevention of DOM-based XSS includes very similar measures to traditional XSS, just implemented in JavaScript code and sent in web pages — input validation and escaping. Some JavaScript frameworks have built-in countermeasures against this and other types of attack — for example Angular.js.

Countermeasure

Contextual output encoding/escaping of string input – The primary defense mechanism to stop XSS is contextual output encoding/escaping. There are several different escaping schemes that must be used depending on where the untrusted string needs to be placed within an HTML document including HTML entity encoding, JavaScript escaping, CSS escaping, and URL (or percent) encoding. Most web applications that do not need to accept rich data can use escaping to largely eliminate the risk of XSS in a fairly straightforward manner.

It is worth noting that although it is widely recommended, simply performing HTML entity encoding on the five XML significant characters is not always sufficient to prevent many forms of XSS. Encoding can be tricky, and the use of a security encoding library is highly recommended.

Safely validating untrusted HTML input – Many operators of particular web applications (e.g. forums and webmail) wish to allow users to utilize some of the features HTML provides, such as a limited subset of HTML markup. When accepting HTML input from users (say, <b>very</b> large), output encoding (such as &lt;b&gt;very&lt;/b&gt; large) will not suffice since the user input needs to be rendered as HTML by the browser (so it shows as “very large”, instead of “<b>very</b> large”). Stopping XSS when accepting HTML input from users is much more complex in this situation. Untrusted HTML input must be run through an HTML sanitization engine to ensure that it does not contain XSS.

Cookie Security – Besides content filtering, other imperfect methods for cross-site scripting mitigation are also commonly used. One example is the use of additional security controls when handling cookie-based user authentication. Many web applications rely on session cookies for authentication between individual HTTP requests, and because client-side scripts generally have access to these cookies, simple XSS exploits can steal these cookies. To mitigate this particular threat (though not the XSS problem in general), many web applications tie session cookies to the IP address of the user who originally logged in, and only permit that IP to use that cookie. This is effective in most situations (if an attacker is only after the cookie), but obviously breaks down in situations where an attacker is behind the same NATed IP address or web proxy as the victim, or the victim is changing his or her mobile IP.

Another mitigation present in Internet Explorer (since version 6), Firefox (since version 2.0.0.5), Safari (since version 4), Opera (since version 9.5) and Google Chrome, is an HttpOnly flag which allows a web server to set a cookie that is unavailable to client-side scripts. While beneficial, the feature does not fully prevent cookie theft nor can it prevent attacks within the browser.

Disabling Scripts – Finally, while Web 2.0 and Ajax designers favor the use of JavaScript, some web applications are written to (sometimes optionally) operate completely without the need for client-side scripts. This allows users, if they choose, to disable scripting in their browsers before using the application. In this way, even potentially malicious client-side scripts could be inserted unescaped on a page, and users would not be susceptible to XSS attacks.

Some browsers or browser plugins can be configured to disable client-side scripts on a per-domain basis. If scripting is allowed by default, then this approach is of limited value, since it blocks bad sites only after the user knows that they are bad, which is too late. Functionality that blocks all scripting and external inclusions by default and then allows the user to enable it on a per-domain basis is more effective. This has been possible for a long time in Internet Explorer (since version 4) by setting up its so called “Security Zones”, and in Opera (since version 9) using its “Site Specific Preferences”. A solution for Firefox and other Gecko-based browsers is the open source NoScript add-on which, in addition to the ability to enable scripts on a per-domain basis, provides some anti-XSS protection even when scripts are enabled.

The most significant problem with blocking all scripts on all websites by default is substantial reduction in functionality and responsiveness (client-side scripting can be much faster than server-side scripting because it does not need to connect to a remote server and the page or frame does not need to be reloaded). Another problem with script blocking is that many users do not understand it, and do not know how to properly secure their browsers. Yet another drawback is that many sites do not work without client-side scripting, forcing users to disable protection for that site and opening their systems to vulnerabilities. The Firefox NoScript extension enables users to allow scripts selectively from a given page while disallowing others on the same page. For example, scripts from example.com could be allowed, while scripts from advertisingagency.com that are attempting to run on the same page could be disallowed.

CSRF

Cross-Site Request Forgery (CSRF) is a type of attack that occurs when a malicious Web site, email, blog, instant message, or program causes a user’s Web browser to perform an unwanted action on a trusted site for which the user is currently authenticated. The impact of a successful cross-site request forgery attack is limited to the capabilities exposed by the vulnerable application. For example, this attack could result in a transfer of funds, changing a password, or purchasing an item in the user’s context. In effect, CSRF attacks are used by an attacker to make a target system perform a function (funds Transfer, form submission etc.) via the target’s browser without knowledge of the target user, at least until the unauthorized function has been committed.

Impacts of successful CSRF exploits vary greatly based on the role of the victim. When targeting a normal user, a successful CSRF attack can compromise end-user data and their associated functions. If the targeted end user is an administrator account, a CSRF attack can compromise the entire Web application. The sites that are more likely to be attacked are community Websites (social networking, email) or sites that have high dollar value accounts associated with them (banks, stock brokerages, bill pay services). This attack can happen even if the user is logged into a Web site using strong encryption (HTTPS). Utilizing social engineering, an attacker will embed malicious HTML or JavaScript code into an email or Website to request a specific ‘task url’. The task then executes with or without the user’s knowledge, either directly or by utilizing a Cross-site Scripting flaw (ex: Samy MySpace Worm).

CSRF vulnerabilities have been known and in some cases exploited since 2001. Because it is carried out from the user’s IP address, some website logs might not have evidence of CSRF. Exploits are under-reported, at least publicly, and as of 2007 there are few well-documented examples. The online banking webapplication of ING Direct was vulnerable for a CSRF attack that allowed illicit money transfers. Popular video website YouTube was also vulnerable to CSRF in 2008 and this allowed any attacker to perform nearly all actions of ANY user. Customers of a bank in Mexico were attacked in early 2008 with an image tag in email. The link in the image tag changed the DNS entry for the bank in their ADSL router to point to a malicious website impersonating the bank.

Example and characteristics

The attack works by including a link or script in a page that accesses a site to which the user is known (or is supposed) to have been authenticated. For example, one user, Alice, might be browsing a chat forum where another user, Mallory, has posted a message. Suppose that Mallory has crafted an HTML image element that references an action on Alice’s bank’s website (rather than an image file), e.g.,

Mallory: Hello Alice! Look here:

<img src=”http://bank.example.com/withdraw?account=Alice&amount=1000000&for=Mallory”>

If Alice’s bank keeps her authentication information in a cookie, and if the cookie hasn’t expired, then the attempt by Alice’s browser to load the image will submit the withdrawal form with her cookie, thus authorizing a transaction without Alice’s approval.

A cross-site request forgery is a confused deputy attack against a Web browser. The deputy in the bank example is Alice’s Web browser which is confused into misusing Alice’s authority at Mallory’s direction.

The following characteristics are common to CSRF:

• Involve sites that rely on a user’s identity
• Exploit the site’s trust in that identity
• Trick the user’s browser into sending HTTP requests to a target site
• Involve HTTP requests that have side effects

At risk are web applications that perform actions based on input from trusted and authenticated users without requiring the user to authorize the specific action. A user who is authenticated by a cookie saved in the user’s web browser could unknowingly send an HTTP request to a site that trusts the user and thereby causes an unwanted action.

CSRF attacks using image tags are often made from Internet forums, where users are allowed to post images but not JavaScript.

Forging login requests

An attacker may forge a request to log the victim into a target website using the attacker’s credentials; this is known as login CSRF. Login CSRF makes various novel attacks possible; for instance, an attacker can later log into the site with his legitimate credentials and view private information like activity history that has been saved in the account. This attack has been demonstrated against Google and Yahoo.

Other Approaches

Additionally, while typically described as a static type of attack, CSRF can also be dynamically constructed as part of a payload for a cross-site scripting attack, as demonstrated by the Samy worm, or constructed on the fly from session information leaked via offsite content and sent to a target as a malicious URL. CSRF tokens could also be sent to a client by an attacker due to session fixation or other vulnerabilities, or guessed via a brute-force attack, rendered on a malicious page that generates thousands of failed requests. The attack class of “Dynamic CSRF”, or using a per-client payload for session-specific forgery, was described in 2009 by Nathan Hamiel and Shawn Moyer at the BlackHat Briefings, though the taxonomy has yet to gain wider adoption.

A new vector for composing dynamic CSRF attacks was presented by Oren Ofer at a local OWASP chapter meeting on January 2012 – “AJAX Hammer – Dynamic CSRF”

Countermeasure

Since CSRF vulnerabilities are reportedly widespread, it is recommended to follow best practices to mitigate risk. Some mitigating include:

• Logoff immediately after using a Web application
• Do not allow your browser to save username/passwords, and do not allow sites to “remember” your login
• Do not use the same browser to access sensitive applications and to surf the Internet freely (tabbed browsing).
• The use of plugins such as No-Script makes POST based CSRF vulnerabilities difficult to exploit. This is because JavaScript is used to automatically submit the form when the exploit is loaded. Without JavaScript the attacker would have to trick the user into submitting the form manually.

SQL Injection

A SQL injection attack consists of insertion or “injection” of a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system. SQL injection attacks are a type of injection attack, in which SQL commands are injected into data-plane input in order to effect the execution of predefined SQL commands.

SQL injection is a code injection technique, used to attack data-driven applications, in which malicious SQL statements are inserted into an entry field for execution (e.g. to dump the database contents to the attacker). SQL injection must exploit a security vulnerability in an application’s software, for example, when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and unexpectedly executed. SQL injection is mostly known as an attack vector for websites but can be used to attack any type of SQL database.

SQL injection attacks allow attackers to spoof identity, tamper with existing data, cause repudiation issues such as voiding transactions or changing balances, allow the complete disclosure of all data on the system, destroy the data or make it otherwise unavailable, and become administrators of the database server.

SQL Injection is very common with PHP and ASP applications due to the prevalence of older functional interfaces. Due to the nature of programmatic interfaces available, J2EE and ASP.NET applications are less likely to have easily exploited SQL injections. The severity of SQL Injection attacks is limited by the attacker’s skill and imagination, and to a lesser extent, defense in depth countermeasures, such as low privilege connections to the database server and so on. In general, consider SQL Injection a high impact severity.

SQL injection errors occur when:

• Data enters a program from an untrusted source.
• The data used to dynamically construct a SQL query

The main consequences are:

• Confidentiality: Since SQL databases generally hold sensitive data, loss of confidentiality is a frequent problem with SQL Injection vulnerabilities.
• Authentication: If poor SQL commands are used to check user names and passwords, it may be possible to connect to a system as another user with no previous knowledge of the password.
• Authorization: If authorization information is held in a SQL database, it may be possible to change this information through the successful exploitation of a SQL Injection vulnerability.
• Integrity: Just as it may be possible to read sensitive information, it is also possible to make changes or even delete this information with a SQL Injection attack.

Types

SQL injection (SQLI) is considered one of the top 10 web application vulnerabilities of 2007 and 2010 by the Open Web Application Security Project. In 2013, SQLI was rated the number one attack on the OWASP top ten. There are five main sub-classes of SQL injection:

• Classic SQLI
• Blind or Inference SQL injection
• Database management system-specific SQLI
• Compounded SQLI
• SQL injection + insufficient authentication
• SQL injection + DDoS attacks
• SQL injection + DNS hijacking
• SQL injection + XSS

The Storm Worm is one representation of Compounded SQLI. This classification represents the state of SQLI, respecting its evolution until 2010—further refinement is underway.

Implementations

Incorrectly filtered escape characters

This form of SQL injection occurs when user input is not filtered for escape characters and is then passed into a SQL statement. This results in the potential manipulation of the statements performed on the database by the end-user of the application. The following line of code illustrates this vulnerability

statement = “SELECT * FROM users WHERE name ='” + userName + “‘;”

This SQL code is designed to pull up the records of the specified username from its table of users. However, if the “userName” variable is crafted in a specific way by a malicious user, the SQL statement may do more than the code author intended. For example, setting the “userName” variable as:

‘ OR ‘1’=’1

or using comments to even block the rest of the query (there are three types of SQL comments). All three lines have a space at the end:

‘ OR ‘1’=’1′ —

‘ OR ‘1’=’1′ ({

‘ OR ‘1’=’1′ /*

renders one of the following SQL statements by the parent language:

SELECT * FROM users WHERE name = ” OR ‘1’=’1′;

SELECT * FROM users WHERE name = ” OR ‘1’=’1′ — ‘;

If this code were to be used in an authentication procedure then this example could be used to force the selection of a valid username because the evaluation of ‘1’=’1′ is always true.

The following value of “userName” in the statement below would cause the deletion of the “users” table as well as the selection of all data from the “userinfo” table (in essence revealing the information of every user), using an API that allows multiple statements:

a’;DROP TABLE users; SELECT * FROM userinfo WHERE ‘t’ = ‘t

This input renders the final SQL statement as follows and specified:

SELECT * FROM users WHERE name = ‘a’;DROP TABLE users; SELECT * FROM userinfo WHERE ‘t’ = ‘t’;

While most SQL server implementations allow multiple statements to be executed with one call in this way, some SQL APIs such as PHP’s mysql_query() function do not allow this for security reasons. This prevents attackers from injecting entirely separate queries, but doesn’t stop them from modifying queries.

Incorrect type handling

This form of SQL injection occurs when a user-supplied field is not strongly typed or is not checked for type constraints. This could take place when a numeric field is to be used in a SQL statement, but the programmer makes no checks to validate that the user supplied input is numeric. For example:

statement := “SELECT * FROM userinfo WHERE id =” + a_variable + “;”

It is clear from this statement that the author intended a_variable to be a number correlating to the “id” field. However, if it is in fact a string then the end-user may manipulate the statement as they choose, thereby bypassing the need for escape characters. For example, setting a_variable to

1;DROP TABLE users

will drop (delete) the “users” table from the database, since the SQL becomes:

SELECT * FROM userinfo WHERE id=1;DROP TABLE users;

Blind SQL injection

Blind SQL Injection is used when a web application is vulnerable to an SQL injection but the results of the injection are not visible to the attacker. The page with the vulnerability may not be one that displays data but will display differently depending on the results of a logical statement injected into the legitimate SQL statement called for that page. This type of attack can become time-intensive because a new statement must be crafted for each bit recovered. There are several tools that can automate these attacks once the location of the vulnerability and the target information has been established.

Conditional responses – One type of blind SQL injection forces the database to evaluate a logical statement on an ordinary application screen. As an example, a book review website uses a query string to determine which book review to display. So the URL http://books.example.com/showReview.php?ID=5 would cause the server to run the query

SELECT * FROM bookreviews WHERE ID = ‘Value(ID)’;

from which it would populate the review page with data from the review with ID 5, stored in the table bookreviews. The query happens completely on the server; the user does not know the names of the database, table, or fields, nor does the user know the query string. The user only sees that the above URL returns a book review. A hacker can load the URLs http://books.example.com/showReview.php?ID=5 OR 1=1 and http://books.example.com/showReview.php?ID=5 AND 1=2, which may result in queries

SELECT * FROM bookreviews WHERE ID = ‘5’ OR ‘1’=’1′;

SELECT * FROM bookreviews WHERE ID = ‘5’ AND ‘1’=’2′;

If the original review loads with the “1=1” URL and a blank or error page is returned from the “1=2” URL, and the returned page has not been created to alert the user the input is invalid, or in other words, has been caught by an input test script, the site is likely vulnerable to a SQL injection attack as the query will likely have passed through successfully in both cases. The hacker may proceed with this query string designed to reveal the version number of MySQL running on the server: http://books.example.com/showReview.php?ID=5 AND substring(@@version,1,1)=4, which would show the book review on a server running MySQL 4 and a blank or error page otherwise. The hacker can continue to use code within query strings to glean more information from the server until another avenue of attack is discovered or his or her goals are achieved.

Second Order SQL Injection

Second order SQL injection occurs when submitted values contain malicious commands that are stored rather than executed immediately. In some cases, the application may correctly encode a SQL statement and store it as valid SQL. Then, another part of that application without controls to protect against SQL injection might execute that stored SQL statement. This attack requires more knowledge of how submitted values are later used. Automated web application security scanners would not easily detect this type of SQL injection and may need to be manually instructed where to check for evidence that it is being attempted.

Go back to Tutorial