Weaponized XSS - Moving Beyond Alert(1)

this again is my talk uh weaponized xss moving beyond alert one so as uh they mentioned i'm ray doyle um you can find me on twitter at doilersec or my blog um www.doiler.net i work at i'm a staff adversarial engineer at avalara they're a tax company so tax compliance sales tax things like that um basically the team lead of a newly forming pen test and red team i'm competing in a ton of ctfs and ran a bunch been on two defcon black badge teams and one derby con um if you want to get into ctfs please feel free to reach out to me on discord or twitter i'd love to talk to you about them i

also collect certs i've got a ton of them and i'm just trying to get into mobile gaming and content creation since quarantine has us all inside more than we'd like so a few caveats before i begin i'm definitely no expert in crosstalk scripting or javascript in general uh i'm a pen tester and a red teamer by trade so i am familiar with it but there are probably those of you out there who know more than me um but i'll do my best to try and teach you what i know and explain why crosstalk scripting is scarier than some people may realize in that same vein this is going to be a very example heavy presentation

so the slides will be available eventually if not ping me on discord or twitter or anywhere and i'll get them to you sooner um there will be a lot of code there will be videos i'll get them to you as fast as possible if you want them i also don't participate in bug bounties but i do know that some of them will want you to sort of prove the severity to get that higher bounty get the get your um finding to count so some for those of you that do this should hopefully help with that um and yeah i'm not really going to cover cross-site scripting that much as a an introduction or protections i'll touch on them briefly

but this is mostly like i said how to weaponize it how to go from that alert one pop-up to something that a real attacker might use so in that vein before we jump into it um respond on discord twitter raise your hand in your room who out there is familiar with prostate scripting and sort of has seen it knows what the vulnerability is so i can't really see from this distance but hopefully at least a few of you um so for those of you who are familiar with it hopefully i can give you a few more tricks to use either for your bug brownie huntings or maybe even a real engagement and for those of you who

didn't raise your hand um especially for the developers the defenders things like that hopefully i can give you a better idea of why some pen testers or sites may say cross-site scripting is medium or even high severity so in that same vein during the talk if you want a live tweet during it please use the weaponized xss hashtag if you want to talk about my covid mullet if i make a mistake during the talk or if you just enjoy it please reach out to me i love having the interaction so a brief introduction to crosstalk scripting this is from owasp directly i'm not going to read all of it but at its core cross-site scripting is

injecting javascript into an application in an unexpected manner that renders it on the client side so this will usually almost always be used for client-side attacks so an attacker is targeting a user of your web application so the most basic example of going beyond alert one alert two now while this is a tongue-in-cheek joke i do want to point out that a lot of our defenses against prostate scripting do come from sort of the the deny or the block list format so i've personally seen cases where i reported to a developer that you know my payload was alert one so they fixed it by blocking alert one well technically they fixed my finding but since they didn't quite understand

the severity of what else i could do alert two would have still worked as well as all of these examples probably so the first example i want to show and sort of one that will encompass everything in this talk is loading external scripts if and actually on that quick note i don't i'm not really going to cover bypassing filters or things of that nature um all of these examples will assume that you can put whatever you want wherever you're loading this crosstalk scripting um wax allowed nylas things like that are good defenses and layering them is even better um i want to just show what you can do in a perfect world as an attacker

so in that vein anywhere you that you can put inline javascript like that second bullet like alert one you can almost always load an external script so in this it's just loading through.evil.js as an attacker if possible it's usually better to go with an external script you don't have to worry about weird characters in your url if it's a reflect across a scripting attack you don't have to worry about length things like that so for all of these examples they're mostly interchangeable um some of them i will show an inline script some will be external but for the most part try to load an external script if possible so in that same vein uh the second example i want to cover is

staging your crosstalk scripting so this payload will be great if you find yourself injecting into a existing script tag so for those of you who don't know if you're already inside of a script tag you can't set a source attribute so you're no longer allowed to load that external javascript i mentioned in the last slide so you have to just sort of build your javascript inline you could run into problems with weird um characters in the url things like that alternatively this is useful for if you find yourself injecting into an html event handler where also you're not going to be allowed to load an external javascript but you can use inline javascript so what this will do is it builds a

