GF - Build hybrid mobile applications like a security pro!

good morning everybody um and welcome to bides Las Vegas this talk built hybrid mobile application like a security pro is given by Vanita a security researcher from synopsis a few announce announcements before we begin we would like to thank our sponsors especially our Diamond sponsor Adobe and our gold sponsors Prisma Cloud Sam grap blue at Plex track Toyota conductor one it's their support along with our other sponsors donors and volunteers that make this event possible we have policies about cell phones and these talks are being streamed live except in the underground as a courtesy to our speakers and audio audience we ask that you check to make sure your cell phones are set to silent

please if you have a question use the audience microphone right there to ask or you can check with me or any other person if you want to use it or ask questions you may be asked to make announcements uh so as a reminder the bide Las Vegas photo uh policy prohibit taking pictures without the explicit permission of everyone in the frame these talks are being are also being recorded except in on theground and will be available on YouTube in the future please move over to this side of the room and uh enjoy your talk thank you and welcome Vanita hi thank you hi everyone good morning my name is Venita welcome to my session build hybrid mobile apps like a

security pro I also go by the name Vinnie like my cousin Vinnie in case that name is too hard uh so let's get started so a little bit about me I am a security researcher at synopsis and my job involves evaluating Frameworks and new languages and all of this research goes into static analysis tools that will help C instances where those libraries are implemented in securely before this I was actually in the Consulting working in the field doing pentests and source code reviews of uh mobile apps and web applications so uh most of my clients were in the financial or healthcare industry I live in the Indianapolis area and when I'm not working I like to do things that keep me

off screens like learning new dance forums uh I learned a bit of violin and I also Al like to be outdoorsy and go on Hikes however my current obsession is all about growing some vegetables in my apartment patio and I'm here for 10 days I'm pretty sure they'll be dead when I go back home all right so in today's session we're first going to set the foundation and talk about some basic concepts about mobile applications like their Char characteristics what they're made of uh what that threat model is like how it's different from that of a web application and then we'll go over some basic concepts about mobile apps as well and then we'll go over certain principles of

application security and see how you can use them to build hybrid mobile apps securely you can build them really fast but it's also important to build them securely and we'll use those principles to understand how to do that at the end of the session I have a fun little interactive exercise plan for you all where I'll show you some insecure pieces of code and if you correctly identify the insecure line of code I have some goodies to give away so uh we'll then wrap it up and summarize everything we've learned today and open it up to questions so Going Back to Basics how many of you here have built mobile apps before okay how many of you have been on

the other end of the spectrum and hacked or broken mobile apps before okay I've got more hackers here okay great okay so just really quick some one-on-one for mobile apps uh initially mobile apps were just for productivity right like to check your calendar your email your planner if you remember Blackberry was one of the first ones who made this available to use on the go but now mobile apps are not for productivity I think they're for everything else therefore uh calling a cab ordering food looking at the sky and identifying stars and I hear there's a mobile app to hunt down ghosts I really hope that doesn't work and uh 99% of of these mobile

applications uh cater towards two main operating systems Apple IOS and Android which is owned by Google um all of these mobile applications are built using software development kits or sdks and typically there is there is one SDK per platform which means there is one for Android usually based on Java and cotlin and there's another for iOS and it's usually based on Swift and Objective C so when you have uh SDK per platform what's the biggest downside to that does anybody know yeah have to build Cod for different correct yes so to repeat that answer the downside is that you have to start building uh the code from scratch again when you start uh supporting new

platforms which is a lot of duplication of effort and that is where where hybrid applications came into being where you can just pick a framework like react native or zamon Cordo what have you and you code just once you test just once and then you build it based on the platform that you want to support which means your developers have now saved a lot of time uh these applications are came to be known as crossplatform apps or hybrid applications and they tend to have a lot of web components in them uh for the rest of this talk we'll try to uh use the word hybrid apps to refer to crossplatform apps as well as hybrid

