Cross-Site Scripting, Modern Protection And Payloads by Dan Cannon

uh so um i'm dan uh i'm gonna talk about uh crosstalk scripting modern protections and payloads um first of all i mean why do we care about crosstalk scripting it's 2022 surely this isn't something we're still dealing with but no it's it's still an issue though we have to think about uh whenever doing web application testing it's something that i find in sadly the vast majority of applications that i do testing against um and our big concern when it comes to uh when it comes to crosstalk scripting is the fact that we've got our malicious entity that is able to interact with a web application uh be able to deploy some method of malicious payload that

our normal legitimate users then for foul of um and our end game of being able to achieve session hijacking compromising data security application security all the good stuff that we try and do whenever we're doing the exciting pen testing work so just a quick refresher for anyone who hasn't done web testing for a while or is in other areas of cyber that's not specifically pen testing uh when we're talking about crosstalk scripting we're talking very specifically about um the ability to have javascript executed in a browser we've got three key different ways that we can achieve cross-site scripting that's either reflected which is typically sent by get requests in your browser where our nice classic uh payload of script alert one

script gets deployed and users have alert boxes executed in their browser we've got stored where as the name defines here this is stored on a server and provided to users when they access uh different pages if anyone is old like me and remembers myspace um you'll remember tom from myspace where everyone became his friend from stored crossout scripting uh where it executable code as soon as you go onto that page you became tom's friend whether or not you liked him or not and then we've got dom-based cross-site scripting which is document object model this is a browser api this is a really interesting kind of cross-site scripting because it's not data that is sent to

and from the server it is a payload that gets executed by the browser itself when it's rendering a page and these are all ways that we can try and elicit some kind of action in a target user's browser so what do we do when we try and find crosstalk scripting in a web application well we can either go for a shortcut approach fire all the payloads an application um start putting in script alert one start trying image source errors start going obscure and having svg's uh these are all payloads that will try and have some kind of alert box that happens in a browser and it is something that we see a lot of people do where testing will

happen and it's the shotgun approach of you know fire everything hope something sticks um and see whether or not you're able to identify vulnerability the problem is if it doesn't execute you're now in a position where you don't know if that application is vulnerable you don't know if you're just a noob who doesn't have the appropriate advanced payloads to be able to execute that vulnerability and fundamentally you just don't know whether or not an application is vulnerable and when it comes to pen testing you know our key thing is being able to give that bit of information so what should we do instead uh we should really focus on the process of how to understand cross-site scripting

and this is very simple uh it's the process of exploring all of our parameters our applications give us it's a process of looking at the actual feedback we get we're lucky that with cross-site scripting it's a client-side attack we get dynamic feedback from an application and we can understand whether or not payloads are working or not it means that we can figure out what protections are in place and we can figure out how to develop our payloads we can identify filtering and we can come up with some imaginative payloads to deliver to an application we're testing and eventually we get our proof of concept and profit by being able to compromise a application so the wrong approach to crosstalk

scripting which we see quite often um is you've got an application you've got an ability to interact with it you fire off a script alert one payload and nothing happens and you're screwed you just have no ability to be able to understand have you been able to work on an application that's fundamentally secure are you now going to turn around to developers and go you know what your secure development life cycle must be fantastic because i can't achieve cross-site scripting or are these things just being filtered and modern protections mean that things like script alert one are yeah they belong back in the 90s to be honest um they are they're not fit for purpose

anymore we need to make sure that we're understanding the process of how we attack applications how they're implementing filtering so that we can come up with a more sophisticated way of working with an application i have realized that i've embedded a couple of videos into this uh powerpoint which i'm now consciously aware that anyone about five rows or further back is potentially not going to be able to actually see so i will walk you through what um what the modern approach to penetration testing of an application should be when it comes to cross-site scripting so we've got a very simple application that allows for users to input data and it's displayed on a screen this should

for anyone in pen testing this should be a flashing light of screaming awareness that you should be thinking cross-site scripting and client-side attacks now when it comes to modern payloads what we can think about is the fact that filtering and putting things like script alert one and just having those things disappear do not indicate that applications are secure we should be thinking about a level of understanding of how applications process data and we should be looking into ways to test whether or not applications are fundamentally vulnerable um to understand whether or not we've got filters in place we've got protections in place and what we can do so what we've got on the screen is this

