A Talk About Cross Site Scripting XSS In 2023 The Mitigated Unmitigated Vulnerability Val Resh

going I'll be talking about cross side scripting in 2023 the mitigated and mitigated vulnerability the reason for this title is that despite the various mechanisms available in 2023 Still Remains one of the most common vulnerabilities in web apps so the aim of this talk is to provide upcoming testers with the approach to finding more of this vulnerabilities and then I will conclude with a recommendation of a in depth implement ation so first let's just quickly Define what's uh cross- side scripting and it's just the injection of malicious uh input that leads to client site JavaScript execution there are a few types but this is the key point to understand so let's jump straight into the first topic and that's documentation

so whenever you find like unique parameters mentions of certain libraries do investigate them developers use often a combination of custom code with existing code and the interaction between the two can lead to a few vulnerabilities not just accss so an example I'm going to give a scenario is this URL and essentially all it did this is not the exact URL but it's inspired by the real one all it did is send a request to a backhand engine then it had various components and one of those is menu so it asks do the click action and it provides a result then the backand would try to get all the different components that are required to show the final page at this stage the

reflected input was both URL encoded and HTML entity encoded so no vulnerability yet after doing a few a little bit of research I found documentation of one of these parameters and you could actually change it to Resource so when you change it to Resource at first it gave me an error why because once it's a resource it doesn't need an action name name so we remove that and once it's removed something interesting happened the first request go to the back end it goes to the menu component and it simply loads it in this RW form without the other component at this point there was no HTML encoding or URL encoding so you could escape from the string in The View mode

escape from that string and insert whatever payload you want and that's the importance of documentation and next let's uh jump straight into okay uh chaining vulnerabilities so wherever you can is not always possible but when you do do chain them together especially especially if this can show an impact to the client an example I'm going to give is a limited Union by SQL injection SQL is just a structured career language for relational database Management systems and by limited I mean imagine all the data is publicly available so no sensitive information and access rights the interesting functionality is disabled so you don't have a lot of impact yet uh and think of the URL being something simple like this translating

to this query roughly so after you can enumerate how many columns there are and once you find one of the equivalent of a string type you can actually use your union payload and inject a string within one of those equivalent of a string type usually also called varchars and if you can and there's some type of trust that all that data is only entered by an administrator in a restricted network if that SQL injection exists and there's that trust they might not HTML encoded and you'll have a xss now and if there are admins on this application you can now chain your SQL injection which was previously very limited to Target admins on the application and continuing on this

journey do remember a stored HTML injection so a lot of times your HTML injections when they are stored they will not lead to xss mostly to content security policy but you should still be able to demonstrate impact to your clients using metatags you can force redirection right so an example is a victim visits a vulnerable application that has that HTML injected redirect and now they get redirected to a militia server which can have a login page that's a clone oh yeah sorry that's a clone of the other application login page and you can say something your session has expired re-enter it again and by doing this you can demonstrate to a client that's now it's

a compromise of Integrity so the application is no longer being used as it was initially intended and now is serving as a redirect proxy for malicious servers and clients won't be happy with that and going back to the previous point of chaining of chaining vulnerabilities so if you have cross-side request forgery this is another thing you can really chain together especially if it's HTTP based so if it's some parameter that's HTTP that creates any change this ignores same side La cookies and essentially you don't have to worry about same origin policy either and by changing this two together you can also make the actual user perform an unintended action and with that let's talk a little

B about customer Journeys so when you are looking into stored xss look at all the combination of different uh actions a user could take like ABC or ACB an example here is simply you have a page and let's say as you fill it out your form it's getting a HTML entity encoded as you fill it out no issues here you publish it and as you do is also HTML uh entity encoded and this is when you always take a step back what other actions this user could do and so what about saving that form if you save the form what I seen in this assessment per se was there was xss this is still not good enough because

