Protecting Crypto Exchanges From A New Wave Of MitB Attacks

all right thank you for being here my name is Bella Fortuna this is actually my fourth besides topless here but this is a bit special for me because it's first it's my last talk of the year and second because it's in my home country and I think this is the number one security event in Portugal right now it's also a bit it's a big responsibility to be the first on stage but I'll give my best so about me I'm a founder and CTO at J scrambler Portuguese company in the last few years I mostly worked in security in client-side application security more precisely in JavaScript code protection but before that I've also worked extensively to design solutions to

detect bots and anything related to many in the browser Trojans to malicious extensions will definitely get my attention so for today will mostly focus in men in the browser attacks against crypto exchanges but first we'll just establish what is many in the browser attacks then we'll cover some of the defenses that we found in some crypto exchanges then we'll get our knees deep into the main topic and finally at the end we will get into application real-time monitoring which is a new approach that we have been working on in the last couple of years so for ones that don't know exactly what is a man in the browser attack or might be confused about it it usually starts by some sort

of phishing attack so you receive an email just inviting you to just click in some link or to download an attachment and this is how it all starts so most of the websites they have thousands or even millions of users of course most of those users won't fall for this but as we know there's always a percentage of users that will actually fall for this and that is enough to for the attack to be profitable for the attackers so once you click that you basically infect yourself with a Trojan and this Trojan will then proceed to download its own configuration usually it has at least a list of web injects which is just a big

file with a with a bunch of targets and usually has a URL which is the target then it has a section for something that they need to look into a webpage which is the reference for the injection then you have the actual injection which in this example is ATM PIN form to request the pin from the user and some data after section which in this case is not being used so this is a web inject and many of the browser trojan has a bunch of this could be hundreds could even go up to thousands of targets and it's usually just weights out for you to visit one of the targets so you make a request for the targeted website comm

and you received the page without any modification at that point in the network that once it reaches your computer basically the Trojan is hooked into the browser process and it's able to modify the the page the markup that is being delivered to the page and after the SSL termination but before being rendered by the browser so what really happens is that at that point it's able to modify the whole content of the page it doesn't matter you can modify HTML and CSS JavaScript whatever and you are basically running a modified malicious version of the page so in a ASP the definition it's more or less what I just demonstrated but there's an interesting bit at the end which is this attack

works regardless or even if other authentication factors are in use and this we'll be important later on in the talk will come to this later here you can see so many in the browser attacks they exist since 2007 when Zeus first right since then we have been seeing lots of different versions some are copycats or just fourth out of Zeus and some other versions appear throughout the years so I already mentioned the web injects but there are actually other capabilities that they are able to do you can do kill logging they can do farm grabbing they can use some of them are remote access Trojans or rats which allows them to basically remote control the whole

computer some are capable of spreading outs they are worms so one of the most reasons is a motet which is capable of doing lateral movement in fact nebula targets and evil deliver other malicious payloads and if you are already capable of stripping out any security headers of the other of the pages which is very malicious so these Trojans basically have been able to to make huge impacts of millions hundreds of millions of dollars throughout the years I'm not going to bother you with mentioning all the stories but eventually a better appear apparently it seems that we haven't been able to to employ very efficient solutions against this type of attacks so one question we did is how secure how

prepared our crypto changes against this type of attacks and to do that we just try to survey what what are the main upside features or defenses that are being implemented by crypto exchanges of course there's too many crypto exchanges to to survey so we just selected a few there are more than 200 crypto exchanges in the world and probably this number changes every day so we decided to choose a representative set so we kind of Sheri picked the crypto changes based on trading volume here it's basically its popularity and how frequency you talked about them and our percent perception of their use so we picked this six bindings between XP tracks coined by super Bobby and crackin

obviously if you ask me that is a crypto change X should be allowed to be hearing probably but we had to pick so any other choices would be also okay so one of the most common features that we found is two-factor authentication of course makes authentication stronger by frustrating attacks that compromised a single channel we all know what's two-factor authentication is you can use SMS you can use some mobile application that you have in your phone like Google authentication and there's also hardware tokens basically all exchanges off of this feature the difference is when they use this feature so you have crypto exchanges that force you to use two-factor authentication when you do login others that force you to use it