really simple benign html that will have text put into header title format bold um yeah inter para insert paragraph into text and we can see that applications are able to process this data and then we can turn and go regardless of the fact that our script alert one just disappeared we've got a fundamentally vulnerable application it will take our input and it will understand what we are saying so we can turn around and go right in the modern age we're not just using script alert one and assuming that because it doesn't execute that this application's fine we're able to actually actually apply some semblance of knowledge and understanding and instead think sensibly about how we can approach applications

that are vulnerable now yeah we can think application input parameters that have been identified let's put script alert one let's put more interesting payloads let's let's think about different html elements such as audio and video um anyone who has tried things like image on error over the last five or six years we'll know that they're going the way of of scripture at one script um these are these are old school payloads that are very prevalent in blacklists um and it means that when we put this we're in a similar situation to turn around and go this payload just disappears this is the importance of being able to understand whether or not applications actually process our data

so that we can focus on developing the modern approach of how to identify cross-site scripting and compromise an application so instead what should be a process of understanding the application becomes the process of just firing payloads and instead we go down the route of understanding we have parameters that are processing our data and are displaying it in a way that is you know understandably vulnerable now this video it's admittedly incredibly small now that i realize for this audience but what this is doing is it's putting the unique word of wiggle which i choose to use whenever i'm trying to find crosstalk scripting because to this date i've only found one website that has the word wiggle in its source code

while i query it and it was the bbc thanks the wiggles but it means that whenever i put a payload into a web application i can really quickly understand in the source code through using inspect element whether or not this data is being understood by an application where it's being stored and this video is currently just going through the process of trying things like script alert embedded script camel case that kind of thing because this is what we need to think about when it comes to uh protections and filtering application developers who have applications that are vulnerable to cross-site scripting which we can understand through having uh heading uh heading parameters bold parameters that kind of data that

is understood by the application are not protecting their their data and their user interface securely enough we can turn around and use unique words to understand where our data is going and eventually find ourselves with payloads of work it's this approach that needs to be adopted to make sure that we're providing real value when we're conducting web application tests because things like script things like alert things like image they're all they all belong back in the 90s they are being filtered and there are too many applications that are flying under the radar of people thinking they are secure because there is not that fundamental understanding that a filter does not make a secure application a filter is

just getting rid of the bare bones and the most common payloads that an attacker could try and use and let's be fair um anyone who's doing pen testing in this room knows that we've got a very time sensitive engagement when we're working with clients attackers don't have that worry if they're getting text it's being filtered out they're not going to turn around and go well i spent 20 minutes on that so i guess i'll move on to the sql injection that i found they're going to focus on attacking user accounts and being able to figure out what the rules of the filter are what the pieces of the puzzle are and then be able to attack an

application so i decided that one of the one of the cheat sheets i have for my work should be created into a tool that is incredibly rudimental um that i recommend anyone who wants to explore cross-site scripting go and have a look at shameless plug i know um but we're gonna do the great the great x-escape what this does is it takes payloads that are being filtered out like script alert one and if you do not have the knowledge or the imagination to come up with different kinds of payloads it will then go through and provide you with a list of other potential payloads that you could try in this example we've got the fact that we can take our

payloads convert them to camelcase embed uh strings within strings we can turn around and think maybe alert one is being filtered let's use text instead of numerical values we can take a lot of approaches of whether or not alert is being filtered and deploy keywords such as confirm prompt anything that we feel like and this is a really good tool of being able to focus on that approach of understanding vulnerabilities and being able to deploy payloads that are actually going to execute when attacking an application so to use it nice and simple again shameless plug but what we have is if anyone does look at the code on on github do not judge me it is incredibly

trivial finder replace for generation one uh generation two will be much more impressive but what we have is the fact that over years of working through application testing um we can take payloads and we can we can obfuscate them we can move data around we can make things likely to bypass filters once we're testing an application and we find out there are fundamental vulnerabilities we can come up with some really interesting ways of trying to attack them and one of the things we can do you saw the sleep the screen chart scripted one what we have here is uh for things like the classic image source on error alert we can turn around and use different