apps um some characteristics about mobile applications every mobile app on your phone is running on its own isolated environment what that means is that that application process only has access to the data in its own isolated environment this environment is usually referred to as a container or or a Sandbox and to talk to other applications on the device or access data in a different sandbox it would need the right permissions and it has to leverage interprocess communication fun fact about why it's called a Sandbox imagine a bunch of kids playing in a big sandbox now I don't have kids but I've been told that's a recipe for disaster because kids don't want to share and it will lead to fights

so what do you do you split them up and put them in their own sandbox and everything's jolly so apparently that's how the term sandbox came into being in the mobile World anyway so uh mobile applications tend to have a lot of code and lot of data on the device because it cannot bother the server every time it wants to access some data that you as a user frequently request for example your display picture your username your email address it tends to store this data on the device so that it can quickly grab it and render it in your mobile application because you probably open your mobile app more often than you do web apps so mobile apps tend to do that

and in terms of how it would communicate with the server it's not very different from that of a web application it would typically make calls to the server using rest or soap API calls authentication is something interesting in mobile apps because in web apps you would probably use username and passwords to log in every single time I'll try to stay here uh you probably are going to use usernames and passwords every single time you want to log in but mobile apps make this easy they make reauthentication easy because mobile apps can Leverage The biometric authentication and the passcode that you already have on your device which means mobile apps could save some session information or username and passwords or

GWT tokens they tend to save them on the device now everything we've discussed so far is what the uh what the mobile OS provides by default in terms of security context but this is your device you probably want to tweak it and customize it for your own like liking imagine you had a laptop and you did not have root access or admin access on it you wouldn't be cool with that similarly some users like to have the ability to really own that device and make it work for them and not have to work within boundaries so such users could jailbreak or root their phone which from a higher level means you're just disabling all of

these security features and isolation but hey you can download that cute little emoji keyboard right so going over the threat model of mobile applications in my opinion one of the biggest Assets in mobile apps is data now in web apps too data is an asset but in web apps most of the T data tends to be on the server side in a database or on the cloud but in mobile applications like we discussed before a lot of sensitive data could be stored on the device so it's a very big asset similarly the code of a mobile application could be on the device which means that it's not just UI code there could actually be some validation code

there could be something more interesting than just like low impact UI code so that is also a very big asset and we discussed about how user credentials or session information could also be stored on the device so threat agents to all these assets could be um other malicious apps on the device or it could be someone who has stolen your phone especially if it's j broken maybe it's easier to access that data uh and users are also threat agents because at the end of the day an attacker is a user and they're trying to understand your app to understand how to break it but in general the likelihood of a successful attack on your mobile application is

considered low because first of all the attacker has has to uh stay up to date with all of the security updates that uh these os are making very frequently number two the attacker may need an already compromised environment or has to chain a bunch of vulnerabilities to get uh to get uh high impact vulnerability so that is why in general it's mobile application exploits are considered to have low likelihood okay so now let's get into HB mobile applications which is why you're here so like we discussed before what is a hybrid mobile application it is something that you just code and build ones and you can release it for multiple platforms and it's not just for mobile oses it

could also be for Linux or Mac OS or even on web browsers so it's it's gotten really really easy to build hybrid mobile applications thanks to these platforms uh thanks to these Frameworks and um and these Frameworks tend to be uh Cordoba or ionic flut react native and uh because these Frameworks have made it so easy hybrid applications are on the rise in fact according to recent statistic uh a lot of the retail applications in the market right now are built through one of these Frameworks so just a fun fact so how would you go about building these hybrid mobile applications it's just like any other mobile app you start by creating your widgets your UI except in

hybrid mobile applications a lot of this is already done for you a lot of this is already pre-built and tested and made available to you through libraries and uh when I talk about libraries I like to use this example they uh uh consider you're trying to make a big bowl of chili for a barbecue you're probably not going to go and get all of the individual ingredients and cut it up and chop it up and add it to your chili you're probably going to get canned beans and canned corn and add it and save time so similarly with hybrid mobile applications a lot of the functionalities not just for UI whether you want to implement data storage or uh