when you do withdrawals when you change your password your API keys and if you do any change to your security settings probably it's a good idea to ask you for you two-factor authentication as well so the rule of thumb is anything sensitive should trigger a two-factor authentication another common feature is captious which is basically to counter or fight BOTS to know if it's a human you have all different sorts of captures the older ones used to be tech space but you know how easy it is to to just bypass text-based captures you have the traditional image based and lately you you have been seeing some new types of captures which are risk-based or because they are good guess there

frictionless because they don't require you to necessarily to to to identify something in an image it stays on your reputation and Google reCAPTCHA is a good example and actually most of the crypto changes that you have analyzed use recapture and this is basically one of the defenses that are very good against spots but don't forget you can always use a sweatshop which basically delegate in humans to defeat the CAPTCHAs and there are many to many offerings for this to work so in the end I don't consider this to be a very good defense but a necessary one still accounting over defenses usually it starts with requesting two-factor authentication login in logins because if you capture

someone's account you may not have captured his second channel or two-factor authentication so that's the first barrier but we actually only found this in finance and in BitFenix so it's a third of all the crypto exchanges that we have analyzed then you send an email on every login which is also good because if you haven't logged in and you received such an email so this will immediately warn you that something is on it should be also if you reset your password or if you reset your to faster identification you need access to your MMO email to confirm that and in some cases we found that crypto changes actually frees your account so you cannot withdraw money during a certain

time which is a very good feature you can use IP device whitelisting again you have to authorize new devices and you have to approve through email and in some cases you need to your account is frozen for a certain period and also a very convenient feature is most emails that you receive have a link in order to you to freeze your account so if you one has logged in into your account and you haven't done it you can just use that link and it's like the fastest way of freezing our account and it's a very good feature you should also have access to your account history and logging of activities in your account and this is

pretty calm withdrawal protections are actually of all the features the ones that I feel closer to I think this is the more the most effective features that you can use if them it is the usability of the websites and if you use any crypto change you know what I'm talking about it's you can not do a step without reaching out for your phone or having to click something in an email so in terms of usability these websites are usually bad but it's necessary as you know but this is very effective if you reset your password if you reset your two-factor authentication depending on the crypto exchange it can freeze your withdrawals from 24 hours up to 15 days

which if you think it's a little bit crazy but it really depends on how risk-averse are the crypto work changes and it also can depend on the amount of funds that you are transferring out so you can lock and disable withdrawals for certain crypto coins that you don't trade so if you don't trade let's say Manero you can't just block it out and if you want to change that you need to go through all the process of do factor authentication maybe your account will be frozen for a certain time so and this goes on and on and it goes for it's valid for withdrawal address whitelists so if you can you can set up a lists and

if you change that list it will freeze your account for instance for five days you can also do white listing of IP and devices which is also good so all in all this is effective because it freezes your account and you receive an email and you have certain time to react and to actually prevent the attack from being successful there's also an interesting feature which is you can receive an image with all the details of the transaction and it will basically display you back a secret phrase that you have set and this is good against fishing and that's actually the next category so there is a certain amount of features to counter fishing one is also a secret phrase that

you can find in your emails they email that you receive that prevents someone from imitating those emails you can encrypt in certain cases with PGP the contents of emails which I find pretty good and in some cases BitFenix for instance who warns you to always check the padlock and if you are in a secure site with HTTPS so last but not least we also checked the implementation of content security policy and I I think to be honest it was kind of disappointing because you expect crypto it changes to be very very strict with their security you expect to find the most recent the most trending application security features in this kind of websites and what we found is that half of them are

not even implementing CSP and all the ones that are are doing all sorts of mistakes that you can find in by implementing CSP for instance they whitelist domains which according to my friends Michela Spagnuolo and Lucas over 20 94 percent of CSP is based on white lists our bypass fall so that it shouldn't rely at all in this type of approach defining CSP it's like first-generation CSP and there's recommended ways of doing it but they are doing other mistakes like using an unsafe eval and safe in line you name it they are doing most of the mistakes that you can do I really recommend you to use CSP evaluator from our friends at Google it's a very nice tool you can point it

out to your website and you'll get like a list of recommendations on how to implement CSV properly this is a summary comparison of all the features you can maybe take a picture or just tweet me after and I will send you this and this is the version where you can see what I consider to be good features and bad features or bad configurations so you can see for instance that coinbase is mostly bread and you can see BitFenix is mostly green but none of the six are full green and this is my understanding of the best configurations so in some cases might be debatable so let's get into the main topic and you wave of the

