You always change your account’s password when you desire for, but what, if your password is changed whenever the attacker wants, and that if when you are not aware with it?  Today in this article, we’ll learn the basic concepts about CSRF attacks or how an attacker forces the user to execute some unwanted actions that they(user) never intended to.

Table of Content

• What are cookies and Session ID?
• What is an SOP?
• Introduction to CSRF attacks
• Impact of CSRF vulnerability.
• Manipulating user-account details
• CSRF over Change Password
• CSRF over Bank Transfer.
• Mitigation steps.

What are cookies and Session ID?

Before jumping into CSRF attacks and how such attacks are executed, we need to understand some important terminologies that somewhere or the other empowers the applications to be secure.

Cookies

Cookies are basically some small text files with a maximum of size 4KB that are stored over on the client’s browser in the form of name-value pair. Cookies are majorly used to track or monitor the client’s activity on the web application and even stores some sensitive data such as username, session ID’s, password preferences, etc, which thus can be sent back to the server for an authentication request.

Session ID’s

Similar to the cookies, sessions are some small files too, but they are generated and stored at the server’s end. Each session is associated with a session ID. Whenever a user logs in, thus a session is created with a session ID, thereby this session ID blends up into the cookie and stored at the client’s browser and thus passed back to the web server whenever the browser makes an HTTP request.

So whenever the client logs out or the browser is closed, these sessions are terminated. And with every new login, a new session with a session ID is generated.

Let’s make this more clear with the following case scenario –

When a new user creates up his account over the web-application, the following procedure happens

Now, when the user visits some other section of the same application, the session ID stored over in the user’s browser is sent to the server for validation.

What is an SOP?

SOP is an abbreviation for Same-Origin Policy which is one of the most important concepts in the web application security model. Under this policy, a web browser permits scripts contained in a first web page to access data in a second web page, but this occurs only when both the web pages are running over on the same port, protocol and origin.

For example –

Say the web-page  “https://www.ignitetechnologies.com/ceh/module1.pdf” can directly access the content at “https://www.ignitetechnologies.com/network/RDP/module7.docx”.

But it can not access the data from “https://www.ignitetechnologies.com:8080/bug/xss.pdf”. As the port has been changed between the two now.

Introduction to CSRF Attacks

CSRF is an abbreviation for Cross-Site Request Forgery, also known as Client-Site Request Forgery and even somewhere you’ll hear it as a one-click attack or session riding or Hostile Linking or even XSRF, basically over in this attack, the attacker forces a user to execute unwanted actions on a web application in which they’re currently authenticated.

To be more clear, let’s check out the following case scenario –

Here the user “Aarti” receives a mail from the attacker, while she was doing a bank transfer to Mr Raj Chandel’s account. She left the transaction incomplete and checks her mail over in the new tab.

There she got the generic URL, with a content stating that “You’ve received an amount as a reward”. Now, as she opens the URL in the next tab, she got the Grab button there. The transaction page was over in the other tab and this malicious page is on the next one. As soon as, she hits the submit button, the query executes up and the amount has been deducted from Aarti’s account without her knowledge, or concern.

Impact of CSRF vulnerability

CSRF is an attack that forces the victim or the user to execute a malicious request on the server on behalf of the attacker. Although CSRF attacks are not meant to steal any sensitive data as the attacker wouldn’t receive any response as whatever the victim does but this vulnerability is defined as it causes a state change on the server, such as –

• Changing the victim’s email address or password.
• Purchasing anything.
• Making a bank transaction.
• Explicitly logging out the user from his account.

Therefore, this vulnerability was listed as one of the OWASP Top10 in 2013. And thereby now has been reported with a CVSS Score of “6.8” with “Medium” severity under

• CWE-352: Cross-Site Request Forgery (CSRF)

CSRF Exploitation

Let’s Start!!

For this section, I’ve used bWAPP the vulnerable web-application and created an account with the user Raj : ignite to login inside the webserver.

Manipulating user-account details

Over in the above image, you can see that for creating a new user, the user “Raj” has set his secret value as “who are you”, now if he wants to change this secret value, he can change it from here.

But what, if his secret value gets changed with the attacker’s desired value without his knowledge?

Let’s check it out how!!

Let’s open the target IP in our browser, and we will set the “Choose Your Bug” option to Cross-Site-Request-Forgery (Change Secret).

