The art of Securing Webviews

they have great experience a ton of experience in you know contesting ethical lacking and they're gonna go through this talk about the webview security as you've already seen from the slides and especially we'll talk about the journey behind the the webview cve uh that they discovered and reported to android um guys the floor is yours thank you david first of all i would like to thank you all for joining this session uh we'll be talking about securing venues and the story behind cbe2021-1136 i'll be walking you through this presentation with my friend and host speaker ingard mohammed so let me start this with quickly introducing ourselves my name is chef sahani i work as a

senior associate with jp morgan i am one of the contributors in overwatch msd and also the author of degree matter of securing android applications hi thank you hi guys my name grab as a is engineer and i'm leading the application security initiatives for various engineering teams here at craft what do you see [Music] so before we go ahead a quick disclaimer any opinions expressed over here solely belongs to us and are nowhere related to our current or past employees so this would be the agenda for today's session we'll be starting this with discussing cve's interviews we'll talk about how exactly the views work once we have established the foundations we'll talk about the timeline on cbe2021

wherein we'll discuss about the overall journey that uh that we went through and the communication we had with google security team next we'll talk about the in-depth analysis that we performed in order to claim the cbe last but not the least we'll talk about common devi related security issues in the way where we could prevent those issues in order to make our apps secure and globus so let me start this with introducing cvs and webview cve is an economy used for common vulnerability exposure it's actually a unique identifier that is associated with a vulnerability in a publicly available software package i hope uh and i believe most of you guys would be aware of the term cv though

webview might be a alien term copy of the folks in the audience that is why we'll just establish the foundations first and then we'll jump to the analysis on on the chromium cb so cv one 2021 six is a unique identifier that is associated with the vulnerability in android web use so during our security research we observed that a lot of mobile applications were actually leaking users or tokens to third parties so when we dig deeper into it we found out that this was happening due to a flaw in android web implementation we'll talk about this in in detail in the upcoming slides so which was just to introduce and talk about on a high level what the

cd was all about so now let's talk about web use so webview is one of the mobile app components that allows mobile developers to load web content directly into their mobile apps so if you see a image over here i have provided the url and then the corresponding web content for that particular url is loaded in the mobile app itself so you could consider it to be a dedicated web browser of the mobile app since they support the concept of code reuse as a mobile developer doesn't need to rewrite the code from scratch and can just use the same the same code that is already available it supports the concept of food reuse and that is why it's extensively used in

the current era of mobile application development so now we know what a webview is let's see how exactly it works so as i mentioned we just need to provide the url that is to be loaded in the webview and then the the corresponding web content is loaded as a part of our mobile app so if you see a code snippet over here we have a load url api so basically this api endpoint take uh this api takes a url and the corresponding web content is being loaded at the at the mobile site so what happens at the backend is when we are using this slowly or api which is an android api and we have provided a url so the front

end would make a network request to www.google.com and the corresponding web content would be received by the front end back from the google google google servers and once it reaches at the front end the corresponding that content is rendered in the mobile app individually so this was the simple way or i would say a normal normal node whenever we are using w's what happens when we want to load a content that is protected through authentication for example let's say we want to load users profile page again backend won't release uses profile data antenna unless we are passing the auth data since it is a restricted content protected content in such cases we would need to pass the auth data in order to

let back-end release the protected resource so if you see over here we have an overloaded version of load url api where an apart from providing the url that is to be loaded we also pass a map so basically headers is a map which is having key value pairs where p is the http header name the value is the corresponding http header value and what happens is when this this api is used the front end would make a http call to the backend and this request the http request would have all these headers attached to the request so now if you see since this is a protected request what i have done is i have passed the authorization header which

would have my authentication token and now backlink would entertain this request and would release the protected resource once it reaches at the front end it would be rendered so if i just sum it up we have two flavors of load url api one is a normal load wherein we just provide the url and the corresponding web content is loaded the other one is an overloaded version of load url wherein we can leverage the same to load an authenticated content or a protected content so now we know what a webview is and how exactly it works now let's talk about details so deep link is is is kind of a uri which helps developers to improve the