talking to the server or uh trying to implement biometric authentication all of this code is already tested for multiple platforms and made available on package managers like npm or pub. Dev depending on the framework and you can just like grab that library and plug it into your code and you just have that functionality like that this is another reason why hybrid mobile applications are really easy and very popular uh because it's so easy to create these libraries are usually maintained through open source or through the community of that framework and currently here are some numbers flutter has 36,000 libraries and react native has 46,000 libraries and that number is just growing it's just making it easier and easier to plug in and play

your hybrid mobile applications here here are some examples of hybrid mobile applications in the market right now some really famous ones BMW Skype Walmart so many of them here's an example of what a library would typically look like here on the right side you can see that the library's name is local o it's a flutter Library it's maintained by the package manager Pub dodev um you can see that it's supports three platforms Android iOS and windows it seems quite popular 99% popularity and it's maintained by uh the verified publisher of flutter now if you're a developer you would probably stop at this page of the library documentation or maybe you would go to the installing

page or look at an example see how you can implement it but how many of us really go deeper and understand how these apis work do we really look at it from a security perspective I don't know so we learn how to do that in this talk so here's an example sample code of how you would use this Library so you would add this Library as a dependency you would import it into your project and then it's as simple as calling the authenticate API to implement biometric authentication for your user if you didn't have this Library you probably will have I don't know three times as many lines of code to implement this so libraries really make it easy now uh I

saw that there are a lot of hackers here can anyone recognize what's wrong with this code is there anything

insecure so if you're a pent tester and you've hacked mobile applications before you will see that this API returns a Boolean value and if you've hacked mobile apps before you know that it's extremely trivial to flip the switch on a false Boolean to a true Boolean and trick the app into thinking that authentication actually passed but it would have failed so uh such kind of validation is considered insecure it's called um event-based validation and we will talk about that more in a future slide Okay so we've talked about hybrid mobile apps we talked about the fact that you may be building these hybrid apps through a bunch of libraries from the open source it's third party so I

researched this I research such things in my job so why don't I just give you a list of secure libraries for every framework for every functionality I could do that but what if that Library gets outdated or what if there's a cve in the future or it gets associated with a supply chain issue what would you do then so let's take an alternate approach and go by this if you recognize what this means it translates to if you give a person a fish they'll just eat once but if you give if you teach that man how to fish they will eat forever so we'll take a similar approach today and see how we can evaluate libraries on our

own and uh to do that we will take the help of five principles of application Security today and see how you can uh comply by them use them when you're picking libraries or when you're writing your hybrid mobile application from scratch it doesn't matter these these principles will really help you okay so the first principle I have is called the principle of least privilege and what it means is that less is more or that you need to have a granular permission model when you're building a application web or mobile it doesn't matter you need to work on the least number of privilege privileges that you can get by with so mobile applications need the user's

permission to access a lot of features on the device like Bluetooth or location or or Apple pay a lot of things are photos so user has to explicitly Grant permission to the user to do this uh but your application shouldn't ask for permissions it doesn't really need like you may not want to think that oh maybe I'll need it in a future release I'll just ask the permission it doesn't work like that users will get suspicious and you may also violate some data privacy laws depending on where you're using that application so let's take an example to understand this principle assume that there is a music streaming app like Spotify and that app asks permissions

for your devices Bluetooth it's fine it probably wants to connect to a speaker but what if it asks permission to your camera or microphone it probably doesn't need that permission it is suspicious it's violating this principle let's take another example a food delivery app can someone name a suspicious permission it can ask cont cont yes correct yes that is the correct answer answer uh so when you're building a mobile application you probably want to make sure can I try to I will try okay thank you okay great so when you're building a mobile application you probably want to work on the minimum set of permissions and when we talk about hybrid mobile applications uh you may be using a lot

