When dealing with mobile applications, common security issues that are well understood for traditional platforms are just as prevalent, and unfortunately can have new implications on the mobile platform:
HTML Interfaces
Many apps have HTML interfaces or screens. These can be vulnerable to cross-site scripting or script injection attacks even though they may not be a full-fledged browser accessing a website. Many times, these issues are worse on mobile platforms as these applications also have access to local data, such as contacts and potentially even files.
SQL Injection
Mobile devices often use a small lightweight database for storing data, contacts, and information that needs to be organized and retrieved quickly at a later time. These applications use SQL to interact with the database. Just like web apps and traditional database enabled applications, if the data can be coerced into a code context, SQL Injection is possible.
Buffer Overflow
Of course, apps written in lower level languages like C nearly always need to pay attention to buffer sizes and beware of buffer overflow issues. Luckily however, attacks aimed at desktops most likely would not propagate to mobile devices, even running the same vulnerable applications- mobile devices typically run different architectures that speak a different language than their desktop components. However, the potential for damage is just as high.
Secure Access Methods
One of the most common issues is the failure to use and enforce secure access methods, such as HTTPS, to ensure that data remains confidential during transit. On protected networks or machines attached with cables, this is less of a concern. However, mobile devices roam and join all kinds of networks- some just unregulated (like a coffee shop) and others downright hostile (a faked free wireless at the airport). Using HTTPS ensures that the user’s confidential information is not divulged, and enforcing SSL ensures that an attacker can’t break the connection and perform Man In The Middle Attacks.
Poison NULL Byte
The poison NULL byte attack occurs when user provided values contain NULL characters and an API is not aware of a string’s specific length, but instead relies on a terminating NULL byte to signal the end of the string. By placing a NULL byte at a specific location in a string, an attacker can control what string is sent to the API, while potentially still passing validation routines that don’t consider the NULL byte. In iOS, Objective-C does not NULL terminate strings, while POSIX C does. Objective-C code that calls C APIs without proper validation may pass along a NULL poisoned string.
Security Defenses in the Presentation Layer
Many mobile applications are written to communicate with web services and, as such, serve as a more tightly controlled presentation layer than a traditional web app, where the rendering browser controls much of the interface. Developers often attempt to hide unavailable or unauthorized options in the user interface, such as removing them from a drop down list, while not performing authorization checks on the service side. Using a proxy, an attacker can bypass the presentation layer restrictions and directly contact the web service, free to explore all available options instead of the subset of options that should only be available.
Improperly Storing Secrets
There are, traditionally, two classes of improperly stored secrets in desktop applications. The first is directly in the binary of the application- such as storing a symmetric encryption key in a string and relying on the fact that most users will never examine the compiled application’s binary code to find it. This issue is the same on mobile devices, and has the same results: malicious users will have no problem pulling the key out of the binary. Often, the secrets that are protected using this method open much bigger holes since developers often assume encryption is a fool-proof protection mechanism and do not perform subsequent validation, leading to issues like parameter tampering, SQL injection, and command injection. The second traditional class of improperly stored secrets is simply writing secrets to an unprotected information store, such as a configuration file or the Windows registry. iOS apps user preference list files, which are XML files. Often, developers write plaintext credentials to these files when a user selects “remember me” at login, believing them to be “safe enough”. For more information, OWASP has a mobile security project that includes a top ten list of mobile risks that should be on the reading list of any mobile application developer. References: https://www.owasp.org/index.php/OWASP_Mobile_Security_Project#tab=Top_Ten_Mobile_Risks http://stackoverflow.com/questions/6539486/objectivec-sqlite3-issue http://code-ninja.org/blog/2012/02/19/ios-quick-tips-avoiding-sql-injection-attacks-with-parameterized-queries-in-sqlite3/ http://www.syscan.org/index.php/download http://techcrunch.com/2011/09/20/skype-aware-of-xss-vulnerability-in-ios-apps-working-hard-to-fix-it/
