Thank you so much. So good evening, everyone. So this is the first security, I mean mobile security topic that we are going to start in the Tequila series. So before that, I want to know how many of them are from security testing background or any basics about security testing or all of automation engineers. OK. Why? Because I want to go in depth with the security terms. That's the reason I'm asking. So all are novice in security testing, right? OK. So first I will start with the mobile security testing today. And OK, so the introduction. I'm Anand Kumar, having 7.5 years of experience in the information security field with some additional skill set of performance, accessibility, and automation as well. And I have completed certified ethical hacker as a certification. And currently I'm doing OACP as well. So this is my introduction. So going on to next slide. So these are the topics today we are going to talk. First we are going to talk about how is the current world looking into the mobile application attacks, how many attacks are happening.   So first we're going to discuss that in mobile attack trends. And next step is the mobile threats. So now we are adapted the mobile environment. So we need to know in what level and what component wise, what are the common threats that going to be happening. So that we have to know because in some applications the attack may happen, the attack may not be happening. So we may not be aware about what is that attack will be happening to the component. So we need to know what are the components first and what will be the common threats going to happen with that component level. So that kind of common threat level we are going to discuss in second agenda. And third thing, by concluding these two things, so what we are going to propose as a solution to mobile security. This we are going to see in the third topic. And then fourth thing, so in non-functional testing, everything should have a guidelines. Let's say security testing, there should be some guidelines. If it is a web app security, we have separate guidelines. If it is a mobile app security, we have a separate guidelines. Okay, let's come to the accessibility testing. Accessibility testing also, we have some guidelines. So everything should follow with the guidelines. So for mobile security also, what are the guidelines? Like what are the predominantly accepted guidelines throughout the world? So we will be going to discuss one of the guidelines today. And then general, today's 2019, what will be the expected threats to our mobile application so that you can go and highlight to your project team, a boss, this will be the upcoming threats or we save our application or not. So like that you can go and mingle up with your project team members as well. And the final topic, like take away, what will be the conclusion and then we'll go up with the question and answers as well. Fine, shall we go? Yeah, okay. So just a quick thing, like before getting to that, you all will very well known that what are the operating systems here? Like Android, iOS, Windows. In Singapore, mostly we will be using like Android and iOS. And coming to the app level thing, like we have three categories. You all know that native app, hybrid app and the web app. So what is native app is nothing but just, it's the application we are going to download from the Play Store and it's going to be directly interact with your OS level. So this is native application. But if you go to web application, it's nothing but the web application is that you are going to run in the mobile browser. That's it. It is not going to download from Play Store, okay? How the web part is going to weave in your mobile browser, that's it. But if you go for hybrid app, it's a combination of both native and web. So some component, it's still the hybrid app you can download from the App Store but few of the components you need mobile browser or some other components to work on it. So the interaction will be with the OS level as well as the browser level. So that is hybrid level. So are you clear with it? So three types of applications, native, hybrid and web. Mostly we will be concentrating on native level applications for today's session. Okay. So for any doubts? No. Okay. So to come up with this session, I have researched on Pradio Mobile Threat Report. This report they released by Q1 2019. In the quarter one, they have released the statistics. They have did a overall research about all the zone-wise, like continent-wise, with the various applications. So based on all this attacks trends, we got this as a three highlight points. So 90% of the time what we are going to use in your mobile is full and full app level interactions. So app consists of all our data, all our profile information, all our, what to say, the interactions, everything is going to store in the app level. So this is going to be the target for all the cyber criminals. They won't concentrate on your mobile hardware or mobile IMEI number or whatever, nothing there. They will only concentrate on your app things. So this is their first target because we are spending more time in that. And all the 61% of mobile applications have code vulnerabilities. So we will be developing the code for mobile applications but we are not ensuring that it is a secure code. Still flaws are sometimes we are using third party libraries and that third party libraries also having some vulnerabilities. Still we are accepting that risk. How many of them aware that your application have some risk but it will be considered as a low risk? So we will be accepting that low risk and we will be implementing that framework in our projects. It is happening, right? Okay, so that's why. So 61% of mobile application still have the code vulnerabilities. Example I am saying one of the application, sorry, one of the component called jQuery. Okay, it is very commonly used but that version will not be updated to the latest at all. Why? Because it will break the compatibility with the other components. You can go and check your developers. None of the jQuery component, today the release jQuery component is 3.3 something version it launched already but still people are using 1.2, 1.3 like that. And that contains many security vulnerabilities like cross-site scripting, many attacks, denial of service, it could lead to that attack but still developer are accepting and even though we're saying that this could consider as a low threat. So they don't want to fix it up. Okay, so these kind of things are happening. So that's why the percentage reached 61. And coming to the third thing, the exploitation of the unpassed vulnerability can lead to the system takeover and measure. Okay, here vulnerability is nothing but defect. Like how you people tell in functional testing same and here we call it as vulnerability. So unpassed vulnerability means like example, our mobile application could be running in some infra level, right? So that infra has some IP servers and everything. In that IP server, what is the OS version? What is the OS kernel level? Suppose now we are using RSL 6.7 or something but still people will be using six versions. And we won't be updating the security patches also. Even think in our mobile itself if iOS release 12.2, how many of them will update our mobile OS at the night itself? No one will do that. Even the mobile Android also. Android now it is reaching eight, I guess. Android Pi version. But still people are using Marshmallow or something like that. We won't go to the up to date level also. So these are the things which leads to system takeover and major data breaches also. OK. And thus the pie chart represents how the vulnerability spread over like application network device level. But 70% of the attacks are happening in application level. It is not happening in network or device. Most of the time, most of the attacks, most of the data leakage, everything is happening based on app level only. And one more thing to say, each and every day, 24,000 mobile apps are blocked by Android Play Protect. You know what is Play Protect, right? If you go to Android Play Store, you can see Play Protect will be there. That will scan your applications, whether you downloaded from any malicious thing or any spyware or any malware. Like that you can think. So you can just play it, play protect. It will tell, it will scan all your applications and it will give you the list. Like if you download any unwanted malware, it will highlight you. So that Play Protect is telling, every day, 24,000 applications is being blocked by Android. But iOS, somehow we are lucky, those who are iOS users, the list of applications is very much less compared to Android. So Android is very much high in vulnerability compared to iOS. And coming to the vulnerability voice, data leakage, DOI is denial of service. Third one is encryption weakness. And fourth one is man in the middle attack. What is man in the middle attack? Like my mobile device is there. My server will be there. So whatever the input, whatever the actions I'm doing in my mobile, it will be travels over HTTP or HTTPS to go to the app server. In that middle, someone can intrude. Someone can monitor. Or someone can listen. What data is moving from your device to the app server. So in that area, if someone intrudes or someone alter your packets, I mean, alter your data, and that goes to the server and come back as a malicious request, that is called man in the middle attack. The example of man in the middle attack, what I can say today is unsecured public Wi-Fi hotspots.  It may be somehow intruded or somehow monitored by some other people.  Everything will be monitored by few other attackers. So always go with secure Wi-Fi hotspots. So these are the major attack trends what we are looking in nowadays. So hope you haven't cleared with the terms and everything. Now I said the second agenda, what are the common threats? I want to know what and all the threats is possible with my mobile environment. That is what we are talking here. So here we divided into system, device, and the back end, and what will be the network level. So with respect to the application level, what will be the things like sensitive data storage, whether my PII information or whatever the personal information or credit card number, if it is going to store inside the mobile, that is called sensitive data storage. And second thing is no weak encryption. Suppose I'm using the weak encryption. Let's say my encryption algorithm is MD4 or MD5 or it's SHA1, SKCA1. These are all deprecated algorithms. Please advise your developers. Don't use these algorithms. This is all deprecated. Easily can be exploited, OK? And third thing is improper SSL validation. Yes, this is very good point. Why? Because everyone will go for SSL search. Everyone will go for SSL configuration and everything. But whether they do the proper configuration of the certificate, that is the question mark. And still some people, you can see in the browser, HTTPS will be there, but some int mark will be or int or cross will be there or red color it will be there. Why it is coming like that? Because invalid certificate or certificate may be expired already. Even though if you use SSL, if you are not use proper certificate pinning, then that is the issue only. And third thing, configuration manipulation. This I will coming to the upcoming slides. What is the configuration manipulation with respect to app level? And runtime injection, as I say, when the application compiles or something like that, then dynamically some values will become injected. That is called runtime injection. Privilege escalation is nothing but authorization mismatches. Suppose low user can be acting as the high user. Let's say I'm the reporting person, but by manager. But I can be acted as my manager. So that kind of escalation is called privilege escalation and device access. So these are part of the application level. Then coming to browser level, phishing, you all know phishing what it is. Like one of the question before that, the Facebook, ph-b-h-o-o-k. So that is under phishing sites. It's look like the legitimate website, but it is not. There will be a small slight alteration. You have to very keen in identifying the phishing site as the normal site. I will tell you how the attackers are doing the phishing website also in the upcoming slides. And framing. Framing is nothing but overlapping of the windows. Like first, I will be running my application in one window. Suddenly, I will be putting some iframe attacks. Iframe means nothing but whatever the attack you are injecting, it will be overlap your screen and then it will be executing there.  Like whatever the data is passing from that device to another device, he will silently use drop. And he will capture the information, gather the information. Example I'm saying, some of the people will be watching porn. And your camera will be, I mean, some of the attacks, some of the, OK, this is common. Don't mistake me why I'm giving this example. Because some of the cameras, it will be automatically running without your knowledge. So these are the things that that also comes under an overframe only. And if you're taking any exams, exam and invigilation, proctor and all that. So that also, the invigilation will be happening in the back end. But that won't be visible to you. So this and all, like a framing concepts. And third thing, clickjacking. Clickjacking is nothing but there will be some, OK, this is the application. And for information, please click here. If you click here, you will be redirected to the phishing domain. So those kind of hyperlinks, those things also will be there. And mouse hovering, everything will come under clickjacking. And man in the middle, I have explained. Buffer overflow, nothing but just if you are allocating few memory bytes, but your program will run in more memory. So it will lead to the buffer overflow attacks. That also cause some of the security issues. And data caching, nothing but data will be resided for a long time. And you will cast the devices. And it will be stored for other purposes. And phone SMS, baseband attacks, SMS phishing is normal, OK. And communication channel wise, I'm telling like, it's a transport layer. No Wi-Fi, sorry, no weak Wi-Fi encryption, packet sniffing, session hijacking, this and all happening in that. And going to the database level, the SQL injection, you all know it's related to web application attack also. And this is number one attack still today. SQL injection is the number one attack in all the web applications because its impact is high. If it is going to compromise, your database is compromised, all your information will be collected. I no need to interact with you or the application also. So that's why SQL injection, privilege escalation, these are very important. And with respect to mobile, you people will often hear the term called jail breaking. Have you heard before, jail breaking? Jail breaking is nothing but in your iPhone, everything is controlled by like iOS and everything.  You can install your own software, you can install whatever, but that leads to many vulnerabilities because Apple won't provide security patches. And you also jail break the device. Now it's an open market. Anyone can come, if you're using any app, if you're using any suspicious app, anyone can, sorry, anything can happen in that device action. So we all, we should not go with jail breaking. But for security testing, we always recommend jail breaking devices, okay? Because to play around with the complete app and what is the insecure data storage, whatever the thing, we want to know curious, right? Like how deep your application is vulnerable. So we always use jail breaking device, but mostly project team won't accept, but still jail broken device is good for security testing. And zero day exploit, another term, zero day exploit is nothing but that exploit is not happened till today, but it may happen tomorrow. In the new technology, in the new way, in the new way of exploit, that is called zero day attack. So why I covered this thing is it's very important slide. Some attacks may be happened to your application, some may not be happened. But you should know what are the things happened to which component or which level. Suppose tomorrow you are working on only app level, you have to tell your security team members that you have to ensure all this checklist are verified. That's why I have explained each and every term, okay? Okay? Sure. Any doubts? Okay. Okay, now we are going to, now we are the doctor, so we are going to prescribe what we need to secure our application and what are the services we can provide to the application team to come, to cure all the insecure things. So first mobile security, like predominantly, okay? I won't say this is the exact term, like what all the companies will do it. Some companies have the naming, different naming conventions also, but what predominantly it will do is first is SAS.  That's it. It won't deal with anything. Just go to your source code and it will thoroughly scan for your source code, find any security issues, fix it. That's it. This comes under the SAS issue. And in mobile, what's the difference between web application SAS and the mobile application SAS is? Web application, we have only source code with respect to, let's say, .NET application or Java application. You will be taking that source code and you will be scanning. But here you have the APK file, APK file or IPA file. Most of the testing time, have you people converted the APK file to zip and you will be converting many files, like, okay? So if you've not done this before, just go to download any IPA file or APK file and convert to zip folder. You will see many things, like Android manifest, .dexture, many files will be there. So that is the raw thing. That is the hot of the APK. That's contain all your source code and everything. So that if you are going to scan it, that going to deal with the security of the particular APK file. So for that we will be using the APK inspector file also, okay? More things to do with APK, I will be telling in the upcoming slides, okay? And so you all okay with the SAS part, okay? So static application security testing, which is nothing but go and scan only your source codes. Next we are going to DAST. So DAST is nothing but static application means here it is dynamic application. So dynamic application means all your application. Your app like native app, hybrid app or whatever web app or whatever it is, we will be going to talk with the DAST part actually. So DAST, the VA is nothing but vulnerability assessment. You may heard this term in your project team. VA, VA, VA like the VA means nothing but vulnerability assessment. It may also call it as pentest application security test. So many terms are there, okay? So here we are going to deal with only the application and how the application threads. So everything we are going to deal with DAST part. And also mobile have the APK web service. Even one of our person here, she's looking for API security, I mean API mobile security testing. So like this, many people will be keen on mobile web services as well as API. Definitely next session or next upcoming particular sessions I will be covering the API security also, okay? Okay, thanks bro. And network level, we have the IP servers. Okay, predominantly what I'm saying is for mobile no one will go for network. Any idea why? Usually they will do SAST and DAST. They won't go for network. Any idea why? Sorry, lot of? In mobile there's a lot to exploit and apply to the server. Okay, okay, any other answers? Encryption. Encryption, okay, any other answers? It's just a simple only. I just tell it now. Most of the IP servers will be used by web application IP servers itself. We don't want anything specific to mobile. You got it, what I mean? Suppose Flipkart is there, okay? Flipkart has some already IP servers with respect to web application. We are going to use the same IP servers only for mobile also. So that's why we usually don't go for mobile infra. So people who, those who conduct the assessment for web infra, they don't want to do it for mobile infra until and unless they have a specific mobile infra. That's a simple logic, okay? Clear? But usually, okay, what we do in the IP servers I will be telling. Like we will be having some tools, Nessus, you may hear it at Nessus, Nmap. Those tools, what it will do is it will go and scan your IP servers. And it will check for whether you have the latest OS version, latest patches, memory level issues, it will test for all other things and it will give you the report. That's it. So these three predominant services, you should do it for your mobile application to ensure it is secure. Got it? Only three services, SAS, DASH, and infra or you can call it as network also. Network infra, okay? So secure code review, application, mobile application vulnerability assessment and infra IP security, okay? So now we got to know what are the services we need to do. So today's session, I'm going to talking about only DASH. Why I'm going to focus only on DASH is, SAS is nothing but just a source code review. I would recommend all should go and do your scanning the mobile source codes or whatever source codes with only the commercial tools. Because commercial tools have the vast checklist. Example I'm saying check marks, micro focus 45, these are the tools is very good in vast coverage. Even though you have some false positive, false positive means it may look like an issue but it may not be an issue. That is called false positive example. I'm giving one example. In my code, I am declaring string password equal to empty strings. Then I put semicolon, I just end the code. If I run this code in the source code review tools, it will say password is hot coded, okay? But you have to go into the code and analyze because you declared the variable name as password but you didn't declare your password as the hot coded. So this is called as false positive because tool won't think like human brain. Tool is actually designed by us. What we say is if you see password in the source code, you just put a column saying that password is hot coded but you have to go and think like a hacker go into the code and just see whether they really hot coded the password or they declared the variable as a password, simple, okay? But sometimes our super duper developers will put a comment saying that they will be declaring the passwords in comments for our easy reference. In the dev environment, not in the production environment, in the dev environment, if I go and see some codes, they always have the slash class dev password, slash class dev username. So these things are not have to be restricted. The security practice should start at developers only, okay? So think, think, think, okay? So now we are going to discuss the next guidelines, okay? Now we know what we need to do but now we are going to do in which way or which manner or which guidelines. So security guidelines, today we are going to discuss OWASP top 10, I mean OWASP, is Open Web Application Security Project, okay? This is like a NGO, I can say NGO, non-profit organization. They will meet like us in every three years once and they will be come up with the guidelines. So currently we are following mobile top 10, 2016. So 2016 they have released the guidelines after that they didn't give with the latest guidelines but still we are following the OWASP top 10, 2016. The same thing is applicable for web also. If you go with web application security testing, they also have OWASP top 10, 2017. And if you go for secure code review, source code level, they have top nine, not top 10, top nine. Also they have the cloud security. If you go with cloud security, they have the cloud top 10 as well. So this project is like a NF, NP or that is non-profit organization. They will be looked keenly into the security practices all over the world. So all our clients, all our people are okay with this OWASP guidelines, okay? Mostly we will be benchmarking our applications with OWASP only, okay? So in this we have the top 10. We have the improper platform usage, insecure data storage, insecure communication, authentication, insufficient cryptography, insecure authorization, client code quality, code tampering, reverse engineering and extraneous functionality. So this 10 things we are going to discuss now and before that any doubts because I want to give some pass over here, yeah? Yes please. Some clients that we need to follow like for example, Dithya, and Dithya, if I have a good point. Also, yeah. Thank you so much. Every project what we will be doing is we will be covering two things. One is guidelines and one is compliance. Let's say I am working for MOH or something like healthcare applications. So what I need to do is I need to follow first OWASP. Then all the healthcare applications have HIPAA standards. You all know HIPAA HIPAA standards. So that considers a compliance. So GDPR, yes right. Now recently they have launched. Now we are following first OWASP and then we have to follow the GDPR as well. If it is suppose retail or something like that then we have to comply with PCA standards. ISO standards. HIPAA standards. Many standards compliances are there. If suppose we are using for MAS, I mean Monetary Authority of Singapore. They also have MAS guidelines over there. So if you are working on that project, Singapore based finance projects, you have to work on MAS guidelines also. Sorry, compliance. So there is two things, guidelines and compliance. So GDPR and everything will come as a compliance thing. So that's why now you see, if you go to any web application, you can see the footprint. Are you accepting the cookies or something like that? Everything will pop up. That and all with the result of GDPR only. GDPR wants to ensure every user of the website should know what are the details they are going to store. If you agree with the cookies, then they will allow the browser to save the cookies. If you decline that, the particular website should not store any cookies. So that permission, you should grant to that website. That is called GDPR. Okay, this is one of the compliances in GDPR. Like that many GDPR compliances there. Still I'm not yet to fully cover the GDPR because it's very vast. So one by one, I'm also reading and try to improve in my projects as well. And mostly they will be doing it for UK projects. GDPR. Okay. So any other things? So shall I move to one one guidelines? Don't worry, I won't take much time. It is very easy. I will be telling you what are the steps to test. In the upcoming sessions, we will be seeing the hands on also for that with respect to because today if I cover hands on, I won't complete this top 10 actually. So I will first go through it. Then you people also go and walk at home or whenever you are leisure or free. So in the next session, we will have a continuous Q&A and we will be following with the demo and hands on also. Okay. Okay. So first thing, we are talking about the improper platform usage. So previously I told one thing like when you go for the, okay here, I said right configuration manipulation. So this thing I'm going to cover now. Okay. So the platform security controls. Okay. Example I'm saying in Android, we call it as Android intents. What is that intent will do is, if suppose my first process is to open the camera. Okay. And that, that is call it as intent. One action is called intent. So what that will do is after I taking the picture, it have to save it in the gallery, right? So that is considered as a second intent. Okay. This is called intents process step by step.  Let's say if you are downloaded one spyware application or malware application in that he have the intermittent code. So what he will do is, he will have some remote path or whatever it is. He will ask the particular intent to do the respective action coded by the hacker. So this is called Android intents. That is misuse of platform security control because if the Android intents is not securely developed, then chances are there, it could leads to some other intents also could happen actually. And next thing is platform permissions. How many of them if you download the app, right? It will show you in the page, like it want to access your gallery. It want to access your this application. It want to access your contacts. It want to access your location. Like that it will give. How many of them are reviewing and really you people are giving the aloo? So that thing, if you are not doing before, just go and do it here after. If suppose the, if you are downloading one widget for calculator and it is asking you to access your contacts, then you should think why the calculator app want to access my contacts. You have to question yourself and you should not suppose to download that application at all, even though if it is, if it is legitimate or if it is a well branded one, you should not go and download it. Think about it. You have other widget also. You have other applications also. And how many of them saving your account number, this thing as a contact. Please don't do that. You know what is true color means? True color you know, right? What it will do you know? Suppose my name, Anand, okay my mobile number is blah, blah, blah. I save my mobile number as Anand. Okay, you people all save as an Anand meetup, Anand meetup, Anand meetup like that. Then it will tell to true color, okay this contact is stored by Anand meetup by thousand instances. Then if someone new people, keen my search for my number, it will show us Anand meetup. How it is happening? Because it read your contacts. It read your contacts. It tells how you save that number and that is going to populate us the result of unknown people. So don't save your account numbers. These things are because already many apps is reading your contacts. Okay, think. So these are why I'm telling this as example is, so this and all comes under platform permissions because you are giving the permission to read but you are only doing the mistake. So that's why we should be very careful on the Android permission. So once you start developing the application, don't put simply permissions all. Don't ask for all the permissions. Just try to understand your application requirements which is required, which is not required. If you don't want any gadgets to be used, just click disallow. Don't allow everything. Okay, and third thing touch ID. And recently in 2015, one of the last because one security conference happened that in that conference, they have actually shown how they steal the touch ID information from the Android device. So how it happened is one of the spyware application. In the spyware application, it asked you to touch the touch ID again and again. So it makes us suspicious and it steal the application. So what I meant to say is don't try to download or don't try to go with any malicious applications that actually wants to read your phone OS kernel level information because all your fingerprints will be stored in the OS level, I mean device level. If it reads that, then the chances of stealing that also is there actually. So and the key chain is mainly for iOS devices. So these are the examples, that is few examples I gave here as a platform security controls, you have to be take care before you develop any applications or you ask your developer whether we properly reviewed the configurations and everything, then you have to move it to the production or whatever it is. Okay, why? Because our developers will be in a super hurry state and they will be finding some third party frameworks and they will be put it into the source code. They will simply develop the application and they will deliver it. But being as a responsible tester, we have to review each and everything and we have to advise them and we have to create awareness to our developers also. And okay, any doubts on this? And this came in 2016 number one vulnerability because many people, many people are irresponsible in this category and so many things are hacked by this category. That's why it's ranked number one. Okay, okay, then going to insecure data storage. Okay, this is very important one. Why? Because when you use your application, right? So many folders will be created inside your devices. Let's say you have Flipkart application, you have Lazada, you have fitness first, like that many applications. So in your SD card or whatever it is, it writes so many folders, like Lazada means Lazada folder will be there, fitness first folder will be there. And whatever the information you are accessing there, it will keep your storage or data cache will be respective folders, it will be there. Okay, and now we are in the critical stage to protect what data need to be stored and what data need not to be stored. This is very important. Okay, first point, lost or stolen mobile device. Nowadays, if your device is stolen, okay, at the time of Android version 2.1 or something like that, you can take like that. Simply, if you have a data cable, just connect to your device. Without any fingerprint or something like that, you can still access to your file structure in the previous Android versions. But now, if you are, plug your Android phone and go and connect to your device, now it will ask for your fingerprint. Am I right?  But previously, it has a fault actually. So these kind of problems will be coming when your device is lost or stolen by someone else. Okay, and don't write your passwords in your notes application and don't write your passwords and that is, all people will have a notes in that we will be saving all the passwords and everything. This is an all easily hackable actually. And if I see the phone like this, your oil fingers will show you the trace also sometimes. Okay, so many things are there.  Do you know people what they will do? They will come and take your phone and they will take your fingerprints. People will do that. So they can easily get into your phone and get all your data also is happening actually. And many people murdering the people for phones also, iPhones also. They can easily get into your fingerprint. They will quickly add their fingerprint and then they will run away also. In US it is happening actually. But I won't say here in Singapore. In US people are doing it for that too. I won't say okay, don't want to go in deep into it. In US it is happening actually. And coming to the technical point of view, data in secure storage such as SQL logs, cookies and SD card. These are the predominant areas where your data will be stored into it. Example what I'm saying is, if suppose all the mobile devices will connect to the SQL lite database. All the mobile applications will use SQL lite databases. So whatever the key in your username or password, it will be stored in the SQL lite databases. Now the question mark is, whether you have implemented proper encryption to the password or not. That is the question mark. If you really implemented the good encryption technique to your password to save into the SQL lite databases, then your secure storage is enabled. If you are not implemented any encryption techniques, since your password is going to be stored in the plain text, then it is thrown to the vulnerability, this vulnerability. Okay, so SQL lite and logs, few files will be in the, few developers will log their password because they want to know which credential make which mistake. So they will usually log username and passwords also. So those kind of mistakes also will be happening, leads to this and cookie values and mostly SD card. All the data will be returned into the SD card in the plain text only. Maybe in the next session, I will bring set up the emulator and everything. Then I will show you, I will execute one application. It will store all the data into a SD card. In the SD card, you can see all the value as the plain text only. Only few applications really they implemented the secure encryption to all the data storage. Okay, because they have an idea saying that only web application will get more hacks than mobile application because your mobile device won't be stolen. Your mobile device will be used by you only. So it won't be hacked much. So this was the common exception all over the world but this is totally wrong, okay? And unintended leads such as, okay, suppose you are using the very old OS. Example, now Android 8 is there actually. But if you are still using Android 4 or Android 2, Android already stop supporting those versions. They won't release any security patches. They won't release anything. So if your application is using in those OS versions, still it is vulnerable to data leakage or whatever it is. And the jailbroken devices. As I said, jailbroken devices, all the applications are still vulnerable. You should not use the jailbroken devices at all actually, okay? Any doubts? How to test this is just go to the emulator. This is what the process is. Emulator, run the application. In the background, just go to the SD card and just read what are the data it is reproduced in the respective folder. This is how we will test. And inside the folder, I will be looking for the SQL lite databases, log files, cookies, everything. I will be go and study each and every layer. Any sensitive data is stored in the plain text. So this is how I will test. I will be telling you how I am doing the testing also. Okay? So this we will be doing in the upcoming classes and everything, okay? First few issues is very critical, but going for it will be very easy, okay? Okay, going on to the third thing, insecure communication. So communication, you people all know what is communication, how the communication is going to HTTP protocol or HTTPS protocol. So that is, so whatever the versions, poor hands shaking and incorrect SSL versions. So as I told earlier, certificate will not be matched with the original one. So these kind of things will leads to the attacking part. So which means if you are, let's say I'm the intruder in the coffee shop Wi-Fi, you people are talking each other. So if it is in the SSL version is not implemented, then I can know what A is talking to B and what B is talking to A. That I can capture the packets and reverse it because it's going in plain text only. It is not SSL implemented. So easily we can retrieve back. That's why don't do any banking transaction or whatever it is, even in wireless.sg. I don't recommend that. If you want to do even your banking things, do it in your own data, okay? Don't do any of the things in the public Wi-Fi hotspot. You can see still it is as unsecured only. Even though if it is government recommended, I won't say it is secured. Still it's unsecured only. Okay, you can listed out what are the unsecured Wi-Fi hotspot. Don't do that because 2019, this is going to be one of the third major attack. All everywhere, nowadays free Wi-Fi, that is malicious hotspots are going there. Even in Singapore, I have overcome one. In little India, one of the area, one person, he set it up the hotspot and he put it as a free Wi-Fi. I thought why people are going and standing over there in a very crowded manner. Then they saying, boss, there is actually free Wi-Fi. Free Wi-Fi, okay? Then shall I go and connect? Then I come to know it's like whatever the thing is like in the configuration, there is one proxies there. So it is deliberately there proxies on and something is going on and then it is coming by. It's actually what to say. It's not trapped or something like that. It's visible, very clear manner, but people are still using actually. So that's why we have to be very careful with the communication wise because communication is very important. If it is going in the secure, if it is not going in the secure SSL thing, then all your NRIZ, TIA information, everything is going to be captured and all the data is going to be sell in the markets, okay? All your data is valuable actually. They will give it to any promotional category. You will be getting some emails, whatever it is. Everything is marked here. All your data is marked here. So don't leave that. Going to next one. Okay, going forward it's very simple and going forward whatever the topics I'm going to talk, it's common to web application security testing also. So if you learn this, you can do it for web application security testing also. So first thing, insecure authentication. So authentication is nothing but, of course your credentials is going to be right or wrong. That is what it's going to be checked. So how I'm going to deal with the mobile partners, like if suppose your mobile applications allows number of unsuccessful login attempts, then that is called brute force attack, okay? How the brute force attack is going to be do, I will give you one example. Suppose if you are keeping your password as one of the word in the dictionary, example I'm keeping my password as impossible, okay? My email ID will be even if you go to the meetup.com, you can see my email ID, everyone can take the email ID. Then if suppose I'm using one of the dictionary word, what that brute force attack will do is, I will take your email ID and in the password, I will create some macro file. And that macro file what it will do is, it will capture all the dictionary words and then I will give it to the robot engine. So it will try to do N number of attempts actually. In one attempt, if the dictionary words leads to I, impossible will be coming, in that particular account, my email ID got breached. So that's why to avoid this kind of stuff, we have to reduce the unsuccessful login attempts. That's why if nowadays, if you go and do three times a mistake in your password, it will ask you to enter your capture ID, right? It will tell you on capture, you have to enter the capture value, why it is like that? Because it will ask if you are not a robot, you have to key in the capture value. So this is what? To avoid this kind of thing, they implemented the capture value. And in the fifth time, next attempt also if you do some mistake, your account will be suspended for particular minutes to avoid this kind of robot attacks. Got it? So this is how the authentication is coming to the picture. And with respect to mobile, we have some other things also. Let's say if I take screenshot of entering, when I'm entering the password, it should not display my password also. And if you're key in your passwords, you have the words and all will be coming, right? When you type the keyword, the suggested words will be coming, right? But when you type the password field, it should not come actually. But if you type the password and if it is even though coming, then the keyboard is vulnerable. The keyboard will capturing your key logs and it will send it to someone else. So beware of keyboards. Why I'm very concentrating on keyboards is we people will be fascinating with the different hand ratings or different styles of keyboard fonts and everything in the mobile. But everything is very malicious. Just go with Google keyboard or go with the phone default keyboard. That is very much important. Why? Because many keyboards will come with the keyloggers and it will capture your, what key you are pressing. Everything will be captured and they will be try to enumerate the key logs. So you should be very careful. Don't go with any key, which is very fascinating fonts or whatever it is. Don't go with that. Always go with the default keyboard or G keyboard, Google keyboard, okay? And the second thing is improper session management. Sometime my application will allow the user to log in from N number of mobile devices. Concurrent sessions will be there. So these things and all will lead to multiple issues actually because who will act as which user? Who is the legitimate user? That also another problem. So sometimes improper session management also we have to take in into the consideration. And with respect to mobile, API is one important part. If suppose I want to call one MyTransport or any LTA APIs or something like that. If it really requires the authentication, then you have to do the proper authentication when the API is going to fetch. Don't assume only the application login part alone, the authenticated user will play the major role because whatever the API you are going to call in the future, it also should be authenticated, okay? API authentication is very much important. Don't go with the authentication only with the app level only. Just go with all the steps. If it is a high secure application, that's it. If suppose you are going to know only the bus route timings or something like that, don't put many complications here, okay? Then next, insufficient cryptography. Cryptography, I meant to say we have a cryptography means like encryption algorithm, decryption algorithm as I said before, we should always implement short 256 onwards, short two 256 onwards. Don't use MD4, MD5, and SHA-1 algorithms. These are already deprecated, don't use this application. So these kind of checks will be covered in the insufficient cryptography, okay? And coming to insecure authorization. Authorization you know very well. Difference between authentication and authorization is nothing but authentication is right credentials, okay? But authorization is right user. That means that particular resource should be used by right set of users. So this kind of checks I will be doing in the insecure authorization, okay? One of the example is privilege escalation. Suppose I'm submitting my leave. My manager only should approve the leave. But if I am acting as a manager and approve my leave of my own, then that is called it as the privilege escalation. So right set of users should use right set of resources. And IDOR is nothing but insecure direct object references. Example I'm saying in the URL, you can see some parameter value, like one, two, three, four, something like that. If you tamper that value with next sequence value or next next sequence value, if you able to see the other people's record, then that is called as the insecure direct object references. Okay, one typical example I'm saying. In India, we studied in the college, right? During the exam time, the results will be published. What we will do is in the URL, our hall ticket number will be, I mean our exam number will be there. So if I tamper the exam number with the next number, next number, next number, I can able to see what my friends code everything. So this is somehow okay. But if you do the same thing for your bank account, let's say your bank account number is going in the URL. If you tamper that bank account number with the subsequent next next number, then if you able to see other person's value, then this is considered as a issue vulnerability. So this is called the authorization because you should not suppose to see other people's bank account information. So got it, right? What is insecure direct object references? So okay, then coming to client quality, as I said SAST, they are including the secure code review here actually. So you should not use the insecure APIs which is already have the issues. Don't use that. Just recommend your product owner or whatever it is. Say this is already vulnerable. So don't use this kind of APIs in our quality thing. And coming to the next thing, code tampering. Code tampering is nothing but phishing websites. Most of the things will looks like a legitimate. So be always go with the careful one and don't go with the phishing sites. And the second thing is Piver via malicious app. Okay, this one I want to give one example. If you're playing some games, in the game you will be seeing the pop up. You want to have a Bitcoin investment or something like that it will give. If you just click that, it will ask you to install any app. Those things are malicious actually. And example, have you people playing the carrom pool? Carrom pool coin. I mean, it's a carrom pool is one of the game. In that game what they are advertising is like if you want to have more coins, just go to this site. We will give you more coins like that. So many people, they went to the site and gave their Facebook ID over there. And so that to that Facebook account, it will send you the coins and gems. But what it happens is most of the email IDs are breached over the coin pool games. So these kind of things and all will becomes under spyware via malicious app. Then next is app data alteration. App data alteration is nothing but man in the middle attack. I will be sending one request, but in the middle some people will come and alter the data and send it back to the server. That is called alteration, I mean app data alteration. And the ninth one is the reverse engineering attack. Reverse engineering attack very simple. With the help of APK, I am going to get the source code, okay? Example, what it is, just download your APK file. Convert the APK file into zip file. If you convert to zip file, you have the dex.dex, one file will be there. If you convert the dex to jar file, it will be converted as jar file. And once you get the jar file, JD GUI, there is one tool is there. If you use that tool, you will be getting the raw source code. If I get the raw source code, I will get into the source code, just change the logo and whatever it is I want. I can publish as a new source code, I mean new application. Example, I'm saying LTA app is there. I'm downloading LTA app, APK to dex file, dex to jar file. Then I can get the real source code also. Then if I have the real source code, I will remove the LTA application logo. Then I can put on in this one of the logo and I can publish that as a one of the APK. So to avoid this kind of attacks, what we need to do is, you people should do the mobile upfuscation, O-B-F-U-S-C-A-T-I-O-N, upfuscation. That is very important to reverse back to your own source code. That's very, very important. Okay, so just go to your developers, tell to them mobile upfuscation is very important to prevent the reverse engineering, or else 24,000 apps is daily malicious, I mean getting rejected, right? In that one of our app will be a source code, okay? Because all your hard work and everything will goes. That's the reason. And external functionality is nothing but very important point, dev environment versus prod environment. Because in dev environment, all our things will be easy for us. I will be putting more extensive log if whenever issues comes, then in this line only this error actually thrown out, like that everything we come to know. So this kind of thing, we will put it in the dev environment, but the same code is pushed to production, then in production is something hacking or anything has happened, the issue will be more. So that's why whatever you people are following in the dev environment, don't practice the same in production environment. Just keep those kind of functionalities, then you have to publish in the production environment. So that's it. Over stop 10 is over. Then just to summarize, what are the key things you have to take? First thing is everything, you have to review the app configuration, whatever the controls you have to do. Second thing is choose the right third party libraries. Don't go with the malicious third party libraries. And third thing is dev secups. Start today itself. Don't think security should come in the last part of the project cycle. Start today itself, that's called shift left approach. From the day one itself, do the secure code review and whatever it is you people start, that's comes under and do it in a continuous integration manner. That's in dev secups and fix low priorities. Don't think low priority issues can be neglected. Don't think that like that. Every low priority issues is also a matter. And do the reverse engineering. So do the proper up first station to prevent the reverse engineering. So any doubts? Okay. This is 2019. What will be the subsequent thing? So data leakage and social engineering is going to be the number one in 2019. So those who are calling you people and ask for bank credential number or bank credit card number, don't give anything. That's considered as a social engineering. So don't give any of your personal PIA information to anyone. In Singapore, we have a PDPA act also. So even in your SP services also from August 2019 onwards, you should not use your NRIC fin as your user number. According to PDPA, you have to use your email ID. So everything is going to get changed. So don't use your identify PIA information in any of the websites. And second thing, insecure wifi hotspots as I told in many places, don't log in with that. And out of date devices, suppose if your Android devices is supporting the old versions, try to change the devices. Don't take risk. Nowadays we are in digital world. We don't want to take any risk by using the old outdated devices. And third thing, last thing is poor password strategy. Don't keep any dictionary passwords. I told you the reason why, because many robots are having the well advanced techniques to hack your passwords and everything. So keep your passwords as alphanumeric and everything should be eight digits plus more. Don't keep it as the same, okay? And one more thing, keep password same, don't keep password same for all accounts. That is also very important because in one site, if it get breached, they will be using the same password to other sites also. So don't keep the same password for all the accounts. So that's it, I guess. Ah, yeah. So one final code, one single vulnerability is all an attacker needs. That is very, very true. Even a single low vulnerability is okay to get the more information about you people. So thank you so much for the wonderful opportunity. So, questions. I think I took more time. Sorry for that actually. Yes, questions, please. I have a doubt on the code review. Okay. What is the difference between the 45 and the sonar cube? Okay, both are tools only. Like 45 is a commercial tool. It has the vast checklist and everything, but sonar cube is an open source. If you want to do the extensive scan with the sonar cube, you have to insert some plugins for the respective languages and you can do the source code review also. But my point of view is sonar cube is mostly for unit testing perspective on the code quality issue. But if you want to know, but you want to have the security point of view vast checklist, then you go with the 45 or checkmarks. My recommendation, yeah. But both will do the same functionality, same category. It comes under SAS tool. Only difference is open source versus commercial. That's it. Yes, I'm sorry. A question for the voice level information. To know the thing about the face level information. So, is it advisable to do all of it? It is advisable, but such that it should not have the access and that is fingerprint should be in the device level. Whenever it is required, it should go there, validate and come back. But that fingerprint cache or something should not be used by the, that particular web application. It's okay. That is, it should not go and retrieve back and keep it in the copy of the server. It should go to the device level, validate and come back. That's it. I always have that kind of restriction, but I'm not sure about Android. Maybe I can read about this and then come back with respect to Android. But iOS definitely won't allow to retrieve the copies of fingerprint in iOS. But face recognition, no idea. What's the risk in saving the password in the browser? What's the risk? Saving the password in the browser. Okay. Good question. There is a term called password auto-complete. You people know about this, right? So, it's a good future, sorry, future, but it is not recommended for all sort of applications. Let's say banking application, if you're saving your details in the password and that mission is going to be used by many users, then think in that perspective. Even if I test any intranet application, I won't enable this future. If my application is using password auto-complete, I will ask to restrict it because intranet systems can be used by multiple systems, multiple users. So I will ask them to not do it. If they really want it, then go with the encryption and store that password in the encrypted manual. Yes. My please. What about tools like NAS passwords? What is that password? Yeah, the password vault, it is very, very good. You mean you asked about the password vault only, right? Yeah, yeah. Yes, that's very good strategy. You can store all your passwords in the password vault. Yes. You mentioned Rebus Engineering. Rebus Engineering, you said it would provide someone with an APK. Yeah. And you can go back to this also. Yes. IOS also, we have a file called tools called O-Tool and some other stuff. Still, we can get into it, but the level of reverse engineering is very tough in IOS compared to Android. For IOS is the APK, right? IPA. Oh, there is not. No, no, yeah. Her question is like how about the difference between the reverse engineering in Android versus IOS. In IOS, it's very bit tough, but in Android, it's plain vanilla. Like I can say three steps, that three steps you can execute of your own to get back the source codes. So don't stop till this point itself. Just go through it. This all, if you browse in Mobile OS top 10, all these points will be there. Just go through it. Then only in the upcoming sessions, it will be very easy to come and go through it. So that's right. If no other questions, I can hand over to the... Any more questions, the last question maybe. Okay, thank you so much.