of libraries for different functionalities like data storage or uh biometric authentication or web views so you want to make sure that the library is not asking for permissions that you don't really need and even if it does you want to make sure that they're configurable that you're able to turn them off and they're not and the library is not forcing an insecure default on you you may also be using libraries that help you uh handle these permissions like checking if the user already granted a permission or maybe you could it it it helps you uh ask the user for permission at runtime so in either case it's important to again have a known set of permissions you want

to allow and uh make sure that you're explaining to the user why you need that permission so that they can make an informed decision applications also tend to expose some of their functionalities in the form of say intents or Universal links and you may want to put some restrictions there too and not expose it to all applications on the device you can make use of app groups make the app belong to a certain group of applications so that you uh expose your functionality is only there or you could even make use of what the native OS provides like onetime access or signature based permissions you can leverage all of that which libraries may not provide the next principle I have for

you is called security by obscurity and yes that is my cat hiding behind my plants and she thinks she's obscure but she's not so uh what this principle means is that if the inner workings of your application are completely hidden you're safe that doesn't sound right does it and you would be correct that is a myth and that has long been debunked uh but let's think about this principle from a mobile application perspective we discussed how mobile applications are very client heavy which means a lot of the code and data is actually present on the device so maybe this principle can be helpful assume that you released your application without any obscurity or aisc and an ATT ER can download this

application they don't even need an account on your application they can just decompile unpack your application understand what's going on understand the different methods and classes and they can use that information to perform targeted attacks at your users or or at your server so you want to make this really hard for the attacker and how you can do that is make your code really hard to understand now if you're a bad coder like me then you're probably already there it's already office skated no one can understand it but if you want to do it the right way make sure that in your hybrid application any framework that you pick any library that you pick uh make sure that the obfuscation

options it provides work for all the platforms platforms you want to support and that these options work for uh all the languages in your source code and not just the code that it comes with all of these Frameworks come with their own languages like react native comes with JavaScript flutter comes with dart and sometimes these code off fisc options could only work for those languages but you don't want that you want to have coverage for everything in your repository um some other ways that you can uh obfuscate your data is by using uh code splitting which is exactly as it sounds it's breaking up your code into multiple pieces so that it's harder for an attacker to put two and two together

so moving on to data in your application you know all the data that's on the client side you want it hidden you want it obscured from an attacker's Pro malicious process or hands so how do you do that one way obviously is to encrypt any sensitive data that you're storing on such an exposed client side environment so when you're using libraries in your hybrid mobile application to handle data like fetching data from a location or writing data to a location or sending data to the network in all of these cases make sure that you're encrypting sensitive data make sure that the library actually SPS safe encryption and please don't use in-house crypto you probably want to

make good choices when it comes to encryption algorithms key generation algorithms hatching algorithms and uh even the key size you want to make good options there because the library is going to give you a lot of algorithms that you can pick from so it's up to you to make the safe Choice there now an interesting challenge you'll come across when you go to implement encryption in your mobile app which is when where will you store the encryption key it's the client side does anyone have an answer yes yes correct yeah you can do that any other answers yes yes correct yes so a lot of options here one answer was do PB pbkdf2 derivation one was using the secure

Enclave all these are correct answers so you can always save encryption keys that uh in a location that is backed by OS sec security for example a keychain this is backed by uh the uh security that secure enclaves provide so that's a great option uh you also want to make sure that you're obfuscating any data that you're displaying to the user especially sensitive data like passwords and Social Security numbers especially if they're going to come to Defcon and other conferences you don't want them to enter payment information in such a public area so make sure that uh when you go to build uh uh display forms or forms that Tak in user input sensitive user input

make sure that the library supports masking of sensitive data moving on to the next principle is called minimize the attack surface and what this means is that what what exactly is an attack surface it's all of the uh entry points into your application that an attacker can leverage and launch exploit through now if you want to secure app you probably want to keep the number of such entry points to the absolute minimum and uh in mobile applications there are a lot of ways through which data can enter your application a lot of untrusted data can enter your application and in my opinion in hybrid mobile applications the biggest culprit to open up your app and