user experience so by uri and uniform resource identifier let's understand this with help of an example have you ever wondered why you're browsing web content in the mobile browser and you click on a link and it opens a specific content in the mobile app that is installed on your device this happens because of deepness if you see an image over here while googling i i searched for a particular particular product and then i click on a link and it opens that particular product in the mobile app that is installed on my my device so all this happens because of deep links so deep link is nothing but a uri a uniform business identifier which opens a

specific content in the mobile apps and improves the user experience significantly so now that we know what our webview is and how exactly that views work and a brief on deep links now let's talk about the journey on cv2021 201136 so all these things that we discussed would help you understand the analysis and the journey in a better way my co-speaker embard would be taking

thank you for briefing the audience with the basics of you and how old it works so from here onwards i'll be can be talking about a journey towards our cv 2021 21136

so first i would like to talk about it you know basic example of of an oauth so in a standard or use case uh where we have uh uh this specific slide here we are talking about the standard use case in the context of mobile application so in in this context we have a mobile application we have an identity service and we have a third party service so let's assume our mobile application integrates with a lot of third-party service with the help of all so as soon as you click on the tile on the third party tile on the uh on the mobile application the first call will go to the of identity service with the client id as

well as redirect url in this specific call the user's authorization token will also be sent in the header since it is an authenticated call so now what the identity service will do is verify the odd token as well as it will match the client id uh as well as the redirect url and generate a id token for for the user and and it will give give it as a 302 response to the mobile application now what the mobile application will do it will redirect to third party url along with the id token to the third party service after this a couple of uh after this a couple of uh requests happens where the user gives a

consent uh to share its data with the third party and finally the user in the mobile application can access the third party services so this is a basic or use case example now let's want to understand what was a bug at a very high level so if you see ended step at this step where the user has now got the id token and he is being redirected to the third party services with the redirect url and the id token so in this specific request where we are having an additional adder the users authorization token was also being forwarded to third party service which means that the user session token which belongs to the uh the this provider is being shared

with the third party so this was the this was an observation at a very high level uh what during the during you know couple of uh a couple of use cases uh reviewing couple of use cases and after uh replicating this issue what we have concluded in our uh you know initial observation was that so uh if you are an android mobile developer then you would understand that when you are doing when you are implementing a web view and you are trying to use load url and you will of course use the uh pass the url inside the load url which you want to load inside to help you and in a case where we saw an example where

we are talking about authenticated load we would pass additional http header which will be the authorization header and in the authorization header you will pass the session token so when you are doing an authenticated loadings in such a case then it sends the additional header to any other request trigger in the process of loading the url which is such as redirects so as we have seen in the previous example even if it is a redirect the origin even if it's a redirect and the origin is different the user's authorization token was me exposed to the third party so this was an initial observation now in this slide let's talk about how let's talk about the timeline how we

started doing our research and how it ended up in an uh cve so uh in august 2019 we uh while doing our you know regular day uh regular research we observe this behavior and we suspected that there to be there could be an issue in the uh chromium so in december 2019 we started to doing a deep down investigation about this issue we developed our own uh android application we had our backend application uh written in python and we wanted to replicate this issue and we submitted uh do our an entire analysis to google in january 2020 we got a response from google that this is an intended behavior and they wanted more analysis to do some more analysis

and finally in fact google accept 2020 google accepted and they said they uh require more time to fix and because of compatibility issue and in november and finally in november the official fix was released in chromium 88 so this was a timeline uh of how we got our cv now let's let's uh get into uh a in-depth analysis of the actual issue so here towards the right what we are seeing is a uh demo application which is simply loading uh a webview which is simply loading a url scratchpatch.org inside and review towards the left the port snippet here what we we are able to see is that uh an android webview component as you can see uh we are doing a load url

load url loading the url over here as well as we are setting the additional http header s the authorization header and then uh once the url is loaded the headers will be sent across so if you if you want to uh have a look at this issue you can uh always uh take the snippet from this early given over here so this was our front fronted application let's look at a package so backend is a very simple code snippet where you are just trying to do a 302 redirect so irrespective of any request received uh in in this web server it will do a redirect to scratchpatch.org so after uh you know after when you actually run this demo