function c which calls the function a that's defined in your external payload and then creates a new script tag inside of the dom sets the source now to your malicious payload which and this is just bitly example and then once the new variable you created is ready it appends it to the document we'll call your a function and now your external malicious payload can be executed so the most basic example of weaponized crosstalk scripting and the one that you'll see the most often is going to be cookie stealing so if you have a injection payload point and you put something like this it would add an image tag to the document with a you know grab.ping which does not

have to exist on the attacker's site and it will set the url parameter of cookie to your current document.cookie now what that will do is if a user were to end up on a page that had this payload their personal cookie would be sent in a get request to the attacker's server now things like http only will protect against this things like that but if there are no defenses in place the attacker now has your current valid session cookie and can use that to basically hijack your session and log in as you without having to know your username or password this is going to be sort of the the easiest way you're going to be able to

demonstrate severity or even use it in a a real attack scenario i've stolen cookies from users using cross-site scripting and been able to log in as them another fairly severe example that is relatively common is using it for full-on html injection so on the right side of the screen it looks like a standard drupal login page um and actually i couldn't get the presenter mode to show up but there are a lot of references and links to some of these um pictures and demos i'm going to show they will be provided with the slides if you want to go and read longer blog posts and things like that but so back to that the picture on the

right looks like a standard drupal login page but it's actually a drupal post if you look at the url that someone used cross-site scripting to rewrite the entire html of the document to look like an access denied login page so a standard user may see this page see that they are not authorized attempt to log in with their username and password unbeknownst to them that username and password be first sent to the attacker controlled server and then they would be logged into the site that they're expecting so now the attacker has their username password and to the user it looks like everything was just fine so the example on the left is what the javascript might look like

it would you can create a new div you can make it the full size of the screen and then you can add any html to that div and build a new login page so if you're attacking a bank um maybe you you know change their login page grab some credentials things like that alternatively you could just change the content of the website not necessarily to sort of steal things i'll have a few more examples later but i'm sure you can think of examples where if you were able to change the content of cnn.com and send it to someone else it could have huge effects so i decided to not go with any live demos because we're already using go to

meeting i'm using hotel internet i don't want to risk the demo god's anger too much so i do have a few video demos i'll talk over and hopefully they'll give a lot of example of these attacks so the first one i want to cover is phishing using cross-site scripting so in this example we have a basic page that just returns our search query we may see a lot of applications so if we type the word test it says our queries test so if we attempt to check it for cross-site scripting if we met our crea query alert one it pops the alert and i apologize for this small font but we can zoom in this is

the script that we want to build is an html block that builds a form with post that will post to our attacker controlled server with the username and the password and again these slides will be available and at the bottom it just sets a cookie that will only fire this awful box then on our attacker controlled server we take all of the post requests we receive with a username and password and put them inside of a credits.txt and then redirect the user back to the query page so what that will actually look like it is

oh i apparently need to so this even this demo i angered the gods so i actually have to clear that cookie because it'll only fire off once but in the meantime basically the idea behind this attack is to show a user a pop-up that looks like their maybe their session has expired and they need to re-log in but in actuality it's just an attacker controlled script that makes it look like it so a user sees this an error has occurred please log in again um they don't know why they type in their username and password again um submit that just to get access back to their application they don't save their password and they're back to where there were their

query was test everything seems fine but on our attacker controlled server we see a post to the login.php page and if we actually take a look at the credits.txt file we got their username of adwin and their password of super secret password one two three four five because to the user it looked like they just needed to relog into the application but it was actually the in the same vein of injecting malicious html into the page using that cross-site scripting vulnerability

so in that same vein less useful for an attacker but more useful for people internet trolls people who are trying to you know activists things of that nature you can just deface a page entirely with your with a cross-site scripting attack so maybe you know i'm sure you've seen pages you know this has been owned by uh the cyber um crash override so what you can do in the same vein you learn your load your external javascript and it will change html the page to your message or whatnot a very common example of this is the stallone.js which has been on a lot of fairly famous websites um i've got the defacement code here again