tax of many other browser attacks against cryptic changes it all started in March this year we it caught my attention in the news men in the browser attack against coinbase and block chained I got info it wasn't the first time that's mainly the browser attack the crypto change but it was the first time that it really caught my attention because we had more data on it and it seems to be becoming a trend so I immediately started working on this or team as well and we reached out for a couple of researchers that published this white paper from security scorecard and what we found from this paper is that it was actually a Zeus find a

strain and it was targeting these two websites among many others many banking websites so from the white paper you can see some interesting details for instance this is the first stage web inject this is always injected into web pages from these targets in this case this is specifically for coinbase calm and it's a bits office gated but it's really very easy to reverse it's not a very good obfuscation so if you just work on it for a little you can see like the basic that it's trying to accomplish it's basically waiting for the page to load and then it just fetches another script the malicious payload and that is that can be always different because it's

dynamic the attack can evolve at any given point you can you can download more evolved payloads so but we wanted more details it only shared details about the bots but not the payloads and the C 2 endpoints were no longer active so we reached out for the Davina and Kathleen and they were very helpful they shared what they had further details on the attack and it basically allowed us to further understand how the attack was going on and we were they shared the the payloads actually and that's allow us to implement to reverse-engineer what the c2 was doing and implements our own c2 so in this case we implemented proof of concepts and this is what I'm going to

show next on the attack and we implemented the injection using verb proxy because why not this is a POC so this is what we know from the attack after researching a little bit so the user visits coinbase calm the first stage is injected by the Trojan and this is always injected in every page of the website credentials are first accelerated in the login form then the Trojan after you login its presents you this this message saying that we detected unusual activity in your account so it's it's pretty seamless so you don't immediately know that this wasn't supposed to be there it's a pretty convincing and and I would guess that most users would fall for this for

sure so any at that moment it requests you a two-factor authentication token so you reach out for your phone and you just give two-factor authentication token to the attacker in this case so coinbase calm didn't request this two-factor authentication so and it uses that that token to downgrade the security settings and this is in my opinion one of the mistakes that they have is that they allow you to downgrade the security settings so usually it says that if you can read in the bottom you any amount of digital currency requires or triggers the requests of two-factor authentication in this case if you have one one token you can downgrade to never and it says least secure but the the guy

that's being attacked doesn't know about this it happens on on the back so in this particular attack this is done inside an iframe so it adds an iframe to the DOM and because it wasn't a completed finished a fully finished attacked that iframe was still visible so obviously in finish the attack that iframe wouldn't be visible at all okay so it then disables you prevents you from going to the security settings so if you go there you just see a message saying something went wrong and please try again later so you cannot tell if the security settings were downgraded or not so and it stops here it doesn't do any more thing but our guess is that the

next task would be to just exit rate funds out and in this case in at coinbase there's nothing really prevent you preventing you from doing this so you already disabled all two-factor authentication tokens there's no fries with a list in coinbase so you could just very easily exit rate one so this is how we replicated the attack so we just placed per proxy next to the clients and it's basically applies the first stage web inject and we strip CSP and x-frame options using by proxy as well and I will explain you later why because initially didn't need to do that but after the attack coinbase implemented further security we configure the browser to use the proxy

okay and that proxy through that proxy the malicious payload will talk with our CTU that is our own implementation of the C - all right let's go to the demo so this is ver proxy most of you should be familiar with this and the last one is the web inject that we are the to the first two lines is stripping out the X frame options and content security policy headers and this is the original obfuscated version of the web inject so let's proceed - oh sorry messed up let me fast forward this a bit

starting the c2 now in this case it was running from the same machine that doesn't matter it's a POC and now let's go to canvas let me try to sometime again so right now one thing is already happening that sign-in button is an injected version that has been placed on top of the original sign-in button so what it does is you you click on sign-in and then it captures your credentials they also disabled the Enter key so if you just click enter doesn't work so this is the normal two-factor authentication that's you are forced to go through when you login and now when you land in the dashboard you begin seeing this message we detected an initial signing activity

then it asks you for the two factor authentication token and the guy just reaches out for his phone and starts giving away a free two-factor authentication token to the attacker all right

so in the original attack you would see a visible iframe as well so we just remove that because it's more interesting this way otherwise it would be a bit silly so if you go to the settings page and reach out for the security tab you are presented something went wrong please try again later all right so at the same time we logged in in a different browser not without the injection and we are just heading to the security settings where we won't be blocked and we would will be able to see that actually the security settings were downgraded let's let me fast-forward this

