WAP-based mobile applications are mobile applications or websites that run on mobile browsers. Most organizations create a lightweight version of their complex websites to be able to run easily and appropriately in mobile browsers. For example, a hypothetical company called ABCXYZ may have their main website at www.abcxyz.com, while their mobile website takes the form m.abcxyz.com. Note that the mobile website (or WAP apps) are separate from their installable application form, such as .apk on Android.
Since mobile websites run on browsers, it is very logical to say that most of the vulnerabilities applicable to web applications are applicable to WAP apps as well.
However, there are caveats to this. Exploitability and risk ratings may not be the same.
Moreover, not all attacks may be directly applied or conducted.
Getting ready
For this recipe, make sure to be ready with the following set of tools (in the case of Android):
ADB WinSCP Putty
Rooted Android mobile
SSH proxy application installed on Android phone
Let us see the common WAP application vulnerabilities. While discussing these, we will limit ourselves to mobile browsers only:
Browser cache: Android browsers store cache in two different parts—content cache and component cache. Content cache may contain basic frontend components such as HTML, CSS, or JavaScript. Component cache contains sensitive data like the details to be populated once content cache is loaded. You have to locate the browser cache folder and find sensitive data in it.
Browser memory: Browser memory refers to the location used by browsers to store the data. Memory is usually long-term storage, while cache is short-term.
Browse through the browser memory space for various files such as .db, .xml, .txt, and so on. Check all these files for the presence of sensitive data.
Browser history: Browser history contains the list of the URLs browsed by the user. These URLs in GET request format contain parameters. Again, our goal is to locate a URL with sensitive data for our WAP application.
Cookies: Cookies are mechanisms for websites to keep track of user sessions.
Cookies are stored locally in devices. Following are the security concerns with respect to cookie usage:
Sometimes a cookie contains sensitive information
Cookie attributes, if weak, may make the application security weak Cookie stealing may lead to a session hijack
How to do it…
Browser Cache:
Let's look at the steps that need to be followed with browser cache:
Android browser cache can be found at this location:
1.
/data/data/com.android.browser/cache/webviewcache/. You can use either ADB to pull the data from webviewcache, or use 2. WinSCP/Putty and connect to SSH application in rooted Android phones.
Either way, you will land up at the webviewcache folder and find arbitrarily 3. named files. Refer to the highlighted section in the following screenshot:
Rename the extension of arbitrarily named files to .jpg and you will be able to 4. view the cache in screenshot format. Search through all files for sensitive data
pertaining to the WAP app you are searching for.
Browser Memory:
Like an Android application, browser also has a memory space under the /data/data folder by the name com.android.browser (default browser). Here is how a typical browser memory space looks:
Make sure you traverse through all the folders to get the useful sensitive data in the context of the WAP application you are looking for.
Browser history
Go to browser, locate options, navigate to History, and find the URLs present there.
Cookies
The files containing cookie values can be found at
/data/data/com.android.browser/databases/webview.db.
These DB files can be opened with the SQLite Browser tool and cookies can be obtained.
There's more…
Apart from the primary vulnerabilities described here mainly concerned with browser usage, all other web application vulnerabilities which are related to or exploited from or within a browser are applicable and need to be tested:
Cross-site scripting, a result of a browser executing unsanitized harmful scripts reflected by the servers is very valid for WAP applications.
The autocomplete attribute not turned to off may result in sensitive data remembered by the browser for returning users. This again is a source of data leakage.
Browser thumbnails and image buffer are other sources to look for data.
Above all, all the vulnerabilities in web applications, which may not relate to browser usage, apply. These include OWASP Top 10 vulnerabilities such as SQL injection attacks, broken authentication and session management, and so on. Business logic validation is another important check to bypass. All these are possible by setting a proxy to the browser and playing around with the mobile traffic (we provide a different recipe for the same in a later chapter).
The discussion of this recipe has been around Android, but all the discussion is fully applicable to an iOS platform when testing WAP applications. Approach, steps to test, and the locations would vary, but all vulnerabilities still apply. You may want to try out iExplorer and plist editor tools when working with an iPhone or iPad.
See also
h t t p : / / r e s o u r c e s . i n f o s e c i n s t i t u t e . c o m / b r o w s e r - b a s e d - v u l n e r a b i l i t i e s - i n - w e b - a p p l i c a t i o n s /