Same-origin policy (SOP)

In this section we explain what the same-origin policy (SOP) is and how it is implemented.

What is the same-origin policy?

The same-origin policy is a web browser security mechanism that aims to prevent websites from
attacking each other.
The same-origin policy restricts scripts on one origin from accessing data from another origin. An
origin consists of a URI scheme, domain and port number. For example, consider the following
URL:
http://normal-website.com/example/example.html

This uses the scheme http, the domain normal-website.com, and the port number 80. The
following table shows how the same-origin policy will be applied if content at the above URL tries
to access other origins:
URL accessed Access permitted?
http://normal-website.com/example/ Yes: same scheme, domain, and port
http://normal-website.com/example2/ Yes: same scheme, domain, and port
https://normal-website.com/example/ No: different scheme and port
http://en.normal-website.com/example/ No: different domain
http://www.normal-website.com/example/ No: different domain

http://normal-website.com:8080/example/ No: different port*

*Internet Explorer will allow this access because IE does not take account of the port number
when applying the same-origin policy.

Why is the same-origin policy necessary?

When a browser sends an HTTP request from one origin to another, any cookies, including
authentication session cookies, relevant to the other domain are also sent as part of the request.
This means that the response will be generated within the user's session, and include any
relevant data that is specific to the user. Without the same-origin policy, if you visited a malicious
website, it would be able to read your emails from GMail, private messages from Facebook, etc.

How is the same-origin policy implemented?

The same-origin policy generally controls the access that JavaScript code has to content that is
loaded cross-domain. Cross-origin loading of page resources is generally permitted. For
example, the SOP allows embedding of images via the <img> tag, media via the <video> tag,
and JavaScript via the <script> tag. However, while these external resources can be loaded by
the page, any JavaScript on the page won't be able to read the contents of these resources.
There are various exceptions to the same-origin policy:

 Some objects are writable but not readable cross-domain, such as the location object
or the location.href property from iframes or new windows.
 Some objects are readable but not writable cross-domain, such as the length property of
the window object (which stores the number of frames being used on the page) and
the closed property.
  The replace function can generally be called cross-domain on the location object.
 You can call certain functions cross-domain. For example, you can call the
functions close, blur and focus on a new window. The postMessage function can
also be called on iframes and new windows in order to send messages from one domain
to another.

Due to legacy requirements, the same-origin policy is more relaxed when dealing with cookies,
so they are often accessible from all subdomains of a site even though each subdomain is
technically a different origin. You can partially mitigate this risk using the HttpOnly cookie flag.
It's possible to relax same-origin policy using document.domain. This special property allows
you to relax SOP for a specific domain, but only if it's part of your FQDN (fully qualified domain
name). For example, you might have a domain marketing.example.com and you would like
to read the contents of that domain on example.com. To do so, both domains need to
set document.domain to example.com. Then SOP will allow access between the two domains
despite their different origins. In the past it was possible to set document.domain to a TLD such
as com, which allowed access between any domains on the same TLD, but now modern
browsers prevent this.

Cross-site scripting
In this section, we'll explain what cross-site scripting is, describe the different varieties of cross-
site scripting vulnerabilities, and spell out how to find and prevent cross-site scripting.

What is cross-site scripting (XSS)?

Cross-site scripting (also known as XSS) is a web security vulnerability that allows an attacker to
compromise the interactions that users have with a vulnerable application. It allows an attacker to
circumvent the same origin policy, which is designed to segregate different websites from each
other. Cross-site scripting vulnerabilities normally allow an attacker to masquerade as a victim
user, to carry out any actions that the user is able to perform, and to access any of the user's
data. If the victim user has privileged access within the application, then the attacker might be
able to gain full control over all of the application's functionality and data.

How does XSS work?

Cross-site scripting works by manipulating a vulnerable web site so that it returns malicious
JavaScript to users. When the malicious code executes inside a victim's browser, the attacker
can fully compromise their interaction with the application.
XSS proof of concept
You can confirm most kinds of XSS vulnerability by injecting a payload that causes your own
browser to execute some arbitrary JavaScript. It's long been common practice to use
the alert() function for this purpose because it's short, harmless, and pretty hard to miss when
it's successfully called. In fact, you solve the majority of our XSS labs by invoking alert() in a
simulated victim's browser.
Unfortunately, there's a slight hitch if you use Chrome. From version 92 onward (July 20th, 2021),
cross-origin iframes are prevented from calling alert(). As these are used to construct some of
the more advanced XSS attacks, you'll sometimes need to use an alternative PoC payload. In
this scenario, we recommend the print() function. If you're interested in learning more about
this change and why we like print(), check out our blog post on the subject.
As the simulated victim in our labs uses Chrome, we've amended the affected labs so that they
can also be solved using print(). We've indicated this in the instructions wherever relevant.

