By default, IIS Express does not allow remote connections. In the next steps I explain how to enable remote connections in IIS Express. In this example I asume that the web application runs in port 1150.

  1. Allow URL access

Open cmd in “Administrator” mode and run the following command.

English version:

netsh http add urlacl url=http://*:1150/ user=everyone

Command prompt response:

URL reservation successfully added

Spanish version:

netsh http add urlacl url=http://*:1150/ user=todos

Command prompt response:

La reserva de dirección URL se agregó correctamente

2. Configure Windows Firewall

Go to start menu and type firewall, next click in “Windows Firewall with Advanced Security”.

windows firewall
Windows 10 Firewall

Click in the upper left option “Inbound Rules” and then click in the “New Rule…” option.

Windows Firewall
Windows Firewall

Windows Firewall add new Inbound Rule
Windows Firewall add new Inbound Rule
Windows Firewall add new Inbound rule
Windows Firewall add new Inbound rule

Windows Firewall add new Inbound rule
Windows Firewall add new Inbound rule

Windows Firewall add new Inbound rule
Windows Firewall add new Inbound rule

Windows Firewall add new Inbound rule
Windows Firewall add new Inbound rule
Windows Firewall add new Inbound rule
Windows Firewall add new Inbound rule

3. Edit applicationhost.config in Visual Studio Project

applicationhost Config Visual Studio
applicationhost Config file
applicationhost config
Configure applicationhost.config, add new binding

Urls:

Justin Clarke

The presence of SQL injection is commonly tested for remotly, you usually do not have the opportunity to look at the source code to review the structure of the query into which you are injecting.

Finding SQL Injection

SQL injection can be present in any front end application accepting data entry from a system or user, which is the used to access a database server.

In a Web environment, the browser is a client acting as a front end requesting data from the user and sending it to the remote server which will create SQL queries using the submitted data. Our main goal at this stage is to identify anomalies in the server response and determine whether they are generated by an SQL injection vulnerability. Possessing an analytic mindset is very important in understanding and progressing an attack. You will need to be very careful in understanding server responses to gain an idea of what might be happening at the server side.

Testing by inference is all about sending requests to the server and detecting anomalies in the response. You might be thinking that finding SQL injections vulnerabilities is about sending random values to the server, but you will see that once you understand the logic and fundamentals of the attack it becomes a straightforward and exciting process.

Testing by Inference

There is one simple rule for identifiying SQL injection vulnerabilities: Trigger anomalies by sending unexpected data. This rule implies that:

  • Identify all the data entry on the Web application.
  • know what kind of request might trigger anomalies.
  • Detect anomalies in the response from the server.

First you need to see how the browser sends request to the Web server, different applications behave in different ways, but the fundamentals should be the same, as they are all Web-based environments.

Once you identify all the data accepted by the application, you need to modifiy it and analyze the response from the server. Sometimes the response will include an SQL error directly from the database and will make your life very easy; however, other tines you will need to remain focused and detect subtle differences.

Identify Data Entry

Web environments are an example of client/server architecture. The browser sends a request to the server and waits for a response. The server recives the request, generates a response, and sends it back to the client. The understanding of both parties is given by the use of a protocolo, in this case, HTTP.

The first task is to identify all data entry accepted by the remote Web application. HTTP defines a number of actions that a client can send to the server; however, we will focus on the GET and POST methods.

GET Requests

GET is an HTTP method that requests to the server whatever information is indicated in the URL. For this requests, you can manipulate the parameters by simply changing them in the browser’s navigation toolbar, alternatively, you can also use a proxy tool.

GET Request
GET Request

POST Requests

Is an HTTP method used to send information to the Web server, the action the server performs is determined by the target URL. This is normally the method used when you fill in a form in the browser and click the Submit button. The values sent to the Web server have the same format exlained for the GEt request, but are now located at the bottom of the request. There are a couple of ways to modifiy data requests:

  • Browser modification extensions: Plugins that run in the browser and allow you to perfomr some additional functionality. Examples are Tamper Data and SQL Inject Me to Firefox.
  • Proxy servers: Piece of software that sits between the browser and the server, this software runs locally on your computer, the proxy intercepts the request to the server and permits you to modify it at will. Exmaples are Paros Proxy, WebScarab and Burp Suite.
