 Happy to announce Arthur Jantz who's gonna give another Talk in in the web track. I think we can say about rootkits in web applications where he's gonna tell us about cross-site scripting I believe so The stage is yours. Thank you So thank you everyone for coming. I'll just do a short introduction My name is Arthur Jantz and I work at Google and Google is doing a lot of really serious security research and some Not really all that serious research some sort of wacky stuff And if you're sort of wondering what the wacky stuff might be, I guess you'll get to see So I was thinking of this talk as a sort of short light-hearted overview of some of the issues that are relevant to Exploiting web vulnerabilities on web clients. So so the first thing to get out of the way is I know that the talk has rootkits in its title, but it's actually not about rootkits at all so if you're You know if you're used to the idea of of rootkits as this thing on the client side that lets you hide Processes and and do and enable malware to avoid detection It's not going to be about that But it'll be about something that's that you know apparently is a little different, but but there are many similarities. So what I'm talking about is Attacks on web application clients that are due to various kinds of script injection and obviously the most often discovered attack is cross-site scripting and So I'll do I'll do a quick introduction to those attacks and how they work very quick and Then I'll talk a little bit about the interesting stuff Hopefully for you, which is what happens after a script injection attack actually is successful So after we have a cross-site scripting victim What can be done and what are the the problems for web application authors? related to that and obviously For it to be a complete Security conference presentation. We have to introduce a new buzzword. There's there's no other way so the buzzword for today is resident XSS and You know, it's it's sort of tongue-in-cheek, right? I don't think anyone should should go off and start using it after I describe it But it's something that will help us sort of be on the same page about the Particular kind of attack and and then I'll talk a little bit about how What the difficulties are with cleaning up users who have suffered from from this attack So I mentioned before that this talk isn't really about rootkits because For in traditional software and client-side software The way you sort of have malware Running on users machines is that first you find a code execution vector, you know, so you find a bug or you You entice a user to to click on your executable and and fold them that way If you actually find a vulnerability you have to bypass ASLR and that and stuff like that And after you get to that point you do the things As malware you do the things that that I classified loosely as a rootkit and you know We can talk about semantics later if anyone wants to so the stuff like inserting a backdoor to maintain Access to the machine for an attacker and hiding the presence of attackers processes on the machine Let's call that rootkit functionality and after you have that after you have the way to execute code and a Way to hide your presence and maintain access then you can do various kinds of evil things And we've all seen malware and what it does. So this is sort of the traditional way Malware has worked and it didn't it never really applied to web apps, right because web apps are sort of different but and the sort of idea that I want to impart on you is that web applications have evolved in the last Five or ten years to the point where we can have similar things to rootkits Running within web applications for a particular user so and and I'll I'll talk I'll talk more about that So Unless you've been living under a rock for the last Nine or ten years, you know what XSS is but I'll just go over it very quickly XSS is cross-site scripting. It's when a web application allows External users to submit queries that will execute some code Supplied by the attacker in a victims browser. So for example, if the victim.net domain is not careful about sanitizing Or escaping actually the User input the script in the supplied in the URL parameter will be treated as a markup in the user's browser And it will execute in the context of the victim domain So the reason for that is that the web application doesn't escape the HTML meta characters and Which leads to the vulnerability attacker scripts get to run there's no way for the browser to distinguish attacker supplied scripts in this case from legitimate scripts on that website so Whatever code the attacker Gives to the victim of this attack will be run in the scope of the victim user's authenticated session and the attacker will be able to execute XML HTTP requests back to the same server and basically impersonate the user it's it's code execution sort of for the web and Whenever people see information about XSS for the first time They they see two two things that that are my sort of pet peeve Because that's not really how it works So the first thing you learn about XSS is that you you find the vulnerability you send a link to some user And they click on it and then you know you can run your code But that that isn't really how it works because you would have to have your entire payload in the URL It doesn't there are many other cross-site scripting attacks that that wouldn't work this way The user would see some kind of weird URL with scripts, but you know that if you send it to them via email the The link might be broken up on onto several lines Just basically it wouldn't really work and the second thing is the way you exploit cross-site scripting it isn't to Just send the cookie a deauthentication cookie back to the attacker because the One of the first things that that we learn about cross-site scripting is that it has access to all the cookies Within the victim's browser So you can just get the browser to send the attacker the session cookie and the attacker can from their own machine Send all the requests that are necessary to to impersonate the user So I'm sure a lot of you know why isn't it how how this works. What's the problem with with the second thing? So browsers don't really allow this and the reason for this is that document cookie So there's this attribute set on cookies Called HTTP only which all web apps that know what they're doing are setting on Authentication cookies and which means that JavaScript doesn't have access to authentication cookies So you can't really steal a cookie this way There are some vulnerabilities that might let you do that, but really that's not how how you would exploit it So how you could exploit cross-site scripting is to to get a user to to visit this page with a cute kitten So obviously there is nothing to let us know that there that there might be a cross-site scripting exploit there But there could be invisible frames that do the same thing basically create an iFrame or some other or a frame To the victim page that the user never sees another way to to exploit XSS is to just visit any popular Internet site My claim is that if you visit this page you might actually fall victim to cross-site scripting on In some web application that you're currently logged into Does anyone have any ideas? Why that might be? Ads exactly yes, so if you're an attacker you can just pay an ad network to distribute your flash file or Snip it of HTML to be loaded in a frame And it will be shown on on various popular Websites, so there have there has actually been research on showing malicious ads to users or researchers have used this technique to Sort of demonstrate evil distributing evil payloads to users. So so this is another way that that you could execute XSS So what would happen is that? You as a user you visit an attacker's page There's a hidden frame somewhere there with the cross-site scripting payload and the exploit Runs in the context of of the target domain and does something malicious So the malicious things could be it could initiate a bank transfer if you're logged into your banking application It could transfer money to the attacker. It could set up an email filter for your web mail service that would Forward all your incoming emails to the attacker and it could do a bunch of evil things Another way is if there is a persistent cross-site scripting bug Which is a way for other users to? Embed code on a page that you normally see in the web application Once you fall victim to that you can there have been many cases of cross-site scripting worms Because of persistent cross-site scripting, but in both cases and we don't need to get into details about that but in both cases The exploit is doing something malicious, but there is a problem from the attacker's point of view a Problem with exploiting this so once you find a bug and you start exploiting it and you have to take So there are two things you have to do first of all, you know that if you are If a user visits your page with a picture of acute kitten They won't be on that page for very long And you could there are some ways in which you can try and to get them to stay on that page, but but in general What you would do as an attacker is you would execute your evil code right away as soon as possible So, you know, you just set up your evil email filter or make the bank transfer and that's it And the second problem and the problem associated with that is that the vulnerable web application Immediately sees when users start getting exploited via this technique that there might be Maybe a thousand users or ten thousand users if we're talking about mass exploitation That Executed some action within a very short period of time. So the web application will know immediately That there is something going on that there's usually monitoring So as an attacker you have to expect that that someone will be on to you in, you know, maybe minutes maybe maybe a few hours and That way you you burn your Your exploit and and you can't use it again because it supposedly it'll be fixed So I talked about cross-site scripting a little bit, but it's not really the only way in which you can inject evil scripts on to Important domains of applications that that internet users use So cross-site scripting is one of them. There's also universal cross-site scripting, which is when a browser or or browser plug-in Has a bug that that affects all web pages So it's not necessarily that you as the web application author have have done something wrong It's you know, it's it's possible that there is a Bug in a plug-in that the user has installed on their machine and to quote Dan from from yesterday it's always fricking Java and It really is because Very recently there have been examples of universal cross-site scripting in in the Java plug-in that's still very widely installed Then there are ways to get the user to Put something Put a bit of JavaScript in their URL bar and when you hit enter it actually executes the code that you put in there So Facebook has suffered from this attack quite a bit because people were unknowingly pasting snippets of JavaScript into their URL bar and when you execute it it actually runs in the context of Facebook without any fault of the web application provider They didn't do anything wrong, but the users didn't really know what they were doing. It's the same way malware gets distributed when you send someone an evil attachment from people just don't know any better and There are some more sophisticated attack attacks related to the abusing the URL bar And then there are there are yet other ways of injecting your evil scripts onto onto target Victim domains. So for example if the if the web application is trusting external Providers for their JavaScript for example for example the omg awesome JavaScript bunnies calm totally trustworthy Page, right? I mean there's what why would we ever worry about their security? But you know, maybe they're they're not all that awesome Even though they might be bunnies So you know they can be compromised and suddenly the resource that your web application is loading is is backdoored in some way and can execute Some evil code of the attackers choosing and it can also happen to your domain So if you have a big domain that hosts many applications, it might also host static files that are uploaded by say Marketing people that that have no I is anyone here from a marketing person All right so so you have clueless marketing people that you know might might have access to a particular Directory on your domain and what if you know they use the same password on You know all their web accounts and it the password gets compromised someone someone logs into Their account uploads a file. That's also that's an HTML file can execute scripts I mean that are all there are a bunch of attacks like that that Allow you to inject evil scripts onto some domain and another Sort of good vector that that many people don't think about is cache poisoning so a Quick question who is using the wireless network here? So about half of the people are using the wireless network and about and the other half are too lazy to raise their hands, right? So yeah, everyone is using the wireless network here So when you connect to an untrusted wireless network, you you're at the mercy of the provider and other people who might Be able to control that network, especially especially wireless, but but not only so what can happen is that you after? browsing the internet from a network like that you will continue to use a browser with with evil cash so cashed resources that were Injected there by the evil network by doing say DNS spoofing or just man in the middle on HTTP traffic And those resources can be very long-lived. So if you you can have for example a JavaScript snippet that is used on many applications such as Maybe SWF object or one of those popular JavaScript libraries When you visit When when you browse the web from an untrusted network It will be Backdoored which and by that I mean it might still contain the same functionality that you're expecting It'll just have an evil script that can be activated in some way by the attacker And you know it it can live in your browser cache for a year or two So that's another way and the the last category of things is even for web applications that do HTTPS properly There are there are some things that so if you have a sensitive web application that that's only using HTTPS So it's less vulnerable to the cache poisoning There are there are a bunch of bugs that that can allow attackers to inject those scripts So there are mixed content bugs where a web application loads resources over HTTP If the page is HTTPS which bypasses the HTTPS protections completely and then we have we can have stolen or forged certificates and we can have evil CAs issuing evil certificates and There's always a chance to get the user to click through a warning and and then they would connect to an attacker's web server That would cache some resource Under the context of HTTPS of the victim domain So So I'm I'm going to focus on cross-site scripting, but but please take into account that when I say cross-site scripting it actually all of these possible vectors are could could be used instead of cross-site scripting and One thing one other thing to to remember is that after an evil script runs In in the context of the vulnerable web application We can assume that the attacker can keep up the communication with With the victims browser and I'll talk a little more about that So we talked about Ways to to inject scripts, but now I'll talk about why what bad things attacker supplied scripts Can do in web applications So now it's time for me to to introduce the buzzword of today resident access so resident XSS by my definition is When malicious code is injected into the user's main web application window or tab so Contrast that with with the techniques. I I mentioned earlier where there is an hidden frame on some website that that might Execute the attack Resident XSS is when the attack that the evil code isn't contained to some hidden frame on some website It's when the the main window that you're interacting with for your say social network or web mail client or anything like that when this window is actually Executing the code that's that the attacker chose So let me just quickly tell you how that might happen So if there's persistent cross-site scripting when you When you use the web application, for example, if there's an email message that someone sent to you That doesn't get escaped properly. You open your web mail application The code runs and it runs right in in your your main web app window And it could be other things status updates and comments on a forum and they would all work that way It's actually a relatively rare vulnerability these days Compared to all the other kinds of cross-site scripting that are still prevalent on the web Another way is Many new web applications use client-side storage mechanisms you introduced in HTML 5 so local storage or Web SQL web database Functionality which lets them store large amounts of data in the browser But the problem is that when there is a cross-site scripting bug the attacker can quickly Backdoor the data in the victims browser and when when the for example when the cached JavaScript File gets loaded next time the user logs into the application. It will also contain the attacker's applied code and There was a great paper investigating that by Don Song and and the students at her lab at UC Berkeley I think it's called the emperors new API So it's definitely worth a read and they found that a lot of the new Sort of cool web applications are using those techniques and are indeed vulnerable And then there are other ways for example if you have a regular cross-site scripting bug it can open a new window to the To the main application So for example, if you if you fall victim to to that attack you You would see two web mail windows right next to one another and one of them is the one that you opened and the second one is is one that was opened by By an evil hidden frame somewhere and that frame managed to open that window and inject Attackers code into that so that that's another technique and there are a bunch of other ways. So My main point here is that Any script injection vulnerability Can be with a high degree of success converted into a resident XSS So I've talked quite a bit about all of that But now let's get to the actually interesting part of of the talk which is Once you run resident XSS in someone's browser all the assumptions they have about Interacting with with the web application are Violated so let me tell you what I mean by that. So first of all Once you have this the web application that runs attackers JavaScript You say you want to log out because maybe there's something strange You think maybe there was an attack on your browser or there just you just want to close it So the first thing you do is you click log off But well the the web application is now running the injected JavaScript so the attacker can hijack the log out button and So that when you click it actually So in the sort of basic case it might not do anything so you can't really log off and the attacker could also Do more sneaky things for example when you click on log out it could create a small window in the background That to bypass pop-up blockers then close the web application window, but keep its own session running in the window in the background and so basically Another thing that it could do is say for your banking application, which times out after You know a few minutes or half an hour or something like that The attacker when you click log off the attacker could show you the log out page. I'm saying thank you You know you have logged out Everything is peachy and then continue issuing keep alive requests to the Banking application server so that you think you're logged out you got the page that says you're logged out But it actually keeps pulling the server to and keeps the session alive until you close that that tab But when that happens the attacker has has yet other ways to keep the the infected session going Another thing is you can't really leave that web application that that's been infected. So if you If you have a link and you want to follow it and you expect the link to take you to another page The attacker can just open it in another window you can Basically any kind of navigation that you expect the web of the web application to do can be subverted But but those are just things to to keep you in The attackers hands But the interesting things is what the attacker can can do once you're once you're interacting with the web application. So for example off the record chats or Or any keystrokes that are typed into that application Are can be monitored by the attacker because he is running his his evil scripts there mouse movements or Any other thing basically is can be monitored that that you're doing even if There is no functionality to sort of save it to the web application just because it's in the Dot in the browser's DOM when you're interacting with it the attacker can get to it and the attacker can also modify anything So you can see messages in your web mail That that come from the attacker that are indistinguishable From valid messages and there's no trace of that at all So for example, if you know you get scammed you you get the police to issue a subpoena against the the web application the Web mail provider to try and track down the the scammers They won't see anything in their logs because it's not really a it's not a real mail message that you got that it's a spoofed one And and there are a bunch of other things so once you're in that application The attacker can show a fake login page to pretend that you're logged out. You will type in your your password. Maybe your You know one-time password or SMS code and the attacker can can get that data And then after you do that The overlay can just disappear and you see you're logged into the web application again And you just don't suspect anything because why would you it can fish for security questions So and that that's even sneakier because it lets you attack other web applications Using the knowledge that you get from from hijacking just one of the web applications that That the user is using and then there are things like geolocation API's or Microphone or a camera that you might have granted access to to just that application But you know the the way browser keeps track of which applications can can access those features is by Origins, so the attacker script run the scripts run in in the vulnerable origin and if there are any There's any functionality like file downloads, so you you're in your webmail application You click on the attachment to download that You think you're downloading just an attachment that you got from someone But it's actually an attacker is executable So you can you can just open malicious file download Dialogs and user might think it's a trusted Bit of code from the application and the same thing with malicious plugins So the application the attacker can prevent you from using the application at all until you Until you install the plug-in of their choice So, you know given the choice of Installing the plug-in that you you don't really know is evil and Just abandoning the web application most people would are probably inclined to just install it And there are a few other things as well. So for example If there are any so if you're in your webmail application and you you get a link to CNN comm What the attacker can do is open the the CNN comm page in in another tab and Inject its own JavaScript into that page So it obviously if there are no cross-site scripting bugs on CNN the attacker can't do it directly But if there are any ads on on CNN the attack the attacker can navigate the frames So the same origin policy has some exceptions for what kinds of Cross-origin Navigation can be done and even if you can't access a page directly you can navigate its Its frames to see if there is a frame that you can control at which point the attacker can inject its code his code Into that frame So and once you have all that Once you have the long-term access to the to the victim's browser you can do So other than monitoring all the data in the web application itself You can do other malicious JavaScript tricks So you have a lot of time to do history detections can local networks possibly attack other web applications and distribute the denial of service all of that and And it really doesn't it doesn't show up anywhere because the the web application You know doesn't really see that there's anything wrong. You don't see that there's anything wrong It's just injected code into the web app. So Yeah, it's it's not good right I mean once you fall victim to that it's all bets are off We're sort of doomed But let's say that You know the resident XSS didn't really work So you you got to run cross-site scripting for for a few seconds then the user just closed the tab all together and Or you weren't able to do to achieve the resident XSS There are things you can do to maintain access to To the user's web application session regardless. So for example, you can backdoor HTML5 local storage and Various kinds of web databases you can backdoor flash cookies So if the flash a local shared object Data stores some kinds of configuration files or or executable data You can inject attacker code into there. So next time the user Loads up the web application legitimately They will execute your code again and if there are any cross-site scripting bugs based on cookies you can you can exploit that But there and there are also some new Mechanisms that are being developed in HTML5 that that make these kinds of attacks easier So I don't mean to To bash HTML5 because in many ways it's great and it's awesome But it gives Attackers the same features that it gives legitimate web developers. So it actually makes and makes some things easier for it easier for attackers as well But even without all those cool HTML5 tricks There are all these there are ways to keep the attacker code running in the in the victims browser so Opening up new windows That will that won't be visible to the user in the background that will keep That will point to the victims domain. So for example You know you would have your social network tab And if you close that the attacker can create Pop under window and before you manage to To close to stop all the attackers scripts They can be injected back into that that tiny window in the background So even though you think you've closed all the tabs that point that might have attacker-supplied code You you can have windows or frames in on completely unrelated websites where this code was injected that still keeps running in the context of of your domain and the name for that Is frame hopping where you where you keep injecting this code wherever you can so when the user closes one tab you the attacker can look at all the other tabs that it has access to and Either exploit cross-site scripting bugs in them which is much harder Or or just look for for frames to add domains when where everyone can inject their own code and and survive this way So After an attack like that executes There is there is relatively little that the web application itself can can do to eliminate The attackers access to itself because if you keep a tab open to To your social network to a page from the social networks domain That had the cross-site scripting code the evil code running It will always have access to to other pages within the same domain So when you you might log out of your social network in another tab But whenever you log in again that That evil tab has access to all your data again So and there is no way as the web application developer that you can close this tab in the user's browser So it's been sort of permanently scarred by the code that the attacker chose And it can always it always has access to the to your web application session And you might think that if you add some functionality so that Every page on your domain will Pull your server for some cleanup code that you might want to run So every five minutes you will you will get some JavaScript from the server and execute it and if the code Sees that there's something wrong with with the page. It'll close it just a sort of a precaution that obviously doesn't work because The attacker can always just disable that code because he is running JavaScript on that page And you can't really even tell the user that there is something wrong or that they should you know Close the browser and you and use a different browser profile or clean everything up because the attacker has control over everything that that you might Send to the user in some cases So So you can't just say you know fix everything to the user because the attacker can intercept this message and just hide it So as the user if you think you've you've been attacked this way What can you do so so let's think of some things that that might work so first of all What if we just close the tab with the web application? Well, that doesn't really help because there might be other tabs or other hidden frames that are still running the injected code If you if you first close all the tabs and then just close the browser completely so that there's no runtime That is that is maintained across the browser closure The problem is that There you might have the client side storage the html 5 local storage mechanism Or or a cache that has been manipulated by the attacker so next time you you open up the browser Even if you have no tabs the first time you navigate to the web application it will get Rehacked because of the the poisoned client side storage And so you might think okay, let's let's clear all the local storage and we'll restart the browser and well Everything will be okay, but between the time that you clean up all the local storage and you close the browser any tab that is open Can that is controlled by the attacker can actually re-poison all the the client side storage because there there's a small time delay between Clearing everything cleaning everything up and closing the browser so there sorry Wow, okay So There is something that that actually might let you clean up Your your browser profile after after you've been attacked this way So, you know you keep you close all windows you close all tabs you keep one tab open you navigate it to a Safe origin that that no attacker scripts should have access to you remove everything you restart the browser You hope that the vulnerability was fixed and that there are no Self-access s bugs that that might have been exploited in the meantime by the attacker But I mean try explaining that to to your mom or or or just a casual You know internet user. It's a really complex process So in a way just throwing away the the browser profile after you've been Victim to cross-site scripting in one web application Might be the easiest thing to do which which is sort of scary right because think of all the data that you have in Your browser profile you have history you have you know You have cash and cookies and and all of that and just to throw everything away because because of one web application that was That was attacked that that sort of it boggles the mind So, you know, but but unfortunately, I mean that that might be that that might be the most sensible thing to do So just sort of recap and talk and finally talk a little bit about about rootkits so Those are the analogies that I that I came up with between the the traditional You know client side bugs and and web application bugs So code execution or remote code execution is in a way cross-site scripting is the analog to that and the same way your exploit has to worry about the Mitigations on the client side you have to worry about cross-site scripting filters or web application firewalls that might not allow you to exploit the bug that you want to exploit and for maintaining access The poison local storage or frame hopping are techniques that you can use in in web browsers And one thing that is that is quite interesting that I haven't really talked about is for most malware you you have some command and control channel to the back to the attacker and Obviously in the web application you can just keep Loading a script from the attackers domain and get commands this way, but there are so many stealthy ways to to sneak in code that that would that would look completely Inocuous to to someone just running a sniffer So you could have DNS based covert channels. You can have There's this thing in html5 called web workers. You can create an invisible window in a way or invisible JavaScript execution context that will keep asking the attacker server for For a JavaScript file to execute that you will never see in firebug or in your web inspector in Chrome And communicate with the infected page with post message that there are there are whole numbers of ways of Doing that and the malicious payloads, you know similar to the client side just running a keylogger or Or doing denial of service attacks in web applications You can also compromise the data in the web application try and elevate access to other applications And and do the the usual malicious JavaScript Tricks that I talked about So this is Almost the end. So so the thing I want to leave you with today is There are two thoughts basically so the first one is that after You have been you are your users have been victim to Cross-site scripting or a script injection attack It's it's really really hard to reliably clean this up and to make sure that any future Interactions of the user with with your web application will be in will have Integrity in any sense of the word because you can always have attackers applied scripts hiding Somewhere in the browser that you're just not aware of and you can't get rid of And the second thing is and it's something that we haven't seen yet, but you know, maybe And I would be very happy if we didn't see it at all but the sort of attacks that that are Enabled by the resident cross-site scripting class of bugs are quite nasty Because of because of all the assumptions that they violate in users mind So you just don't realize that the application you're using might do all the things to to harm you. So, you know snooping on you Fishing you and and and just act against your interest because you we're not really used to that right for on the client side if you have Injected code it Doesn't really inject itself into existing applications most of the time So if you have a backdoor version of of Microsoft Office, it doesn't really Intercept your click on the file menu because why would it and things like that Are possible and are actually remarkably easy to do with with JavaScript in web browsers So I just want to Tanked two of my colleagues who really helped flesh out the ideas that I talked about today Mihał Zalewski is a great web security guy and security guy in general He recently wrote a book called the Tangled Web and if you if you have any interest in web security This is the book to read. So I strongly encourage you read it Just a word of caution if you search for it on Amazon There are some other books by the same title. His one doesn't have the naked guy on the cover So so just search for it for that one And Eduardo Villanueva is another one of my colleagues who has amazing at all client side things and he helped me out a lot as well So Thank you very much Thank you very much Arthur for that great talk Let me just reiterate what I said at the beginning if you would we're gonna have a Q&A session now, so if you would be so kind to maybe Stay seated and quiet until we're done so everyone can enjoy it and Take all your trash with you when you leave later and leave by the front door, but let's Start with some questions Right, let's just wait half a minute for the impatient Okay Let's start with a question from the front row So I noticed you haven't actually covered anything about like attacking browser up plugins or like sorry add-ons All like stuff like that because like this have been hilarious bugs and stuff like tweak deck and whatever else and like in Chrome So some there's like permissions to the somewhat restricted, but like Obviously because they are going to use local storage. I mean wouldn't that be a better target? I'm just surprised you didn't cover anything on them So this is actually a very good point. So most of the The plugins that or the add-ons that use local storage do it in the context of the In the origin of their Sort of web application, right? So you have Or often they trust that data So by by running cross-site scripting in the context of that origin you can actually elevate privileges because the The add-on will will treat that data as trusted because why wouldn't it? It's their domain And yes, so it would it would give you a privilege escalation because you would execute in the context of the Of the add-on rather than just just a random web app. Yeah, thanks All right further questions Do you have any knowledge about known exploits of this concept in the wild? I'm not really so so I believe right now. It's actually easier to get users to run Malicious executables in many ways unfortunately, so, you know, there are so many easier things to do than than doing all the work to backdoor someone's Web application session if you can just get them to to double click on an exe but I Do think I'm a little afraid that that's something like this Will come to the web world once the sort of low-hanging fruit attacks are Harder than they are right now. So just the question is, you know, will they ever get? Difficult enough that it'll be worthwhile for attackers to use these techniques Hi Hi Hello I have I have two questions for just for understanding this better The first is if I'm so I'm I have the scenario now I go to a website I get this malicious code somewhere in my local storage. I Close my browser. It's there in the local storage. Now the website detects the malicious code Remove the malicious code and now I go back to the website. So what is the help in the local storage? I mean, it's not a wall evolved the local storage. What does the attack I get from my local storage when it's still there? So so the main The main problem is that the web app with that a lot of web applications trust the data in local storage, right? So they They just eval at JavaScript resource that that's in there. So once once the web application cleans it Okay, so you mean the local storage is evolved sometimes from the website by By intention. Yes. So so this is so we can treat it as a as a bug and The paper I mentioned the the emperor's new API's They were actually They got in touch with a lot of web application providers telling them, you know You you maybe you shouldn't be trusting the data in local storage Because it can have a negative consequences. For example secondary cross-site scripting Okay, okay, so then everything is clear. I Didn't know the fact that websites really aware you are the locals. So it doesn't have to be eviled, right? So there are many other ways but otherwise so you can no advantage. I think so well There are other ways in which they trust the data that doesn't have to resort to eval for example If you use it in an inner HTML assignment if you store some snippets of sanitized HTML is You know you sanitize it on the server side your application puts it in local storage Then you trust it then when you when you use it again the attacker code can can be injected. Okay, okay Right. We then have a question from the interwebs Hello One question from Brussels He asks what can assist admin do to prepare for this? That's that's a tough one So I hate to say nothing, but but really Nothing So so I actually so my my main worry is that there is relatively little debt web applications themselves Can I can do about it? Right? So even at that level? I mean for just the local storage attacks you can make sure you you never trust anything in local storage or you can You know you can have signatures on on any data that you want to eval or something like that But for For assist admins, I don't really see any mitigations Okay, another one another one Quick question. What about the privacy modes of web browsers today? Mitted Jade the problem of recovering from once it has been infected Yes, yes, so this is a very good point that I didn't mention. So if you run in private browsing mode For for pretty much all your your web navigation. This will this will help right because there will be no So once you close it All the local storage data gets wiped out the execution context of of all the code that might be running in hidden Windows or or tabs or hidden frames. It will also get wiped out So the the only problem I see with that is is if flash doesn't play well And I know historically there there are some incompatibilities between Flash shared objects and and bribes browsers private modes You could put potentially inject some some Data into flash cookies that that would persist after you quit the private browsing mode But but yes, this is a good mitigation But then you sort of So I actually think it's a very good solution But when you do that you lose on some of the benefits of using a modern browser You don't have any history any any saved data, but but might be a worthwhile trade-off Wouldn't it be possible to to use some kind of hashing like just get us for the local storage Maybe an external program to check it up when the one the bra before the browser starts or anything like this So you could so as a web application if you if you intend to eval a blob of JavaScript When you when you load when you start your application you can definitely You can have a signature-based system to verify the integrity of that the problem is that you can't really store the signature anywhere on the client side because Because that can be tampered with but if you You know if you always get the signature from the server You run some kind of you know you run the RSA on it and you verify that that the local storage is Is correct and And then you load it It might have some problems for example if between the time you you run the check and the time you actually load it If it has been tampered with then you would still you know there are race conditions there But but in general it's it's probably If if you use local storage cache Which is which is actually a recommended solution for? mobile apps, so we have a lot of the people in the performance web performance community pushing for for using the the client side storage mechanisms as cash for CSS and JavaScript and and other kinds of resources So I actually think some kind of signature system would be a good way to make sure that you can use this mechanism safely Thanks. Okay. There's time for one or two more No further questions Right Then let's thank Arthur again for the great talk