What are the types of XSS attacks?

There are three main types of XSS attacks. These are:

 Reflected XSS, where the malicious script comes from the current HTTP request.
 Stored XSS, where the malicious script comes from the website's database.
 DOM-based XSS, where the vulnerability exists in client-side code rather than server-side
code.

Reflected cross-site scripting

Reflected XSS is the simplest variety of cross-site scripting. It arises when an application
receives data in an HTTP request and includes that data within the immediate response in an
unsafe way.
Here is a simple example of a reflected XSS vulnerability:
https://insecure-website.com/status?message=All+is+well.

<p>Status: All is well.</p>

The application doesn't perform any other processing of the data, so an attacker can easily
construct an attack like this:
https://insecure-website.com/status?message=<script>/
*+Bad+stuff+here...+*/</script>

<p>Status: <script>/* Bad stuff here... */</script></p>

If the user visits the URL constructed by the attacker, then the attacker's script executes in the
user's browser, in the context of that user's session with the application. At that point, the script
can carry out any action, and retrieve any data, to which the user has access.

Stored cross-site scripting

Stored XSS (also known as persistent or second-order XSS) arises when an application receives
data from an untrusted source and includes that data within its later HTTP responses in an
unsafe way.
The data in question might be submitted to the application via HTTP requests; for example,
comments on a blog post, user nicknames in a chat room, or contact details on a customer order.
In other cases, the data might arrive from other untrusted sources; for example, a webmail
application displaying messages received over SMTP, a marketing application displaying social
media posts, or a network monitoring application displaying packet data from network traffic.
Here is a simple example of a stored XSS vulnerability. A message board application lets users
submit messages, which are displayed to other users:
<p>Hello, this is my message!</p>

The application doesn't perform any other processing of the data, so an attacker can easily send
a message that attacks other users:
<p><script>/* Bad stuff here... */</script></p>

DOM-based cross-site scripting

DOM-based XSS (also known as DOM XSS) arises when an application contains some client-
side JavaScript that processes data from an untrusted source in an unsafe way, usually by
writing the data back to the DOM.
In the following example, an application uses some JavaScript to read the value from an input
field and write that value to an element within the HTML:
var search = document.getElementById('search').value;

var results = document.getElementById('results');

results.innerHTML = 'You searched for: ' + search;

If the attacker can control the value of the input field, they can easily construct a malicious value
that causes their own script to execute:
You searched for: <img src=1 onerror='/* Bad stuff here... */'>

In a typical case, the input field would be populated from part of the HTTP request, such as a
URL query string parameter, allowing the attacker to deliver an attack using a malicious URL, in
the same manner as reflected XSS.
What can XSS be used for?
An attacker who exploits a cross-site scripting vulnerability is typically able to:

 Impersonate or masquerade as the victim user.

 Carry out any action that the user is able to perform.
 Read any data that the user is able to access.
 Capture the user's login credentials.
 Perform virtual defacement of the web site.
 Inject trojan functionality into the web site.

Impact of XSS vulnerabilities

The actual impact of an XSS attack generally depends on the nature of the application, its
functionality and data, and the status of the compromised user. For example:

 In a brochureware application, where all users are anonymous and all information is
public, the impact will often be minimal.
 In an application holding sensitive data, such as banking transactions, emails, or
healthcare records, the impact will usually be serious.
 If the compromised user has elevated privileges within the application, then the impact will
generally be critical, allowing the attacker to take full control of the vulnerable application
and compromise all users and their data.

SQL injection
In this section, we explain:

 What SQL injection (SQLi) is.

 How to find and exploit different types of SQLi vulnerabilities.
 How to prevent SQLi.

What is SQL injection (SQLi)?

