> For the complete documentation index, see [llms.txt](https://yasmeen-rezk.gitbook.io/my-notes/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yasmeen-rezk.gitbook.io/my-notes/bug-bounty-playbook-v2/basic-hacking/owasp/xss.md). # XSS Stealing user cookies for account takeover is much better than popping an alert box. #### There are three types of XSS vulnerabilities reflected, stored, and DOM. ## Reflected User input is reflected in the html source, If done improperly an attacker could insert malicious payloads into the page. #### Input Field Just because your payload is reflected in the page doesn't mean it will immediately trigger, you might have to break out of a few tags to get the payload to work properly. #### Event Attributes applied to HTML tags for the execution of Javascript when certain events occur, for example, onclick, onblur, onmousehover, etc. * by using them, we don’t need “<” or “>” tags. EX: "Onfocus" event attr: * When a user focuses on this input tag, the function will execute and an alert box will appear. ## Stored #### What distinguishes stored XSS from reflected XSS? * stored XSS will be permanently stored somewhere while reflected XSS is not. The XSS payload is stored in a (Database, JSON file, and XML File) and retrieved by the application. * once a user visits the vulnerable endpoint the XSS payload will be retrieved and executed by the application. #### Popular places to store user input: * Email, Username, BIO, Address, Comments, Images, and Links. ## DOM Based 💡Note, If a javascript function is passed to the eval function it will be automatically executed before the eval function is run. #### What distinguishes DOM-based from stored XSS and reflected XSS? * it happens client-side entirely within the browser. * spotted by looking at the JavaScript source code. When performing a code review people generally look for user-supplied input (source) and track it through the program until it gets executed (sink). #### illustration

#### Sources 💡If the source is being paced to a dangerous sink you could have XSS. A list of javascript sources can be modified by the user: * document.URL, location.hash, Document.cookie, Location.pathname, location.href, location, document.baseURI, and document.documentURI #### Sinks The sinks are meant to be the points in the flow where data depending on sources is used in a potentially dangerous way resulting in the loss of the CIA triad. If user-supplied input(source) is ever passed to a dangerous sink you probably have DOM-based XSS. #### A list of dangerous sinks

Sink	Example
Eval	eval(“Javascript Code” + alert(0))
Function	function(“Javascript Code” + alert(0))
SetTimeout	settimeout(“Javascript Code” + alert(0),1)
SetInterval	setinterval(“Javascript Code” + alert(0),1)
Document.write	document.write("html"+ “<img src=/ onerror=alert(0)”)
Element.innerHTML	div.innerHTML = "htmlString"+ “<img src=/ onerror=alert(0)”

## Polyglot When testing for XSS you often have to break out of multiple tags to get a payload to trigger. A famous XSS polyglot by “0xsobky” it can be used to trigger your xss payload on a multitude of scenarios: ```javascript jaVasCript:/*-/*`/*\`/*'/*"/**/(/* */oNcliCk=alert() )//%0D%0A%0d%0a//\x3csVg/\x3e ``` ## Cookie Stealer Cookies are used to store a user's authentication details. * If an attacker steals this cookie by send it to the attacker's machine, they will be able to impersonate the victim giving them access to their account. #### Exploitation Modifying the “document.location” forcing the browser to navigate to an attackers webpage: * Document.location = ” ” Javascript "Document.cookie" Function used to retrieve a user's cookies. Combining these two commands to grab the victims cookies and send them to the attackers machine: ```javascript ``` When the payload was executed it sent the users cookie to our server then cookie used to login as the victim user allowing us to fully compromise their account.