you can find it there'll be links to it in the slides but what it does is it sets a background image it adds some text that the page has been hacked um adds a little more text and nothing too major but basically it's very clear that some sort of malicious activity has occurred on the website well this has actually occurred um so the first history lesson i want to go over there's a book called xss attacks cross-site scripting exploits and defense so this book has a link on an example on the right side where maria sharapova's website scripting vulnerability in which someone loaded that previous stallone dot js file and it looks like the page looks like the

image in the bottom right so that's the actual payload on mariassherifova.com well when this book was sold on amazon.com that same crosstalk scripting payload executed so it's a little harder to see but that image on the top right is an amazon.com url preview for that book in which that the facebook javascript payload executed and if you try to read the book on amazon.com all you would see is you got stallone in that same vein the web application hackers handbook also had a crosstalk scripting payload demonstrating grabbing session cookies also fired on amazon.com so imagine if instead of alert one people wanted to use malicious payloads on purpose they could have attacked every single user of amazon looking at these books

so while not directly a cross-site scripting attack i did want to cover an attack in the same vein that can utilize some cross-site scripting elements um and there's a great presentation on this from black cat 12 it's that man in the middle talk with that disgusting title but at the core of it is it performs a man-in-the-middle attack to inject html and javascript so this isn't necessarily always exploiting cross-site scripting attacks although you could utilize it with that but it's overwriting pages similar to what it looks like on the right so in this talk someone goes to facebook.com but is displayed a photo of the this guy with a yes or no button before they can get to the main

page while man in the middle html injection isn't necessarily a cross-site scripting issue a lot of these attacks could be used in that same manner so i did want to touch on it briefly um and one more slide on that same idea if using man in the middle attacks or cross-site scripting html injection you are able to inject an image tag and the user is using internet explorer and i don't mean edge i mean internet explorer itself if you use the file uri handler it will send a request to the server try and grab this file but internet explorer sees this as a unc path so for those of you who are more familiar with

penetration testing and things like that if the attacker server is listening for this it can send a response and actually grab the local users net ntlm hash from their system and then have access to at least their local system if not their entire network um it's a very scary attack that i covered more in depth in another talk as well as some blog posts but at the core of it just by by injecting html or via crosstalk scripting or a man-of-the-middle attack someone could get your username and password for your computer not just that specific web application so let's do another demo this one is actually stealing passwords so we're not going to trick a user into typing their username

and password we're actually going to steal passwords that they already have so in this example we have a basic login page with my my beautiful css skills so on this login page at the very bottom it's a little harder to see but there's a text that says your current language is blank as it turns out so we can change our language this website supports multiple languages like en and sp um but it looks like it's reflecting this value straight to the page so if we try alert one as our language the pop-up occurs and we we know that this is vulnerable to cross-site scripting well we're not too worried about that right now we'll log into the web

application as our admin user and i will type the password correctly so we're going to save our password it's a complicated password we don't want to worry about remembering it later so next time we go to our login page it automatically populates because we saved it in firefox awesome so what we can do as an attacker we could build a cross-site scripting payload that will build a second form with a username and a password field and it will populate those values using the existing username and password field so since firefox automatically populated those first two fields for us as an attacker we can grab those two populate our malicious form and then send it off to our sorry

it can grab those two values from firefox populating those forms and then send them off in a get request to our attacker control server so as you see it grabs it sets the username equal to getdocument.getelementbyid the pass to getelementid password and then creates a new image which will just send a get request to that attacker controlled server it's an easy way to send that get request um whether or not the image exists does not matter so i convert that page i url encode that page that malicious payload to make my life easier um and then if we set the language to that malicious payload so maybe we send this to an admin user in

an email it looks just fine but on our attacker controlled server we actually get a post request or a get request containing those stored admin and password values and if we scroll down on the page that they're at we'll see our newly created body tag which is technically not valid html but will work in a lot of browsers that calls that steel creds method for us and sends it off to our attacker and if we see we stored those passwords for the admin user for that localhost 8123 page

