![]() This is a cross-post from the Black Hills Information Security blog. You can read it here: http://www.blackhillsinfosec.com/#!Stored-XSS-via-Reflected-XSS-or-How-Not-to-Fix-Your-Web-Application/c1592/56aa33c40cf289b6a281f44c http://targetwebsite.com/page?id=<script>alert(‘This is XSS’)</script> If the target website and ‘id’ parameter are vulnerable to reflected XSS then upon visiting this link the injected script will be executed in the browser. A second, more serious type of XSS is called Stored XSS. Stored XSS makes exploitation of a target much easier for an attacker. Instead of the XSS script needing to be located within a link itself the malicious script can be injected into a web application where it is then stored in a persistent state. While it is still true that a victim that an attacker wishes to target must visit the site where the XSS script is stored in order for it execute in the victim’s browser, it might not take as much work for an attacker to get them to visit it. An example of a Stored XSS might be found in message board functionality of a site where users can post various messages to other users of a site. Typically, these messages are “stored” so they can be displayed to other users later on. If an attacker can successfully inject malicious scripts in these locations a Stored XSS vulnerability might be present. In a recent assessment I was working on I found an interesting way to execute what is essentially a Stored XSS attack by utilizing a Reflected XSS found in another part of the site. The way I stumbled upon this technique was during the third retest of a web application I was performing for an organization. During the first two retests the organization had attempted to fix a Stored XSS vulnerability but each time I was able to evade the fixes they put in place. I will detail each of these in this post and how I ultimately was forced to find a new way to exploit the Stored XSS vulnerability, by leveraging a Reflected XSS in the same target application. Also, I’d like to detail how they “tried” to fix the vulnerability and how they failed each time. In this post I’d like to highlight two things.
<IFRAME src=# onmouseover="alert(document.cookie)"></IFRAME> On the first retest of this application I found that it started validating the attributes ‘src’ and ‘onmouseover’. So I gave it a valid ‘src’ and modified the script to perform an "onload" instead of "onmouseover". This worked: <IFRAME src=test.com onload="alert(document.cookie)"></IFRAME> The fact that this worked indicated that the organization was simply patching the proof of concept I provided to them. This is not the way to fix vulnerabilities penetration testers give you. <IFRAME src=”javascript:alert(1);”></IFRAME> <IFRAME src="javascript:alert(1);//"></IFRAME> I say “Stored XSS via Reflected XSS” but in reality it is truly just a combination of Reflected XSS and HTML injection. It was evident that the developers of the application spent time filtering the input to this message board. The problem was that HTML content could still be submitted. Even though they did a good job blocking common XSS attacks in this form I was still able to force a target’s browser to load a Reflected XSS script via an iframe that was submitted to the message board. The submission would look like this: <IFRAME src="https://targetwebsite.com/page?id=a"><img src=a onerror=alert(document.cookie)>"></IFRAME> Now whenever any user navigates to the message board their browser will load the iframe containing the Reflected XSS link. Since this iframe is stored within the message board it will essentially execute the same way the Stored XSS scripts executed previously. For pentesters: When you are performing a web application assessment in the future and you locate a form you can submit and store data to try submitting an iframe with a Reflected XSS script. You might find that you can create a Stored XSS condition when none of the standard XSS injection techniques work. Automated scanners will not detect this method of executing Stored XSS as the attack requires previous knowledge of a Reflected XSS vulnerability. When assessing mitigations put in place be thorough and don’t be afraid to try new things. For developers: Output encode HTML and HTML attribute contexts. This means take the untrusted user input (i.e. <script>alert(1)</script>) and convert it to HTML encoding (i.e. The less than symbol ‘<’ would convert to < The greater than symbol ‘>’ would convert to >). Now when the the user input is displayed back to the user it is being displayed as data rather than executable code. Filtering input is rarely the right fix for XSS and as demonstrated in this blog post these “filters” can often be bypassed with a little creativity. Input filtering can be helpful but should only a secondary mitigation control. A good source for Cross-Site Scripting prevention techniques can be found here:https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet As a developer XSS should be addressed at the source of the application. However, there are network based tools that can assist in preventing some of these attacks. Web application firewalls (WAF) can be utilized in front of a web application to be an additional layer (think defense-in-depth) to protect against common web application vulnerabilities. Lastly, do not simply patch the specific proof of concepts a pentester has provided you. When presented with an issue such as XSS attempt to understand the underlying issue, and develop a plan of action to eliminate this vulnerability at the source of the problem. _________ Beau Bullock works at Black Hills Information Security and hosts Hack Naked TV, along with many other projects. Read more about Beau here. |
root@dafthack:~# >