html elements uh we can use different objection techniques and we can make sure that we've got some really interesting ways to try and deploy payloads into parameters that we are 90 sure are vulnerable to attack so what's our aim doing that i mean our aim is fundamentally to to bypass filters our aim is to be able to understand that an application that will process our data and deploy and display it in bold or in paragraphs or in a header format is definitely taking our input and processing it in a way that means that it's a vulnerable application what we can do as you know intelligent security professionals is leverage the fact that people accessing applications from

purely a computer is is a concept that belongs back in the early naughties we all have mobile phones we all have tablets we can focus on an ability to create obscure payloads different payloads and use the fact that technology has evolved and that we can identify more ways of attacking applications by bypassing filters and using special terminology ontouchstart is a massively underused cross-site scripting payload for anyone who does penetration testing i highly recommend you start thinking about using it this is a really trivial way of being able to demonstrate cross-site scripting without having to worry about blacklists that get deployed against users who are typically accessing an application through a browser on touchstart means that whenever you load an application

into a mobile phone or a tablet as soon as that user touches the screen they are going to have cross-site scripting execute for them and it means that we can really display the ability to attack different people and this is something that is not occurring in very many black lists i had incred i'm trying to think of any application that has actually filtered the on touch start verb it's a really effective way of being able to demonstrate applications are vulnerable filtering is being deployed but filtering does not a secure application make other things we can think about when it comes to bypassing filters because again this is the main approach application developers are taking they're not making

secure applications they're just filtering attacks is we can use a concept called data uris for anyone not familiar with data uris again look into it massively valuable way of trying to attack applications so a data uri is a string uh it's a string of data that essentially turns around and gives a command to an application it is metadata and data combined in one and we can turn around and provide commands that will be flagged up in cross-site scripting filters in such a way that applications don't understand them this one specifically is taking the svg payload that may be filtered due to svgs or on load commands and all it's doing is simply base64 encoding it and deploying it to the

application in such a way that we leverage that technology to say you're you're a computer you understand what base64 is you understand how to encode and decode so if i give you a parameter that has been encoded i want that to bypass any filters in place and i want you to decode it and then execute what i'm asking you to do really effective way of being able to bypass filters because it means that any any string checking is just not working script does not occur occur in this payload svg does not occur on this payload alert does not occur on this payload this is all base64 encoded parameters and you are telling the application decode it execute it really effective

way of trying to establish whether or not cross-site scripting is a vulnerability that could be leveraged so having having things like alert one alert two yeah lovely we all know that's our proof of concept uh you know clients end users attackers no one's happy with that as a method of attack it's it's a it's an alert box it doesn't achieve anything it doesn't do anything our end game is all about stealing sessions being able to achieve some method of attack to compromise security so other things we have to be aware of in uh in our approach to attacking applications that have taken an approach of filtering and protecting their their input variables is that when we are trying to achieve

some form of session hijacking more likely than not we are going to use some form of quotation marks whether or not there are single quotes double quotes whatever you you know whatever payload you choose to use whenever someone is attacking an application and this is a really simple way of developers being able to try and again protect applications that are fundamentally vulnerable and to staple security onto an application that has already been coded already been deployed and is fundamentally vulnerable so what we can do with this is we can go back to classics from years gone by that people forget about now and we can bring them into the modern age and we can use standard ascii characters

to be able to bypass filters again that are going to turn around and say you're trying to use quotation marks you're trying to use some method of of establishing a way to have a victim user come back and communicate with you and i'm not going to allow that the application is fundamentally vulnerable but this is something that can't be allowed to happen because it will lead to user vulnerability what we can do is we can take a really nice simple payload of something like ngs cross-site scripting with our double quotation marks that are again commonly filtered out in applications where security is bolted on at the end of development and we can turn around and say

you're a computer you understand what what code is you understand what commands are i want to give you a payload that you will understand as ascii characters and you will recombine into a payload that will then be executed by the browser really nice simple way of being able to demonstrate an application vulnerability really nice simple way of then being able to achieve cross-site scripting in a method that achieves some kind of goal at the end of it so alert one alert to text box with with text in it this doesn't achieve anything of value to us it doesn't give clients an ability to understand those vulnerabilities here there's concern here what can we do we

can really simply take this kind of data and we can wrap it all up in multiple different steps to obfuscate this data and be able to deploy it to an application that will then be used to un-obfuscate it execute the code and give us back data that is valuable to us so what we can do is we can turn around and think about applications that are deploying filtering again a lot of applications now are just bolting security on at the end and they are only as good as their filtering and we can turn around and say you know what i want i want to have my victim user come back to me on a port that i control and i want them

