Ethical Hacking and Penetration Testing Guide

Svg Craziness: Bypass 2
Consider a scenario where a website is insane enough to use SVG and it’s using htmlspecialchars 
for filtering out the input. Your input will be reflected in the following manner:

---

376
◾ 
Ethical Hacking and Penetration Testing Guide
Now we submit the following input:
www.site.com/test.php?var=text
"
;alert(1)//
This is how your input would be reflected with htmlspecialchars enabled:

This will execute JavaScript even if HTML chars have been enabled, and htmlspecialchars 
converted your 
"
to its html entity ““"”. However, it still executes under SVG because it 
introduces an additional context (xml) into the html context. A solution would be to render a 
double encode instead of a single encode of to the characters.
The following is the screenshot of a jsfiddle’s output:
Bypass 3: href Attribute
This third one is the easiest of them all. You would often come across this particular scenario. 
Imagine your input is being reflected in href tag and then being parsed and displayed on the 
screen.
Click
An attacker injects the following payload as an input:
Javascript:alert(1);
It would be reflected as follows:
Click
This will bypass htmlspecialchars and result in a valid JavaScript execution. Here is the real-
world example of this scenario.

---

Web Hacking
◾ 
377
Stored XSS/Persistent XSS
We learned about various techniques for identifying reflected XSS vulnerabilities. Let’s talk about 
the second form of XSS, that is, stored or persistent XSS. Unlike reflected XSS, in stored XSS 
vulnerabilities, the user input gets stored in a database or on a server and is reflected back later. 
The identification and detection techniques are the same as the reflected XSS; however, the only 
difference is that the data are stored. Stored XSS vulnerabilities are most dangerous of all as they 
require very less user interaction. Let’s now look at an example of a simple stored XSS.
We have a guestbook that allows random guests to write a message. The guestbook accepts two 
parameters: name and message. We will try testing both of them for XSS vulnerabilities.
Payloads
Name: 
rafay">
Message: 
">
As we click the “Sign Guestbook” button, our name with our comment is posted; however, the 
problem is that both of these inputs are not properly escaped before they are reflected back to us. 
And since the input is stored in the page, we call it a stored XSS.
This means that the JavaScript would be executed when anyone visits the page containing 
guestbook. We will see how this can be dangerous a bit later.

---