Here, we’ll be redirected to the web-page which is suffering from the CSRF vulnerability, where you can see that we’re having the option to change the secret value.

Now, let’s “hit the change button” and capture the passing HTTP Request.

Form the below image, you can see we have successfully captured the request. Time to create a Fake HTML form, to accomplish this, do a right-click anywhere on the screen and select the engagement tools further hit the Generate CSRF PoC option.

This CSRF PoC generator will automatically generate an HTML form page. Now, click on Copy HTML in order to copy the entire HTML code, further past the copied data into a text file.

Great!! Let’s manipulate the secret value=“” parameter with “hackingarticles” and then we’ll save this file as “csrf.html”. Moreover, we need to set the user name “Raj” as for whom the secret value will get changed.

Now, we’ll use the social engineering technique to share this csrf.html file to the targeted user.

As soon as the victim Raj opens up this csrf.html, there he will get a submit button, as he clicks over it, his secret will get changed without his (victim) knowledge.

From the below image, you can see that he got the message as “The secret has been changed !”, over with this similar way a successful CSRF attack can even change up the email addresses, usernames and the other personal information of the user.

CSRF over Change Password form

“Change Your Password” feature is almost offered by every web-application, but many times the applications fail to provide the security measurements over such sections. So let’s try to exploit this “Change Password” feature over with the CSRF vulnerability, which is one of the most impactful CRSF attacks where the user’s password will get changed without his knowledge.

Back into the “Choose Your Bug” option select the Cross-Site-Request-Forgery (Change Password) and hit hack button.

Now, let’s again “fire up the Change button” and capture the passing HTTP Request over in the Burpsuite.

Form the below image, you can see that we have successfully captured the request. Let’s follow up the same procedure to generate a “forged HTML form”.

Now, click on Copy HTML in order to copy the entire HTML code, further past the copied data into a new text file.

Once we’ve pasted the HTML code, let’s now add the new password value (attacker’s password) and the confirm password value, and then save the text document as csrf.html

Now, we’ll again use the social engineering technique to share this csrf.html file to the targeted user.

As soon as the victim opens up this csrf.html, there he will get a confirm button, as he clicks over it, the password will get changed without his knowledge.

From the below image, you can see that the CSRF attack changes the old password set by user “Raj”.

Cool !! Now when he(victim) tries to login with the old password, he’ll get the error message.

CSRF over Bank Transfer

“You might have heard some scenarios where the money is deducted from the victim’s bank account without his/her knowledge, or a fraud has been taken place where the victim receives an email and as soon as he opens it up his back account gets empty.”

Wonder how CSRF is related to all this? Let’s check out the following attack scenario.

Login inside bWAPP again, then choose the next vulnerability Cross-Site Request Forgery (Transfer Amount) and click on the hack button.

Over in the below screenshot, you can see that the user “Raj” is having only 1000 EUR in his account.

Let’s try to transfer some amount from this, as the account number is already there in the filed.

The procedure for the CSRF attack is similar as above, use burp suite to capture the sent request of the browser and then share the request over on the Engagement tools section.

Again it will create an HTML form automatically for intercepted data. Simply click on Copy HTML and paste it into a text file.

Great!! Time to manipulate the value“” field, add amount “200” (attacker’s desired amount) which to be transferred, save the text document as csrf.html and then share it with the targeted user.

As soon as the victim open’s this file up, and hit the submit button, the amount (entered by the attacker) will be transferred, without his (victim) knowledge.

From the given screenshot, you can see that the amount is left 800 EUR in user’s account which means 200 EUR has been deducted from his account.

Thereby over with such basic techniques, the attacker can make major changes over on the victim’s account.

CSRF Drawbacks

1. The CRSF attack is having a major drawback, as these attacks are only successful when the attacker knows which parameter and what values are blended in the HTML form.
2. And even these attacks need some good social engineering technique as sometimes the HTML forms require earlier used values as “Current Password” to change up the new password one.

Mitigation Steps

• The developers should implement the use of “Anti-CSRF tokens”
• Use of Same-Site cookies attributes for session cookies, which can only be sent if the request is being made from the origin related to the cookie (not cross-domain).
• Do not use GET requests for state-changing operations.
• Identifying Source Origin (via Origin/Referer header)
• One-time Token should be implemented for the defence of User Interaction based CSRF.
• Secure against XSS attacks, as any XSS can be used to defeat all CSRF mitigation techniques!

