Stored Cross Site Scripting (XSS)
Stored Cross Site Scripting (XSS)
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. (owasp.org)
Intro
XSS is in the top 10 OWASP 2017 vulnerability. Stored XSS occurs when attacker input a payload, most often JavaScript code, into a target system and then the victim executed the payload every time the victim visit the page. This type of attack is still common to be found on real target.
Usage
For this case, I’m giving an explanation how to execute Stored XSS using a lab from portswigger.
After accessing the lab, it just display a bunch of post and nothing interesting to be found. Then, if we want to execute a XSS payload we need to find some input field to inject our payload.
So, I click “View post” button to find something interesting inside the post page. And then, I found a comment section that can to be inputted, so I try to inject my XSS payload into commend field. I’m using a simple XSS payload <script>alert(1)</script> for this case. Sometimes, in real case target you need to bypass to be able succeed execute XSS, you can find some payload to bypass from OWASP or from github by swisskyrepo.
If the payload successful to be executed, every time the victim visit the page it will be shown an alert with value 1.
Remediation
For preventing XSS to be executed. Developer can use filtering techniques to remove dangerous keywords for example <script> tag, using frameworks that automatically escape XSS by design, escaping untrusted request data based on the context in the HTML output (more details here)