to give me the cookie value that they have this is a common common attack method for cross-site scripting it's an ability to be able to take a victim user's session token and then be able to leverage it to compromise the entire security of that um of that session of that application and what we can do is we can wrap this up in ways to bypass filtering by implementing base64 encoding through btoa common library an ability to focus on again obfuscation of data remember filtering is all about seeing strings seeing regex is that you are not happy with and pulling them out of data so we can base64 encode different variables that we want we can then ascii encode different

payloads that we need and we can focus on the fact that something like audio source on error and that big long string there is something that will be able to achieve a real tangible impact to data security and application security regardless of any process an application developer has bolted on to the end of their development by saying i've made an application bugger it's vulnerable let's let's stop let's stop hackers being able to deploy code that's going to cause us a problem this is how we can take that kind of modern approach of identifying filters finding out what problems exist and being able to leverage that understanding of fundamental vulnerabilities into a way of deploying really obfuscated

text really obfuscated payloads and achieve an end goal that will compromise security compromise user accounts and this is what we get at the end of it we get uh yeah for anyone who's not done this before anyone who's not a pen tester anyone who is a pen tester who's never tried session hijacking this is one this is what comes back to us we have an application um running on port 8000 that is going to listen for connections and we get a nice payload at the end of that which is a base64 encoded session token and again the mentality of using that base64 encoding is to bypass any filters both inbound and outbound that application developers and firewalls or

any network devices are trying to deploy to be able to remove our ability to attack an application so we've got our inbound obfuscation of ascii code we've got our outbound obfuscation of session tokens that are base64 decoded and all we have to do is really simply base64 decode that and we've got a session token or in this instance a a flag from one of the north korean security labs so this just shows that whenever we're bolting security onto application development whenever we're taking the approach that security can be put to the end of a development life cycle that there are multiple steps that we can take to be able to identify fundamental flaws in security and be able to leverage that

as part of a cyber security attack and be able to do interesting work that can adhere to all the rules an application deploys of filtering and protection and still leads to a successful attack and a successful compromise of data security so what do we do about this uh we've got to focus on the fact that development of security needs to be put into an actual secure development lifecycle we can't just bolt on security to the end of application development we can't have developers who don't understand the concerns of application security we're all aware that it's 2022 cloud first is the approach of most industries everybody wants a web-based dashboard for literally everything the internet is

no longer anything that people think of as optional and so therefore everything well almost everything is renderable in a browser and therefore a potential attack vector and we need to focus on the fact that user input needs to be sanitized not just filtered but sanitized on its way in it needs to be encoded on its way out when it's being displayed to users we can even encode using html context or javascript context whatever the appropriate situation is for an application but developers should focus on encoding data on its outbound direction back to users we need to think about things like content security policies that can focus on making sure resources aren't loaded from other environments instead of just

the application that we're working with and we need to make sure that any session token that an application uses is actually protected against javascript being able to pull that down for an attacker this is all things this is these are all considerations that end users have absolutely no control over and therefore when we as security professionals either as developers or testers or consultants are working with people developing programs and software we need to be addressing this because end users have absolutely no ability to be able to protect themselves from this kind of thing they are not in control of the code and the ingress and aggressive data they need to have that level of assurance that a secure development life

cycle has actually been adhered to thought resources are out there for people to think about if they're interested in cross-site scripting and how you can bypass filtering oh wasp big one there are a couple of really nice uh cross-site scripting uh applications out there to give people the chance to to practice uh xss game appspot is fantastic level three has dom based cross-site scripting if anyone is interested in that it's an area that not everyone is particularly familiar with and it means that you can focus on being able to execute payloads within a browser context without actually having that directional communication with the server it's level three if anyone actually wants to focus on it it's uh it's really

cool um and there are huge amounts of payloads out there to be able to develop strings develop um sophisticated word lists of attacks that you can focus on when it comes to testing applications so does that mean all of them

i purposely haven't put

um partly because it's yeah the shameful plug and i will casually say again even though it's not a flight deck feel free to take a look at it um but the key takeaway from this is that in a modern approach

