Have you ever
welcomed with a pop-up, when you visit a web-page or when you hover at some
specific text? Imagine, if these pop-ups become a vehicle, which thus delivers
malicious payload into your system or even capture up some sensitive
information. Today, in this article, we’ll take a tour to Cross-Site Scripting and would
learn how an attacker executes malicious JavaScript codes over at the input
parameters and generates such pop-ups, in order to deface the web-application or
to hijack the active user’s session.
Table of
Content
·
What is JavaScript?
·
JavaScript Event Handlers
·
Introduction to Cross-Site Scripting (XSS)
·
Impact of Cross-Site Scripting
·
Types of XSS
o Reflected
XSS
o Stored
XSS
o DOM-based
XSS
·
Cross-Site Scripting Exploitation
o Credential
Capturing
o Cookie
Capture
o Fuzzing
§ Burpsuite
§ XSSer
·
Mitigation Steps
What is
JavaScript?
A dynamic web-application
stands up over three pillars i.e. HTML –
which determines up the complete structure, CSS – describes its overall look and feel, and the JavaScript – which simply adds powerful
interactions to the application such as alert-boxes, rollover effects, dropdown
menus and the other things.
So, JavaScript is the programming language of the web and is considered
to be one of the most popular scripting languages as about 93% of the total websites runs with
Javascript, due to some of its major features i.e.
·
It is easy to learn.
·
It helps to build
interactive web-applications.
·
Is the only
programming language that can be interpreted
by the browser i.e. the browser runs it, instead of displaying it.
·
It is flexible, as it
simply gets blends up with
the HTML codes.
JavaScript
Event Handlers
When a JavaScript code is embedded over into HTML page,
then this JavaScript “react” on some
specific events like:
When the page loads up, it is an event. When the user
clicks a button, that clicks is too an event. Other examples such as - pressing
any key, closing a window, resizing a window, etc. Therefore such events are
thus managed by some event-handlers.
Onload
Javascript uses the onload function to load an object over on a web page. For example, I want
to generate an alert for user those who visit my website; I will give the
following JavaScript code.
So whenever the body tag loads
up, an alert will pop up with the following text “Welcome to Hacking Articles”.
Here the loading of the body tag is an
“event” or a happening and “onload”
is an event handler which decides what action should happen on that event.
Onmouseover
With the Onmouseover event
handler, when a user moves his cursor over a specific text, the embedded
javascript code will get executed. For example, let us understand the following
code:
Now when the user moves his cursor over the surprise the displayed text on the
page, an alert box will pop up with 50% discount.
Similarly, there are many JavaScript
event handlers, which defines what event should occur for such type of actions
like a scroll down, or when an image fails to load etc.
|
onclick:
|
Use this to invoke
JavaScript upon clicking (a link, or form boxes)
|
|
onload:
|
Use this to invoke
JavaScript after the page or an image has finished loading
|
|
onmouseover
|
Use this to invoke
JavaScript if the mouse passes by some link
|
|
onmouseout
|
Use this to invoke
JavaScript if the mouse goes pass some link
|
|
onunload
|
Use this to invoke JavaScript
right after someone leaves this page.
|
Introduction
to Cross-Site Scripting (XSS)
Cross-Site Scripting often abbreviated as “XSS”
is a client-side code injection attack where
malicious scripts are injected into trusted websites. XSS occurs over in those web-applications where
the input-parameters are not properly sanitized or
validated which thus allows an attacker to send
malicious Javascript codes over at a different end-user. The end user’s browser
has no way to know that the script should not be trusted, and will thus execute
up the script.
In this attack, the users are not directly targeted through
a payload, although the attacker shoots the XSS vulnerability by inserting a malicious script into a web
page that appears to be a genuine part of the website. So, when any user
visits that website, the XSS suffering web-page will deliver the malicious
JavaScript code directly over to his browser without his knowledge.
Confused with what’s happening?
Let’s make it more clear with the following example.
Consider a web application that allows its users to set-up
their “brief description” over at
their profile, which is thus visible
to everyone. Now the attacker notice that the description field is not
properly validating the inputs, so he injects his malicious script into that field.
Now, whenever the visitor views the attacker’s profile, the
code get’s automatically executed by the browser and therefore it captures up
the authenticated cookies and over on the other side, the attacker would have
the victim’s active session.
Impact of
Cross-Site Scripting
From the
last decay, Cross-Site Scripting has managed its position in the OWASP Top10 list, as it is one of the most crucial and the most widely-used
attack method on the internet.
Therefore,
over with this vulnerability, the attacker could:
·
Capture
and access the user’s authenticated session cookies.
·
Uploads
a phishing page to lure the users into unintentional actions.
·
Redirects
the visitors to some other malicious sections.
·
Expose
the user’s sensitive data.
·
Manipulates
the structure of the web-application or even defaces it.
However,
XSS has been reported with a “CVSS
Score” of “6.1” as on “Medium” Severity under
·
CWE-79: Improper Neutralization of Input
During Web Page Generation ('Cross-site Scripting')
·
CWE-80: Improper Neutralization of
Script-Related HTML Tags in a Web Page (Basic XSS)
Types of XSS
Up till now, you might be having a clear vision with the
concept of JavaScript and XSS and its major consequences. So,
let’s continue down on the same road and break this XSS into three main types
as –
§ Stored XSS
§ Reflected XSS
§ DOM-based XSS
Stored XSS
“Stored XSS”
often termed as “Persistent XSS” or “Type I”, as over through this
vulnerability the injected malicious script gets permanently stored inside the
web application's database server and the
server further drops it out back, when the user visits the respective website.
However,
this happens in a way as -. when the
client clicks or hovers a particular infected section, the injected JavaScript
will get executed by the browser as it was already into the application’s
database. Therefore this attack does not require any phishing technique to
target its users.
The most common example of Stored XSS is the “comment option” in the blogs,
which allow any user to enter his feedback as in the form of comments for the
administrator or other users.
Let’s carry this up by
considering an example:
A web-application is asking its
user to submit their feedback, as there on its webpage it is having two input
fields- one for the name and other for the comment.
Now,
whenever the user hits up the submits
button, his entry gets stored into the database. To make it more clear, I’ve
called up the database table on the screen as:
Here, the developer trusts his
users and hadn’t placed any validations
over at the fields. So this loophole was encountered by the attacker and
therefore he took advantage of it, as – instead of submitting the feedback, he commented his malicious script.
From the below screenshot, you
can see that the attacker got success, as the web-application reflects with an
alert pop-up.
Now, back on the database, you
can see that the table has been updated with Name as “Ignite” and the
Feeback field is empty, this clears
up that the attacker’s script had been injected successfully.
So let’s switch to another
browser as a different user and would again try to submit genuine feedback.
Now when we hit the Submit button, our browser will execute
the injected script and reflects it on the screen.
Reflected XSS
The Reflected XSS also
termed as “Non-Persistence XSS” or “Type
II”, occurs when the web application responds immediately on user’s
input without validating what the user entered, this can lead an attacker to
inject browser executable code inside the single HTML response. It is termed “non-persistent” as the
malicious script does not get stored
inside the web-server’s database, thus
the attacker needs to send the malicious link through phishing in order to trap
the user.
Reflected XSS is the most
common and thus can be easily found over at the “website’s search fields” where
the attacker includes some arbitrary Javascript codes in the search textbox
and, if the website is vulnerable, the web-page return up the event as was
described into the script.
Reflect XSS is a major with two types:
§
Reflected XSS GET
§
Reflected XSS POST
To be more
clear with the concept of Reflected XSS, let’s check out the following
scenario.
Here, we’ve created a webpage, which thus permits up the
user to search for a particular training
course.
So, when the user searches for “Bug Bounty”, a message
prompts back over on the screen as “You have
searched for Bug Bounty.”
Thus, this
instant response and the “search” parameter
in the URL shows up that, the page might be vulnerable to XSS and even the data
has been requested over through the GET method.
So, let’s
now try to generate some pop-ups by injecting Javascript codes over into this “search” parameter as
get.php?search=
Great!! From the below screenshot, you can see
that we got the alert reflected as “Welcome to Hacking Articles!!”
Wonder why
this all happened, let’s check out the following code snippet.
With the ease to reflect the message on the screen, the
developer didn’t set up any input validation over at the ignite function and he simply “echo”
the “Search Message” with ignite($search)
through the “$_GET” variable.
DOM-Based XSS
The DOM-Based Cross-Site Scripting is the
vulnerability which appears up in a Document Object Model rather than in the
HTML pages.
But what is this Document
Object Model?
A DOM or a Document Object Model describes up the different
web-page segments like - title,
headings, tables, forms, etc. and even the hierarchical structure of an HTML
page. Thus, this API increases the skill of the
developers to produce and change HTML and XML documents as
programming objects.
When an HTML document is loaded into a web browser, it becomes a “Document Object”.
However,
this document object is the root node of the HTML documents and the “owner” of all other nodes.
With the object model, JavaScript gets all the power it
needs to create dynamic HTML:
§
JavaScript can change all the HTML elements in
the page
§
JavaScript can change all the HTML attributes in
the page
§
JavaScript can change all the CSS styles in the
page
§
JavaScript can remove existing HTML elements and
attributes
§
JavaScript can add new HTML elements and
attributes
§
JavaScript can react to all existing HTML events
in the page
§
JavaScript can create new HTML events on the
page
Therefore
DOM manipulation is itself is not a problem, but when JavaScript handles
data insecurely in the DOM, thus it enables up various attacks.
DOM-based XSS vulnerabilities
usually arise when JavaScript takes data from an attacker-controllable source, such as the URL, and passes it to a sink (a dangerous JavaScript function or DOM object as eval()) that supports dynamic code execution.
This is quite different from reflected and stored XSS because over in this attack, the developer
cannot find the malicious script in HTML source code as well as in HTML
response, it can be observed at execution time.
The
DOM-Based XSS exploits these problems on the user’s local machines in this way:
– The
attacker creates a well-built malicious website
– The
ingenious user opens that sites
– The user
has a vulnerable page on his machine
– The
attacker’s website sends commands to the vulnerable HTML page
– The
vulnerable local page executes that commands with the user’s privileges on that
machine.
– The
attacker easily gains control of the victim computer.
Didn’t
understand well, let’s check out a DOM-based XSS exploitation.
The
following application was thereby vulnerable to DOM-based
XSS attack. The web application further permits its users to opt a language
with the following displayed options and thus executes the input through its
URL.
From the
above screenshot, you can see that we do not have any specific section where we
could include our malicious code. Therefore, in order to deface this
web-application, we’ll now manipulate up the “URL” as it is the most common source for the DOM XSS.
http://localhost/DVWA/vulnerabilities/xss_d/?default=English#
After manipulating up the URL, hit
enter. Now, we’ll again choose up the language
and as we fire up the select button, the browser executes up the code in the
URL and pops out the DOM XSS alert.
The major difference between DOM-based XSS and Reflected or Stored XSS is
that it cannot be stopped by server-side filters because anything written after
the “#” (hash) will never forward to the server.
Cross-Site
Scripting Exploitation
I’m sure you might be wondering that “Okay, we got the pop-up, but now what? What we could do with this?
I’ll click the OK button and this pop-up will go.”
But this
pop-up speaks about a thousand words. Let’s take a U-turn and get back to the place, where we got our first
pop-up; Yes over at the Stored Section.
Credential Capturing
So, as we
are now aware of the fact that whenever a user submits up his feedback, it will
get stored directly into the server’s database. And if the attacker manipulates
the feedback with an “alert message”,
thus even the alert will get stored into it, and it pops up every time,
whenever some other user visits the application’s web-page.
But what,
if rather than a pop-up the user is welcomed with a login page?
Let’s try
to solve this by injecting a malicious payload that will create up a fake user login form on the web page,
which will thus forward the captured request over to the attacker’s IP.
So, let’s includes the
following script over at the feedback field in the web-application
Please login to continue!!
| Username: | |
| Password: |
Over at
some other browser, think when a user tries to submit the feedback.
As soon as
she hit the submit button, the browser executes up the script and he got
welcomed with login form as “Please
login to continue!!”.
Over on
the other side, let’s enable our listener as with
nc –lvp
4444
Now, as
when she enters up her credentials, the scripts
will boot up again and the entered credentials will travel to the attacker’s
listener.
Cool!! From the below
screenshot, you can see that we’ve successfully captured up the victim's
credentials.
Cookie Capturing
There are times when an
attacker needs authenticated cookies of a logged-in user either to
access his account or for some other malicious purpose.
So let’s see how this XSS
vulnerability empowers the attackers to capture the session cookies and how the
attacker abuses them in order to get into the user’s account.
I’ve opened the vulnerable
web-application “DVWA” over in my
browser and logged-in inside with admin:
password. Further, from the left-hand panel I’ve opted the vulnerability as
XSS (Stored), over for this time
let’s keep the security to low.
Let’s enter our malicious
payload over into the “Message” section, but before that, we need to increase
the length of text-area as it is not sufficient to inject our payload. Therefore,
open up the inspect element tab by hitting “Ctrl + I” to view it’s
given message length for the text area and then further change the message maxlength field from 50 -150.
Over in the following
screenshot, you can see that I have injected the script which will thus capture
up the cookie and will send the response to our listener when any user visits
this page.
Now, on the other side, let’s
set up our Netcat listener as with
nc –lvp 4444
Logout and login again as a new user or in some other browser, now if the user
visits the XSS (Stored) page, his
session cookies will thus get transferred to our listener
Great!! From the below
screenshot you can see that, we’ve successfully captured up the authenticated
cookies.
But what we could do with them?
Let’s try to get into his account.
I’ve opened up DVWA again but this time, we won’t log in, rather I’ll get with
the captured cookies. I’ve used the cookie
editor plugin in order to manipulate
up the session.
From the below screenshot, you
can see that, I’ve changed the PHPSESID
with the one I captured and had manipulated the security from impossible to low and even decreased the security _level from 1 to 0 and have
thus saved up these changes. Let’s even manipulate the URL by removing login.php
Great!! Now simply reloads the
page, from the screenshot you can see are that we are into the application.
Exploitation
with Burpsuite
Stored XSS is hard to find, but
over on the other hand, Reflected XSS is very common and thus can be exploited
with some simple clicks.
But wait, up till now we were only exploiting the
web-applications that were not validated by the developers, so what about the
restricted ones?
Web applications with the input
fields are somewhere or the other vulnerable to XSS, but we can’t exploit them
with the bare hands, as they were secured up with some validations. Therefore in
order to exploit such validated applications, we need some fuzzing tools and thus for the fuzzing thing, we
can count on BurpSuite.
I’ve opened the target IP in my
browser and login inside BWAPP as a bee: bug,
further I’ve set the “Choose Your Bug”
option to “XSS
–Reflected (Post)” and had fired up the hack button, and for this section, I’ve set the
security to “medium”
From the below screenshot, you
can see that when we tried to execute our payload as , we hadn’t got our
desired result.
So, let’s capture its ongoing HTTP Request in our burpsuite and will further share the captured
request over to the “Intruder”.
Over into the intruder, switch to the Position tab and we’ll configure
the position to our input-value parameter as “firstname” with the Add $ button.
Time to include our payloads
file. Click on the load button in
order to add the dictionary. You can even
opt the burpsuite’s predefined XSS dictionary with a simple click on the “Add from list” button and selecting
the Fuzzing-XSS.
As soon as we’re over with the
configuration, we’ll fire up the “Start
Attack” button.
From the below image, you can
see that our attack has been started and there is a fluctuation in the length
section. In order to get the result in the descending order with respect to the
length, I’ve double-clicked the length field.
We’re almost done, let’s double
click on any payload in order to check what it offers.
But wait!! We can’t see the XSS
result over in the response tab as the browser can only render this malicious
code, so in order to check its response let’s simply do a right-click and choose the option as “Show Response in browser”
Copy the offered URL and paste
it in the browser. Great!! From the below image, you can see that we’ve
successfully bypassed the application as we got the alert.
XSSer
Cross-Site “Scripter” or an “XSSer” is an
automatic framework, which detects XSS vulnerabilities
over in the web-applications and even provides up several options to exploit
them.
XSSer has more than 1300 pre-installed XSS fuzzing
vectors which thus empowers the attacker to bypass certainly filtered
web-applications and the WAF’s(Web –Application Firewalls).
So, let’s see how this fuzzer could help us in exploiting
our bWAPP’s web-application. But in order to go ahead, we need to clone XSSer
into our kali machine, so let’s do it with
git clone https://github.com/epsylon/xsser.git
Now, boot back into your bWAPP, and set the “Choose your Bug” option to “XSS –Reflected (Get)” and hit the hack button and for this
time we’ll set the security level to “medium”.
XSSer offers us two
platforms – the GUI and the Command-Line. Therefore, for this
section, we’ll focus on the Command Line method.
As the XSS vulnerability
is dependable on the input parameters, thus this XSSer works
on “URL”; and even to get the precise result we need the cookies too. In order
to grab both the things, I’ve made a dry run by setting up the firstname
as “test” and the lastname as “test1”.
Now, let’s capture the browser’s request into our
burpsuite, by simply enabling the proxy and the intercept options, further as
we hit the Go button, we got the output as
Fire up you Kali Terminal with XSSer and run the following
command with the --url and the --cookie flags.
Here I’ve even used an --auto flag which will thus check the URL with all the preloaded
vectors. Over at the applied URL, we need to manipulate an input-parameter value
to “XSS”, as in our case I’ve changed the “test” with “XSS”.
python3 xsser
--url "http://192.168.0.9/bWAPP/xss_get.php?firstname=XSS&lastname=test1&form=submit"
--cookie "PHPSESSID=q6t1k21lah0ois25m0b4egps85; security_level=1"
--auto
Oops!! From the
below screenshot, you can see that this URL is vulnerable with 1287 vectors.
The best thing
about this fuzzer is that it provides up the browser’s URL. Select and execute
anyone and there you go.
Note:
It is not necessary that with every
payload, you’ll get the alert pop-up, as every different payload is defined up
with some specific event, whether it is setting up an iframe, capturing up some
cookies, or redirection to some other website or something else.
Therefore, from
the below screenshot, it is clear that we’ve successfully defaced this
web-application.
Mitigation Steps
·
Developers
should implement a whitelist of
allowable inputs, and if not possible then there should be some input validations and the data entered by the user must be filtered as
much as possible.
·
Output encoding
is the most reliable solution to combat XSS i.e. it takes up the script code
and thus converts it into the plain text.
·
A WAF or a Web Application Firewall should be implemented as it
somewhere protects the application from XSS
attacks.
·
Use of HTTPOnly
Flags on the Cookies.
·
The developers can use Content Security Policy (CSP) to reduce the severity of any XSS vulnerabilities
0 comments:
Post a Comment