Now, what happens if the application leaks, do the data leaks in the application is another issue
in mobile applications and in a mobile application security, it is possible that an app may unintentionally
leak sensitive data to an attacker.
This requires an extra attention from the developer and the code he uses for Logan during the development
phase.
It must be removed and he must make sure that no data is actually prone to leaks.
So again, this includes sensitive data.
It probably logs on sensitive that it goes beyond the sandboxing.
So the main reason behind focusing on this is that applications on boxing not be applicable to some
of the attacks in this class.
If a user actually copy some sensitive data, such as your security answer from an application or anything
that will be placed on the device, Flipboard or in other portions of memory, which is definitely out
of the application sandbox, and any other application sitting on the same device can read this data,
copy it without the knowledge of the first application.
OK, now another thing is a Web services and Web services are almost similar to Web applications.
So it is possible that a Web service can be affected with all the common vulnerabilities that a normal
Web application can actually help.
For example, you can leverage many different types of vulnerabilities and threats like authentication,
authorization vulnerabilities.
Session management in mobile platforms is typically done using an authentication token.
OK, so when the user logs in for the first time, he will be given an authentication token and this
will be used for the rest of the session if that token is not properly secured until it's destroyed
or expired.
It definitely may lead to an attack.
OK, now, killing the station at the claim site, but not at the server side is another common problem
that is actually seen in mobile applications as well.
So those are the type of things that you actually can manipulate and reuse tokens and also input validation.
OK, so input validation is also known as data validation that we actually have seen in application
for years.
Right.
So it is possible to have a sequel injection or a cross scripting vulnerability if no input validation
controls are actually implemented.
OK, so those are the things that you focus to evaluate that backend now, errors that are addicted
to attack or something, testers or another type of threat, and that is error handling.
And if not properly done, then the API is actually throwing database or server error specific to the
crafted request.
It is actually possible for you to actually craft attacks using those errors.
Right.
And let's see another thing, and that is the cryptography is another area where developers commit mistakes
during the development.
I am making sure that they do not employ the cryptographic protocols.
OK.