take in uh untrusted input are web views a web view is like having a tiny little web browser in your mobile application that that hosts or loads an external web page now you may be trusting this web page but if you think back you're again violating to some extent the least privileged principle CU you're trusting something external and noing it in the context of your application so when we talk about web views obviously there are web elements like HTML and uh JavaScript and when I talk about JavaScript we have to mention the vulnerability anybody knows JavaScript xss yes correct yes so uh xss is scary sorry I get it here so xss is scary but it's especially scary in

mobile applications because because this script this untrusted script could actually have access to the sandbox in your of your application or maybe your application has permissions to other components in your device like contacts or Bluetooth and the script could actually have permissions to all these applications because of your app so you want to make sure that when you build web views I'm sorry the mic is just echoing a lot here okay that's better so when you're building web views just make sure that uh you're validating any inputs that are coming in through untrusted sources and it's not just user input some other untrusted sources could be the clipboard or the system keyboard cuz everything on

the device has access to them so you want to make sure that anything coming in to your hybrid mobile application is getting validated and sanitized and uh when you pick a library to handle all of this user input for you to create forms for example make sure that the library supports you um in performing such validations uh when we talk about attack surfaces it's also important to mention deep links and Android intents and what that means is that you are exposing certain function functionalities to some other applications through something like a URL and this URL can actually have query parameters and these query parameters can enter your application and corrupt what's in your sandbox so

again you want to make sure that you thoroughly validate them and it's always best to keep it to the absolute minimum and not accept untrusted data unless absolutely necessary you want to limit such functionalities here is some sample code about an insecure web View as you can see you have created uh a web View and then you are injecting at run time some JavaScript that will take user input and manipulate the inner HTML of that web page so this is really bad and it'll open up your application to a lot of injection attacks so we've talked about how untrusted input could enter your application and cause trouble but there are also other ways where you increase

your attack surface and one of that is uh writing data or leaking data onto untrusted locations on your device so you want to make sure that when you pick libraries for your hybrid mobile application you want to make sure that it does not do any excessive logging you want to make sure that you follow good practices and not log sensitive data or uh save user data on a location that's outside your control like external storage you want to make sure that you keep it locked down and uh Leverage What the native OS provides to keep everything secure and isolated all right the next principle I have is called a principle of client trust and what this essentially means is that you

shouldn't trust the user using your device and you shouldn't trust the environment in which your application is running I like to use the phrase trusted on busted what that what that means is that trusted code is running on uh a busted environment and uh you want to make sure that your application stays resilient and protects the user even in such a compromised environment so let's break this down and see what it means what trust means in each of these components let's talk about libraries first we talked about how hybrid mobile applications are probably going to bu be built with libraries and these libraries are thirdparty so obviously third party risks are inherent you cannot avoid that

but you could have some practices to make sure that you are mitigating the risk that comes from these third party libraries uh which involves performing periodic software composition analysis so that you have an idea of all of your dependencies and what that opens you up to and you want to make sure that the library is from a verified publisher you want to make sure that there are no cves and uh you also want to make sure that uh all of the security controls the library provides Works work all across the platforms that you want to support now let's talk about the network how does the client know that it's talking to the right server counter part does

anyone know how do mobile apps do that yeah yeah correct yeah so the answer is certificate pinning yeah so the answer is certificate pinning and uh in your hybrid mobile application you may be using a library to do this for you again it's important to understand how that certificate pinning API Works make sure that it doesn't return a Boolean value it's not event based because we saw how easy it is for an attacker to flip that switch and trick the app into believing that it is talking to the right server where it may not be doing that and the native OS also provides a lot of good uh network configuration controls to make sure that uh the app is talking to the

right server in apple the option you have is to use application transport security settings it's usually just a configuration file or pist file where you can specify a lot of Network Security Options like forward secrecy or uh enforce https communication with the server a lot of those options uh moving on to the user why shouldn't you trust the user because at the end of the day a user could be a hacker again who's trying to break your application or there are two other kinds of users the extremely tech-savvy one who probably J broke their phone and has some suspicious apps on their phone or the extremely non- techsavvy user like my grandmother who probably has clicked all links and

