start	end	text
0	5920	I have no idea what time this will be played, but thanks for coming to my virtual talk for
5920	11300	this edition of DEF CON SAFE MODE, and I figured a great way to start it off,
11300	16160	since this is technically my first DEF CON talk, would be to take a shot.
16160	20800	So we've got some 1712 bourbon, so let's get it started.
20800	22180	Don't fuck it up!
23900	28680	So, other than that, this is normally where I try and get some
29360	33660	crowd engagement in the talk. So, whenever you're watching this,
33660	37780	and I will hopefully be in the Discord at least during the talk, if not around the same time,
38240	44100	let me know if you are aware of XSS or if you're not. Hopefully most of you are,
44100	47580	with this being the Red Team Village, but for those of you that aren't,
47580	50900	hopefully you'll at least learn a little bit about cross-site scripting,
50900	55680	as well as sort of why it's more of a severe attack than you may initially realize.
57140	63400	So, I realized that I need to move this webcam out of the way. Let's try the top right corner.
65880	70020	So, I'm Ray Doyle. You can find me on Twitter, at DoylerSec,
71480	77640	or my blog, Doyler.net. I'm currently a Senior Staff Adversarial Engineer at Avalara.
77640	82520	We're a tax, software, and compliance company. We're always hiring, but not necessarily for
82520	85060	security, so definitely reach out to me if you're looking for work.
85660	91400	I love CTFs. I've actually been on two DEF CON Black Badge winning CTF teams,
91400	97120	for the Wireless CTF, as well as the IoT CTF. I love them, if you want to talk CTFs,
97120	102040	as well as being a member of Team Eversec, who actually runs some CTFs, mostly in North
102040	108140	Carolina-based conferences, but a few other regional ones. So, definitely reach out to
108140	113400	me about conferences or CTFs, things like that. And I also love collecting certifications.
113400	118900	I got my OSCE last year, my OSCP a few years back. I'm always looking for new ideas for
118900	122460	certs to take or training, so definitely let me know if you're aware of any.
124380	130140	And also, if you couldn't tell from the Avalara orange on the slides and the last one, clearly
130140	135340	it's our company color. I figured I might as well go with the theme. So, a few caveats before we
135340	142160	get into this. I'm not an expert in cross-site scripting, I'm not a bug bounty hunter,
142160	147380	I'm definitely not a JavaScript expert, but I am a penetration tester who has used cross-site
147380	151240	scripting in the past, so hopefully I'll be able to at least teach you a few tricks.
151600	157920	This is going to be a very example-heavy and focused talk, so definitely feel free to go
157920	163440	back over the slides, re-watch the videos. I'm going to include a lot of links in the
163440	170260	presenter-slash-comments section of each slide, so if I don't post them soon enough,
170260	173500	reach out to me on Twitter and I'll get you a copy sooner rather than later.
173780	176600	It's definitely going to be a lot to digest.
177520	181800	Like I said before, I don't participate in bug bounties, but some of these payloads should help
181800	186840	you to demonstrate the severity of the vulnerabilities you find and maybe get them
186840	192060	increased to a P1 or something like that. A lot of this information is going to be from
192060	196280	my personal blog. I've already used a lot of these exploits and payloads before,
196280	200060	so I will include links to that to a little more in-depth post as well as some
200060	205340	more screenshots and things like that. I'm going to cover a ton of information,
205340	210920	so please feel free to ask questions afterwards, before, or on Twitter at any point.
211340	216120	And I'm not going to cover really how to find cross-site scripting or what really protects
216120	221480	against it, so this is really going to be heavily focused on exploiting it once you've found it.
222440	229780	Also, another caveat, this is obviously a COVID recording of a presentation that
229780	234020	won't be given live, so any technical issues I apologize for, I'm going to do my best.
234020	240940	We'll see how it goes. So, I know that this isn't live, but definitely feel free to use
240940	246060	the weaponized XSS hashtag on Twitter. I'll definitely be checking it during the conference
246060	250960	as well as any time afterwards. If you want to talk about my technical issues,
250960	254340	if you want to share some really cool payloads with the community, really anything,
254340	260160	just to have some sort of viewer interaction during this weird virtual conference.
261140	266500	So, here's a quick introduction to cross-site scripting. This is from OWASP directly.
266520	272640	I'm not going to just re-read it back to you, but the gist of it is that cross-site scripting
272640	279260	is an injection-based attack in which an attacker is able to
279260	286820	inject usually JavaScript, but can also sort of cover HTML as well as CSS. It's frequently used
286820	293760	for loading malicious scripts and executing them on the target's client-side browser. So,
293760	299260	these aren't going to be attacking your servers as much as the people who are connecting to your
299260	307640	websites, things like that. So, the most basic example of going beyond Alert 1 is Alert 2.
307920	312260	Now, while this is fairly tongue-in-cheek, I do want to quickly point out the fact
312260	317420	that there are going to be systems, and I may move this window from time to time,
317420	324180	I apologize in advance. So, there may be systems that are alerting or filtering for
324180	331740	very specific payloads, and something like Alert 2 could even bypass a
331740	335780	deny list that was protecting against Alert 1, things like that. So, when you're working
335780	340000	on these weaponized payloads, be sure to try different variations or different ways to get
340000	347860	them into these systems. So, the first example I wanted to cover is loading external scripts.
347860	352920	This is the most basic example, but it's fairly important to try and do.
352920	360420	So, anywhere in which you were able to inject that script Alert 1, generally speaking,
360420	365880	you could also load an external JavaScript file. So, in this case, I'm loading doiler.net
365880	372180	slash evil.js. Now, what this allows you to do is have bigger payloads, not worry as much about
372180	377140	things like encoding, stuff like that. So, if at all possible, you should definitely try and go
377140	382920	with an external-based payload instead of keeping it inline if you're able to.
384320	392500	So, another example of this is using staged cross-site scripting. So, if you find yourself
392500	398140	injecting into an already existing script tag, you obviously cannot set the source of it. Or,
398140	403020	if you find yourself in an HTML event handler, you aren't going to be able to load an external
403020	412600	JavaScript file. In this case, what you could do is have inline JavaScript that will create a new
412600	419540	script element inside of the document, then set the source of that script element to be your
419540	425320	external JavaScript payload. So, for this quick example, it's bit.ly slash example.
426160	431180	And this is a payload that was created by someone. I've included a link to the GitHub
431180	436060	in the comments. Definitely check it out. It's come in really handy when I've been stuck in sort
436060	441060	of an HTML event handler, especially. If you are in an existing script tag, you could write longer
441060	445700	JavaScript, but you may run across payload length limits, things of that nature.
448600	458660	So, the most common payload that you'll see or hear of when discussing or attacking using cross-site
458660	466720	scripting is going to be cookie stealing. So, in this example, our XSS payload writes a new image
466720	475480	tag to the document, only this image tag has a cookie parameter that sends the document.cookie
475480	480460	from your local application to the attacker-controlled server. So, in this case,
480460	486080	any cookies we had on our target web application would have been sent to doload.net through the
486080	493040	HTML get parameters. Now, there are things that are going to protect against this, like HTTP-only
493040	497220	cookies, things like that. But if you are able to successfully grab one of these cookies,
497220	502520	you could use it for session hijacking, any existing sessions, and basically logging in as
502520	507380	that user to the application without knowing their credentials. So, definitely keep this one in mind.
507380	513400	This is the one I've used most often in my career, and it's super simple and straightforward to do.
514880	523620	So, another... a different way that XSS injection, or technically any injection, could be used is to
523620	530880	rewrite the HTML of the page. So, the example on the left sort of shows this, but it creates a new
530880	538580	div that takes up 100% of the page, puts it on top, and allows you to write arbitrary HTML into that
538580	546000	div. What that means is you basically get to overwrite the content that your target sees for
546000	553060	an entire website. So, that image on the right looks like a standard Drupal login page, but it's
553060	558400	actually a cross-site scripting vulnerability that was found in a Drupal comments section,
558400	564940	and an attacker used that post to rewrite the HTML of the page to make it look like an access
564940	571780	denied or an authentication page. Sorry about that, my video cut out. But what I was saying was,
571780	578640	if a user were to visit this vulnerable post that contained this malicious HTML, they would
578640	583440	receive this login page, think that their session had become invalidated or they just hadn't logged
583440	587800	in yet, they would enter in their credentials, and then these would be sent off to the attacker
587800	594480	controlled host that this form was pointing to, and then they'd be redirected to maybe the actual
594480	599280	post or something like that. So, using this cross-site scripting vulnerability, an attacker
599280	606260	could be able to basically trick users into entering into HTML forms or really anything.
606600	613240	So, in that same vein, we have cross-site scripting phishing. So, this will be an actual video demo.
613700	617340	I am going to have to talk over it as this video does not have any audio,
617340	620300	so hopefully I'll be able to keep track and let you know what's happening.
621320	629140	So, as we can see, there's a basic search.php web page that has a parameter called queue. So, if we
629140	634040	enter test, for example, it's reflected back to the user. This indicates that there could
634040	639240	potentially be reflected cross-site scripting in this page. So, as you can see, if we put alert1
639240	646400	as our query, it reflects it back to the user. So, in this case, what we could do is we could
646400	654820	create a XSS payload that looks like an authentication pop-up. So, we're creating a
654820	661740	new div that has a sort of a shaded background that has a pop-up window asking for their username
661740	668460	and password and an error saying that there was an error and please log back in. So, if a user
668460	672900	were to see this, they may think that their session is invalidated. Try and log back in.
672900	678140	The creds would be sent to our attacker-controlled server, saved as creds.text,
678140	682420	and then the user would be redirected to the page that they were expecting. In this case,
682420	690300	search.php and queue equals test. So, we would send a link to a user like this with our malicious
690300	695440	JavaScript payload as the query. And I actually need to clear this out because if you noticed
695440	702320	briefly, the phishing page is only set to display once. So, if a user keeps clicking this link
702320	710980	again and again, they won't be confused as to why the password authentication prompt keeps popping
710980	717900	up again and again. So, if an attacker sent this external script to a user in the payload,
717900	721960	they would be prompted with something like this. So, they may re-enter their username and password
721960	726420	to try and get back into the system, get to the actual query that they wanted to see.
727420	731300	Fairly long password, so they think they're secure. They're not going to say this password
731300	736840	end. They're just redirected to your search queries test. But actually, on the attacker side,
736840	742720	we see that... well, this is actually the actual server. So, a post was made to login.php.
742720	748260	And if we check the attackers creds.txt, we see that the user admin logged in with super secret
748260	753780	password 12345 and a bunch of symbols. So, we actually were able to trick the user into typing
753780	758600	in their credentials into a fake login page just because we found a reflected cross-site
758600	771330	scripting vulnerability. Another less common but still usually used for stuff like hacktivism
771330	776330	or things like that is cross-site scripting defacement. This is very similar to the HTML
776330	785230	injection, only the JavaScript file in question I mentioned here is Stallone.js. This is a
785230	791430	fairly old JavaScript file that actually replaces your website content with a picture of Sylvester
791430	797190	Stallone that says you have been Stalloned. It's been used in a few different scenarios,
797190	804110	but I'm actually going to cover a case where this happened in real websites, a couple of them.
804830	809610	Now, it doesn't have to be this Stallone.js. If you find a cross-site scripting vulnerability,
809610	817230	you can deface a website to be whatever you want. So, you can rewrite CNN to show your own news
817230	824090	instead of the news you expect to read. Things like that. So, anytime you would want to rewrite
824090	829130	the content of a website, you are able to if you find one of these cross-site scripting vulnerabilities.
831070	836930	So, here's the actual code from that Stallone.js. I know that this is a lot. I've also included a
836930	841810	link to that .js file and you can google it and find it fairly easily. But, as I said, it
841810	846590	sets some text to this page has been hacked, it loads a picture of Sylvester Stallone,
846590	852430	and similar to that first payload I showed, it overwrites the content of the entire page with a
852430	860360	giant div. So, like I said, back to the history lesson. So, there's actually a book called
860690	866810	XSS Attacks Cross-Site Scripting Exploits and Defense that contained a reference to this
866810	871190	Stallone.js file because it was talking about how cross-site scripting can be used to deface
871190	879370	websites and things like that. Well, unfortunately, on Amazon.com, they were vulnerable
879910	887550	to a stored cross-site scripting via book previews. So, sort of a high barrier for entry
887550	892150	for attackers as you would have to publish a book with a cross-site scripting payload in it. But,
892150	897850	if you're writing an XSS book and you manage to upload one of these malicious payloads,
897850	903830	you were able to actually exploit cross-site scripting on any Amazon.com user that viewed
903830	909670	your book preview. So, for a bit there, Amazon.com, and the example on the right is actually Maruta
910470	916070	Sharapova's website that was also vulnerable. But, for a while, Amazon.com's preview of this book
916070	924790	would just show the Stallone.js instead of the actual book preview. In addition to Amazon.com,
924790	928670	note that this could have been used for things other than defacement. People could have tried
928670	934650	to steal Amazon.com cookies. So, the picture on the left shows the Web Application Hacker's Handbook,
934950	940810	a very common book for web pen testing, payloads, things like that. This had an example of a cookie
940810	947430	stealing payload, alert-document.cookie. This also fired off on Amazon.com. As you can see,
947430	952850	an Amazon cookie is being displayed just because a user is previewing the book. So, these attacks
952850	958150	have occurred in the real world, and users could have been exploited by, technically,
958150	971680	malicious book authors. So, not exactly cross-site scripting-based, but if an attacker is able to
971680	978840	perform a man-in-the-middle attack, and this slide is based on a Black Hat USA talk that was
978840	983080	given a few years back with that man-in-the-middle talk with a disgusting title,
983760	987360	which the first link is for, I highly recommend you checking it out.
987620	995640	But not exactly XSS-related, but I wanted to cover it as it is a similar style of attack. So,
995640	1003140	if a man-in-the-middle attack occurs, a user could arbitrarily rewrite the HTML of a page
1003140	1009340	that their target is viewing. So, in this case, this guy overwrote a target's Facebook.com
1009340	1012900	with a picture of himself and a prompt that says, will you go out with me?
1012900	1020240	That would not be bypassed until the target clicked yes or no. So, not exactly XSS-related,
1020240	1026280	but you're still able to inject HTML or JavaScript into a page that the user is viewing.
1027800	1032920	So, in that same vein, while this is more relevant with actual cross-site scripting
1032920	1038140	and HTML injection, I wanted to cover a sort of a scarier, worst-case scenario.
1038320	1044960	So, if you were able to inject HTML, either via man-in-the-middle or cross-site scripting,
1044960	1049520	into Internet Explorer, now this is not Edge, this is only Internet Explorer,
1049520	1056510	you could inject a file URI to, say, an image to an attacker-controlled server.
1056880	1060780	Now, what this would do is, if it's loaded in IE, it would actually send
1061160	1067420	a UNC request for that images-slash-file.jpg. Now, for those of you that are familiar with
1067420	1075000	Responder, this would actually send a net-ntlm response to this attacker-controlled server
1075000	1080540	after it responded with a challenge. So, an attacker could actually use this XSS or HTML
1080540	1086860	injection to get a net-ntlmn hash for your local or domain user that's currently logged
1086860	1092340	or into that system that the browser is running under. So, just by finding this vulnerability,
1092340	1096680	an attacker could have credentials for either a local machine or your entire domain,
1096680	1101820	assuming that they're able to capture and crack these hashes. So, while it's easier with a
1101820	1107060	man-in-the-middle attack, it is still possible with something like a cross-site scripting attack
1107060	1114830	and Internet Explorer. So, back to another video demo,
1114830	1119270	here I want to cover an example of password stealing using cross-site scripting. So,
1119270	1123890	not phishing like the last one, but actually stealing saved credentials within a browser.
1125450	1135330	So, as you can see, we have a basic login page with a username, a password, and a login button,
1135950	1139530	as well as a prompt at the bottom that says your current language.
1139890	1143810	So, since our very well-developed web application supports multiple languages,
1143810	1148790	we can set our language to EN or SP and it will display at the bottom. It doesn't change the
1148790	1154970	language since I'm not that great of a developer, but it's just for demo purposes. So, as expected,
1154970	1161270	it reflects the query parameter into the page. So, if we put alert 1, it shows that this page
1161270	1166290	is vulnerable to cross-site scripting. So, let's say our admin user had actually logged into this
1166290	1172270	application. They're going to save their password because they don't want to have to remember that
1172270	1177290	pretty secure password. It takes a lot of work. So, when they log in, they're redirected to a
1177290	1182210	comments page. And when they go back to the login page, their credentials are obviously saved.
1182210	1188250	So, nice and convenient. Nothing too scary since we haven't phished their credentials.
1188250	1192370	Instead, what we can do is we can create a second body tag, which this will still work
1192370	1198090	in most browsers, but is not technically valid HTML. And in this second body tag,
1198090	1204070	we will call the steel creds method that we write that will create a new form with the
1204070	1211010	password or the username and password fields with the same ID and name as the existing fields,
1211530	1218110	make it invisible, and then set this username and password to be the values from the previously
1218110	1224230	saved or entered username and password. Once it grabs those, it sends them in a get request to
1224230	1229170	our attacker-controlled server, and the user is none the wiser that just because they saved their
1229170	1235950	credentials in a login page, we were able to grab them. Now, note that this payload does require
1235950	1240670	cross-site scripting on the login page. It won't work if there was a cross-site scripting
1240670	1248850	vulnerability, say, in that comments page. So, we convert this to URL encoding just to make
1248850	1256310	our lives a bit easier, and we send this to our target in the language parameter.
1257330	1261050	So, as we can see, nothing happened. Their credentials are still saved. User is none the
1261050	1266910	wiser. But on our attacker-controlled server, we actually get a get request for the username,
1266910	1274430	admin, and that same and b-size password. And if we take a look at the HTML of this new page,
1274430	1281350	our original form is there, as well as our second body tag with that steal creds method.
1281870	1287250	And we see an error that is not valid HTML, like I said. But just because a user saved their
1287250	1294210	credentials on a vulnerable login page, we were actually able to steal them with this
1294210	1305230	cross-site scripting payload. So, again, I know this is very demo and example heavy.
1305230	1309630	Please feel free to reach out to me for these slides or go back over everything.
1312120	1320440	So, another example that is particularly useful on login pages, that's where I've used it most
1320440	1325580	myself, but really anywhere that you might want a keylogger is a cross-site scripting keylogger.
1325580	1333680	So, the top picture shows our JavaScript payload. But what it does is every time any key is pressed,
1333680	1340500	it creates a new event handler that will send an XML HTTP request to our attacker-controlled server
1340500	1348240	with a post data of whatever key was pressed. And if we take a look at our keylog.php file
1348240	1354900	in the bottom left corner, we see that if there is post data, it will open the file data.txt and
1354900	1361020	append whatever was in that post data. So, every time a user hits a key on a page after loading
1361020	1367300	this malicious JavaScript file, the attacker will get their keystrokes. So, in the bottom right,
1367300	1373300	we see that they enter pentest as their name in the stored cross-site scripting vulnerability
1373300	1379500	page. And in our data.txt on the attacker-controlled server, we got all of those keystrokes back.
1380200	1383660	So, obviously on a login page, this would be great because you could grab their username
1383660	1388520	and password without them having saved it. But really anywhere where you might want to obtain
1389720	1393680	a user's keystrokes, so if they're entering credit card information, even just stuff like
1393680	1400080	addresses or other PII, this would be a useful payload for a malicious attacker to use.
1403680	1411240	So, another thing that you could do with a cross-site scripting payload is steal sensitive
1411240	1417140	information. And again, I know that there's a ton of code on this page, but what this does is
1417140	1423880	sends a POST request to the attacker-controlled server containing all of the source code from
1423880	1432140	the application. So, say you find a cross-site scripting vulnerability in a sensitive page,
1432140	1439060	so maybe an administrative console, banking application, password manager,
1439060	1444840	or really any sort of private pages that you want to see someone else's content. You could use the
1444840	1449160	code on the left to grab the source code, or the example on the right to grab a screenshot of the
1449160	1454900	page, and you send that off to your attacker-controlled server. So, maybe you want to,
1454900	1460100	if you find a cross-site scripting vulnerability in your bank, if you were to target someone with
1460240	1465720	a payload, you could maybe see their bank account number, their balances, things like that, as well
1465720	1471200	as maybe admin settings on a firewall or router, things like that. So, if there's sensitive
1471200	1476960	information on an application that stealing would be valuable, this is another use for a
1476960	1488050	cross-site scripting payload. So, a really fun cross-site scripting payload use that I have done
1488050	1493770	personally quite a fair bit is defeating CSERV. So, if you're not familiar with what CSERV is, I'm just
1493770	1499850	going to briefly cover it. It's cross-site request forgery. At its core, it's sending a request from
1499850	1507130	Site A to Site B. So, a very common example would be if Amazon was vulnerable to CSERV,
1507130	1514830	if a user visited my malicious website while they had an Amazon session still active, my malicious
1514830	1519650	website could send a request to Amazon that would make them purchase an item and ship it to me, for
1519650	1525530	an example. Now, Amazon is not vulnerable to CSERV, so this attack isn't valid, but that's just a
1525530	1531850	common example of it. Now, there are CSERV protections like tokens or nonces, things like that, that
1531850	1538450	are an ideally unique value on every form that prevents an attacker from sending these malicious
1538450	1544590	requests to a different server. Now, a cross-site scripting vulnerability, since it can read the HTML
1544590	1551270	of a page, the payload could read the HTML of your page, grab that CSERV token, and then use that
1551270	1559790	to send your malicious CSERV request. So, a very simple read body looks for a CSERV token parameter,
1559790	1567070	gets it, and returns it to a different method. So, this is an example that I got to use
1567070	1570630	in a real engagement in which there was a reflected cross-site scripting vulnerability
1571190	1576750	that I used to grab a CSERV token and then actually exploit a stored cross-site scripting vulnerability.
1577950	1583230	So, as you can see, we have a very similar login page to all those other examples I've shown.
1583450	1589750	Not the most beautiful page. Our search page that reflects back the kube parameter, as well as on
1589750	1596110	an authenticated comment section. So, we want to be able to put our stored cross-site
1596110	1602790	scripting payload into that comment section as an authenticated user. So, when someone logs in
1602790	1606730	under their admin account, they're able to see the comment section of the application, as you can see.
1608330	1615850	So, the search.php is unauthenticated and vulnerable to a reflected cross-site
1615850	1621710	scripting attack. So, as we can see, if we enter a test, it shows test again. If we test for cross-site
1621710	1627350	scripting with alert1, we will get our pop-up and confirm that we have pre-authentication
1627350	1634610	reflected cross-site scripting. So, what we can do is we can use a payload similar to
1635250	1640070	this one. And I know it's quite long. I'm going to share it, as well as give a link to it. But
1640910	1644710	what... or actually, no, sorry, this is the comment section that shows you have to be authenticated.
1644710	1653110	And it uses a SHA-256 hash of the session, salted with the very secret password, to create a CSERF
1653110	1658750	token for the comment section. So, our developer secured their application. The comment section
1658750	1664590	is not vulnerable to cross-site request forgery. We should be good. Unfortunately, since we have
1664590	1670490	that reflected cross-site scripting payload on the search page, we can use that to grab this
1670490	1679210	very secure-looking value for that CSERF token. So, as we see, if we post test, test,
1679210	1687220	it works fine since we're authenticated and we had the CSERF token. So, what we can do next is
1687780	1693380	use the reflected cross-site scripting vulnerability to grab that CSERF token,
1693380	1698680	use that CSERF token to send a POST request to the comment section, and then put error payload
1698680	1707930	on that page. So, that top read body method looks just like the one I showed a few slides ago.
1708270	1714190	Grabs that CSERF token from the body of our target page and returns it to a different method
1714190	1722890	that we want to use it for. And I apologize if some of the audio is slightly off of these videos.
1722890	1727590	As I said, I recorded these videos a while ago and was not able to keep the audio with them.
1729670	1735370	So, once we get this CSERF token... well, first, we have to send... first, this payload will send
1735510	1741130	a GET request for the comment section. So, the authenticated user will send back the comments
1742010	1747170	page, then we'll grab the CSERF token, and then we will use that in our POST request.
1765860	1770980	So, yeah, sorry about that. I did not quite plan the audio right on this one and the screen
1770980	1775900	capture took a little too long, but I will share this code. It is going to be a lot easier for me
1775900	1780520	to share it than talking over it line by line as I originally planned to do. But,
1780520	1785160	once we have this CSERF token... I'm not able to skip, unfortunately.
1793020	1798300	Okay, so, now that we're done looking over that exploit.js file,
1798300	1804980	once we load that externally into this search.php page, which is what I'm doing now,
1805560	1812400	the user will not see the requests in the background, but we're actually able to
1812400	1817360	post to the comment section as that user now. So, if we refresh this comments.php page,
1817360	1823940	we actually see a stored cross-site scripting payload of alert1 written by CSERFTest, which
1823940	1830100	was what that payload does that I was showing before. So, if we quickly search for CSERFTest,
1830100	1836100	as we see, their comment was scriptalert1. And now we upgraded from our slightly less
1836100	1842160	severe reflected cross-site scripting payload to a more severe stored cross-site scripting payload.
1843240	1849460	So, as you can see, it sent a POST request with the name of the comment and the CSERF token.
1849660	1853620	Now, I just want to briefly touch on the difference between reflected and stored
1853620	1859160	cross-site scripting. At its core, reflected cross-site scripting is usually going to require
1859160	1864660	some sort of malicious link or something of that nature that you send to your specific targets,
1864660	1870080	and they're going to need to click it. So, not quite as severe, requires some user interaction
1870080	1875120	usually, stuff like that. Now, stored cross-site scripting is like what we saw in that comment
1875120	1881500	section. So, our cross-site scripting payload will now execute on any user that goes to that
1881500	1889360	comments.php page. So, it's more persistent. It targets more users, and it basically lasts
1889360	1893440	for more than... and it requires zero user interaction outside of them visiting our
1894220	1906570	vulnerable pages. So, in addition to generic payloads, you can also use cross-site scripting
1906570	1913310	attacks for application-specific payloads. So, this one is a quick example of the
1913310	1919490	damVulnerableWebApp using cross-site scripting to sign the guestbook under a different user.
1919490	1925790	So, a similar idea to the Csurf cross-site scripting example from a previous application,
1925790	1931390	but this can be done... anything that a user could do within your application,
1931390	1936970	an attacker could do if they found a cross-site scripting vulnerability. So, for instance,
1936970	1941930	changing your wireless password. If an attacker found a cross-site scripting vulnerability in
1941930	1947030	your router firmware, they can use that to change your WPA passphrase. Things like that.
1949570	1957310	So, this is a great repository from HackLuke, but it contains a number of application-specific
1957310	1962450	payloads. As you can see, there's a Drupal one, MyBulletinBoard, and a few for WordPress.
1962650	1969550	So, if you are able to find cross-site scripting in a WordPress post or a WordPress plugin,
1969550	1974890	you could do something like send a malicious cross-site scripting payload to an
1974890	1980950	administrative user and use that payload to add a new user into the WordPress application.
1981890	1987910	And there's a great blog by TrustedSec about weaponizing XSS in this manner that goes
1987910	1993270	through all the steps they would use to create the new user, grab any WordPress-specific
1993270	1999270	things like that. And the second link, for those of you not familiar with WordPress,
1999270	2004390	is a list of all of the CVEs that have been found in the past. While I personally love WordPress,
2004390	2010950	it has been known to be vulnerable in the past, especially the plugins that people use.
2010950	2018590	So, this is not an uncommon attack vector. One thing I do want to note is if a user is able to
2018590	2023090	exploit a cross-site scripting vulnerability and create a new user,
2023090	2029350	if that user has high enough privileges, they could then use that to privilege escalate even
2029350	2036750	one more step to a system-level shell. Because WordPress posts contain PHP, if you want,
2036750	2041150	so they could write a PHP command shell, use that to escalate to a system-level shell,
2041150	2047030	and now they turned a potentially reflected cross-site scripting vulnerability into a shell
2047030	2059820	access on your web server. A very common framework when talking about cross-site scripting, and one
2059820	2065980	that I at least wanted to touch on a little bit, is BEEF, the Browser Exploitation Framework.
2065980	2074820	This is a cross-site scripting framework of payloads and exploits. It's an open-source
2074820	2079640	piece of software designed for penetration testers to exploit browser-based vulnerabilities.
2080360	2087880	So, BEEF can be used to effectively have a botnet of browsers that you can control and monitor
2087880	2094940	in the top left image. You're able to execute any JavaScript on these client-side devices, so
2094940	2101800	the middle image shows grabbing the IP of the host that you've hit with your exploit. Any browser
2101800	2108080	information, so the bottom left shows what is enabled, what's installed, any user agents, window
2108080	2114640	sizes, things like that. So, effectively any HTML or JavaScript that could have been executed by
2114640	2123400	this web browser could be executed by BEEF on the back end. Now, the most value I've found from BEEF
2123400	2131280	is actually upgrading from a browser-based exploit to a system-level exploit. So, there's over 500
2131280	2136560	Metasploit modules, so if a user is running an old or an out-of-date browser, you could just
2136560	2147560	use BEEF to exploit a Metasploit payload and escalate to a reverse shell from that user,
2147560	2152740	for example. So, here's a bunch of Firefox examples, but there's a ton in BEEF and it's great for
2153460	2156620	escalating from cross-site scripting to command access.
2158100	2161940	As I said, there's a ton of payloads. I'm not going to cover them all.
2161940	2168400	Here's a few examples. Note that anything BEEF can do, you could also do with your own cross-site
2168400	2173600	scripting payloads if you wanted to be a little quieter or learn JavaScript or just get a more
2173600	2178800	controlled feel for it. That said, it does make your life a lot easier as it's just a matter of
2178800	2185040	right-clicking the browser and then clicking on Keylogger. Stuff like that. But as I said,
2185160	2191200	a ton of awesome payloads. I highly recommend you at least check it out. It is going to be
2191200	2196020	for if you find cross-site scripting during your penetration tests, things like that,
2196020	2204200	to quickly exploit it as opposed to needing to weaponize it for bug bounties, things like that.
2204380	2211000	That said, if you can load any external .js file, you could load a BEEF hook and get all of this
2211520	2218440	quickly and easily. So, I briefly want to touch on blind cross-site scripting,
2218440	2224760	mention what it is, and include a few references. It is easily a topic that could be at least one
2224760	2232080	talk on its own. But at its core, blind cross-site scripting is the cross-site scripting JavaScript
2232080	2239120	script payload executes somewhere that you cannot see it, hence the name blind. So, for example,
2239120	2245940	if a login page was vulnerable to cross-site scripting but only administrative users could
2245940	2254300	see your payload, or if it was on a web forum that you didn't have access to, maybe an administrative
2254300	2261560	panel has logs, a chat application that's different for the help desk technician than it is for the
2261560	2267460	end user, firewall logs that you never get to see as an attacker but that execute malicious
2267460	2273660	JavaScript payloads, things like that. So, testing for blind cross-site scripting requires a bit more
2273660	2280140	work as you are going to not be able to quickly test it easily and see the results in your browser.
2280160	2285000	I highly recommend checking out stuff like XSS Hunter or Sleepy Puppy from Netflix. These are
2285000	2289600	really fun tools for finding blind cross-site scripting and especially for your bug bounty
2289600	2294480	hunters. These are going to be vulnerabilities that aren't going to be found right away, especially by
2294480	2301140	tools like Burp or things like that. So, I highly recommend taking a look at blind XSS, learning
2301140	2306360	what it is, and trying to find it, potentially during your engagements, but especially during
2306360	2317010	stuff like bug bounty hunting and things of that nature. So, now that I've covered a ton
2317010	2320730	of different payloads, let's take a quick trip down memory lane for some