all right settings security settings and as you can see never okay can you see that can you read that not very well okay it's never all right moving on so the insights from doing this it's first it's a very noisy attack because the first stage web inject is injected in every endpoint of that website so if I were to implement this attack I would only inject the first stage web inject in the endpoints I would want to actually do something so it's a little bit noisy it uses a state machine to control all the phases it's in and the code seem very experimental like script kiddie work it wasn't very it was very poorly written Java scripts

so again the visible iframe this is for sure an indication that the attack was still being built but it was found found in awhile so there's a function for exit rating funds but the attacking code had a return statement just at the very beginning of that function so if they remove the return you had further logic just trying to accelerate data to the funds I mean so the one one takeaway from this is that two-factor authentication be it SMS or Google Authenticator in regards to many in the browser tax is not a real barrier it's not a barrier at all it just reduces the usability of the website I still think that you should have them of course because there are

other attack vectors there are other ways of attacking attack that will actually be stopped by the two-factor authentication but in terms of many in the browser or malicious injections from extensions or wherever it won't do anything because it can trick the user into giving away a two-factor authentication hook so and it can be very seamless it's you can even full a security professional I think it very unless you know a deep knowledge about the website and what what how it works and what it can ask ask from you you will probably be tricked so since then coinbase has disabled eye framing although on their website so this was actually one of their mistakes they allowed eye framing of their website

from within their their websites and since then I think they were actually the only crypto changed from the this list that actually implemented or disabled eye framing from even within their website so what can you do you can follow the usual man-in-the-browser recommendations which is maybe grab for a live distro and just go to your crypto exchange but that's in my opinion that's hurting the usability even more if you have to do that probably I mean forget about usability so we think there's other ways of doing it so the question is what if we can detect the injection and do something about it so this is more or less the question that we had a couple of years

ago when we started working in application real-time monitoring and let me show you what what is application real-time monitoring so it consists in two pieces a real-time monitoring agent this is extra JavaScript that you put inside the website and it continuously monitors for any tampering to the Dom to JavaScript or to event handlers poisoning etc and it does that by leveraging mutation of servers checksumming of certain parts of the website and implementing poisoning detection techniques so whenever something is detected it's sent to the the other piece of this solution which is the real-time monitoring back in and it crunches and tries to determine if it's not a false positive and tries to classify the level of

maliciousness of the attack and then it sends the the classifieds evaluation of the attack to the back end of the application and this is done in real time so in a matter of one second or two your back end will know whether or not certainly something is happening on the client side what kind of injection and it can decide whether or not to keep the user out of the session or just disable certain parts of the website or just freeze account withdrawals or whatever it's up to the backend to decide and to set policies that make sense for that particular website so and with that they can react also in real time so this solution is a white leasing approach it

means that it can detect any kind of injection real new injections or if you want zero day or although your day is something that we call vulnerabilities which this is not it has different levels of sensitivity uses machine learning to to tell whether or not this is a modification that is expected for that website because today's websites are very dynamic they change a lot throughout the lifetime of loading a page and reacting to events in the page and it but it also supports signatures so you can you can identify what you you know and and and have client-side countermeasures to react to what is happening on the client side so you can what we you can do what we call

Dom healing which is basically let's say a bunch of markup has been injected into the Dom so you can remove that in a split of a second but that requires the signature you can redirect the page to another URL you can delete cookies you can execute a callback on on the client side and this is done on the client side without going back to the backend so obviously to do this because our own agents can be a target of the injection you need to be able to have some sort of attack automation prevention so you need to use polymorphism JavaScript obfuscation tamper-resistant codes and make things unpredictable or the attacker in a certain way or if the

attacker is able to somehow modify the code you have to be able to react using tamper resistant code this agent code can also be mixed with the code of the webpage which makes it harder for the attacker to just cut out the agent code and just leave all the other code in the page so it's it will be fully blended together so now let me show you how it works using the same example really so we are going to inject our agent using verb proxy because we are not working together with coinbase in this case otherwise they could just install it this is the dashboard which is now completely clean so nothing was detected so far and let's go to convice comm and