application though and try to intercept the traffic this was the initial observation that as you can see the authorization header which we have said if in the initial request while we were loading the uh url is being actually forwarded to scratchpatch.org so now that we have seen a couple of screenshots of how exactly has happened we have recorded a demo uh where we are uh trying actually trying to replicate this specific issue having our own uh you know uh android front end as well as the uh python back-end let me try to play that for you so towards the right what you can see is uh is basically uh [Music] towards the right what you can see is

basically uh uh our android code snippet which is running on four uh android application which is running on the android emulator and this is a http proxy which which everyone knows that bob should this is bubson basically http proxy so let's play the demo as you can see uh as i clicked on this button our request has been initiated towards my backend python flash server and i'm loading the authorization header over here and once i forwarded it i got a response 302 and it is trying to redirect me to scratchpatch.org once i forward this request back to the client which is the mobile application again here so scratch patch.org is getting loaded and if you see over here

the secret header which is the actual user's authorization token is also being forwarded to scratch pipes or quality so this was the exact behavior that we have observed our research that all that users authorization token which was uh for was being forwarded to the third party so now that we have gone through the entire analysis we know the exact issue let let's have a look what was the actual fix that was rolled out and we roll out plan so this was pretty much interesting to understand how exactly google works when it comes to fixing a particular bug so if you want to have a look at the code snippet you can visit this leak over here

which is given over here so so the fix was very simple they they had removed any extra adder from the request so the request is being redirected to a different origin so if if there is an origin mismatch between the request and the response then any extra header will be drawn because it could be sensitive and then they wanted to record a metric on when we added and what was done which means that after the redirect whether any header is being added in the process or what was done to that specific header and the last but not the least they had in test case verifying that the extra headers are clear up so once this fix is in place they wanted to

make sure that uh there is no extra header being added anywhere in the process so this was the rollout and official fix by google so uh now that we have spoken about the cbe we have spoken about peopling webview and uh we we have focused more on the uh exact cbe uh now she will take on from here and he will talk about most common webview issues that that occurs over to you thank you for the detailed analysis uh now let's move to the second part of the presentation wherein we'll be talking about the common web related security issues and the way wherein we could prevent those issues and make our apps secure and global

so over the time uh what we have observed is these are the four most common web related security issues the first one is lack of url validation followed by insufficient viewer revalidation in both the cases what happens is we are loading a ur webview with with no validation in place the first one and in the second one we have a validation in place but the validation is not sufficient and can be bypassed so the first two are related to the amalgamation of webview and a trigger which helps load a particular urm in the w that trigger could be deep link or could be an intent we'll talk about it in the next slide the third one is unintended leakage of

sensory third parties so this is very similar to the chromium cb that we talked about where in all all those cases where in unintentionally we are sharing users or data pii or some business sensitive data to a third party all those categories of issues would fall under this this issue family last but not the least one is insufficient webview isolation it captures the scenarios wherein we are leveraging or using our own webviews to load in untrusted content by untrusted content i mean a partner content or a third party content we will talk about all these issues in detail in the upcoming slides let's let's talk about the first two issues so as i mentioned it it happens when we are

loading a url in the w and there is no validation at all or a very minimal validation which could be bypassed so let's understand the use case first so there could be there could be two ui components by ui component i mean an activity in the case of android and a view controller in the case of ios so there are two ui elements first ui element calls the second ui element and passes a url while calling the second element and the second element is actually having a webview component and it loads the url that is passed by first component in the component of the second component so when we are calling the second component there are two ways or multiple ways i

would say where we could trigger this the first one is a deep link so we could use a deep link if you recall we talked about deep links away when we could improve user experience by just clicking on a specific link and it opens specific content on on the on the mobile app so for for this particular trigger for calling the second component we could leverage deep link or we could have vanilla intense again intents are just messages that two components uses to interact with each other so it could be an intent or it could be a deep link in both the cases what happens is we are triggering this particular ui element which is having a

value component and while we are triggering we are also passing a url and the second component loads that particular url now in this particular use case if while triggering the second component and while loading the url if you have no validation in place it would fall under the first category if you have a validation in place before loading the url it will fall under the second category let's understand this with help of some code snippets so the first one wherein we have no validation at all if you see we have this cheap link w demo app and this deep link is actually having a url so what happens is whenever this deep link is triggered it would open this url

