Day 4 from #100daysofhackandimprove comes with an explanation about the common vulnerability, but a with certain level of complexity called Cross Site Scripting (XSS). Besides Cross Site Scripting, and more types of SSRF escalation attacks.
Cross Site Scripting (XSS)
", ', <, >.
If some of these characters doesn’t change the output that the website provides, might be because they’re being rendered as HTML encode characters. In this case it will display as the following:
double quote (") as " or " single quote (') as ' or ' opening angle bracket (<) as < or < closing angle bracket (>) as > or >
If the website doesn’t sanitize angle brackets, it is possible to change the HTML structure of the webpage. This is an example of a basic XSS payload.
httponly flags, or not. This
httponly flags will not allow to the attacker to steal cookies, but if the flag is not set, the attacker can steal the victim’s cookies. Also, if the site is vulnerable to this attack, try to understand what kind of cookies the site is using. For example, the attack would have more impact if the attacker is able to steal sensitive cookies as well.
Not always might be possible to inject HTML tags as a form of payload. It’s necessary to understand the website and how it works in order to make the payloads work. Let’s get to the following example to understand how important is to understand how the website works in order to create a good payload.
<input type="text" name="username" value="hacker" width=50px>
By injecting a double quote in the value attribute, you could close the existing quote and inject a malicious XSS payload into the tag. You might do this by changing the value attribute to hacker” onfocus=alert(document.cookie) autofocus “, this would achieve the following.
<input type="text" name="username" value="hacker" onfocus=alert(document.cookie) autofocus "" width=50px>
From the example showed above, the payload that has been injected is
Let’s say you find a variable within a
<script>tag. You can inject a closing script tag
</script> and inject your own payload.
# Before payload <script> var name = 'hacker'; # After payload <script> var name = 'hacker';alert(document.cookie);''; </script>
Types of XSS
The main types of XSS are reflected and stored XSS.
Reflected XSS occurs when a single HTTP request that isn’t stored anywhere on the site delivers and executes the XSS payload. Nowadays, browsers are made to prevent this kind of attacks. Therefore, when an XSS attempt occurs, the browser shows a broken page with a message related to the protection of the users.
Occurs when a site saves a malicious payload and renders it unsanitized. The payload might not execute immediately after submission, but it could execute when another page is accessed. There are other subcategories of XSS attacks such as DOM-based and blind.
Write Ups and Explanations
The attacker sent the following payload in the URL
# Decoded URL https://wholesale.shopify.com/asd';alert('XSS');' # Encoded URL https://wholesale.shopify.com/asd%27%3Balert%28%27XSS%27%29%3B%27
The payload was
';alert('XSS');' . Look how the attacker didn’t have the need to insert HTML tags in order to make the attack successful. Remember to look how the website sanitized the input.
The attacker had the chance to act as an administrator where he had the chance to manipulate the HTML of the website. He introduced the following payloads.
Therefore, when the victim was trying to get access to the store, a pop up displaying the name of the domain will appear.
The attacker achieved to bypass the HTML filters in the emails. Also, the attacker had the chance to manipulate the HTML values by injecting the following payload.
<img ismap='xxx' itemtype='yyy style=width:100%;height:100%;position:fixed;left:0px;top:0px; onmouseover=alert(/XSS/)//'>
The attacker while trying to change his picture in hacker one he found the following URL in Google search.
Something that attracted his attention was the parameter
imgurl with the href attribute
<a>. Therefore he went to triage the vulnerability with the following payload: “
SSRF to read Internal Files and AWS Metadata
Rajesh Ranjan, There may a possible where we can read the internal files using SSRF. Suppose the
example.com is vulnerable by SSRF, and this look like:
So, you can put the payload in “
url=” parameter, and the final URL will look something like:
Now this can be escalate this further to read the AWS EC2 metadata if the application is using the AWS services. To do that, suppose the application is running its AWS services on
169.254.169.254, then we can craft a malicious URL as:
And, now replace the url parameter with this, so the final crafted URI will be:
Now to read the Access key ID, secret key, we can use the following payload will be:
Blogs Related to SSRF Escalation
Reports Gathered from HackerOne