SQL injection (SQLi) is a web security vulnerability that allows an attacker to interfere with the
queries that an application makes to its database. This can allow an attacker to view data that
they are not normally able to retrieve. This might include data that belongs to other users, or any
other data that the application can access. In many cases, an attacker can modify or delete this
data, causing persistent changes to the application's content or behavior.
In some situations, an attacker can escalate a SQL injection attack to compromise the underlying
server or other back-end infrastructure. It can also enable them to perform denial-of-service
attacks.

What is the impact of a successful SQL injection attack?

A successful SQL injection attack can result in unauthorized access to sensitive data, such as:

 Passwords.
 Credit card details.
 Personal user information.

SQL injection attacks have been used in many high-profile data breaches over the years. These
have caused reputational damage and regulatory fines. In some cases, an attacker can obtain a
persistent backdoor into an organization's systems, leading to a long-term compromise that can
go unnoticed for an extended period.

How to detect SQL injection vulnerabilities

You can detect SQL injection manually using a systematic set of tests against every entry point in
the application. To do this, you would typically submit:

 The single quote character ' and look for errors or other anomalies.
 Some SQL-specific syntax that evaluates to the base (original) value of the entry point,
and to a different value, and look for systematic differences in the application responses.
 Boolean conditions such as OR 1=1 and OR 1=2, and look for differences in the
application's responses.
 Payloads designed to trigger time delays when executed within a SQL query, and look for
differences in the time taken to respond.
 OAST payloads designed to trigger an out-of-band network interaction when executed
within a SQL query, and monitor any resulting interactions.

Alternatively, you can find the majority of SQL injection vulnerabilities quickly and reliably using
Burp Scanner.

SQL injection in different parts of the query

Most SQL injection vulnerabilities occur within the WHERE clause of a SELECT query. Most
experienced testers are familiar with this type of SQL injection.
However, SQL injection vulnerabilities can occur at any location within the query, and within
different query types. Some other common locations where SQL injection arises are:

 In UPDATE statements, within the updated values or the WHERE clause.

 In INSERT statements, within the inserted values.
 In SELECT statements, within the table or column name.
 In SELECT statements, within the ORDER BY clause.

SQL injection examples

There are lots of SQL injection vulnerabilities, attacks, and techniques, that occur in different
situations. Some common SQL injection examples include:

 Retrieving hidden data, where you can modify a SQL query to return additional results.
 Subverting application logic, where you can change a query to interfere with the
application's logic.
 UNION attacks, where you can retrieve data from different database tables.
 Blind SQL injection, where the results of a query you control are not returned in the
application's responses.

Retrieving hidden data

Imagine a shopping application that displays products in different categories. When the user
clicks on the Gifts category, their browser requests the URL:
https://insecure-website.com/products?category=Gifts

This causes the application to make a SQL query to retrieve details of the relevant products from
the database:
SELECT * FROM products WHERE category = 'Gifts' AND released = 1

This SQL query asks the database to return:

 all details (*)

 from the products table
 where the category is Gifts
 and released is 1.
The restriction released = 1 is being used to hide products that are not released. We could
assume for unreleased products, released = 0.

The application doesn't implement any defenses against SQL injection attacks. This means an
attacker can construct the following attack, for example:
https://insecure-website.com/products?category=Gifts'--

This results in the SQL query:

SELECT * FROM products WHERE category = 'Gifts'--' AND released = 1

Crucially, note that -- is a comment indicator in SQL. This means that the rest of the query is
interpreted as a comment, effectively removing it. In this example, this means the query no longer
includes AND released = 1. As a result, all products are displayed, including those that are
not yet released.

You can use a similar attack to cause the application to display all the products in any category,
including categories that they don't know about:
https://insecure-website.com/products?category=Gifts'+OR+1=1--

This results in the SQL query:

SELECT * FROM products WHERE category = 'Gifts' OR 1=1--' AND released
= 1
The modified query returns all items where either the category is Gifts, or 1 is equal to 1.
As 1=1 is always true, the query returns all items.

Subverting application logic

Imagine an application that lets users log in with a username and password. If a user submits the
username wiener and the password bluecheese, the application checks the credentials by
performing the following SQL query:
SELECT * FROM users WHERE username = 'wiener' AND password =

'bluecheese'

If the query returns the details of a user, then the login is successful. Otherwise, it is rejected.