in the w so if you see the code snippet over here we have extracted this url out of a deep link and we are directly using load url api to load this url which we have passed out of a deep link so if you see we are not doing any kind of validation so that is what a problem is so we are not doing any validation and we are directly opening a url which is coming as a part of a good link in in our own battery companies we will talk about the impact in in the next slide now let's understand the second second problem in this particular case we have a same kind of a deep link webview demo app

which has a url while we are passing the deep link we are extracting the url out of it if you see now we are comparing this with a specific domain so we are we are following the standard practice of by listing these validations where we have a domain which is shitsani.com and i'm comparing this with the domain that i have got while passing the url from deep link and i'm comparing whether the domain the host matches in both the cases so either divorce should be shifsani.com or it should be a subdomain of shakesani.com and once this validation passes only then we are loading a url this looks the the right way of doing things right

wherein we have a white listing based approach we have a white list which is sunny.com and we are comparing against that by the problem is the use of get host api so there was a vulnerability identified in implementation of gethost method which which allows uh uh adversary to bypass the validation so now let's understand this and magnify it a bit so if you see we have a profit url here it is having two domains attacker.com and legitimate.com so what happens is when this kind of a crafted url which has backslash and ad symbol separating two domains is passed to get host method it behaves differently so it takes legitimate.com it takes second domain out of this crafted ui

while when the same domain is being passed the same url has been passed to load url api it takes the first url so that is how we could bypass the validation so for validation we have this legitimate.com however when we are loading a url it would this was a very amazing finding and buggy pro uh buggy pro has written a very amazing report on this so there is a hyperlink once we'll be releasing this deck you can go through this so the problem is if i conclude the problem is implementation of get host method as it behaves differently when whenever we are passing a crafted url to a get host api so the fix is

we should not use getpost for validation instead we should use with get authority we will talk about the secure way of doing things in the next section but for now i would recommend whenever we are doing a validation we should not use that host and we should always do a validation so the first one we were not doing any kind of validation and loading the url directly the second one we were having validation but that validation was of no use because it could be bypassed this issue was fixed uh the issue with get host method was fixed in api level 28 however 27 and below are still vulnerable based on my analysis so we should always refrain from using

get host if we are supporting android api levels 28 and below 27 envelope so now we know what the issue is let's talk about impact so again if you see we are able to load a malicious url in webview now it totally depends it depends on the privileges of the underlying webview which is under attack so the impact would be as simple as just loading the html content and phishing the users but it could be as severe as executing remote code on the mobile device or uh exfiltrating users or throughputs so it totally depends upon the privileges of the underlying webview which is under attack the higher the privileges of the underlying webview is the more would be the impact and vice

versa so if i talk about few examples let's say in the scenario wherein we have that views which are configured to have javascript bridges that that would allow javascript which is not now under our control because our value is compromised so this javascript could actually call the native methods with which which could be kotlin or it could be javascript javascript code would call java important methods if this java if this w is privileged enough to have uh interfaces js bridges in place so just to conclude the total impact of the issue would depend upon the privileges of the underlying webview and the higher the privileges are the more would be the impact now let's move to the third issue which

is unintended data leakage so as i mentioned it's very similar to the chromium issue we talked about so there are multiple instances that we have observed wearing unintentionally developers leads users or business sensitive data to third parties let's understand this with help of some examples if you see over here this is a very common one wherein we have seen multiple times users or tokens or id tokens are being sent as a part of referral headers to google tag manager and google tag manager is just one example so it could be any third party domain so if you see the report header we are passing users or token to a third party so we should always make sure that

whenever we are having a third party integration all the network requests are logged and verified for some potential like this in this one if you see we are doing an authenticated load to a third party domain if you recall we talked about a normal load in the webview and authenticated load in the authenticated load we pass auth data as a part of headers additional headers and front end passes those headers to the domain and they are not meant to be shared to resource servers they are only meant to be shared to identity servers which are which which would validate those or data so if you see we are leveraging the same webview component which is doing an

authenticated load to load a third party domain in this particular case we are sending jwt to a third party domain uh the next one is uh sharing auth data or any other sensitive data as a part of query string so query string uh would so whenever you are passing anything as a part of query string it would be logged at back in and by this i mean anyone having access to logs and everyone having access to logs would be able to retrieve that sensitive information be qa engineers be mobile developers beat security engineers they could they would have access to sensitive data including all systems so whenever we have to pass some sensitive data to back-end we should never