for a client well it means another user would have to view your malicious saved form and save it again so go in another step what about deleting that form and once I did it also showed okay there's xss there now is more impactful to a client because if there are administrative users they look and they see why some other users save this suspicious looking form let's delete it and that's how you have your attack pad that's realistic and now error messages and I think error messages should be your best friend not just for xss but any type of vulnerability the more error messages you get and the more unique they are the more things you will

uncover so here's an example of a long URL there are a few nuances here and it is inspired by a real one with everything changed but the key Point here is not looking at something like oh I see https let's think about server side request fory instead is how many error messages you can get what if you change the protocol does the Dom pop up a unique message to you and Dom is just a document object model that's the structure of your pages web pages and so things like this try to think creatively like put some random characters don't even worry about xss yet try to changing that part that said object to something different not object

equaling whatever and keep being as thorough as you can looking at how many error messages you can do even adding extensions that weren't there so to recap do research and read any available documentation on anything you find even if it's a web app test that's focusing on a client side vulnerability chain vulnerability is wherever you can as well to demonstrate more impact leverage those store injections such as to facilitate fishing attacks follow all the customer Journeys so do look at ABC ACB and do remember it's not just you clicked all the actions is also you've tried to see what happens when those actions are used in different orders so it's not just you did I publish I delete what if you just

try to delete someone's and then you try republish that deleted by using some IDs that were left over so then uh the last one is identify all uni car messages and its triggers and the key Point here is unique error messages and the triggers so the more you can get unique error messages using some trigger that you can manipulate the more accss you'll find and with that out of the way let's look into implementing the fence and depth approach so essentially the core issue for the majority of cross-site scripting vulnerabilities is the lack of HTML entity encoding so the solution is uh HTML entity en code all input by all input that means user input

and input that's coming from sources that you might perceive as legitimate including your database systems or other web sites owned by the same organization so anything that shouldn't be rendered or interpreted as HTML should be HTML entity encoded if you already have pre-existing libraries and things that do not support it for whatever reason which they should at this point uh you can just add a wrapper around the function that you're using and make sure that input is encoded before being passed to the next function and after this you can start thinking about filtering and escaping potentially malicious characters such as this backlash this is more for some nuanced Down based ta assess things and to avoid some JavaScript encoding such

as Unicode or even attempts at Escape from certain string context then you can start to implement your HTTP only flag for Relevant cookies this is session cookies right so by doing this it will prevent injected JavaScript or JavaScript in general from being able to access the browser cookies via the document object and then reauthentication for highrisk actions so a high-risk action could be deleting a user changing an existing user password or shutting down a server by reauthentication you simply prompt a user to reenter their password when such high-risk action is performed and equally when the injected JavaScript tries to replicate such action via request it would require to know that user's password I've seen in the past

where some xss I found the biggest impact I shown to a client is because I didn't have reauthentication and I was able to perform really bad actions as an ad and after this I think everyone's favorite is content security policy so it is more at the top because first it has to be effectively set and by effectively set also means that it's restrictive so by being restrictive in nature in a good implementation is not always something that all clients prefer to do at least not in the correct implementation but what this does is just a set of directives or rules that tell a competitor mble browser what type of content it should load and then on top of this you can

deploy also your web application firewall simply to demotivate more less uh motivated adversaries essentially and the reason I've put web applications and firewalls and this content could you posy more at the top of your in-depth approach strategy is simply that's not that's mitigation that is quite effective at least Contex policy when correctly implemented but is not by itself a solution to the underlying problem and yeah I think at the start I went a bit too fast I'm sorry about that so for that reason I'll have questions for everyone now so no [Applause] problem yeah any questions hi how do you think genitive AI will assist or hinder your cross-site vulnerability scanning and mythologies assist I don't think per se cross-site

scripting is a difficult vulnerability to uncover so the things that AI currently can exist in Cross side scripting is something you can already do via fuzzers so it will use already very commonly exploits and try them and luckily if it does have some uh I forgot the name but it's when it can go backwards rearn and forward with a piece of data that is received in one iteration if it can do that then yeah it could probably help but in general at the moment what I've seen from my experience is most of xss that I found in general was because it hasn't been found previously by the tools available that scan them if AI can do