In this case, an attacker can log in as any user without the need for a password. They can do this
using the SQL comment sequence -- to remove the password check from the WHERE clause of
the query. For example, submitting the username administrator'-- and a blank password
results in the following query:
SELECT * FROM users WHERE username = 'administrator'--' AND password =

''

This query returns the user whose username is administrator and successfully logs the
attacker in as that user.

Retrieving data from other database tables

In cases where the application responds with the results of a SQL query, an attacker can use a
SQL injection vulnerability to retrieve data from other tables within the database. You can use
the UNION keyword to execute an additional SELECT query and append the results to the original
query.

For example, if an application executes the following query containing the user input Gifts:

SELECT name, description FROM products WHERE category = 'Gifts'

An attacker can submit the input:

' UNION SELECT username, password FROM users--

This causes the application to return all usernames and passwords along with the names and
descriptions of products.

Blind SQL injection vulnerabilities

Many instances of SQL injection are blind vulnerabilities. This means that the application does
not return the results of the SQL query or the details of any database errors within its responses.
Blind vulnerabilities can still be exploited to access unauthorized data, but the techniques
involved are generally more complicated and difficult to perform.

The following techniques can be used to exploit blind SQL injection vulnerabilities, depending on
the nature of the vulnerability and the database involved:

 You can change the logic of the query to trigger a detectable difference in the application's
response depending on the truth of a single condition. This might involve injecting a new
condition into some Boolean logic, or conditionally triggering an error such as a divide-by-
zero.
 You can conditionally trigger a time delay in the processing of the query. This enables you
to infer the truth of the condition based on the time that the application takes to respond.
  You can trigger an out-of-band network interaction, using OAST techniques. This
technique is extremely powerful and works in situations where the other techniques do not.
Often, you can directly exfiltrate data via the out-of-band channel. For example, you can
place the data into a DNS lookup for a domain that you control.

Second-order SQL injection

First-order SQL injection occurs when the application processes user input from an HTTP
request and incorporates the input into a SQL query in an unsafe way.

Second-order SQL injection occurs when the application takes user input from an HTTP request
and stores it for future use. This is usually done by placing the input into a database, but no
vulnerability occurs at the point where the data is stored. Later, when handling a different HTTP
request, the application retrieves the stored data and incorporates it into a SQL query in an
unsafe way. For this reason, second-order SQL injection is also known as stored SQL injection.

Second-order SQL injection often occurs in situations where developers are aware of SQL
injection vulnerabilities, and so safely handle the initial placement of the input into the database.
When the data is later processed, it is deemed to be safe, since it was previously placed into the
database safely. At this point, the data is handled in an unsafe way, because the developer
wrongly deems it to be trusted.

Examining the database

Some core features of the SQL language are implemented in the same way across popular
database platforms, and so many ways of detecting and exploiting SQL injection vulnerabilities
work identically on different types of database.

However, there are also many differences between common databases. These mean that some
techniques for detecting and exploiting SQL injection work differently on different platforms. For
example:

 Syntax for string concatenation.

 Comments.
 Batched (or stacked) queries.
 Platform-specific APIs.
 Error messages.
SQL injection in different contexts

In the previous labs, you used the query string to inject your malicious SQL payload. However,
you can perform SQL injection attacks using any controllable input that is processed as a SQL
query by the application. For example, some websites take input in JSON or XML format and use
this to query the database.

These different formats may provide different ways for you to obfuscate attacks that are
otherwise blocked due to WAFs and other defense mechanisms. Weak implementations often
look for common SQL injection keywords within the request, so you may be able to bypass these
filters by encoding or escaping characters in the prohibited keywords. For example, the following
XML-based SQL injection uses an XML escape sequence to encode the S character in SELECT:

<stockCheck>

<productId>123</productId>

<storeId>999 &#x53;ELECT * FROM

information_schema.tables</storeId>

</stockCheck>

This will be decoded server-side before being passed to the SQL interpreter.

OS command injection
In this section, we explain what OS command injection is, and describe how vulnerabilities can
be detected and exploited. We also show you some useful commands and techniques for
different operating systems, and describe how to prevent OS command injection.
OS command injection is also known as shell injection. It allows an attacker to execute operating
system (OS) commands on the server that is running an application, and typically fully
compromise the application and its data. Often, an attacker can leverage an OS command
injection vulnerability to compromise other parts of the hosting infrastructure, and exploit trust
relationships to pivot the attack to other systems within the organization.
Injecting OS commands
In this example, a shopping application lets the user view whether an item is in stock in a
particular store. This information is accessed via a URL:
https://insecure-website.com/stockStatus?productID=381&storeID=29