so and again i know this is a lot of payloads i will share these payloads and slides but hopefully you can use at least one of these in a real life attack or just demonstrating the severity of this formidability so another one that i haven't seen that often personally um and i think i've only used in demonstrations is you can actually build a cross-site scripting key logger so imagine in that last example if instead of we if the admin hadn't saved his credentials what if we sent him a link to the login page containing a keylogger then when he typed in his username and his password it would be sent to our attacker controlled server

so the very top image shows the malicious javascript that we would uncheck every time a key is pressed it grabs the event it grabs the character code for that key and it sends a new creates a new post request sending that key as a parameter to our attacker control server in keylog.php in the bottom left screenshot we see keylog php which just if it receives a post request containing the key parameter it will add that to a text file so every time someone hits a key on a page containing a malicious payload it will be sent to our attacker so it's a little harder to see in the bottom right but if we had a page that had a maybe a

message board with a name and a message um every time they typed a character so p-e-n-t-e-s-t it would actually end up in that data.txt file on our attacker control server this is going to be the most useful on login pages where you can grab usernames and passwords but it could still be used on i mean a myriad of other pages imagine a firewall in which you found cross-site scripting while it'd be better to do a more malicious attack you could at least find out what settings they're configuring what ip addresses their internal network devices are using um and potentially see flaws things like that so it's a it's a stealthier version of some of the previous attacks but it

still allows you to grab some fairly sensitive information so in that same vein if we don't want to grab the keys one by one it's still possible to grab other sensitive information so the javascript on the left is an example of grabbing all of the html of the current page and then sending it off to our attacker controlled server whereas the screenshot on the right is handling a post request containing an image um and there's actually a lot of references in the speaker notes part of this slide but there are existing tools that will convert an html page to a web canvas which you could then send as a ping image the biggest uses of these payloads are

grabbing sensitive information from pages that you necessarily can't see so imagine a cross-site scripting vulnerability on a banking website while you may not be able to grab the login information if you were to send someone one of your payloads or if they were to run across one of your stored payloads you could potentially grab their account balances their account numbers um maybe their address and their name things like that or if you're attacking maybe a router maybe you can't log into the application but you can see the administrative console see what settings they're using what services are enabled or disabled things like that so this attack you want to use on really anywhere any application where there may

be sensitive information that you want to get but you are unable or unwilling to sort of directly attack the login page directly attack cookies things like that so another cross-site scripting attack that i i have used personally and really enjoy is bypassing sea surf protections so a brief introduction sea surf is cross site request forgery basically it's sending a request from site a to site b to do something even though you necessarily shouldn't be allowed to the most common example would be if you were logged into amazon.com and there were no c surf protections i could send you to a malicious website that in the background would use your authenticated amazon session to purchase an item and ship it to me

well there are plenty of defenses against cserv that sort of protect against this there's attributes in the html c-serve tokens things like that well for most of these cross-site scripting can actually defeat them so what you can do is with your first cross-site scripting sort of your first stage of your payload you can send a get request to that page you want to attack so in that previous example the amazon you know click once page grab the html from that page parse it out look for your c sort token parameter and then store it in a variable so that now the rest of your payload you can send that c-surf request having defeated all of the protections

that they built into that application so this is actually a a demo that is based on an attack that i was able to perform during an engagement engagement i found a reflective crosstake scripting vulnerability on an unauthenticated page and they stored cross-site scripting vulnerability on an authenticated page that had sea surf protections so what i was able to do was utilize the pre-off reflected cross-site scripting payload to grab the authenticated c-serve token and make a post under the session of the target so again we have our very beautiful basic login page we also have that same search page we've seen before there's a comments section so a guest book things like that maybe an internet forum

that requires authentication so we're not able to post to it as an unauthentic human attacker so we login as our admin user and we can see the section there are no comments at the time but it just shows your username or your name and your question or your comment in this guestbook or this forum so again we check our search query page it reflects tests so we will check it for cross-site scripting again we'll use alert one standard you know basic payload it does fire off so the unauthenticated search page is vulnerable to cross-site scripting so if we take a quick look at the comments page it does require a valid session it says you must be logged in