this in the future then I think it's great I think we should all in General accept new technology and push towards implementing and coexisting with new trends anyone else Co well once again background oh no sorry there's one more here we go like U for for absite program if you want like for a product security engineer who is directly working with with uh with the application and if you want to have a detection mechanism for accss in a continuous cicd workflows uh what would be the best uh approach you would suggest for identifying this injection not only exess but ex is one of the topic but yes other you mean identifying this during the software development cycle like

throughout it so I think the first step is always having a good good basically not education but having resources that can teach your developers to understand this vulnerability so that's always the first step and making sure that they are aware of how this vulnerabilities occur and then in your development process it should be by the start you have a policy where you HTML encode all input that shouldn't be HTML as I said in that for in the first core issue once you do that if you adapt this and if you use rapper functions for example around the already existing uh calls that put put the input through if you implement that then you should be

fine in general I don't know if that answer your question so if you can reiterate is fine as well I mean definitely that uh prevention me the methods which you mentioned that's absolutely correct education is actually vital most vital uh but uh like um the other thing which you mentioned about about the I think you're referring to the input validation mhm right so I think in your defense in depth approach I was there mention in that because I did see there was a filter one but I think there wasn't a a white list like what weally recommend to the developers that follow a white list approach using regular expressions for uh field input Fields yeah so that's that's a fair point so

you could use allow list when focusing on potentially malicious characters here for filtering an escape so you could use a list of only characters you want right that's perfectly fine but that HTML encoding all the input what it does is in the sense that you want people to be able to use certain characters but you don't want them to be executed right good then HTML entity encoded would be preferred because you would still want those people to be able to use those uh greater or minor signs for whatever reason you want to give them that ability that's fine as long as that HTML encoded when it gets reflected on any of the pages so you mean to say like if if

if we give bit liberal in not implementing inut validation regular expression for like say first name field then it would be fine in a to a certain extent is that so yeah yeah I I get the question so the key Point here is your strategy in general right yeah so if you focus on this strategy you will first fix the instances and any potential of xss of occurring at all before even allow listing so it's similar to having um for example injection parameter saries for SQL injection yeah so if you prevent SQL injections your filters are just a second step yeah because they're already getting properly prevented such as with parameterized or using RMS that are

securely developed if you have that it will already prevent so your filters is on a top ahead of this and those filters are there to also give you an additional protection in case that you failed to fully implement the first step because if you fully implement the first step throughout your whole application and as you in your software development cycle when you create new updates and add new functionality if that same methodology follow to HTML encode all type of input you're already preventing the actual vulnerability in itself if that makes sense yeah that is definitely that's the primary mitigation HTML encoding is the primary mitigation uh coming back to the same question about HTML encoding uh

like nowadays a lot of Frameworks also provide uh so what spe do you like the standard API for html. encode or for framework specific inbuilt that there are a lot of inbuilt features as well which actually allow the developers to natively use the encoding features uh encoding cap capabilities so uh can you give some example of such framework or something or what do you suggest to the developers that so I think in general almost any framework like spring boot for example if you use or was it is it to be relied on because we never know how they have implemented so if there are open source you are able to check the implementation and you'll be able to yeah and you'll be

able to check in the implementation if it's open source you'll be able to see that piece of code that actually does the encoding and you'll see if it's secure or you'll have a team that's able to analyze if it's secure at that instance in time so another thing important to consider is that even open source any applications they grow with time right so they develop with time there are new updates and sometimes new updates include vulnerabilities so so today the actual Library you are using might be secure HTML encoding and the new update might show up that changes a bit of that code and it might be now vulnerable in the next update which is also a reason why some

vulnerabilities are not discovered in 1998 because some of them were introduced in 27 you know but that's just the explain that point yeah obviously a lot of discussion to be had about this topic and it's quite in depth but um yeah once again thank you very much to our speaker today