To provide the stock information, the application must query various legacy systems. For
historical reasons, the functionality is implemented by calling out to a shell command with the
product and store IDs as arguments:
stockreport.pl 381 29

This command outputs the stock status for the specified item, which is returned to the user.
The application implements no defenses against OS command injection, so an attacker can
submit the following input to execute an arbitrary command:
& echo aiwefwlguh &

If this input is submitted in the productID parameter, the command executed by the application
is:
stockreport.pl & echo aiwefwlguh & 29

The echo command causes the supplied string to be echoed in the output. This is a useful way
to test for some types of OS command injection. The & character is a shell command separator.
In this example, it causes three separate commands to execute, one after another. The output
returned to the user is:
Error - productID was not provided

aiwefwlguh
29: command not found

The three lines of output demonstrate that:

 The original stockreport.pl command was executed without its expected arguments,
and so returned an error message.
 The injected echo command was executed, and the supplied string was echoed in the
output.
 The original argument 29 was executed as a command, which caused an error.

Useful commands
After you identify an OS command injection vulnerability, it's useful to execute some initial
commands to obtain information about the system. Below is a summary of some commands that
are useful on Linux and Windows platforms:
Purpose of command Linux Windows

Name of current user whoami whoami

Operating system uname -a ver

Network configuration ifconfig ipconfig /all

Network connections netstat -an netstat -an

Running processes ps -ef tasklist

Blind OS command injection vulnerabilities

Many instances of OS command injection are blind vulnerabilities. This means that the
application does not return the output from the command within its HTTP response. Blind
vulnerabilities can still be exploited, but different techniques are required.
As an example, imagine a website that lets users submit feedback about the site. The user enters
their email address and feedback message. The server-side application then generates an email
to a site administrator containing the feedback. To do this, it calls out to the mail program with
the submitted details:
mail -s "This site is great" -aFrom:[email protected]
[email protected]

The output from the mail command (if any) is not returned in the application's responses, so
using the echo payload won't work. In this situation, you can use a variety of other techniques to
detect and exploit a vulnerability.

Detecting blind OS command injection using time delays

You can use an injected command to trigger a time delay, enabling you to confirm that the
command was executed based on the time that the application takes to respond.
The ping command is a good way to do this, because lets you specify the number of ICMP
packets to send. This enables you to control the time taken for the command to run:
& ping -c 10 127.0.0.1 &

How to prevent OS command injection attacks

The most effective way to prevent OS command injection vulnerabilities is to never call out to OS
commands from application-layer code. In almost all cases, there are different ways to implement
the required functionality using safer platform APIs.
If you have to call out to OS commands with user-supplied input, then you must perform strong
input validation. Some examples of effective validation include:

 Validating against a whitelist of permitted values.

 Validating that the input is a number.
 Validating that the input contains only alphanumeric characters, no other syntax or
whitespace.

Never attempt to sanitize input by escaping shell metacharacters. In practice, this is just too
error-prone and vulnerable to being bypassed by a skilled attacker.

HTTP Host header attacks

In this section, we'll discuss how misconfigurations and flawed business logic can expose
websites to a variety of attacks via the HTTP Host header. We'll outline the high-level
methodology for identifying websites that are vulnerable to HTTP Host header attacks and
demonstrate how you can exploit this for the following kinds of attacks:

 Password reset poisoning

 Web cache poisoning
 Exploiting classic server-side vulnerabilities
 Bypassing authentication
 Virtual host brute-forcing
 Routing-based SSRF
 Connection state attacks
What is the HTTP Host header?
The HTTP Host header is a mandatory request header as of HTTP/1.1. It specifies the domain
name that the client wants to access. For example, when a user
visits https://portswigger.net/web-security, their browser will compose a request
containing a Host header as follows:
GET /web-security HTTP/1.1

Host: portswigger.net

In some cases, such as when the request has been forwarded by an intermediary system, the
Host value may be altered before it reaches the intended back-end component. We will discuss
this scenario in more detail below.

