Exploiting stored XSS on CodeCast.io
Transcript
English (Auto-generated)
Okay, today we are going to attack code cast dot io that's right. There is a live vulnerability on this website and we are going to exploit it. Um the vulnerability exists on series. So when we edit a series, we have the option to load um, markdown in the promo text. Right? So we can make something bold like that. But what a lot of people don't know is that markdown um, also allows you to have in line html right there and usually they'll use a library like dong purify that will allow you to have html without excess. S but if you don't have that, then X ss will absolutely be an issue, right? Because if you have in line html, hey javascript is part of html um in in the form of things like this, I'll show you. So let's say we have an image with some meaningless source that will cause an error when it tries to load the image, that's when we use our on error to say something like alert, you have been taxed okay. And I actually made a previous version of this video before and I was just recording this tab so it wouldn't show the alerts and that's what we're fixing. But the someone noticed that I I forgot this closing brackett for this tag and I noticed it to the second time I watch, it was like it was driving me nuts, but let's fix to now. So so here we have our series and now we're going to load the series with this promotional page and see how it renders it. So we've got a series. Look at that, you have been hacks. Oh no that's it. That is a stored exercise. Anyone who comes to my page, I don't have to have them do some special U. R. L. Anyone who clicks this series, this is gonna be loaded for them and we could do something more malicious for example, I mean there's a purchase button here, we could try to click that by manipulating the dom here. But even more simply we could do something like window dot location dot replace and send them to a malicious website. Um That looks just like podcasts that maybe have some fishing stuff and they're probably not gonna assume that they've been redirected somewhere malicious. Right? How would they know that? Or even just changing the content of the page in any way we want. That's something we do, we have complete control over this page because we're running javascript. The only thing we can't do is steal their session. Um That's something you can sometimes do with these kinds of vulnerabilities but ha ha you have been hacked but we're not gonna be able to do it. And the reason for that is that the developers very wisely made the cookies. If we look at the cookies, we have a session one somewhere around here. I'm gonna log out after this that this won't work. Um the cookies, this cookie is http only, we see it's http only, so javascript won't have access to it. Good job debs. I don't need to log out so that my session cookie isn't valid anymore. But yeah, easy as that. I'm gonna log back in now so that I can get rid of that excess. S and thank you for this podcast, it's private. So if you're watching this it means that it should already have been fixed. Thanks a lot. Bye.
sdsdsdsd
const [ codeCastVideoDiv ] = document.getElementsByClassName(‘embed-responsive’) codeCastVideoDiv.innerHTML = ‘<iframe width=”560” height=”315” src=”https://www.youtube.com/embed/dQw4w9WgXcQ” title=”Epic codecast, gotta see this!” frameborder=”0” allow=”accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture” allowfullscreen></iframe>’;
It’s worth noting that even regardless of the Markdown -> HTML -> JS route I exploited, even a basic Content Security Policy like
script-src 'self'
would have made this vulnerability much harder (if not impossible) to exploit.Also I’m curious if comments are vulnerable to other markdown-based XSS attacks