hello there we go in a in a modern approach to cyber security and in a modern approach to addressing application security and web security we need to be focusing on the fact that bolting on security is not a suitable approach we need to focus on the fact that taking a shotgun approach of allowing people to just deploy payload after payload without fundamentally understanding vulnerabilities is not a sensible approach and we need to think about the fact that a lot of applications are fundamentally vulnerable to these kinds of attacks we just need to have a workforce to understand these issues uh we just need to have a skill set in the industry of people who understand these issues and are able to

again like use tools like createx escape and deploy payloads that are going to actually provide value and demonstrate vulnerabilities to end clients okay are there any questions

oh

um

so what i've found recently is i well i did a test two weeks ago maybe and this site was protected by cloudflare and cloudflare was picking up all the stuff that you you covered in there you know on error image alert everything script was was being detected big unsubtle message coming up saying malicious activity you've been blocked um but what i did on that page was just put simple form like uh please enter your username and password in there and it was all in the url so just put that whole entire built a whole login mechanism that farmed credentials off to my site um and none of that was picked up by cloudflare and and it was you know there

was no um validation there was no you know i didn't have to encode anything or anything i was literally just former and you know input fields and away you go and i think that gets overlooked that's my point i think i guess they were overlooked nowadays is that some of the older simple attacks are still valid yeah i think i don't know i think i think that's a massively fair point for everyone not particularly familiar with html injection is taking the same concept of being able to understand how browsers are rendering inputs uh to be able to leverage that as part of an attack um i think that we are we are kind of unfortunately i'll deny them um but as

time goes on i think that there's too much reliance on on tools and that ability to just fire off payload after payload and take the shock and approach uh to see what happens and i think one of the i mean one of the key things i like anyone who is in actual testing as a role here to take away is that the modern approach of taking that uh that process of just firing off a shock and approach worth of payloads uh and being able to test through sheer force of will um does not work there needs to be that understanding of the work is it working yeah it's working there needs to be that understanding that um

the the old-school ways in some ways are the best and the the fundamental knowledge is still there um and that no matter how much cloudflare or akamai or the next steps to try and protect applications from attack get implemented that with that fundamental understanding of how these things work you're able to bypass these attacks and there are there are too many times where we're letting these things slip under the radar um it wasn't it wasn't long ago that i was on a client site with a uh with a colleague who found crosstalk scripting on an application purely because another consultancy had left cross-site scripting on an application page um and for loved or money could not trigger uh

a new cross-site scripting vulnerability um and but by taking that approach of not shotgunning this and going well descriptor one work no it's gone therefore it's fine but instead working through a process of identifying the filtering identifying the fundamental issue um it took five minutes to be able to understand you this is just filtering out keywords and it's not recursively going back and checking that so we need to take this approach of actually adhering to technical standards and technical understanding before we start creating payloads or before we turn around and just pin a vulnerability and go it's that didn't work therefore the application's fine

yeah yep i'm not sure any microphone but uh do you think uh frameworks like react view do you find they make much of a difference um in my i mean anecdotally in my experience uh yes um i'm sure some other people are gonna tell me to go in their experience and not at all um i think frameworks always have their place um they allow uh the frameworks for development are typically focused on cross-site scripting as a way of um as a potential attack surface and a potential attack vector and therefore a lot of work gets put into it the big concern is that as soon as you start working on a framework you know that multiple other applications

are using that as well therefore it's an area of interest for anyone trying to identify bypasses and as mark said it's another blinky light kind of mentality of i don't need to focus too much on secure development because i'm using a framework that's going to do that for me um in like i said anecdotally react is something that i've uh struggled to achieve cross-site scripting with some of the applications but i don't know if that's because the developers using that framework have been particularly good or whether or not it's just at the moment a coincidence so so i think reacts has a bunch of techniques to try and mitigate yeah but i think there is a

small subsection of things you can do that might leave you vulnerable do you think that's best solved by developer education or automatic tooling that scans code for those so i think i think developer education is best for that because as soon as um i mentioned we've got reflected and installed across the scripting are some of the most common um crosstalk scripting attacks there are but dom based cross-site scripting where you're leveraging the the actual browser api itself is something where any over-reliance on on technical solutions to turn around and say well when you give me this data start stripping out um stripping out keywords start deploying it this way start making sure that it's not