so we know that and then if we scroll down it actually builds a shot 256 hash of our session id with the salt of secret and adds that as a c surf token to all of the post requests on that comment section so we would need a valid session we need to hash that and we need then we'll be able to post to that comments section so even if it was exposed to the internet we're not going to be able to make these post requests as you can see this is a pretty long um value we're not going to be able to guess it that easily but as an authenticated user we can just post tests and it works fine

so what we can do is we can utilize that pre-authenticated cross-site scripting vulnerability on the search page to try and grab the sea surf token from the comments section and then use that to post our malicious stored cross-site scripting payload and then this payload would be executed on all users browsers instead of just the one we targeted so this payload reads the body of the document this is the same code from a previous slide it reads the document it parses the request type it looks for the element called c surf token inside of the response and then it returns that value to use later in the attack oops all right excellent sorry about that okay so then it will

take it will send this initial request that we built send it to the target server and sorry it sends a get request to the comments section reads that response and then forces out that c serve token oh if i managed it okay i did not excellent so again this just creates that request i said grabs the token

so once it sends that request reads the body and grabs that token it will then build a second request using this token to send to a post request to that commons.php page now remember that we are targeting a logged in user so if we were not authenticated an attacker would not be able to grab the c surf token because it would show that he must be authorized to comment message but since we're targeting the authenticated user we're able to send the cross site request as the admin in this case but any user so then if we look at the so then we have our if we use a payload in this case okay now i'm just going to load that

external javascript file so this will load an external malicious payload like i showed in that first slide with that exploit user sees nothing but if we go back to the comments.php page there's now a stored cross-site scripting attack um which is right there it's from the user c-serve test um which we named our our malicious user in this case um and if we take a look at that c surf test user their message was indeed script alert one but it could have been any of these more malicious payloads um that i showed earlier so if we scroll back down on the exploit.js file if we take a look it builds a new message where the name is sea server token

c-serve test the comment parameter is script alert one and the c-serve token is that token that we stole earlier it then sends this as a post request to the common.php page storing our malicious payload so now we managed to upgrade our moderately severe reflected cross-site scripting payload to a more severe stored cross-site scripting payload and we bypass sea surf protection in the process don't need that again so

outside of these generic crossing scripting payloads the even higher value exploits are going to come from application specific so in this example it's a very basic example but it's the damn vulnerable web app guest book so what an attacker could do for this would be to create a new request and post to this guestbook with their cross-site scripting payload now this specific example isn't a huge deal but think of anything that you can do in a web application if that web application was vulnerable to cross-site scripting there's a good chance that an attacker could do those same things so if ec2 was vulnerable to cross-site scripting if your amazon web console is vulnerable an attacker could potentially spin up

new ec2 instances for your user even if they can't access them they're costing you hundreds thousands of dollars if an attacker finds cross-site scripting in your router maybe they can use that to change your wireless password or change your administrative login things like that so here is a great github repository of a few fairly common weapons processed for company loads for specific applications so if you look on the right um the most common ones are actually cms systems um wordpress drupal things like that if you are familiar with these applications you may have seen that they have been vulnerable to cross-site scripting once or twice in the past if you're not these are fairly common

applications that allow users to more quickly or more easily sort of build their websites out well if you were to find cross-site scripting on or say wordpress you could use that cross-site scripting vulnerability to do things like add a new administrative user post on behalf of existing users things like that so the trusted tech blog goes into a longer example of this post but if you look on the top right there's a stored there's a a post called success post with a stored cross-site scripting vulnerability that actually grabs a non-string which is required in wordpress to basically make any of the post requests you might make as a normal user grabs that sub string and then executes

a payload for add user so it sends a post request to the user's add new page and adds a new malicious call a new malicious user called sneaky user so now an attacker can log into your wordpress application potentially as an admin and use that to change your settings makes make posts or whatnot additionally if they are able to use this to become an administrative user of your wordpress application they could potentially then use that to escalate to a system level console on your server by utilizing something like a php web shell things like that so what went from a moderate to severe cross-site scripting vulnerability resulted in them having shell access to your server

and the second bullet is just a quick example of how many vulnerabilities wordpress has had um i do like wordpress people knocking a lot but there have been plenty of products like tripping vulnerabilities in the past that could have caused plenty of people to lose servers lose accounts things like that

