This series of articles will walk you through the most important topics about security and mobile applications, whatever the platform is (iOS, Android or others).
The objective is to demystify the different aspects of mobile security, in simple words.
Topic number 1 this week: Server-side controls
Yes, Server-side controls. The first risk is on servers, not necessarily on the mobile device itself. Here is why.
A mobile application rarely comes alone, and communicates with a server that provides the data :
- Authentication data (to authenticate users)
- Business data (basically for the application to know what to display to users)
- Financial data, if there are transactions.
- Transactional data (sells, HR…)
- Reporting data
- Personal data
The part of the server software that communicates with mobile devices is called the API, or webservice.
Since the server is a central and global part, chances are that it will be attacked.
The variety of potential attacks on the server is huge. The OWASP made a detailed Top 10 of these risks, which we went through in a previous series of articles (Understanding web vulnerabilities in 5 min – episode #1: injections!).
Among them, the most famous and dangerous are:
- Injection attacks (where an attacker can directly get access to the data)
- Authentication and session attacks (where the attacker bypasses controls)
Let’s imagine a mobile application where users can order products and see their invoices.
To display and download the invoice, the mobile application sends a request to the webservice:
That request can be sent in a very simple manner, via a web browser or any other tool a hacker may want to use.
If the webservice lacks protection in the way it identifies the request issuer and his permissions, then similar request can be performed to retrieve any (all) invoice:
All billing information of all consumers (and probably their personal information) is then accessible to the entire web.
Securing the server
Even if the final user interface will be the mobile application, attackers will for sure try to attack the server and the API.
It means that security efforts must be allocated to the server and the API in order to implement controls and prevent attacks. Assuming the mobile application on the device will take full responsibility for the security is a bad approach.
Concrete solutions are:
- Code review (with multiple developers)
- Security audit (pentest), to detect vulnerabilities and get technical solutions
- Web Application Firewall, to add an extra protection layer
Of course many efforts in terms of security are also on the mobile side: we will detail them one by one in upcoming articles
Do not rush when your mobile app is developed, and protect it before it reaches the market!