see what happens okay let's proceed to login and we are already seeing things happening on the back and this is actually the first stage web inject which is being injected in every endpoint of the website so we can see the details we can see the endpoint we can see the injection so it's a one-liner loading further JavaScript code from a certain URL this is good to do follow-up investigation to do incident response and whatnot all right and this is the other one so after after loading the second-stage payloads it removes the first the first stage from the Dom so this is the login page and I told you before that there's the tampering to this page let's see what we

are able to detect and as you can see it's pretty fast so it's it's something that you can load even before the user has time to login into the page and we can already be doing some countermeasure or just and in the backend will be warned and probably within time hopefully for refusing the logging in into the account okay so let's proceed anyway we could be reacting at this at this point but I will go into the very end like before just to for you to be able to to see the whole attack this is the normal two-factor authentication that is needed to log in and again we can see the first stage being injected always alright so

remember before initially when we talked about many of the browser attacks and I said that regardless of other authentication mechanisms that could be in place this is what I meant you have two factor authentication but it's by passable so here you can see the detected unusual signing activity part and you can see various parts of the injection you can see a data URI which is probably that image that you are seeing in the bot bottom the the mobile phone let's see if we can grab it let's paste it into the browser this is the spinner the original spinner that you see okay and there's other others injections Casey dump tampering alright and this is the other the other part

that loads afterwards the the mobile phone and requesting the two-factor authentication from the user with all of this information we could be reacting we could be responding back stopping the attack let's proceed just insert the two-factor authentication token and the attack will be finished

okay this is a somewhat slow let me try to speed this up okay two new threads all right you can see a data URI there so it's probably the second image and now let's reach out for the security settings page because we know there's further tampering in that page as well squeek security and you can see in the back additional tampering are happening so let's see the final example so the attacker basically removed all the Dom parts of the security settings page and replaced everything with this single a message and you can see in red this red bar with - it means that everything was removed stripped out of the page all right let's proceed and just about

to finish the talk so in my view cryptic changes are becoming a under threats of many in the browser attacks not only many in the browser but also malicious extensions and also supply chain attacks are becoming a trend - and all of them have more or less the same capability they are free to modify the code of the page they can present false messages they can exit rate information from the page and they are really dangerous and and it's making money for the attackers so whenever that happens for sure we are seeing more of that it's far too appealing to do that to crypto changes because the money is most of the time and traceable so it's not like robbing a

bank where they can we can still try to recover the funds to follow the tracks from bank to bank and eventually in some cases they can catch that the fraudsters and they can recover the money you don't have that in crypto exchanges once money is like we drawn from the account forget it so it's far too appealing for attackers so in this case I present you an example of such attacks a live example so it's a real-world example but you can see this as a warning because in this case it wasn't fully finished attack but it could be so five more minutes and that this attack would be exit rating the funds from from the

account so another thing that's very important like I said two-factor authentication is not the answer for this type of attacks okay I still think it should be implemented but you must be aware of this all right there's all sorts of attacks that are able to fully in paper with with a client sign I think there's room or exchanges to improve their defenses after our survey of what they are doing definitely I think they can like reduce the attack surface they can put further barriers for this to happen I think accounts freezing or withdrawal freezing it's a good measure okay especially because attackers if they let's say this attack the attacker needed to downgrade the security

settings imagine that they had implemented freezing the account for 24 hours this would actually prevent the attack from being successful probably because the user would see an email and would probably be able to do something to prevent the attack but let's say let's say the user was actually exit rating the fun zone okay and let's say that in this case they wouldn't freeze the accounts based on the destination account number so the user would probably receive an email telling him that he just done withdrawal and that would wouldn't be strange because he actually done that and the only thing that the attacker would need to do in that situation with is to change the destination account number

okay so further freezing and further risk reduction would be needed like whitelisting the destination account that would be effective as well so I think the attacks will definitely grow to be more creative and fully automated and you don't need to be an expert in JavaScript in order to do that so we started working in this approach application real-time monitoring which basically change the Assumption we just assume that's tampering will occur because there's nothing really effective to prevent the tempering and and try to detect the tampering and have real-time reactions to that and we think that can be a real help in in preventing some attacks and and reducing the risk so you can you can deploy custom policies even

for attacks that you haven't seen before and you have the you have very good information to study what happened and to just do further investigation you can see the URLs where the information is sent to and this is something information that you don't have available because it all happens on the client side usually you don't log that at all you don't have this information unless it's some information that is going through the server you won't be able to know what's happening on the client side so in if attacks keep failing the rule of thumb is they will move on to other targets because it's easier and the attackers are usually lazy they go for the low-hanging fruit