oh there we go yep okay so i don't want to go to and depth but i did want to touch on a to a tool called beef so beef is the um now i'm forgetting what the second e stands for um but it's the the browser execution framework and i i apologize i can't see my speaker notes i don't use it as much as other people but at its core beef allows you to load an external javascript file that will turn your target's web browser into basically a full-fledged agent similar to maybe a metasploit agent things like that you're able to interact with the user browser in a clean easy ui and grab a ton of stuff

you're able to grab local ip information you're able to grab browser information things like that and remember all of this is just coming from javascript within the user's browser obviously this is going to be fairly heavy network and file size wise but you're able to get all of this information and then potentially use this user for further attacks so these has options for port scanning using your hooked browser um the way that works is your targets browser would send a get request to an internal ip and a specific port and then would check if it timed out or receive no response things like that it also comes with a ton i think it's up to almost 600 now

of metasploit payloads so if you are able to hook a target running an older or a vulnerable browser you could actually just use beef to execute this malicious metasploit payload within their browser and then get a shell on your user system which you could then use to attack that user further pivot into their internal network things like that it's a a huge framework um there have been plenty of talks on it i provide a ton of resources but if you are doing a real engagement or specifically attacking users you may want to look into using beef it does make life a whole lot easier you don't have to send multiple cross-site scripting payloads things like that so here's another just

quick example of honestly just some of the beef payloads so it will do a lot of those examples i showed earlier as far as stealing cookies um stealing sensitive information your basic alert pop-ups phishing redirection all of that um as well as some other fun stuff but yeah it's a it's a huge framework if you want to actually attack some users this may be what you want to look into but remember all beef does is writes javascript and html for you anything that beef can do you can do with inline cross-site scripting or external javascript using any of these previous examples oops so

this is an entirely separate topic that i do want to touch on it's called blind prostate scripting what this means at its core is there's a cross-site scripting vulnerability in an application but you personally cannot see the javascript execution so imagine a a comment or a help support form that you fill out but the name field is vulnerable to a cross-site scripting vulnerability when you fill out this form you make you put your malicious name you put your comments section maybe you upload a file when you hit the submit button all you see is thank you for submitting your feedback our customer support representative will get back to you within 24 hours and that's it as it turns out

on the back end when the help desk technician goes to view your ticket a the cross-site scripting payload actually executes within their browser maybe it's a different administrative console maybe it was vulnerable and you couldn't see it um but that's sort of an example of just because you can't see the payload execute does not mean that the application is not vulnerable so the first three links here sort of cover examples as well as a bit more in depth what line crosstalk scripting is but the bottom two are actually tools you can utilize to find these line cross-site scripting vulnerabilities so when the user executes your payload these tools will send back a request to your controlled

server saying you know your line cross-site scripting payload 4 was executed by this user on this date and potentially from this application things like that long process scripting is great for attacking things that you may not be able to get into so in addition to you know like i said before attacking the help desk imagine if you were on some unauthenticated web page or just browsing and a firewall in line at your company was vulnerable to cross-site scripting from the logs so while you may not be seeing any cross-site scripting an administrator viewing their firewall logs is now executing your malicious javascript payload you could use that to gain admin access to the firewall things like that a lot of times this

will be used to either laterally or vertically escalate privileges because if you're not able to see this your payloads it usually there's usually a reason for that either your payloads are ending up at an administrator level a different user things like that um it is a a very in-depth talk i highly recommend you check out some of these examples especially as a if you do bug bounty hunting um this is a a huge attack service that you may be missing if you're not checking for it so after all of these different payloads and stuff like this let's take a trip down memory lane and take a look at some real-life examples of weaponized cross-site scripting

that cause some pretty bad or at least interesting issues so i can't give a cross-site scripting talk without covering the sandy worm so for those of you who are a little older you may remember a website called myspace um there's a guy named tom he pretended to be your friend it's a great website as it turns out myspace profiles were vulnerable to a stored cross-state scripting attack so a he was fairly young i'm a young sammy campar who is now a infrasec security researcher blogger talker great guy i've spoken with him plenty actually found a this cross-site scripting vulnerability on his myspace profile and i didn't want to show all of the code because his actual payload is very interesting