install all kind of malware so you want to be you want to make sure that your app actually is safeguarded even in such an environment you want to help the user make good choices you also want to protect the user from themselves how do you do that let's take an example say that your uh user has downloaded a third party keyboard and they're using this keyboard to even enter sensitive data in your application that's a great way to for attackers to harvest credentials of your application so as an app developer what you could do is you could enforce the system keyboard for such sensitive uh fields which means you have to force the user to only use the system

keyboard and disallow any other thirdparty keyboards from being used especially when it comes to such sensitive areas in your application so when you pick a library to handle user input in your hybrid mobile application make sure that it supports such um such kind of uh enforcement of ke boards you want to make sure that um you help the user this way and uh help them make good choices um you also want to make sure that uh when you're using uh the keyboard uh you want to make sure that the user is not able to bypass that enforcement that you have there are some ways where again it's event based so it will be bypassable so I want to make sure again

that it's not uh event based the next principle I have the last one is called defense in depth and uh this is what this essentially means is that you should strive for holistic security you want to make sure that you have multiple controls in place so that if one fails you have others protecting you from chaining of vulnerabilities and hence avoiding a domino effect um there are different defense and depth strategies you can take in uh mobile applications one of which is uh ensuring that your application does not run in a J broken environment so does anyone know how you could do this without using Library how do you detect that a user's device is J

broken yeah this is a hard question

yeah yes correct so the answer that came from the audience is that uh you want to ensure that you're not able to Fork a process you're not able to uh run certain processes or open certain files I think that's what you said so yeah I'm going to try to do this let's see if I heard someone please don't sue me oh thank you sorry about that okay great so uh yes that is the correct answer if you are implementing jailbreak detection uh in the native code you probably have like several different checks you can bundle together and ensure that it's not it's not J broken but see in hybrid mobile applications you're probably going to use a library

to do jbre detection for you and what these libraries will do is that it will bundle all of these multiple checks into one single API call so that you can just call that API and depend on that API to check for jbre and now this API will again return a Boolean value which is again very easy to bypass so what can we do what should you look for you still probably want to use such apis but you want to use it secure so when you pick such Daybreak detection libraries make sure that it is result based and not event based result based means that it doesn't return a Boolean it returns like a type so it's harder for attackers to

uh to spoof that and uh some other defense in depth strategies would be uh making sure that it is running on the latest OS version of that platform because typically the latest OS versions have all of the security updates in place and hence it is hard order to uh bypass it and you also want to have some anti-reverse engineering uh controls in place not allow any debuggers to be attached to your application process you also want to make sure there's no debug code or development code left over in your source code uh there are some Frameworks where uh there could be some debug or development code in your repository and it doesn't get stripped when you uh get

it ready for the release so you want to watch out for such things and um in general you want to make sure that the library is clean not associated with any supply chain risks no cve is being kept update it's actively maintained you also want to make sure that there are no deprecated methods that's a big one a lot of the libraries have a lot of deprecated methods that uh that uh that a native o probably cannot understand so it might malfunction and open it up to security issues so you want to watch out for that so that was the last principle I had now we can play that exercise that I said so I'm going to show you some

Library documentation uh I've got three libraries that I'm going to show you so I have three chances um and if you correctly identify what is an insecure option or an insecure line of code in that Library documentation um I'll give you that little orange ball so the first Library I have is uh something that you can use to Hash data and it lets you pick some hashing algorithms uh to to Hash that data so here's that API and here are some options can someone recognize what's bad here yes yes correct yes yeah any other yeah yeah here I'll give you another one forget about it uh yes that is correct I think I already gave you one right no here I'm