use query string and a get verb for making the http call we should always send it as a part of body in the post request so last last one is lack of the isolation so as i mentioned whenever we are leveraging our own that means to load a partner content or third party content all such issues would fall under this category again let's understand this with help of a use case so let's say we have an application which would which which is integrated with lot of third parties so what what happens is a user could use third-party services through our application and these applications are being accessed by user to a webview so our application is having lot of webby

components corresponding to the third parties that are integrated to our app so whenever a user clicks on a particular link uh it opens a web view and it opens a partner content and then user could actually avail services that are provided by third party and this is something which is very common in the current era of like super apps so uh what happens in in the scenario wherein let's say we have this kind of uh implementation wherein the partner content is loaded as part of their deeds so in this particular case if we are using our own web views to load the partner content we are actually opening a door for a potential leakage so what

could go wrong is uh if there is a breach of trust or the third party or a partner itself is compromised the the expected uh legitimate content would be replaced with some malicious javascript and again we are allowing since we are using our own web views the malicious javascript would run as a part of our own values and again now it depends upon the privileges of our own component so the attacks impact would be as simple as just phishing the users by just loading some malicious html uh it could be as severe as exfiltrating users or tokens or doing a remote for execution of the mobile device so whenever we have this kind of implementation in place

we should never load parking content in our own web views we talk about the ways when we could prevent these issues when we could leverage chrome custom tabs in the case of android and safari view controllers in case of ios and that will be taking care of those recommendations so for now we have discussed the most common weather related security issues that we have observed over time in the next section we'll be talking about learnings and recommendations the way where you could prevent those issues and secure our mobile apps and that will be taking it over from here over here thank you uh hi guys uh so uh let's let's let's now understand uh what are the learnings and the

recommendations that we have that we have so far from the entire research and from the entire you know analysis

so the first and foremost like uh in android whenever we have a content provider or whenever we have a deep link so uh let's assume that we have a deep link up in the deep link and if you are trying to pass a url in the deep link so the first thing what we really recommend is to do a secure url validation so to prevent cases where we have seen uh there are you know vulnerable functions such as guest get post which will actually bypass the check you must always use get authority so here uh this is a sample android port snippet where where the function validate url uh uh takes in an url object over here and

after that it checks whether as well as the uh scheme so once this passes the function will return either a troop or a pass the second set of example is in ios the sports library provided over here is is a swift code in which we are using the url component dot scheme as well as url component dot post so here i'm trying to do the same thing and extract the scheme as well as the post from the url and uh and validating it returning either false or true so this is how what we recommend to do a security url validation when you're whenever you're trying to accept the url from the user or via the deep link or

any other way so as she already spoke about webview isolation so this feature comes into a picture where you are trying where you're wanting a user to uh you know access the third party service without any interaction with your native app so for example you don't want to have a native bridge or you don't want to do an auth load or you don't want to share any data you just won't be able to be isolated so in that case in android we have custom chrome tab and in ios we have safari view controller so this is what we recommend like when you want to browse a third-party services so why because it actually doesn't run as a

process of that application instead it it runs as a process of safari as well as chrome process which actually minimize the risk of you know running a malicious javascript accessing non-exported services and you know other component of the mobile application and apart from that as it acts as an embedded browser into your application it also gives a seamless user experience so so let's assume uh let's have a couple of checklist when you're trying to you know secure or android link or let's say when you're trying to harden android deep link so the first and foremost point is this disable employee implicit access to content providers so the set allow content access property will by default disable uh by setting the

this property it will disable access to your content provider so in case you have some send it sensitive information stored in your content provider it can be accessible via the webview but with this specific property you can disable it and the second point comes to the local storage so we have a lot of information in the apps local storage and this can also be accessed through the webview if we uh leave if we leave the default setting on so you can disable it using set allow file access the third point is like uh the with the help of clear cache you can like plus the webview cache whenever the web component is no longer required last but