POST Request
POST Request

Other Injectable Data

Most applications retrieve data from GET or POST requests, however, other parts of the HTTP request might trigger SQL injection vulnerabilities. Cookies are a good example, cookies are sent to the browser and they are automatically sent back to the server in each request, cookies are usually used for authentication , sesión control, and maintaining specific information about the user, such as preferences, you should consider cookies as begin susceptible to injection.

Other examples of vulnerable parts of the HTTP requests include the Host, Referer and User Agent headers. You can modify cookies and HTTP headers through proxy software.

Information Workflow

It is important to have a clear understanding of how the data entry influences an SQL query and what kind of response you could expect from the server. Web server and the database server are separate entities, the Web server just creates an SQL query, parses the results, and display the results to the user and the database server receives the query and returns the results to the Web server. This is the process of information worflow:

  1. The user sends a request to the Web Server.
  2. The Web server retrieves user data, creates an SQL statement which contains the entry from the user, and then sends the query to the database server.
  3. The database server executes the SQL query and returns the results to the Web server. Note that the database server does not know about the logic of the application; it Will just execute a query and return results.
  4. The Web server dynamically creates the response based on the database response.

Database Errors

The SQL injection happens at the database layer but the errors are displayed in the Web server response. It is very important to familiarize with the different database errors that may get from the Web server when testing for SQL injection vulnerabilities. Below is shown the Flow during an SQL injection error.

  1. The user sends a request in an attemp to identify an SQL injection vulnerability. In the case, the user sends a value with a single quote appended to it.
  2. The Web server retrieves user data and sends an SQL query to the database server.
  3. The database server receives the malformed SQL query and returns an error to the Web server.
  4. The Web server receives the error from the database and sends an HTML response to the user. In this case, it sent the error message, but it is entirely up to the application how it presents any errors in the contents of the HTML response.

Depending on how the application is coded, the response will be constructed and handled as a result of one of the folowing:

  • The SQL error is displayed on the page and is visible to the user from the Web browser.
  • The SQL error is hidden in the source of the Web page for debugging purposes.
  • Redirection to another page is used when an error is detected.
  • An HTTP error code “500 (Internal Server Error)” or HTTP redirection code 302 is returned.
  • The application handles the error properly and simply shows no results, perhaps displaying a generic error page.

When you are trying to identify an SQL injection vulnerabnility you need to determine the type of response the application is returning, the ability to identify the remote database is paramount to successfully progressing an attack and moving on from identification of the vulnerability to further exploitation.

Microsoft SQL Server Error
Microsoft SQL Server Error Example

Application Response

Applications react differently when they receive an error from the database, and sometimes identifying SQL injection vulnerabilities is not as easy as previously shown.

The process of finding SQL injection vulnerabilities involves identifying user data entry, tampering with the data sent to the application, and identifying changes in the results returned by the server. You have to keep in mind that tampering with the parameters can generate an error which could have nothing to do with SQL injection.

Generic Errors

When the application returned typical errors from the database, it is very easy to determine whether a parameter is vulnerable to SQL injection, in other scenarios, the application will return a generic error page regardles of the kind of failure.

This is a very common scenario, it happens when the application does not handle errors and no custom error page has been configured on the server, if you are testing a Web site and discover that the application is always responding with a default or custom error page, you will need to make sure the error is due to SQL injection.

HTTP Code Errors

HTTP has a number of codes which are returned to the Web browser to specify the result of a request or an action that the client needs to perform. The most common HTTP code returned is HTTP 200 OK, which means the request was successfully received. There are two errors codes that you need to familiarize yourself with to detect SQL injection vulnerabilities. The first one is the HTTP 500 code, this error is returned from a Web server when an error has been found when rendering the request Web resource. In many scenarios, SQL errors are returned to the user in the form of HTTP 500 error codes. The HTTP code returned will be transparent to you unless you are using a proxy to catch the Web server response. Another common behavior adopted by certain applications in the event of errors found is to redirect to the home page or to custom error page, this is a HTTP 302 redirection code, as mentioned before, this process is handled by the Web browser and it is transparent to the user unless you are using a Web proxy intercepting the Web server responses.