sorry all right so the next one I have is a library that does SE pinning but you don't need to know what is SE pinning it's that obvious what is insecure any any guesses yeah the this one yes correct so if you can see this Library lets you disable all security which means you can disable sech pinning for that for that uh application thank you so much I appreciate it it's a good idea no I was going to get ready to but there's so many obstacles on your way I'll hit someone in the head so yeah so disable all security is an option that this Library provides thankfully it's not set to True by default so this is a option that you can

use to disable SE pinning for a specific URL so the next option the next Library I have is something to launch a web view in your hybrid app and these are all the options you can configure the web view with it's the last Library this one is a little controversial but I'll wait till you guess

it okay I'll give you a hint it's something to do with Boolean yes yes yes correct yes I am so happy that that was the last question this is my last one okay great so uh yes that is correct with JavaScript is set to true you probably don't want to create web views with JavaScript running by default you want to turn it on on an as needed basis because we talked about it earlier it's just increasing your attack surface it's not a good defense and Di strategy to keep it on by default that's an insecure default okay so let's summarize I think yes I think we on time so to summarize hybrid applications are really really

easy to build they're really really easy to just plug in and play and support multiple platforms multiple users at once so you want to make sure that when you build one you're building it securely and if you're not a developer here you're someone who manages some developers who help who support the security aspect of application development in your company you can support them by maybe having them uh take a course on uh the security aspect of the framework that they decide on during the design phase of the sdlc process so maybe that is something you can do if you're a developer and if you're trying to pick libraries to implement different functionalities when you go to code this hybrid mobile app

make sure that you really scrutinize this library and understand what the API does go past the example page in the documentation go deeper into the API documentation and make sure that it does not have some insecure defaults is not using event based authentication or event based validation and uh you want to make sure it does not it's do not have cves and if they are it's patched you keep the library up to date all of these great great controls and do not forget that the uh that the native OS actually is trying to help you it has a lot of controls that you can also leverage so make sure that you complement your security controls with

the OSS controls okay so real quick here are some res resources that you can use when you're more interested in this topic uh I like I like the mg guide by oasp it's not necessarily for building apps but it's more for getting a perspective from the from the attacker's perspective to understand how a mobile application could be broken there is the ovas mobile top 10 um it gives you the top 10 vulnerabilities right now for mobile applications and uh right now they just came out with their initial release for 2023 you're interested uh there is the n document for mobile device security this is not really for mobile apps but more in general how mobile devices are used

and what OSS could provide and lastly there's the OAS cheat sheet Series where uh it's a quick reference for developers in case they want to refer to some security controls per uh category or per Concept in your mobile application I would also like to mention that it's not a b bad idea to read the security context documentation that OS is release it's really not technical jargon it's actually very easy to read I've I've read the Apple's IOS security context document it's it's really not bad it's not like a user agreement so it's not boring so I would really recommend reading that too cuz then you'll understand how the native OS works and how it tightly integrates these security

apis so that you can leverage them when you go to build your hybrid mobile app with that I will thank you all first of all for coming thank you for bides and any questions I'm sure if you don't catch me here I'll be outside so thank you everyone for

coming please if you have questions you will come over here to ask thank

you okay guess no questions that's uh okay there you are thanks there go one of the big things that I like to do when when I'm implementing stuff is put uh checks in like the continuous integration environment do you have any like ideas or recommendations about like static analysis tools that you can use as a part of because it's easy to check once but like I may not remember you know 6 months from now whether or not that library is still maintained or whether it's you know on the latest version of the mobile operating system um is that something that you have any recommend ations on uh yes so um there are a lot of static code analysis tools

there are free versions and paid versions but all of them uh have all of these rules that you can use to uh identify such insecure implementation of libraries uh now I'm from synopsis synopsis has a great static code analysis tool that you can use as an IDE plugin so that developers can catch it even before it hits the pipeline you can put pre-commit Hooks and what have you uh and uh yeah I think does that answer your question I'm not supposed to mention tools I I signed an agreement okay all right any other questions okay well uh thank you all for coming have a great conference thanks thank you