OWASP Top 10 for Mobile

00:00

Hey, everyone, welcome back to the course in this video. We're gonna talk through the OAS top 10 for mobile,

00:06

so the always top 10 for mobile includes improper platforms usage.

00:10

We've also got insecure data storage, insecure communications, insecure authentication, insufficient cryptography. So there's in cryptography and used, but it's not properly being used. We'll talk about that in a little bit. We've got insecure authorization, client code quality,

00:24

code tampering, reverse engineering and finally, extraneous functionality. So let's talk about each one of these just a little bit.

00:32

So improper Platform usage, which is number one on the mobile list.

00:36

This is where we've got something like an expose p I that the attacker can and get access to, and they'll go ahead and put malicious data. One area we might see this in is if the developers using app, local storage for the data and not using something like the IOS key chain. If it's an IOS device

00:55

insecure data storage. So as the name implies, this is where an attacker can have. Uh, they might have physical access to the device, or they might do it through an app with malware or something like that,

01:06

and so this could be many things, right? So it's insecure. Data storage. But it could be many things that that are included under that right, so it could be an insecure sequel database or a leaky sequel database Could be. The logs are insecure and the attacker can get access to those. Could be the data on an SD card

01:23

could even be the cookie data, right? So the stored cookie data on the device.

01:26

Next, we have insecure communication.

01:30

This is where a lot of times the data is being transmitted in clear text

01:34

or it's being transmitted with weak or miss configured encryption. And this includes things like the poor handshake of communication and some common attacks against this, our man in the middle attacks, where they're just grabbing the data and the Attackers putting themselves in the session as well as phishing attacks insecure authentication. So

01:52

the app or application is not

01:55

actually identifying the user. It's failing to identify the user, or it's failing to continuously identify the user. So things like such a management weakness, insufficient cryptography. So this is where we might be using, like a weaker, weaker algorithm or some kind of process flaw in the crypt encryption itself insecure authorization. This where

02:14

it could be exploited via malware. So,

02:15

um, this is where the attacker will bypass the authentication control and then actually take over the communication. So we just talked about insecure authentication, which is just proving you are who you say you are essentially right. Credentialing that user and then insecure authorization we're talking about What do you have access to? Right, So we wanna make sure that our APS are

02:36

operating off a principle of least privilege

02:38

client code quality. So this is where we're talking about code level issues with the client. So things like untrusted inputs that can lead to things like buffer overflow attacks or format string vulnerabilities, code tampering. So this is where the attacker actually changes the app code itself. They might also change the contents of memory dynamically as well as

02:58

changing the system. AP ice. And then we have reverse engineering. So this is where the attacker analyzes the core binary. And the goal is to try to get

03:05

information like a source code or libraries and use. And we could do this with tools such as Ida Pro and I. It is actually a popular one in the Mauer reverse engineering aspect as well as a forensic realm. And then finally, we have extraneous functionality. This is where we're talking about things like back doors. Right? So Thebe vela per might have hard coded some credentials in there like a password, for example.

03:23

Or they might have even disabled two factor authentication and just forgot to enable it

03:28

before the APP was pushed out to the app store. So just a quick, quick question here for you. For this vulnerability to be exploited, the company must expose a web service or a P I call that is consumed by the mobile app. So I gotta be improper platform usage, client code quality or insecure data story. All right, so if you guessed improper platform usage, you are correct.