Source :

https://owasp.org/www-community/attacks/csrf

https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html

Author: Chiragh Arora is a passionate Researcher and Technical Writer at Hacking Articles. He is a hacking enthusiast. Contact here

“Are you one of them, who thinks that Cross-Site Scripting is just for some errors or pop-ups on the screen?” Yes?? Then today in this article, you’ll see how an XSS suffering web-page is not only responsible for the defacement of the web-application but also, it could disrupt a visitor’s privacy by sharing the login credentials or his authenticated cookies to an attacker without his/her concern.

I recommend, to revisit our previous article for better understanding, before going deeper with the attack scenarios implemented in this section.

Table of Content

• Introduction to Cross-Site Scripting
• XSS Post Exploitation
  • XSS through File Upload
  • Reverse Shell with XSS
  • System Exploitation over XSS
  • CSRF with XSS
  • NTLM Hash Capture with XSS
  • Session Hijacking with Burp Collaborator
  • Credential Capturing with Burp Collaborator
  • XSS to SQL Injection

Introduction to Cross-Site Scripting

Cross-Site Scripting is a client-side code injection attack where malicious scripts are injected into trusted websites.

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.

 “XSS” thus has been classified into three main categories:

• Stored XSS
• Reflected XSS
• DOM-based XSS

I guess you’re now having a clear vision about -“What is XSS” and “How it occurs”. So let’s try to exploit the vulnerable labs over The Portswigger Academy and bWAPP in order to capture up the authenticated cookie of the users and the server’s remote shell.

But before making our hands wet with the exploits, let’s understand what is Blind XSS?

Blind XSS

Many times the attacker does not know where the payload will end up and if, or when, it will get executed and even there are times when the injected payload is executed in a different environment i.e. either by the administrator or by someone else.

So, in order to exploit such vulnerabilities – He blindly deploys up the series of malicious payloads over onto the web-applications, and thus the application stores them into the database. Thereby, he thus waits, until the user pulls the payload out from the database and renders it up into his/her browser.

Let’s Start !!

XSS through File Upload

Web-applications somewhere or the other allow its users to upload a file, whether its an image, a resume, a song, or anything specific. And with every upload, the name reflects back on the screen as it was called from the HTML code.

As the name appears back, therefore we can now execute any JavaScript code by simply manipulating up the file name with any XSS payload.

Boot back into the bWAPP’s application by selecting the “Choose your bug” option to “Unrestricted File Upload” and for this time we’ll keep the security to “High”.

Let’s now upload our renamed file over into the web-application, by browsing it from the directory.

Great !! Form the above image, you can see that our file name is over on the screen. So as we hit the Upload button, the browser will execute up the embedded JavaScript code and we’ll get the response.

Reverse Shell with XSS

Generating a pop-up or redirecting a user to some different application with the XSS vulnerability is somewhere or the other seems to be harmless. But what, if the attacker is able to capture up a reverse shell, will It still be harmless? Let’s see how we could do this.

Fire up your Kali terminal and then create up a reverse-php payload by calling it from webshells  directory as

Now, in order to capture the remote shell, let’s manipulate the $ip parameter with the Kali machine’s IP

Back into the vulnerable application, let’s opt the “Unrestricted File Upload” and then further we’ll include the ReverseXSS.php file.

Don’t forget to copy the Uploaded URL, i.e. right-click on the Upload button and choose the Copy Link Location.

Great!! We’re almost done, time to inject our XSS payload. Now, with the “Choose you bug” option, opt the XSS – Stored (Blog).

Over into the comment section, type your JavaScript payload with the “File-Upload URL”.

But wait!! Before firing the submit button, let’s start our Netcat listener

nc –lvp 1234

Cool !! From the below image, you can see that, we are into our targeted web-server.

I’m sure you might be wondering – Why I made a round trip in order to capture up the Reverse Shell when I’m having the “File Upload” vulnerability open?

Okay!! So, think for a situation, if you upload the file directly and you’ve successfully grabbed up the Reverse shell. But wait!! Over in the victim’s network, your IP is disclosed and you’re almost caught or what if your Ip address is not whitelisted. Then?