so if you just deploy more barriers it's it's almost like pushing the problem to your neighbor which is not very good but it is what it is and this is all I had for today thank you

[Applause] do we have time for questions okay do we have questions all right hi it's I it's not entirely clear to me like where's that so for in order for the user to type code for the two factor authentication doesn't mean that there was actually a push from like a legitimate push from the website or is this the kind of two-factor authentication where a code is generated like all the time well actually think about Google Authenticator you can reach for Google Authenticator all the time and it will give you an one time password all right and if the time between requesting one and reaching out for the security settings where the e server will ask you

for one it's close enough then and you can do this with automation then that will work right so would it would it make things harder if this was the kind of two-factor authentication where you send a code well let's see in this case they would go for the security settings after receiving the two factor authentication but they could they could do it the other way around they could read load the security settings page ask for the server to request a two-factor authentication but synchronize that with a message to the user telling him give me a two-factor authentication because of this reason so the only thing that wouldn't work in my opinion is that if let's say it was using SMS if SMS

message would tell the user specifically that it's requesting the two-factor authentication for this exact purpose so they would be able to see to downgrade the security settings okay that would be kind of affect it could be effective because in that sense they would be warned but Google Authenticator cannot have that even hardware tokens won't give you a personalized message to the user yeah perfect thank you hi one question regarding this dissolution is this something that we need to have in the server-side protection for the server-side or is this something for the browser because for me what I in the suit it's something that's it's an issue in the browser not in the in the server right well it's

actually both you have two components the client sites embedded agent which is constantly monitoring the page and then he communicates back to back end piece which is not on your server but it's next to it in a different server and it also has communicates with with your server after understanding whether or not it's a malicious injection so there's two pieces you have is a client side and the server side piece but that's for the solution I was asking for the full attack itself is it a sim for the attacker area it's just a server side right in the browser well it's a traditional man-in-the-browser attack so it's a so the latest more recent attacks from many new browser

they actually downloads dynamically a new payload at javascript pillowed so it's definitely client-side fully client-side but it communicates with the c2 so there's a server side and usually that's how you you find about the threats you just like scan networks for given signals that indicate there's a c2 there and then you just follow the tracks we try to reverse-engineer the communication with the c2 and you find the Trojans and you try to retrieve the web injects from the Trojans and then you understand what is trying to accomplish okay thanks anyone else hi sorry hi just a quick question regarding the load on the server your application does real-time monitoring of the of the webpage presented to the browser what about the

loads or the overhead that is placed on the the server side if you did some some research on that sorry can you repeat what what about what the server side load of the monitoring of the web page do you mean like performance-wise sorry performance-wise yeah yeah from those finds it really depends on the on the on how much traffic do you have and you can do this for every page that is loaded or you can do sampling you can do simply like you can you can sample 10% of your traffic you can sample 50% you can put it in some in some pages but not others so there's all sorts of ways of reducing the the impact on how many clicks you

need to monitor but you can also monitor everything if you want and then the amount of resources that you will need will be comparable to the amount of resources that you need in order to serve your application so it needs to scale obviously another question what type of measures does the application perform client-side to avoid that the exploit actually removes the client communication with the server and it's communicating the exploits that it's finding whatwhat do you mean moves the communication to the client for example if I did that exploit and J scrambler was like a standard to monitor the application I could remove the JavaScript for descrambler that's running in my browser that's what I understood the extreme say

if I understood correctly you would inject the payload the second-stage payloads but then you would like to strip off the script tag from the page yeah okay so it doesn't matter if you do it because it doesn't depend on the solution detecting the Cedeno in scripts okay it just depends on whether or not you are modifying the Dom and like if you're modifying event handlers in the forms if you are placing buttons or if you are just adding iframes I mean removing the solution that is monitoring the page oh this I got it sorry well that can always happen two things first you can mix the agents code with a code of the webpage so it will be

difficult for to cut this solution out of the mix but it it can remove everything and just put something that mimics the how the webpage works and in that case the solution needs positive acknowledgement that it has indeed executed without tampering okay so in order to deem the the session to be clean you need some positive acknowledgement that the agent has run and affected or untempered so and the strength of that realize in the resilience of the code protection obviously there's always a way of defeating this type of solution regardless of how good you are but like I said it's raising the cost of the attack and just be motivating the attacker and probably he will move to

the next story

you