technically and has a lot of bypasses but it's pretty gross to look at and what his payload did was actually add to someone's profile the text but most of all sammy is my hero and then added the payload to their profile so if i visited sami's profile my profile would say sammy's my hero and then the payload would be on my page and then if one of my friends visited my page sammy would be their hero it'd be on their page it ended up spreading to over a million users on myspace it is technically the fastest spreading internet worm it brought down my space and if i'm not mistaken some of fox's servers as well

um and there are some more links it's a really interesting vulnerability that is one of the earliest examples of a crosstalk scripting worm so it was in the same sense of a a application level or a system level worm it was self-replicating it spread to every profile for everyone who viewed it and it was persistent um it's a really interesting story and it's part of the reason he ended up getting uh arrested the first time the only time i'm not sure so a sort of less severe but very interesting vulnerability was actually in the uber driver portal and i want to share this one more so because it's a wonderful write-up and shows that just because a cross-site scripting

vulnerability doesn't seem severe doesn't mean that you can't make it more severe so the top-left left screenshot demonstrates someone setting up their uber profile only they set their home address to be a malicious in this case it just alerts the domain cross-site scripting payload if you've ever driven for uber you know that no one else can see this information um and this was not a blind cross-site scripting it wasn't that uber administrators could see this you are the only one who was ever able to see this address so it doesn't seem like that big a deal i can maliciously attack myself kind of cool but not that useful what someone was actually able to do

was they set their personal driver profile to a malicious cross-site scripting payload and then used a full attack gene so they sent an attack an attack chain to their target that logged into the or well the target would have already been lying to the uber application it created an iframe still logged into uber it logged them out of their driver profile it logged into this malicious profile since the attacker knew the username and password could allow them to log in and it executed that malicious javascript and if since it was still on uber.com it was able to grab the domain and cookie information from the target drivers profile since it was the same site and things like that um it's a great

read it's a very in-depth cross-site scripting attack chain that i really can't cover in a minute or two here but it's a it's a great example of why just because a cross-site scripting vulnerability doesn't seem that bad does not mean you should ignore it or not fix it things like that another really fun one was barack obama's website was vulnerable to cross-site scripting um and a few security researchers found it but it was inside of the basically the volunteer and the mailing list section of the application and the server so if you take a look someone is trying to change their email address for organizing for america and my.barackobama.com is actually popping an xss payload window you can imagine

what sort of things you could do with this if you had html injection you could change barack obama's website to be in support of at the time i want to say it was against hillary clinton so you could have changed four users you're targeting if it's reflected or everyone if it's stored his website to appear to be in support of a different candidate or to be in support of maybe values he was against things like that or just try and steal and target information of people visiting the website and as it turns out i don't have a second screenshot this payload was actually both reflected on the email address page as well as being stored on the backend so people were

receiving emails with this malicious javascript or html injection so you could have actually used your payload to send emails containing you know modified payloads things like that or barack obama supporters at the time a few more real world examples um there are tons of great ones i highly recommend that secondly the stack exchange one um it covers a ton that i would have loved to go over during this but i didn't have time um ebay ebay has been vulnerable to crosstalk scripting attacks so you could have you know attacked other ebay users made them make bids on your things um made them accept offers on their items things like that so at its core cross-site scripting is just interacting

with a client browser and potentially a vulnerable application the same way that a user could so we've got nine minutes left uh a few quick acknowledgements i really want to thank besides satx um letting me present about a topic that i've really enjoyed um and really for working with people i mean it's weird having to do a go-to meeting conference i'm sure everyone misses seeing people but it's awesome that they got this set up it's awesome that we all get to at least be together virtually i want to thank my company avalera i don't know if you've noticed the theme but slides are orange the shirt is orange the logo is orange i didn't pick the color but it's what we

worked with um i did want to give a shout out to eversec we are both a ctf team and hosts of ctfs um please reach out to me if you enjoy ctfs or if you want to build challenges for us it's a lot of work and we love procrastinating um i do want to acknowledge my girlfriend she made sure that i got this talk finished and clean and i actually managed to finish up some of the slides while she was driving um so i definitely appreciate that and you guys for being here um if no one came to my presentation i wouldn't have been able to give it um and again if you watch this talk live or in the