What is the purpose of the HTTP Host header?

The purpose of the HTTP Host header is to help identify which back-end component the client
wants to communicate with. If requests didn't contain Host headers, or if the Host header was
malformed in some way, this could lead to issues when routing incoming requests to the intended
application.
Historically, this ambiguity didn't exist because each IP address would only host content for a
single domain. Nowadays, largely due to the ever-growing trend for cloud-based solutions and
outsourcing much of the related architecture, it is common for multiple websites and applications
to be accessible at the same IP address. This approach has also increased in popularity partly as
a result of IPv4 address exhaustion.
When multiple applications are accessible via the same IP address, this is most commonly a
result of one of the following scenarios.
Virtual hosting
One possible scenario is when a single web server hosts multiple websites or applications. This
could be multiple websites with a single owner, but it is also possible for websites with different
owners to be hosted on a single, shared platform. This is less common than it used to be, but still
occurs with some cloud-based SaaS solutions.
In either case, although each of these distinct websites will have a different domain name, they
all share a common IP address with the server. Websites hosted in this way on a single server
are known as "virtual hosts".
To a normal user accessing the website, a virtual host is often indistinguishable from a website
being hosted on its own dedicated server.

Routing traffic via an intermediary

Another common scenario is when websites are hosted on distinct back-end servers, but all
traffic between the client and servers is routed through an intermediary system. This could be a
simple load balancer or a reverse proxy server of some kind. This setup is especially prevalent in
cases where clients access the website via a content delivery network (CDN).
In this case, even though the websites are hosted on separate back-end servers, all of their
domain names resolve to a single IP address of the intermediary component. This presents some
of the same challenges as virtual hosting because the reverse proxy or load balancer needs to
know the appropriate back-end to which it should route each request.

How does the HTTP Host header solve this problem?

In both of these scenarios, the Host header is relied on to specify the intended recipient. A
common analogy is the process of sending a letter to somebody who lives in an apartment
building. The entire building has the same street address, but behind this street address there
are many different apartments that each need to receive the correct mail somehow. One solution
to this problem is simply to include the apartment number or the recipient's name in the address.
In the case of HTTP messages, the Host header serves a similar purpose.
When a browser sends the request, the target URL will resolve to the IP address of a particular
server. When this server receives the request, it refers to the Host header to determine the
intended back-end and forwards the request accordingly.

What is an HTTP Host header attack?

HTTP Host header attacks exploit vulnerable websites that handle the value of the Host header
in an unsafe way. If the server implicitly trusts the Host header, and fails to validate or escape it
properly, an attacker may be able to use this input to inject harmful payloads that manipulate
server-side behavior. Attacks that involve injecting a payload directly into the Host header are
often known as "Host header injection" attacks.
Off-the-shelf web applications typically don't know what domain they are deployed on unless it is
manually specified in a configuration file during setup. When they need to know the current
domain, for example, to generate an absolute URL included in an email, they may resort to
retrieving the domain from the Host header:
<a href="https://_SERVER['HOST']/support">Contact support</a>

The header value may also be used in a variety of interactions between different systems of the
website's infrastructure.
As the Host header is in fact user controllable, this practice can lead to a number of issues. If the
input is not properly escaped or validated, the Host header is a potential vector for exploiting a
range of other vulnerabilities, most notably:

 Web cache poisoning

 Business logic flaws in specific functionality
 Routing-based SSRF
 Classic server-side vulnerabilities, such as SQL injection

How do HTTP Host header vulnerabilities arise?

HTTP Host header vulnerabilities typically arise due to the flawed assumption that the header is
not user controllable. This creates implicit trust in the Host header and results in inadequate
validation or escaping of its value, even though an attacker can easily modify this using tools like
Burp Proxy.
Even if the Host header itself is handled more securely, depending on the configuration of the
servers that deal with incoming requests, the Host can potentially be overridden by injecting other
headers. Sometimes website owners are unaware that these headers are supported by default
and, as a result, they may not be treated with the same level of scrutiny.
In fact, many of these vulnerabilities arise not because of insecure coding but because of
insecure configuration of one or more components in the related infrastructure. These
configuration issues can occur because websites integrate third-party technologies into their
architecture without necessarily understanding the configuration options and their security
implications.