- [Wesley] You might be
browsing the website, suddenly somebody gives you a URL, you click it and bam
you've lost your account. - The one concern I have is, I don't wanna go to your website now. - We are taking over the
world before you know it. (David laughs) (upbeat music) - Hi everyone. It's David Bombal, back with a very special guest. Wesley, welcome. - Thank you very much, David. - Can you tell us what
handle you're well known for on Twitter and on other platforms and tell us why you use that handle? - So I usually use the handle, the XSS Rat. It started because I have a
fascination with exotic animals that a lot of people like, like rats and I have like a bearded dragon and a spider here. I have those kinds of pets and rats are really intelligent animals. They're more intelligent
than cats and dogs. You can teach them a lot of tricks and if you can teach them
cross-site scripting, that would be amazing. So I was like, (David laughs) Let's start teaching rats
cross-site scripting. But it didn't turn out that way. So why not be a rat and then teach myself
cross-site scripting. No, just kidding. Of course, like rat is
also a remote access tool. First of all, I really do
like rats that wasn't a joke, but cross-site scripting
remote access tool has been a fantasy of mine. Like, okay, if I can do cross-site scripting, maybe I can escape that somehow and turn it into a remote access tool. It just a crazy fantasy of mine, but maybe one day who knows. - That's fantastic. So, I mean, can you explain what cross-site
scripting actually is? And perhaps in this sort of interview, give us a demonstration. - I think there's a lot of
misconceptions out there about cross-site scripting.
- Yeah. - Like if I go online right now and I look up cross-site scripting, I can find at least four
mistakes in the first page. And the problem of cross-site scripting is that a lot of people, first of all think it's
only in JavaScript. That's not true. Cross-site scripting basically means that I, as an attacker can insert
a script in a website, a piece of script that's gonna
execute on your computer. And that piece of script can happen in any scripting language. Like the notorious Flash, for example, it's an exploit in of itself. But besides that cross-site scripting is
very possible there as well. And we don't use that anymore of course. It happens predominantly in JavaScript because JavaScript is the
predominant scripting language. It's as simple as that. Basically, it happens because a
developer doesn't sanitize user input properly. And even if they sanitize
user input to a degree, there might still be
Cross-site scripting possible. So if you have a script on your website or it's just a normal website, and I insert a piece of HTML, that says script, and then my script in there, and then slash script that basically can execute if you don't sanitize it properly. I'll show you guys what I mean by that. But I first need to
talk a little bit about the types of cross-site
scripting out there because a lot of people think that reflected and stored and DOM cross-site scripting are the predominant types
of cross-site scripting. So you have stored cross-site scripting, which means that, as an
attacker insert a value into the website and than stores it somewhere on a database or in a file or whatever and then displays it again. I can also have reflective
cross-site scripting, which doesn't touch the server. I send you a link and
it contains the attack. Then also DOM cross-site scripting. And when you have a website, you have the website itself, the source code, like we can see, and then you have the DOM, which is everything
around the website itself. The document object model, things like the history, the link, things that describe
your website basically. And you can, from the source code, enter a value with enters
the document object model and that happens due to a DOM sink, as we like to call it. Now a DOM sink, I can show you that later on as well. Basically means I take
a value from my source and I enter it into my
document object model. Like if I have to take user input and enter it in a URL, for example. - Yeah. - That can happen through
DOM or document.write. There's a lot of DOM sinks out there and a lot more in jQuery even. Now, I don't want you to
worry too much about that because that's already pretty complicated. I'm gonna keep it a little
bit more simple today and talk only about source
cross-site scripting. We have reflected source
cross-site scripting and stored cross-site
scripting on the source. But that also happens on the DOM. We have reflected DOM cross-site scripting and stored DOM cross-site scripting. Besides that we also have
blind cross-site scripting. And in recent years, mitigation cross-site scripting. So there's a lot of types of
cross-site scripting out there. I'll predominantly focus
on source reflected and source stored. So the most basic types of
cross-site scripting basically. On hackxpert.com/labs, you can find a lot of
labs that I've created. These are the reflected
cross-site scripting labs that I was talking about. But there's a lot more on here of course. - To make sure that
everyone's on the same page, you've got a basic HTML page here that you wrote in PHP. Is that right? And then it asks for user input. Now, normally we would just
put user data there, like John, is you first name and they would reflect it in the URL, like you've shown there. But what you're saying is you can, rather than just a username, like data, I can try and execute JavaScript there. So that's where you use the script thing, is that right? - Exactly. So this user data is being reflected into my source code right here. - Yeah. - But I can enter anything in here. It doesn't have to be John. It can also be script, for example or a broken image with a script on it. - Just for people who dunno JavaScript. That script implies that it's
gonna run some JavaScript and then alert means it's gonna
pop something to the screen. Is that right? - Exactly. So script is a JavaScript, like you said and alert is gonna make
that pop up appear. Now I talked about
sanitizing user input before. The script tag is being sanitized. As you can see, nothing is reflected. So the developers have gone as far as to
remove that script attack. So that would be a basic attack. If the developers filter nothing at all that script would pop
up an alert right here, a little alert box. - You've got a div class. So you've created like a piece of code. And in there you've saying
alert equals dollar zero. Is that how you're stopping
alert from doing something? - It is because there is
no script in here anymore. - Okay. - So if I show you the
source code of this page, it would say remove
anything that says script the string script, remove that completely. For example, if I do script a in here, you can see that it's removed script and only left a. - Oh, I see. Yeah. So you're looking for that word script and then stripping it out, basically. - Exactly. That's a very basic defense
against cross-site scripting. But it doesn't stop things that don't contain the word script in it. And on a HTML tag, this is an HTML tag. For example, an image with a source. And I can say, this image
is located at this location, but I can also say x, to make it a broken image. So now I'm inserting a HTML tag in here with a broken image, as you can see. And that was also reflected in here. You can see, if I go here, I have created an image tag. - Yeah. So we see the image just above first name. But the image is obviously broken. So what you're saying is and if you can just
show us that code again, image, if broken then on that error, do something. And that's how you got the alert. Yeah. - Exactly. This is what we call a event handler, a JavaScript event handler. We can have HTML tags. And on there we can have event handlers, like an unload event, for example. Which means that if this item loads, execute this code in here and I've chosen to pop up an alert and if I execute this, I can see, it's a little bit hard to see, so I'm gonna close my
source code for a second. You can see popup over here. - So basically the vulnerability here is in traditional HTML. We've changed HTML over the years to allow scripts to run within HTML. But that allows someone malicious like you to basically run code to do something that the developer didn't
think would happen originally. Yeah. So you basically injecting
code in the web server, whatever's just running that code and you getting it to do something. And a popup, like you
say is kind of pointless, but you could steal credentials. Is that right? - Exactly. Like if we log into a website, we have many ways of authenticating. - Yeah. - And one of them is a session cookie. And if I steal this
session cookie, PHPSESSID. So I can demonstrate that as well. I can pop an alert, which contains that
session cookie document. (keyboard clanking)
Cookie. And as you can see, right now I've popped up an alert. It's the same attack that I've did before. But now I'm including the cookies in here. - So just for the people who are not sure what does a cookie do? Does this contains the
session information? So if I have that, I can connect to the servers, if I'm you, is that right? - Exactly. This PHP session ID,
basically identifies me. This says that I am Wesley. And if you steal that, you can be Wesley as well. You can log in as me without
actually knowing my password. - Let's use you and me as an example, I'm looking at my bank
statements through an app or whatever. If you steal that session information, if the bank hasn't done it right, you could basically
take over that session, have access to all my
bank account details, and then you could take
money out of my account. Something like that. Yeah. - Exactly. - Wow. Okay. - It can be a very
dangerous attack, this one. A lot of developers have
tried filtering over the years and there's a lot of
filters possible for this. But the problem is that, cross-site scripting is a
very varied and deep attack that not a lot of people
understand correctly. This was a very basic attack factor, where I literally insert, anything that you put into that field, into the HTML source code. If I sent a cross-site scripting, reflected cross-site scripting attack, I can just take this URL
with the attack factor in it and send it over to you, David. And if you open that, this URL, I have your cookie. - So like, you can send me an email. It's like a phishing thing, type thing. And I click on that. You've got it. Yeah. - Exactly. You might be browsing the website. Suddenly somebody gives you a URL, you click it and bam. You've lost your account and they can send emails
as you maybe even, or messages as you, who knows. This is very dangerous
as an attack factor. And right now it seems like
nothing is reflected right here. But if you look real closely and you inspect source code, you can still find this item that I've put in here in the source code, but it's an HTML comment. This is not a very common thing to occur, but if your user input does get
reflected in a HTML comment, I can also break out of this
by just ending this comment. So an HTML comment is indicated
by a greater dense sign and then a exclamation mark, and then two dashes. And to escape that, to end that, I enter two dashes and a great, sorry, this is a less
than sign of course. And a greater than sign. And now I've broken out of this comment. So anything that I enter now, is not gonna be reflected
in the comment anymore. But it's actually gonna
be reflected on the page. And then I can still
perform my attack factor like I normally would and get that pop up to appear for me. - The reason that you're doing this is the code was perhaps not written right. Is that correct? The developer didn't
write the page correctly. And you just circumventing that. - Exactly. The developer just assumed that maybe there is the piece of, let's say the developer created this and he reflects your input
into the page somewhere, but also in HTML comment. If he's filtering out the
page properly, that's good. But if he's then not filtering
out the comment properly, you still have an option to escape it. This is just a very simple
attack factor again, but this is out of the way. This is not something that you see a lot. That's the problem with
cross-site scripting. It's often things that you don't see a lot that are most dangerous. For example, this is
also an attack factor, but if I enter this one, you can see that my input gets reflected into a input field. Now you might be thinking, okay, if I enter just the script, like I entered before, it just gets reflected
into the input field, nothing wrong here, because in the input, this doesn't execute. But the problem is that I can then break
out of this input again. You can see your input of value you equals and then a double quote. And then what I just entered. So let's say I enter a double quote. I entered myself, then I stop this value here. This input tag is terminated. Especially if I enter this in here. You might think now I am
outside of my input field, but you're not. Because it looks like there's a double quote
being used right here. But if I look at the PHP quote, I actually used a single quote. So if I used my single quote here, now I do break out of my input tag. And this is the dangerous part because a lot of people might miss this cross-site scripting, because they're only
testing for a double quote. So if a pen tester only test
for a double quote here, is completely missing this
cross-site scripting vector, but there's still a
possibility to execute it. So I'm breaking out of
my input tag right here. I'm ending this value and then I'm just gonna
enter the same attack factor that I always do. And I'm gonna get a cross-site
scripting pop up again. - You demonstrating with a popup that's just to make it simple, yeah. But you could forward that to
another server or somewhere. Is that right? - Exactly. This is always the proof
of concept that people use because it's easy. If you're ever testing
for cross-site scripting, I really don't want you
testing with an alert. I want you testing with a prompt or with anything but alert. Every developer out there knows that we are testing with alert. So every developer is
gonna filter on alert. Instead of my alert here, I can enter a prompt as well. And while you might be
filtering onto alert, he might not be filtering out the prompt. - This kind of looks
like, okay, who cares? You're getting a prompt or an alert, but that's not the point. The point is you could do
something a lot more malicious than what you're demonstrating, yeah. This is just, as you said, proof of concept of the fact that you doing something on a webpage that the developer didn't expect and you're able to
extract information. Yeah. - Exactly. Do you guys see these parameters here? What I'm gonna be doing is I'm gonna be entering the
cookies that I'm stealing. I'm gonna be transforming
that into a parameter and then JavaScript can do a lot. JavaScript can make a
request to my server, to my web server. And on my web server, I have what's called access logs and I can check those logs and I can see that a request has been made with a certain parameter. And if you remember that
parameter is the cookies. I now have your cookies on my server, in my access logs. Now there are protections against this. Things like CSP, for example. That's a header that is sent
from the server to the browser and the browser interprets the CSP header. And it says, for example, you cannot make this request, it's not okay. Or you can, sorry, you cannot execute this JavaScript, it's not okay. But those protections again, can be circumvented if you don't implement them correctly. Like for example, if the browser doesn't
implement CSP headers, because this is purely a
browser based mechanism. If the browser doesn't interpret that, then you're out of luck. Then I can still execute my script. There's also a X cross-site
scripting protection header. That's mostly been made irrelevant because of the CSP headers. But older browsers only support the X cross-site scripting
protection header. Now the cool thing about that is you can actually introduce
exploit by using that header. - In other words, let me just see if I
understand it correctly. You can inject code onto a page that the user will run locally. Is that right? So this stuff gets executed
locally on the client and then you can get that
client's session information, all kinds of other information
sent to your server and log that kind of thing. Yeah. - Exactly. And the thing is, I can even insert a key
log onto your computer if I'd like. Like if I cannot get your cookies, because as you can see
these cookies right here, they also have flags on them. HostOnly, Session, Secure and HtppOnly, if the HttpOnly flag is enabled, like I'm gonna enable it right now. And I'm gonna try to
steal my cookie again. It's not possible because that cookie
doesn't get read anymore. That's a protection that
a lot of people will use. So you can see that the
PHP session ID cookie is no longer in here. That's because it cannot
be read from JavaScript and I cannot steal it
anymore as an attacker. There's so much more I can do because every website these days contains a lot of JavaScript. And if I execute a JavaScript
function on your computer and you are logged in. For example, the JavaScript function delete account. I am deleting your account. There's a lot more that can be done with cross-site scripting. If we talk strictly bug bounties, things like keyloggers and stuff like that is
usually not accepted. You have to show some real, proper impact. But even cryptocurrency
miners, that's hot these days. You can be browsing a
website unsuspectingly because all I've shown right now is reflected cross-site scripting. But I can also store this attack factor. So I can either send you this URL or I can go to get some
stored cross-site scripting. I also have labs for that, of course. So this is stored cross-site scripting. And as you can see, I can log in right now. I can register. As you can see, I can make a post and other people can see my posts. So if you browse this website, you can see what I have posted. Now again, I can insert a cross-site
scripting attack in here. And if you browse across this, you might have cross-site
scripting being executed. And the thing is you might be browsing a
website unsuspectingly like Facebook or Twitter, and without knowing it's some cross-site
scripting attack factor. And I make it very obvious
by popping an alert, but a real attacker wouldn't do that. They would silently install
a cryptocurrency miner on that website and you come across it. And suddenly you have
a cryptocurrency miner on your computer, running all day and night. - This is perhaps a dumb question, but how do you as the
attacker inject that code? Cause here you manually doing it. But how does an attacker actually get that code to run on? Like you said, Facebook and we just use that as an example, but like any other website, how do you inject your
code into their website? So that when I go to
their website, it runs. - This is the way. So I've been making a post right now and my post has been cross-site
scripting in this case. So again, a normal attack factor. And if you come across my code, my post, then that code is gonna get
executed on your computer. - You went to this website
and you did something. And that got stored on the website. Now if I go to that website afterwards, that code gets run. - Exactly. - Okay. - If you see my Facebook post, my code gets run on your computer. There's a famous example, from this, a while back on Twitter, there was a self retweeting tweet. Everybody that stumbled across that tweet, retweeted it because there was code being
executed in the background. - Oh. That's bad. - That spread really fast. - You put code on Twitter
or Facebook, whatever, they stored that code on their servers. So it's stored, hence the stored name. I go to that page as a client, I load that post. Instead of seeing a picture of cats, I'm now getting rat code that you wrote or doing something. - Exactly. I'll show you an example of this as well. So let's say you're happily. You're working in your environment. You log in, suddenly you are browsing your website. You come across this post and bam, you have your code executed. This is also a website
that I wrote, by the way, that everybody can go to
it's hackxpert.com/ratsite. And in here you can register, you can log in and you can
make your self administrator. This is a very vulnerable website, but this contacts page, I just opened it. I didn't write any code, as you saw, I just opened this page and bam, I get cross-site scripting executed. Somebody inserted this in here. And they were funny because they gave the answer to life and everything apparently
in my cross-site scripting. (David laughs) But yeah, this is a very vocal example. This is not something
which you will come across in real life. An attacker will try to be silent and try to not pop any alerts, but instead execute code or steal your cookies. Or like you say, suddenly just replace all of
the pictures of cats with rats. And we are taking over the
world before you know it. (David laughs) - So that was, so I get the stored one. That makes a lot of sense. You go and post some code rather than me getting pictures of cats. That is like some kind
of code that runs now and shows pictures of rats or something like much more malicious. With that reflected, that's where I, you send me an email or something and then I click on it. And that's how that executes. Is that right? I'm just trying to get in my head, how does the code actually run on like, a reflected one? - So you can see that I
have a parameter in here, search term. - Yeah. - I can literally send this to, David. - Yeah. - And You click on this and bam, you have your code executed. Of course, stored cross-site scripting
is worse than reflected because in reflected, I'm gonna have to do
some social engineering to get you to click on my link, whereas stored, you just browse the website and bam your code gets executed. - Wow. Yeah, it makes a lot of sense. - And I just showed you two
contexts or three contexts. There's a lot of contexts
that code can get executed and a developer might be very secure, very secure in filtering out anything, that is a attack factor like this, completely filtered out. But in here, there's still an attack possible because this is a, what we use Angular. This is a templating engine in JavaScript, AngularJS, this is what it's called and I'm using a vulnerable version that allows for client
site template injection. If I do this, for example, seven times seven. You can see that it gets converted to 49. It gets executed and I can insert an
attack factor like this. This is pretty complicated, of course. And you see that I still have a popup. Even though the developer
has been very secure indulging in and filtering out anything that they think of, if they still use a vulnerable version of a templating engine, I can still insert cross-site scripting. So just to demonstrate, it's so complicated and it's not something you can solve with a few simple steps, you really have to be diligent everywhere. - So the answer is don't run
JavaScript on your website. (Wesley laughs) - Off with JavaScript is not, the JavaScript is making a real, it's getting really like,
JS is coming up really big and templating engines are
making a really big introduction. - Yeah. I mean, it's not something
that's gonna go away. That's I mean, I say that in as a joke, because it's like saying don't use HTML. It's so important these days, isn't it. But the story, the moral of the story is, it gives attackers so
many options to attack. - Yeah. - Or someone who's interested
in like bug bounty. Gives them a lot of options. Yeah. - And I just want to say, know what you're doing. Don't put a developer on securing this, if they haven't been trained
properly in securing this. Because this is not
something very easy to fix. If you have a developer
use a templating engine, make sure they know that
templating engine inside and out, and not just somebody who is
learning things about Google and then throw it into production. That doesn't work. - The more you talk the more, I think, man, I need to learn more about this. Do you have a course or something that someone can access or how do they, how could they learn more about this? - Definitely. On Udemy, I have a complete course explaining all of these
different attack types with several different contexts as well. It's a cross-site scripting course. Introduction to cross-site scripting. Called introduction, because there's so many
things you can learn. But when you finish that course, you'll be proficient in hunting cross-site
scripting in the passive way and in the active way. There's many different ways you can test for cross-site scripting. But I just like to keep
it to passive lazy way. Not finding as much, an active, much more involved way, but being able to cover much less ground, still finding more. - That's great. I'll put a link below. So if anyone's interested
in getting that course, they can purchase it below. What else did you wanna show us? - So you were talking about DOM cross-site scripting as well. For Dom cross-site scripting, this one is more easy. Well, I say easier, but it's basically, it's just one lab. That's what I have on it right now. I'm expanding these. But for this lab, you can see that I a selection right here. A select source of different
things that I can do. But I also have a script in here. And this is my Google script. So if I go look for script, (keyboard clanking) here it is. And this script, as you can see uses the documents.write. Basically what I'm doing is, I'm taking and this is a very simple explanation. I'm taking a part of the URL where I say, default equals and than I'm taking that item and I'm inserting it on to my page. So I just have to read
this JavaScript carefully and than I can say, for example, default equals 1. You could see that, that
is reflected in here. So it all comes down
to source code review. Now, this is a super simple website. Not a lot of things on here at all. If you're dealing with a a real website, JavaScript is a goldmine. That's what I want to give to everybody that read to the JavaScript code. There are so many good things in here. And if you know what to look for, like the DOM sinks. This is an example, document.write, you can insert DOM cross-site scripting into these different, img source equals x. So as you can see, it's kinda breaking my code already. And you can insert a lot of attack factors into the document object model as well. And start from there. Your normal source based
cross-site scripting, which is very literally
just displayed code into the source code or I can enter document object
model through a DOM sink. And than spit it back out
as a DOM source in here and that I could still have
cross-site scripting possible. DOM cross-site scripting is one of the hardest types
of cross-site scripting to look for. It's something that I would recommend you use a scanner to look for this. Scanners are very efficient in picking up this type of cross-site scripting, that humans are not. We literally have to look
for a of the DOM sinks, PortSwigger has a excellent
article about this. You can see here, document.write. That's the one that I've been using. You also have documrnt.writeln, document.domain, innerHTLM, outerHTML and these are just
the JavaScript DOM sinks. If you talk about jQuery, jQuery, by the way, for you guys who doesn't know this, it's also JavaScript but
it can do a lot more. It's basically like an
extension of JavaScript. It has lot more DOM sinks even. So you can that all of these
DOM sinks have the potential to lead to DOM based cross-site scripting. - Just from a opportunity point of view, most websites use JavaScript these days. Is that right? - Yeah. And even jQuery or Ajax or like TypeScript. Those are all types of
JavaScript, by the way. I know I'm over simplifying this for the more technical viewers, but these are all
extensions on JavaScripts. For example, with Ajax
I can do live updates, like if I have an auction for example, and I'm on the website I don't wanna have to refresh my website to see if there is a new bid. - Yeah. - So I can use Ajax to
see if there is a new bid and if there is, I can update my website. And so that's also a version of JavaScript and jQuery is known to
have a few DOM sinks that are vulnerable to
DOM cross-site scripting. - So in other words, someone
who wants to do bug bounty or someone who just wants
to get into this and learn. There is a lot of opportunities because you can test almost any websites. Because it's used all over the place. And the concern is, like you said, developers who do code don't necessarily understand
the security implications of what they are doing. Right. - Yeah. And even if they do. Even if they fully understand it, even if they are able to filter every single input field, they might forget one. It only takes one
parameter to be vulnerable. My very first cross-site scripting I found for bug bounties was hidden in a very part of the website and I was like, you had a website, you could create a system on that system you could put benchmarks and in the benchmarks you had a table, which was vulnerable to
cross-site scripting. So to come across these
things is not easy. But as a bug bounty
hunter and a pen tester, it comes down to testing
all of the parameters. - It's always nice to learn from someone who's walked the road. So you have courses on Udemy, that people can buy. I'll put links below. But you also do live training. Is that right? - Exactly. I do boot camps as well. And also for cross-site
scripting I've one and two days, we'll go over all of this stuff and we'll teach you how to hunt for these, including filters, like
there is one filter where you've to enter an email address and only email address is accepted, well guess what, you can still enter
cross-site scripting there. - Okay. That's great. So I mean someone could like register for your two day course. I'll put a link below as well. If they are interested in live training. I know you charge very low prices compared to some places. So, I just want to say this, Wesley, since I've got to know him, is someone who really tries
to help the community. And often he helps too much. Cause he just wants to help people. So please support him. Buy his course below or go to his boot camps. He's really trying to help the community with what he's doing. Wesley, one concern I have is, I don't wanna go to your website now. Should I use a virtual machine or something like not my normal computer to go to this website that you've got all these demos on? - No, it's not a problem at all. You can rest easy, there is no cryptocurrency
miners on there. (David laughs) I'm not gonna infect you with a bug and the thing is, if you visit the website, cross-site scripting is
limited to that website only. So I'm not gonna be able to execute code on different website or anything. And specially do reflected
cross-site scripting. There is worries there, you can rest easy. - I'm not sure if I trust you. No I'm kidding. Well that's great. - Bugs but verified,
that's what I always say. - Exactly. Just for everyone who's watching I'll put Wesley's social
media links below. He's big on twitter. He has quiet a big social
presence these days. Wesley, I really wanna thank you. I'm I should call you XSS Rat, but it's for me to say Wesley. But I really wanna thank you for sharing this knowledge with us and sharing with the community. - I really wanna thank
you for having me on and if anybody is interested in doing cutting edge research these client sites templating engines that I've talked about. They are very under researched. So that's a great area. We need a lot more people looking into. Thank you very much. Really appreciate it. - Wesley, it's a pleasure, thanks. (upbeat music)
