Web vs Mobile Security Testing: A No0b's Observation
Dearest Reader, As I am moving along in my journey towards learning more about information security and testing, I've come to understand how the pieces fit.While my testing experience began with mobile, a lot of the testing principles carried themselves to the web. Browser nuances aside, I've noticed distinct similarities in how applications work, and some obvious differences.
The same can be said with regards to security testing.
How Web & Mobile are the similar
Some of the similarities I've encountered with regards to Mobile versus Web Application Security Testing include:- Browser behavior So the first thing I've come to realize is just how similar web and mobile behave. As it relates to presentation, the UI interactions are identical. A mobile-friendly site can elicit the same response as a native app. This presents the ideal playground for hackers to take action. A user can view a site or install an app from a "trusted" source and unknowingly introduce trojan horses in their system. Its been reported just how rampant the spread of malware is from trusted app stores.
- SQL / JS Attacks In my testing experience, I've come across both web and app forms that fail to follow certain design patterns. The first of these patterns being max field length constraints. All-too-easy to enter verbose text and cause a crash or other negative behavior.
- Data Manipulation - MITM While this required a little more effort, the means by which submitted data could be manipulated occurred the same way both on web and mobile devices. Some time ago, I was tasked with testing an app that required user input in order to trigger an SMS operation.
- Session Hijacking Attacks Because web and mobile apps rely on cookies for state-transitions and navigation, the means by which sessions can be hijacked are identical. With the help of proxy tools, session tokens can be intercepted and manipulated, wreaking all kinds of havoc.
Another common situation involves the lack of proper input restrictions. While easier to mitigate on web, more often than not the likelihood of injecting malicious code into a form is evident when the controls to prevent special characters from being entered are not found.
Imagine being able to trigger a "DROP TABLE" command from a form that isn't preventing the system keyboard from entering special characters where none are expected. Not good!
With the help of a proxy tool, I was able to manipulate the payload and transmit gibberish where a legible message was expected. I've successfully done this on web sites as well.
How Web & Mobile are completely different
In my opinion, not a lot separates web from mobile aside from the obvious differences in resource and hardware. There may be more to this list than I can possibly mention, but I shall endeavor to keep it short and sweet.- Native SDKs So the first thing to mention is the SDKs. In this category, iOS (Apple) has the clear advantage with regards to how it manages its application universe. With the way they handle release management and policies regarding application submission, Apple ensures its operating system remains tamper-proof. But recent exploits have shown nothing is unbreakable.
- Tools To Use In my experience, working with native apps and web sites, the tooling for security testing is diverse. That being said, the one tool I found working the best way was BurpSuite.
- Attack Vectors As stated before, while the device ecosystem is stout for iOS, this is the complete opposite for Android.
Security testing apps involves using a lot of proprietary tools and the biggest challenge is overcoming the iOS restrictions.
Android, written in JAVA, presents an implicitly easier way of testing apps from a security stand-point. The biggest challenge however, is the device ecosystem. While testing may prove stout in many of the devices, lower-tiered devices using a legacy-version of the Android OS may prove likely targets as their code-base might be not patched.
Where the differences lie are in how you proxy the device to interact with the framework. On a website, one just sets the IP address to be detected by the proxy tool and VOILA! you are being detected.
With mobile devices, one has to create a Certificate with the proxy credentials. Then the certificate must be installed onto the device. Lastly, the device wifi and proxy suite must reside on the same network.
Another key difference was applying OWASP Top-10 test cases. The test cases for web did not translate 100% to mobile, and vice-versa (ie., there were subtle nuances to account for).
There are a plethora of devices, OS versions, and other fractious iterations in the wild, not to mention rooted devices, that testing and securing platforms proves an enormous endeavor.
No comments:
Post a Comment