Over in such a situation, taking the round trip is the most preferable option, as you’ll get the reverse connection into the victim’s server through the authorized user.

System Exploitation Over XSS

In the last section, we captured the reverse shell, but what, if rather than the server’s shell, the attacker managed to get up the meterpreter session of the visitor who surfs this vulnerable web-page?

Let’s check it out how – To make it more clear we’re having:

Attacker’s machine: Kali Linux

Vulnerable Web-application: bWAPP(bee-box)

Visitor’s machine: Windows

So, the attacker first creates up an hta file i.e. an HTML Application over with the Metasploit framework, that when opened by the victim will thus execute up a payload via Powershell.

Great!! He got the payload URL, now what he does is, he simply embed it into the XSS suffering web-page and will wait for the visitor.

Now, whenever any visitor visits this web-page, the browser will thus execute the malicious script and will download the HTA file over into his machine.

Cool !! From the above image, you can see that the file has been downloaded into the system. Now, as soon as the victim boots it up to check out what it is, there on the other side, the attacker will get his meterpreter session.

CSRF with XSS

Wouldn’t it great, if you’re able to manipulate the password of the user or the registered email address with your own, without his concern?

Web-applications that are suffering from XSS and CSRF vulnerability permits you to do so.

Boot inside the vulnerable web-application bWAPP as bee: bug, further select “CSRF (Change Password)” from the “Choose your bug” option.

This selection will thus redirect you to a CSRF suffering web-page, where there is an option to change the account password.

So as we enter or sets up a new password, the passing value thus reflects back into the URL as the password is changed to “12345”.

Copy the password URL and manipulate the password_new and the password_conf values to the one which we want to set for the visitor. As in our case, I made it to “ignite”.

Now, its time to inject our script into the XSS suffering web-page with the “image” tag.

Now, let’s consider a visitor is surfing the website and he visits this vulnerable section. As soon as he do so, the browser executes the javascript embedded payload and will consider it as a genuine request by the visitor i.e. it will change the password to “ignite”.

Great !! He did that, now whenever he logs in again with his old password, he won’t be able to as his password has been changed without his concern.

But the attacker can log in into the account, as he is having the new password i.e. “ignite”.

NTLM Hash Capture with XSS

An XSS vulnerability is often known for its pop-ups, but sometimes attacker manipulates these pop-up in order to catch up sensitive data of the users i.e. session cookies, account credentials or whatever they wish to.

Here an attacker thus tries to capture the NTLM hashes of the visitors by injecting his malicious Javascript code into the vulnerable application.

In order to carry this up, he enables up the “Responder” over in his attacking machine, which will thus grab up all the authenticated NTLM hashes.

Further, he simply injects his malicious script into the XSS suffering web-page with an “iframe”

Cool !! Its time to wait for the visitor. Now as the visitor visits this web-page he got encountered with a pop-up asking for the credentials.

As soon as he enters his system credentials, the web-page thus reloads and the attacker will have his NTLM hash.

It’s not the end. He needs to crack this up. Therefore over in the new terminal, he directed himself to the directory where the hash is stored.

Further, he makes up a new password file as “pass.txt”

Great!! His work is done now. He simply embeds the password file and the hash file over into “John The Ripper” and there he’ll get the authorized session.

Session Hijacking with Burp Collaborator Client

As in our previous article, we were stealing cookies, but, impersonating as an authenticated user, where we’ve kept our netcat listener “ON” and on the other side we logged in as a genuine user.

But in the real-life scenarios, things don’t work this way, there are times when we could face blind XSS i.e. we won’t know when our payload will get executed.

Thus in order to exploit this Blind XSS vulnerability, let’s check out one of the best burpsuite’s plugins i.e. the “Burp Collaborator Client”

Don’t know what is Burp Collaborator? Follow up with this section, and I’m sure you’ll get the basic knowledge about it.

Login into the PortSwigger academy and drop down till Cross-Site Scripting and further get into its “Exploiting cross-site scripting vulnerabilities”, choose the first lab as “Exploiting cross-site scripting to steal cookies” and hit “Access the lab” button.

Here you’ll now be redirected to blog. As to go further, I’ve opened a post there and checked out for its content.

While scrolling down, over at the bottom, I found a comment section, which seems to have multiple inputs fields, i.e. there is a chance that we could have an XSS vulnerability exists.

