XSS will never die

XSS will never die | by Oleksandr Opanasiuk - Freedium Milestone: 20GB Reached We’ve reached 20GB of stored data — thank you for helping us grow! Patreon Ko-fi Liberapay Close < Go to the original XSS will never die Stories about 5 very different XSS Oleksandr Opanasiuk Follow ~8 min read · November 2, 2019 (Updated: December 12, 2021) · Free: Yes Hello all the Penetration Testing community, hope you are doing well. Got some unusual XSS vulnerabilities for last months, but today I want to discuss the general idea of explanation, since the writeup for each of these vulnerabilities is small. So let's go!👨‍💻 Disclaimer: there will not be complicated explanations and code analysis, this is a simple discussion of the strange concepts of protecting 5 applications and breaking it. Okay, so we have one HUGE shop-company, that has a lot of sub-domains and different applications running on them: It will be 5 parts with short story about one XSS, protection and breaking in each one. Part 1 — Stored XSS for mobile on the forum Really love forums since there are a lot of potential vulnerabilities due to a huge list of functions . I went to the forum.example.com/post?id=123 and started testing of File Upload via URL functionality — here I noticed that it taking the name of file and inserting it twice on the page — in tag and in the description of the file, it looks like: Me : what if insert " to the name? Ok, lets test http://…/1.webp" Site : Me : Ez, go onerror and report it! Site : Ahahahahahah 👋 What happens? All the DOM-events are removing ( going to 🤯). But, but it turned out that not all. As the world is always improving, DOM-events appeared for mobile too — so they were not blacklisted and we got Stored-XSS for mobile devices. Finally it was like: Also do not forget that you can use alert`1` instead of alert(1) (here service blocked all the parameters inside "()") Resume : no blacklists will help due to the improving of technology — everything cannot be prevented. But filter quotes — it's quite possible to try. Here we saw that a quote was inserted into html-code — and with the idea "I won't believe that you will block all the possible DOM-events" we found that the mobile events were not blacklisted and got Stored XSS in forum post. Part 2 — Reflected XSS on email preview I got an email from our HUGE-shop, and they use the domain email.example.com to view emails, like email.example.com/view?id=123&key=abc&statname=DiscountEmail . The parameter "statname" was and did nit filter the " , but filtered <> . So, we just looked how to exploit XSS in hidden input and founded " accesskey='X' onclick='alert(1)' ". It worked, and we got Reflected-XSS. Resume : You will increase your chances of finding vulnerabilities if you subscribe to newsletters from the service that you are testing. Firstly , you will receive news about service updates, and will be able to test it faster than other hackers (I do remember how some guy tested YouTube Beta-studio as soon as it was presented and found great IDOR in 15k$). Secondly — it is quite possible that in the email you will find vulnerable links due to less attention to such minor functionality. So after finding non-filtered quotes and quick-recon in Google "XSS hidden input", we have found the way to exploit it with "accesskey". Part 3 — Stored XSS in live support chat They had domain support.example.com, where we can find some information about using the service and chat online with manager in case of needing of the help. And you know what — I started chat with manager, and inserted — it was injected into html-source! I was very surprised…🙈 As I later understood, no one could get to test this thing — first you have to go to the site at a time when managers are online, and this time is limited to 6 hours a day. Secondly, you need to start a chat, and for this we need to wait for about half an hour to start a conversation with an online manager. That is, from the 3rd time I decided to test this functional, and from 5th time I got into the chat — I think this explains why no one found this thing before. Resume : Any company has a lot of functionality, and sometimes some things remain outside the scope of developers. We all know that we need to test all the possible functionality, but, unfortunately, sometimes we miss vulnerabilities due to laziness or fatigue. Here we found a service that was probably created a very long time ago, but was not updated from a security point of view, since no one checked it. Part 4 — Reflected XSS in User Dashboard This is the longest vulnerability, if we count from the time when I found the first clue about the presence of the vulnerability, and until the time when I finally exploited it (Before this it was Race Condition in purchasing functionality with about 1 month. Just so that you understand how this process happens with me — when I find some interesting things, I usually record bugs info, and later, when new ideas appear, I return to them and continue to exploit). Are you become to be interested in? 😊 So here we have User Dashboard, and functionality of filtering our activities — we can insert value " time_from " to filter it with the dates. It was not filtering quotes, so we quickly inserted quote and got: Ok, next step — does it filter "< >" . Yes, so I decided that we would exploit this via an input element with DOM-events. But after ' time_from="777" onfocus="alert(1)" ' I got it: What just happened? Like in the Part1, it is filtering DOM-events and removing it . But, everything is much more complicated — they don't have a blacklist, they just block all the parameters in the tag that starts from "on" 🤷‍♂️🙂️🤷‍♂️ Suddenly I was attracted by another coincidence on the page with the entered data and I saw such a strange field: It was something like break-links logger and… here "<>" were not filtered: I want to stop at this step so that you understand what is going on: we have a filtering function for our activities ( user.example.com/activities?time_from=777&acc=submit , and the " time_from " parameter is vulnerable. But there is protection in the application: it removes events (the WAF finds everything inside the tag that starts on "on"). If this happens, the logger fires, captures the broken link, and inserts it in a strange way to page source without filtering " and <> 👍 But you remember that all DOM-events are removing — I started looking for tags that you can insert and receive XSS, but it turned out that it cuts them out just like events. Another one "but": I noticed a strange thing — if I wrote a tag, but didn't close it — it didn't delete it, that is, only the closed tag was cut out. So it turned into: YES!😱 So now we can insert link to execute script, but how to close script tag? If the src is given in script tag — all the source is ignoring inside the tag, so we just need any later on the page. Finally source looks like: Let me please explain again what just happened: so we found the broken value " old_request ", that creating if we add something potential danger to url (DOM-event). And in this value we can insert '<>" into source, but still can not insert tags and DOM-events. But since the input tag was closing itself — we insert "