imported into this parameter can start to fall around i mean dom-based cross-site scripting is a method of being able to allow a a web application page to load and then be able to provide it with a payload that will execute on that load so the server itself never even gets the chance to do it you're almost entirely client-side protection um which is fundamentally flawed because you're manipulating what you're giving it on a client side and i think therefore that reliance on on tooling is going to potentially be an issue but the the the software the software developer education means that at least there's going to be an awareness of anything web first anything internet facing is going to be attacked so think

it through think about any input okay thanks

do you ever um put any tokens within your xss payloads so you can try and track where they were injected quite often i've had a large website limited time like you mentioned earlier um and yeah you've got a bit of a shotgun approach you're smashing all the input values you stopped doing exercise testing because you couldn't find anything two hours later you get an alert one where did you know where's that come from yeah now you've got to try and trace back for all the different places you injected alert one was do you ever do anything where you like alert aaa aab aac so then you can start to track back where where the injection was so uh if

i've got if i've got a huge um a huge application with a lot of different potential vulnerable parameters but yeah that's when i start to make sure that i've got some understanding of you know this this payload is going to achieve this this is going to do that so i can get an understanding of specifically which one was triggered and when things like document domain instead of document cookie are good ways of being able to get an understanding of what what domain actually executed this was this data just passed off to something else somewhere else that then executed that and to get a bit of a better understanding it's not something i've had to be overly

concerned about i i've personally not had one where two hours later suddenly uh data starts flowing back to me but making sure that yeah the different parameters have different payloads and using things like document.domain instead of document.cookie could be really helpful to understand where things are being processed so i've seen it before on different privilege levels within applications you might have one interface for an admin another interface with standard users you're messing around in the standard user world and then you think right i'm going to jump into admin completely different application but access is the same data and that's where i've rendered it and that's quite often where i've struggled to think got to go back to client now and look

where that low priv user injection was yeah and that's fair uh massively fair comment because that's a really nice way of achieving that private escalation through through crosstalk scripting instead of just taking over a generic user session um again anecdotally when i've been doing it it's been one application with multiple user levels as opposed to multiple applications reading the same data lake or data source um so it's not something i've personally come up against um but i can completely understand you have the challenge of trying to focus where what actual payload triggered that you know if an application if an admin is able to read only specific parameters from a normal user which one which one

was it um and i think the if you if you know that you've got multiple parameters that have the ability to be injected into um there's definitely got to be that importance of making sure that you understand um what the payload is for each parameter and even things such as trying session hijacking turning around to having payloads like you know plus c equals document. plus document.cookie plus d plus document.cookie so that you can turn around and be like right if this suddenly comes back with an admin session token or this suddenly gets executed somewhere um i've got that ability to understand how this was achieved and which which parameter for this on or which bit of

data is is being shared across multiple apps so does your tool for that payload creation add randomization into those payloads not at the minute it's uh it's something that um it's something that i'd look at doing um but at the minute it's very much focused on the obfuscation of data and taking things like scripture one and going right try all the different variations of alerts try lots of different variations of script let's encode that base64 and put that in a payload for a uri let's encode that in ascii and put that in a string from char so that you can turn around and say right i have one payload that i'd like to try here's lots

of different variations um but i mean there's massive amount of massive revolution of that of that tool um but at the minute it will take the specific payload that you're trying and give lots of different variations if fundamentally you know script is recursively checked for that it will not work and it will wait for you to turn around and make attempts to say well what about image on source blah blah blah and terminal right here are again data uris ascii encoded different html5 elements like audio and video that i've had a lot of success with um and it will give you that kind of list of different payloads that can be worth a try thank you

uh yep

protections was putting up content security policy yep in your experience doing so like web app pen testing how many companies actually goes through the process building a comprehensive csp i mean in a phrase not enough um there's i mean this is this is such a nice way of being able to turn around and say you know do not load things that are from untrusted resources um do not just allow anyone to be able to to have things executed on a browser um and it's something that i just haven't seen the adoption rates get to the point where it's actually useful to protect applications isn't it about we've got about 18 months to two years to get in for um

pci dss version 4 because it's being mandated now i think for when it fully comes in with all the new stuff in there to be made script and things like that i mean i'll be honest i'm massively fortunate enough i haven't had to do a pci for about a year and a half now so um i can't comment on the new standard but um if if the deadline is coming then hopefully we can just help the developers start taking taking notice

okay all right thank you very much um i will hand over to the uh to the next talk [Applause]