Now its time to bring “Burp Collaborator Client” in the picture. Tune in your “Burpsuite” and there on the left-hand side click on “Burp”, further then opt the “Burp Collaborator Client”.

Over into the Collaborator Client window, at the “Generate Collaborator payloads” section, hit the Copy to clipboard button which will thus copy a payload for you.

Cool!! Now, come back to the “Comment Section” into the blog, enter the following script with your Burp Collaborator payload:

 

Great!! From the below image, you can see that our comment has been posted successfully.

Time to wait!! Click on the Poll button in order to grab up the payload-interaction result.

Oops!! We got a long list, select the HTTP one and check its “Response”. From the below image you can see that in the response section we’ve got a “Session Id”. Copy it for now !!

Now, back into the browser, configure your proxy and over in the burpsuite turn you Intercept “ON”.

Reload the page and check the intercepted Request.

Great!! We’re having a Session ID here too, simply manipulate it up with the one we copied earlier from the collaborator.

Hit the Forward button, and check what the web-application offers you.

Credential Capturing with Burp Collaborator

Why capture up the session cookies, if you could get the username & passwords directly??

Similar to the above section, it’s not necessary, that our payload will execute over at the same place, where it was injected.

Let’s try to capture some credentials over as in some real-life situation, where the web-page is suffering from the Stored XSS vulnerability.

Back into the PortSwigger account choose the next defacement as “Exploiting cross-site scripting to capture passwords”.

As we hit “Access The Lab”, we’ll get redirected to the XSS suffering web-page. To enhance more, I’ve again opened up a blog-post there.

Scrolling the page again, I got encountered with the same “comment section.” Let’s exploit it out again.

Back into the “Burp Collaborator”, let’s Copy the payload again by hitting “Copy to Clipboard”.

All we need was that payload only, now inject the comment field with the following XSS payload.

Let’s hit the “Post Comment” in order to check whether it is working or not. The below image clears up that our comment has been posted successfully.

Now let’s wait over into the “burp Collaborator” for the results. From the below image you can see that our payload has been executed at some point.

Let’s check who did that.

Oops!! It’s the administrator, we’re having some credentials.

But where we could use them?

Over at the top of the blog, there was an account login section, let’s check it there.

Cool!! Let’s try to make a dry run over here. Tune in your proxy and capture up the ongoing HTTP Request.

Okay !! Let’s manipulate the username and password with the one we captured earlier in the Burp Collaborator.

Great!! Now simply hit the Forward button and there you go….

XSS to SQL Injection

So up till now, we were only discussing, how an attacker could capture up the authenticated cookies, the visitor’s credentials and even the server’s remote shell. But what, if I say that he can even dump the complete database of the web-application over in the single pop-up? Wonder how? Let’s find it out in this section.

Over in the vulnerable application, the attacker was encountered with a web-page which was suffering from the SQL Injection vulnerability.

Therefore in order to grab up the result more precise, he checked the total number of columns with the “order by” clause.

As he was then confirmed by the total columns, he thus used the UNION operator with the SELECT query.

http://192.168.0.14/bWAPP/sqli_1.php?title=’ union select 1,2,3,4,5,6,7–+&action=search

Great!! This was all he wanted, the printed value. From the above image, you can see that “2” has been displayed on the screen.

It’s time to check this for XSS. But he can’t inject his Javascript code like the same he used to, therefore he’ll thus convert it all into the “HEX string” and then he’ll manipulate “2” with the hex-value.

Cool!! It’s working. Now he can add any script, whether it is for cookie capturing or the remote shell one. But for this time, he’ll dump up the database, its tables and the fields.

Great!! From the below image, you can see that the complete database structure has been presented in front of us.

Author: Chiragh Arora is a passionate Researcher and Technical Writer at Hacking Articles. He is a hacking enthusiast. Contact here

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 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 the 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

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.

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

Now this malicious code has been stored into the web application’s database.

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

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

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 <script>alert(“hello”)</script>, 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

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

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

Source

• https://portswigger.net/web-security/cross-site-scripting/dom-based
• https://www.w3schools.com/

Author: Chiragh Arora is a passionate Researcher and Technical Writer at Hacking Articles. He is a hacking enthusiast. Contact here