video feel free to reach out to me at any point on twitter or the b-sides discord about crosstalk scripting ctfs infosec in general so remember if you're an attacker a defender a builder or breaker we're all in this together the reason to demonstrate cross-site scripting severity is to ensure that people know why to fix it um obviously if you're a malicious attacker that's different but we're on this together we want to get this vulnerability fixed we want to show why it's a bad vulnerability things like that so i've got eight minutes left i will open up the coaching meeting for questions if that's the easiest i'm also in discord if you prefer to ask there but that is all i have left

so yeah you want to use the go to meeting or discord i've got a few minutes to answer questions

sorry go ahead i was just gonna say i don't see any questions cued within go to webinar uh but there is of course the the track four breakout channel and the track four in the weeds channel uh we're seeing some acknowledgments there uh thank you very much rael's a great talk we really appreciate you uh coming and presenting thanks yeah i'm glad to present it was awesome being able to present to you guys um we do have a question here uh what was the most difficult aspect of this one of the one of the attendees of crosstalk scripting or the talk or of cross-site scripting okay yeah um so the most honestly the the most

difficult part of cross-site scripting is one that i really didn't cover and it's going to be bypassing the defenses that you will run into so um sometimes applications may be encoding or mangling your inputs sometimes they may be blocking some specific characters like the less than sign the greater than sign sometimes they may be breaking them up or putting them on different pages the hardest part is actually getting that alert one pop-up sometimes once you get that and sort of have figured out what you can do to bypass the application after that it's mostly just being able to write the malicious javascript and html that you want which is actually fairly difficult for me my javascript isn't great

and then being able to execute it

we have an additional question uh i'm asked regularly to speak to the three different types of cross-site scripting for jobs i know how to abuse them not as good as you of course but i find it difficult to be able to speak to them do you think it's critical to memorize the different types and provide textbook answers so i think it's important to understand the differences at the very least between reflected and stored and i can cover that answer right now real quick we've got time so for those of you who don't know there are three main types of cross-site scripting there's reflected cross-site scripting stored cross-site scripting and dom-based cross-site scripting reflected cross-site scripting

is a cross-site scripting attacker payload that is reflected in the user's browser so this is going to be those examples i showed where maybe the search parameter of a website shows the value of what is in the url bar on the page so it is in essence reflected these are usually only going to be executed when you send a user a malicious link or they they click on malicious link things like that um you can't get them to execute this payload just by visiting any old web page so these are a little less severe generally speaking because they're usually targeted and they don't exist on the server forever this is contrary to a stored cross-site

scripting attack so this is going to be that example with the in the attack chain i showed that guestbook page so in a stored cross-site scripting or vulnerability the malicious payload is stored on the server and any user that ever visits that page ends up executing that malicious payload so in a guestbook or a forum if you make a post with your crosstalk scripting payload every user that ever visits that page will execute that payload this is going to make it a little more severe because a you're targeting more users and b you don't have to worry about sending malicious targeted emails you just need people to use their web application as normal the final one is dom cross-site

scripting it's a little different because it's injecting javascript directly into the document object model and that again is a whole talk or blog post series but at its core it's generally very similar to reflected cross-site scripting except almost universally the javascript payload ends up after the hash mark in a url so if you're familiar with how browsers and web servers and things like that work anything after that hash mark only ever touches the user's browser so if you go to google.com this is my super secret password google will never see everything after that hash mark but there is a chance that your browser will do something with the things after that hash mark so if

there was a dom-based javascript or a dom-based cross-site scripting vulnerability it could use that hash attack hashmark and everything after it but google would never see it in their logs things like that so it's ostensibly a reflective cross-site scripting vulnerability as far as execution and severity but the results won't be sent off to web application firewalls they won't be sent to server logs for sort of remediation things like that so while it does help to memorize the textbook answers for an interview the biggest takeaway i can give you is to memorize why stored is worse and how you can attack people with it

you