not the least it's very important most of the cases where you don't have a javascript bridge between your webview and as well as your application so in that case simply uh with the help of this property said javascript enabled simply disable the javascript uh javascript bridge so that uh the attacker is not able to access any sensitive information with the help of people or with the help of any non-exported activity or content provider so now that you have spoken about android let's talk about talk a little bit about how you can achieve this in ios so in ios uh uh people used to use ui webview which is actually now depreciated so if you have

an application uh in ui review it is it will no longer be accepted in the app store as well as update to the existing application is also not accepted why because it has it had a lot of settings which was by default enabled uh and it it wasn't which will allow which which in turn is an open attack surface to you know steal sensitive information to the attacker for example the javascript uh as we've seen in the previous example we were able to disable it but here you can if you want you cannot disable it and other sensitive settings are also enabled by default the successor of wk uh the successor of ui webview comes the wk webview wherein

we have uh different properties with which you can uh you know harden your view for example using the javascript enabled uh property you can actually disable the javascript uh bridge and uh we have ash only secure content for property to make sure the content loader in the web view comes from an encrypted connection and uh apart from that similar to android we have allowing read access to url when whenever you are you know uh have whenever you are having this setting enabled and you have a static page you wanted to load in your webview make sure that you do not give access to the entire directory rather specifically give access to that specific file uh

which you want to load in the webview so apart from that we have allow file access from file url and allow universal access profile url which are security sensitive settings which can be disabled by default if if it is not consumed by the feature so let's move on to the key takeaways for from the entire presentation first and foremost always follow the least privileges while review for example disabling the security settings that we have spoken in the previous slide also disabling javascript if it is not required only allow those uh you know properties that is consumed by the feature second one so use always always use custom chrome tabs in safari you can view controller whenever you're trying

to load a third-party content so that the malicious javascript cannot access the cannot have an interaction with your native web application third one if your pro as we have spoken about the secure url your url validation so if our deep link is trying to load the url ensure that url is validated in a secure way and always while validating the url have an explicit match with the authority and protocol with a wide listed set of urls last but not the least always when you're trying to do a third party integration make sure you have a uh make sure you have a test case in place like in case of google they have a test case

to make sure that no sensitive data is being exposed and also have a check on logs that whether we are unintently sharing any sensitive data to third party [Music] so we want to go uh we are coming to the end of the presentation and we want to thank a couple of people like mona vinodan bruno was involved from the end-to-end analysis and he was a great motivation in doing the entire research and we also want to help uh thank to changu for helping us during the analysis and these are the couple of references that we took uh in our research and while preparing these uh entire presentation i think that that's all from from our

side we are open for questions so if the attendees have any questions they can ask us or leave the question in this slack channel thank you i believe we don't have sufficient time left for questions uh you can you can always reach out to us on linkedin or twitter in case you have some questions thank you everyone yes please thanks to you folks um we have still a couple of minutes before our break uh i actually have some questions so if we see if that keeps you know some time for others to come up with some questions it's what about uh again statistics uh i would say um it seems you know through this presentation

that i mean security is odd right in general so it seems like you have to do your due diligence while implementing you know web views uh so you have to you know again parse and perform a lot of you know um security related um controls and measures do you have any statistics or you know that basically tell us roughly you know how many implementation of web views are actually lacking some security uh measures um i'm talking about for example i don't know usually like i don't know 20 percent of your application that you analyze you know following some issue with you know with security and webview i don't know if you have done this type of research

so basically i we don't have any statistics so so that is why we cannot come on our specific number but based on our analysis what we have observed is most of the times i would say 9 out of 10 times what we have observed is that views are not configured properly so what happens is reviews by default have certain privileges so these default privileges are not even required sometimes so that is why we are unintentionally expanding the attack surface so this is something which is very common so whenever we are configuring configuring we should follow the principle of least privilege so nine out of ten times what we've observed is that these are overly permissive so i

can i can just tell you something based on my analysis but we don't have statistics behind this but yeah this is something which is very common yeah i recall that you know webview it's uh there are a few some vulnerabilities and cds around you know webbings in the past right so it's a very sensitive it's a very sensitive component as you have shown right so powerful still you know requires the due diligence right that we have to so yeah again thank you very much folks and again uh if attendees you have any question we have the public channel you can you know write there your questions or reach out directly to uh shiv and in that

thank you very much gentlemen for your time