When you are manipulating the parameters sent to the server and you get an HTTP 500 or HTTP 302 response, that is a good sign, it means that somehow you interfered with the normal behavior of the application, the next step will be to craft a meaningful injection.

Different Response Sizes

Each application reacts differently to the input sent by the user. Sometimes it is easy to identify an anomaly in an application, yet other times it can be harder, you need to consider even the slightest and most subtle variation when trying to find SQL injection vulnerabilities. Other examples can include where minor Web interface items, such as product labels, are loaded based on parameters from the user, if an SQL error occurs, it is not uncommon for missing minor interface ítems to be easy to overlook. Although it may look like a minor mistake, you will see that there are ways to exploit this kind of issue using blind SQL injection techniques.

Blind Injection Detection

Web applications access databases for many purposes, one common goal is to acces information and present it to the user, in such cases, an attacker might be able to modify the SQL statement and display arbitrary information from the database.

However, there are other cases where it is not posible to display any information from the database, but that does not necessarily mean the code can not be vulnerable to SQL injection, this means the Discovery and exploitation of the vulnerability is going to be slighty different.

When you find this kind of situation it can be useful to verify by injection an always false condition, and checking that the returned value is different. After the always false test you can confirm that the application is vulnerable to SQL injection. This is called blind SQL injection, this is a type of SQL injection vulnerability where the attacker can manipulate an SQL statement and the application returns different values for true and false conditions, however, the attacker cannot retrieve the results of the query.

Blind SQL injection is a very common vulnerability, although sometimes it can be very subtle and might remain undetected to inexperienced eyes. The important thing to note is that we are in a situation where we can manipulate an SQL query but we can not get data from it, additionally, the Web server sends a different response depending on the condition thath we send.

Confirm SQL Injection

Once you identify an anomaly you will always need to confirm the SQL injection vulnerability by crafting a valid statement. Although there are tricks that will help you create the valid SQL statement, you need to be aware that each application is different and every SQL injection point is therefore unique, this means you will always need to follow and educated trial and error process.

Identification of a vulnerability is only part of your goal, ultimately, your goal will always be to exploit the vulneranilities present in the tested application, and to do that you need to craft a valid SQL request that is executed in the remote database without causing any errors.

Differentiating Numbers and String

You need to derive a basic understanding of SQL language to craft a valid injected SQL statement, the very first lesson to learn to performing SQL injection exploitation is that databases have different data types, these types are represented in different ways, and we can Split them into two groups:

  • Numbers: represented without single quotes.
  • All the rest: represented with single quotes

Inline SQL Injection

Inline injection happens when you inject some SQL code in such a way that all parts of the original query are executed. We first start the finding process by injecting input that might trigger anomalies. Once we identify the vulnerability, our goal is to craft a valid SQL statement which satisfies the conditions imposed by the application so that we can bypass the control in the Web application.

Inline
Inline SQL Injection

Signatures for Inline Injections of Strings

Testing StringExpected Results
Error triggering.
If successful, the database
will return an error.
1′ OR ‘1’=’1′Always true condition.
If successful, it returns
every row in the table.
VALUE’ OR ‘1’=’2′No condition.
If successful, it returns
the same result as the original
value.
1′ AND ‘1’=’2′Always false condition.
If successful,
it returns no rows from the
table.
1′ OR ‘AB’=’A’+’B’Microsoft SQL Server
concatenation.
If successful, it returns the
same informationas an
always true condition.
1′ or ‘AB’=’A”B’MySQL concatenation.
If successful, it returns the
same information as an
always true condition.
1′ OR ‘AB’=’A’||’BOracle concatenation.
If successful, it returns
the same information
as an always true
condition.

Signatures for Inline Injection of Numeric values

Testing String Expected Results
Error triggering.
If successful, the database
will return an error.
1+1 If successful, it returns
the same value as the result of the operation.
VALUE + 0 No condition.
If successful, it returns
the same value as the original
request.
1 OR 1=1 Always true condition.
If successful,
it returns every row in the
table.
VALUE OR 1=2 No condition.
If successful, it returns the
same result as the original value.
1 AND 1=2 Always false condition.
If successful,
it returns no rows from the
table.
1 OR ‘AB’=’A’+’B Microsoft SQL Server concatenation.
This injection is valid for Microsoft SQL Server. If successful, it returns
the same information
as an always true
condition.
1 OR ‘AB’=’A”B MySQL concatenation.
If successful, it returns
the same information
as an always true
condition.
1 OR ‘AB’=’A’||’B Oarcle concatenation.
If successful, it returns
the same information
as an always true
condition.

Terminating SQL Injection

Injection terminating an SQL statement is a technique whereby the attacker injects SQL code and successfully finalizes the statement by commenting the rest of the query.

Terminating
Terminating SQL Injection

Database Comment Syntax

Comments in SQL code are similar to comments in any other programming languages, they are used to insert information in the code and they are ignored by the interpreter.

Database Comments

Database Comment Observations
Microsoft SQL Server and Oracle – – (double dash)
/*    */
Used for single-line comments
Used for multiline comments
MySQL – – (double dash)
/*    */



#
/*    */
Used for single-line comments.
It requires the second dash to be
followed by a sapce or a control
character such as tabulation,
newline, etc
Used for single-line comments
Used for multiline comments

You many find scenarios where a doublé hyphen (- -) can not be used because it is filtered by the application or because commenting out the rest of the query generates errors, a defense technique consists of detecting and removing all spaces or truncating the value to the first space from the user entry, multiline comments can be used to bypass such restrictions, the new query will not have spaces in the user input, but it will be valid.

This technique requires more tan one vulnerable parameter and an understanding of the position of the parameters in the SQL statement. String concatenation is something you will always need when doing SQL injection testing. However, because it is done differently in SQL Server, MySQL and Oracle, it can thjerefore be used as a tool to identify the remote database.

Database Concatenation Operators

Database Concatenation
Microsoft SQL Server Used for single-line comments
Used for multiline comments
Microsoft SQL Server ‘A’ + ‘B’ = ‘AB’
MySQL ‘A’ ‘B’ = ‘AB’
Oracle ‘A’ || ‘B’ = ‘AB’

Signatures Using Database Comments

Testing String Expected Results
ADMIN’- – Bypass authentication mechanism by returning
the admin row set from the database
ADMIN’# MySQL – Bypass authentication mechanism by
returning the admin row set from the database
1- – Commenting out the rest of the query, it is
expected to remove any filter specified in the
WHERE clause after the injectable parameter
1 OR 1=1- – Return all rows injecting a numeric parameter
‘ OR ‘1’=’1′- – Return all rows injecting a string
-1 AND 1=2 – – Return no rows injecting a numeric parameter
‘ AND ‘1’=’2′ – – Return no rows injecting a string parameter
1/*comment*/ Comment injection. If successful, it makes no
difference to the original request. Helps identify SQL injection vulnerabilities.

Executing multiple Statements

Terminating an SQL statement provides you with greater control over the SQL code sent to the database server. In fact, this control goes beyond the statement created by the database. If you terminate the SQL statement you can create a brand new one with no restrictions on it.

The exploitation technique requires that you are able to terminate the first statement, so you can then concatenate arbitrary SQL code.

The idea is that depending on the application, you can execute the appropiate statement.

Most of the art of understanding and exploiting SQL injection vulnerabilities consist of the ability to mentally recreate what the developer coded in the Web application, and envision how the remote SQL code looks. If you can imagine what is beign executed at the server side, it will seem obvious to you where to terminate and start the single quotes.

There is no golden rule to determine whether certain input triggered an SQL injection vulnerability, as the possible scenarios are endless. It is very important that you remain focused and pay attention to detail when investigating potential SQL injections, it is recommended that you use a Web proxy, as your Web browser will hide details such as HTML source code, HTTP redirects, and so forth. Besides, when working at a lower level and watching the HTML source code you are more likely to discover other vulnerabilities apart from the SQL injection.