WAP and Mobile HTML Security : Application Attacks on Mobile HTML Sites

5/5/2011 3:47:46 PM
Many traditional web application attacks will work on mobile browsers/devices supporting WAP 2.x/Mobile HTML sites. Mobile devices with mini-browsers are not fully featured, but they do contain the bare-bones necessities to function on most web applications or Mobile HTML sites. The same items that are needed for bare-bones functionality, such as some type of cookie support on the mobile device, are the same things attackers usually target. Overall, there’s nothing really new in the Mobile HTML world—it has more of the same issues, but just a different implementation of the attack classes.

Cross-Site Scripting

Cross-site scripting (XSS) is everyone’s favorite web application attack class, attack example, and general use case. If you are new to cross-site scripting, simply refer to the millions of online articles that describe the attack class and how to test for it. A good reference is the Open Web Application Security Project (OWASP) or the Web Application Security Consortium (WASC). In short, cross-site scripting allows an attacker to steal a victim’s session cookie (or any cookie for that matter), which is then used by the attacker to access a given web application as the victim. I will not go into how the attack works but rather go into how cross-site scripting fits in with mobile devices.

The bad news is that XSS is alive and well on mobile devices. Most mobile devices have limited storage space, which limits what can be stored client side during mobile browsing when compared to PC browsing. One of the main differences is the storage space allocated for cookies. In the PC world, storage space is not really an issue, so an application will use multiple cookies for various items, including for maintaining session state. On the mobile device, where storage space is limited, multiple cookies may or may not be used, but the session cookie (the cookie that is needed to maintain state between the mobile device and the web application) is always required. This scenario works out well for attackers using XSS attacks, where the session cookie is the only cookie they really care to steal. Regardless of whether a single cookie or multiple cookies are used, Mobile HTML sites support xHTML (although still limited), CSS, and JavaScript, thus keeping the attack class alive and well. Follow these steps to complete a proof-of-concept demo of an XSS attack on a mobile device/browser.


This demo will purposely execute JavaScript from the book’s test site on the PC and the mobile device browser.

  1. A pop-up box appears, showing a proof-of-concept session ID (see Figure 1).

    Figure 1. Cross-site scripting on a PC browser
  2. Now using the browser on your mobile device, visit the same link in step 1.

  3. While the appearance of the pop-up will vary from phone to phone, the idea is the same. You should see some type of alert window appear on your phone, with the proof-of-concept session ID (see Figure 2). Although the picture is a bit fuzzy, notice the JSESSIONID in the Alert box.

    Figure 2. Cross-site scripting on a mobile browser

  4. If you don’t have a mobile phone handy, you can try the same thing using a phone emulator running on a PC. You can use any emulator you choose, but the ES40 emulator seems to be 90 percent accurate. Here are the steps to follow:

    1. Download and unzip ES40 from

    2. Double-click on the icon after the files are unzipped.

    3. Once the emulator is up and running, insert in the text box under “URL you want to test: http://.”

    4. The emulator will then visit the demo page, showing the local session cookie in an alert box (see Figure 3).

      Figure 3. Example of cross-site scripting on a mobile phone emulator

It should be noted that the idea of forcing an alert box to appear with a session ID value is not the real attack, but just a proof of concept as to how a remote attacker can force a victim to execute hostile JavaScript on their own device. A real cross-site scripting attack usually involves code that sends the victim’s session information to the attacker, which will then be used by the attacker to log into the application as the victim. As shown in the previous demos, cross-site scripting will work on a WAP or mini browser that is using cookies for session management and supports CSS/xHTML/JavaScript.

SQL Injection

The next attack class we’ll discuss is SQL injection, which is an old attack class that unfortunately still has a lot of legs in some application circles. The attack basically allows attackers to send SQL commands to backend databases via web applications that are not sanitizing input or using parameterized queries. The idea behind SQL injection is simple: An attacker inserts SQL statements into a web application—in a form field, hidden field, cookie field, and so on—instead of the expected value, such as a username, address, or phone number. The web application takes the input from the attacker and sends it directly to the database. The database, probably expecting a username or address, but willing to process anything it gets without a doubt, simply takes the SQL statement and executes it, running any action stated in the SQL statement by the attacker, such as Drop_Table “passwords”.

Similar to XSS, a good reference to SQL injection can be found on the OWASP and WASC sites. Also similar to XSS, SQL injection is alive and well in Mobile HTML sites. A user can enter a SQL statement from a mobile device to a Mobile HTML site quite easily. If the Mobile HTML site does not sanitize the input, the SQL statement can be sent to a backend database server. If the database server is not using prepared statements and generating SQL statements dynamically, then the mobile platform is vulnerable to a SQL injection attack.

Testing for SQL injection attacks from the mobile device to the Mobile HTML application might be a bit logistically challenging with a small keyboard and limited character sets. In order to perform the most efficient testing, there are a couple of options. The first option is to simply browse to a Mobile HTML site using your PC browser. Most organizations have a different URL for the mobile site than for their regular site. Two good examples are Google and eBay:

Mobile HTML

At least for SQL injection testing, one can use the Mobile HTML URLs for security testing rather than the main URLs. The one exception, which is a rather big one, is if the Mobile HTML site changes its page/appearance based on the browser it detects being used. For example, many sites will change behavior depending on whether they detect Internet Explorer, Firefox, Safari, or Chrome as the client’s browser. Similarly, many sites will automatically change appearance if they notice a WAP/mini-browser is being used versus a traditional browser. If this occurs, using the Mobile HTML URLs listed previously will not work, so you’ll either need to download a mini-browser or a WAP plug-in to your existing browser. A WAP browser may or may not be effective for security testing because traditional security tools might not work on it (such as a web proxy). Alternatively, downloading a browser plug-in that will allow a traditional browser to appear as a WAP browser might work out a bit better, because traditional security tools already loaded on the browser can be used with the plug-in as well. Several WAP browsers and WAP plug-ins are available. Here are a few to consider:

Use the following steps for a quick method to test for SQL injection in Mobile HTML sites:

  1. Download and install the Firefox or Internet Explorer add-in listed previously. Ensure you have the add-in enabled, making the browser appear as a WAP browser.

  2. Download and install some freeware SQL injection tools that can be added to the browser, such as the following:

  3. Visit the Mobile HTML page of the application you wish to test, such as:

    • m.<domainname>com

    • www.<domainname>.com/m

    • or whatever the exact mobile HTML page is

  4. Using the security testing tools plugged into the browser, testing the Mobile HTML site (from the WAP browser perspective).

    • For SQL Inject Me, follow these steps:

      1. On the menu bar, select Tools | SQL Inject Me | Open SQL Inject Me Sidebar.

      2. On the sidebar, select “Test all forms with all attacks.”

      3. Review the results after the testing is completed.

    • For SecurityQA Toolbar (SQL Injection module), follow these steps:

      1. On the toolbar, select Data Validation | SQL Injection.

      2. After the test is completed, select Reports | Current Test Results.

      3. Review the results after the testing is completed.

There are several other ways to test for SQL injection, but this section should give you a good start. The main idea here is that because SQL injection is an attack class that does not care about WML or HTML, testing it from a browser with some add-ons will give you the same type of testing as testing it from a mobile device itself.

Cross-Site Request Forgery

The next attack class we’ll discuss is cross-site request forgery (CSRF). CSRF, which should not be pronounced C-surf, but rather C-S-R-F, is a newer attack class that forces a victim to perform a particular action on a site without their knowledge or approval. For example, a user can be logged into their bank site in one browser tab and reading a news article in another browser tab. If the second browser tab contains a hostile link trying to perform a CSRF attack, it can force a victim to perform actions on the original tab, such as transferring funds from one bank account to another, if the banking application does not have adequate protection for CSRF. A great reference to CSRF can be found at Similar to the “Cross-Site Scripting” section, I will not go into how the attack works but rather how cross-site request forgery fits in with mobile devices. In this section, we’ll talk about executing CSRF on users using mobile browsers as well as CSRF vulnerabilities on Mobile HTML applications.

Targeting the Mobile Device to Execute CSRF

Similar to the PC world, browser behavior is important to discuss. In the PC world, a CSRF attack needs to be on a browser using the same process for the applications it is visiting, either with a different tab on a single browser or a new browser invoked under the same process as the original browser (easily done by selecting CTRL-N). Most browsers on the PC do this very thing, so a CSRF attack is widely exploitable on traditional PC and web applications unless server-side protection is built in. In the mobile browser world, the use of multiple tabs is not so common, but the browsers do use the same process for all web surfing. Hence, a CSRF attack under traditional circumstances on the PC side will work on mobile devices using min-browsers. A good way to test for this is by using your favorite webmail application via your phone. Try logging into your web mail application on your mobile device. Then surf around to two or three other pages outside of your webmail application. After a few minutes of browsing, return to your webmail application again. You’ll notice you are still logged in because you do not have to reauthenticate to your original webmail session, even though you clicked away to visit other sites for a while. Complete the following steps to follow this idea:

  1. On your mobile browser, visit Log in with your username/password.

  2. Visit three to five other pages, such as the following:

  3. Now revisit You’ll notice you are still logged in, despite browsing away to other sites.

Steps 1 to 3 simply prove the browser behavior on the mobile device is similar to a PC, hence making CSRF attacks using mobile browsers very possible and not different from the PC world. For example, if Gmail were vulnerable to CSRF attacks, then hostile content on the sites listed in step 2 could force actions on Gmail without the user’s knowledge or permission, due to the browser maintaining state on multiple sessions across multiple destinations. This idea becomes very critical when you replace Gmail with a mobile bank application that is vulnerable to CSRF. For example, many mobile users will probably use their device to check their bank balances. If the user does not sign out or is not signed out automatically, and then visits other pages on their mobile device for casual reading or general web surfing, any hostile page targeting their bank application will be able to perform a CSRF attack, using the tradition attack methodology of CSRF.

Targeting CSRF on Mobile HTML Applications

Now that you know that CSRF attacks are possible using mobile browsers, let’s now focus on the real issue, which is the exposure of CSRF on Mobile HTML sites. Similar to regular applications, CSRF exposures on a Mobile HTML site is a huge concern. Mobile users are just as likely, if not more, to surf around from one site to another while being logged into a sensitive mobile application such as a banking site, stock trading site, payment site, or something similar. In most scenarios, users are not going to log off from the stock trading site before visiting a news site on their mobile phone; they will just perform the action seamlessly. Furthermore, if the user is logged into their banking site on the mobile browser and gets a hostile link from their e-mail client on their phone, they are more apt to quickly click on that link, which will redirect to their mobile browser, than to keep the two items separate. Similar to SQL injection, the best way to test for CSRF attacks on a Mobile HTML site is using a WAP plug-in for IE or Firefox (ensuring the Mobile HTML page is loaded on the browser, just in case it changes any behavior based on that information), using a web proxy to view the web information (such as the TamperData add-on for Firefox), and then using the Mobile HTML page of the application. Complete the following steps to test for CSRF on mobile HTML sites:

  1. Using Firefox, install the wmlbrowser add-on (

  2. Install the TamperData add-on (

  3. Visit the mobile HTML site of the application you wish to test and log in with a valid username/password.

  4. Go to an area of the application that performs sensitive actions, such as the account/user profile page (where users can reset their password, e-mail address, username, and so on).

  5. Enable TamperData (Tools | TamperData | Start Tamper).

  6. Change the e-mail address on the page and select ENTER.

  7. When the Tamper Data pop-up appears, select Tamper.

  8. On the right side, view the contents of the post (details of the user/account profile page). Delete the values for fields that look unique or unpredictable, such as fields labeled nonce, token, SessionID, and so on. The idea is to delete any value for a field that is unpredictable/unguessable between users, so if something looks machine generated, delete it. Fields that are predictable and should not be deleted include e-mail address, name, password, and so on.

  9. Select OK and then Stop Tamper.

  10. If the action completes successfully, the mobile page is vulnerable to CSRF.

Now that you know how to test for CSRF on mobile HTML sites, let’s actually perform a demo attack using a mobile device. Complete the following steps on your mobile device:

  1. Using the web browser on your mobile device, visit Site A:

    1. Select Charge Me.

    2. Your account balance will change from 10.00 to 9.75.

  2. Now open up the address bar on your mobile device and visit another random page, such as Feel free to visit a few more pages as well after the iSEC Partners page. After a few web visits, open up your address bar again and enter the address

    1. Select the “The Latest News” hyperlink. After you make that selection, you’ll be redirected to

  3. Open up the address bar again and enter the original site (do not hit any back button options):

    1. You notice your account balance has changed from 9.75 (from step 1) to 9.50 (automatically). This action occurred during step 2, when you selected “The Latest News” link. That link forced a GET action to on behalf of the user, which was “logged in” during step 1, and then redirected the user to

Why did this happen?

  • The mobile HTML application in step 1 is vulnerable to CSRF (no unpredictable values need to perform sensitive GETs/POSTs).

  • The mobile browser is maintaining session state across multiple destinations, which is normal browser behavior.

  • The link in step 2 forced the user to perform an action on Site A. In the real world, the “Charge Me” action could be “Transfer Funds from Account A to Account B.”

HTTP Redirects

Another attack class we’ll talk about is HTTP redirects. Whereas cross-site scripting, SQL injection, and CSRF are popular attack classes, HTTP redirect (also known as open redirect) is very far behind, but it’s important to discuss when it comes to mobile devices. HTTP redirects are important to test for on mobile HTML sites because of the limited viewing area of mobile browsers, making the attack by far more attractive to attackers.

HTTP redirects are an attack class that redirects a victim to a page of the attacker’s choice without the user’s knowledge or permission. The attack works by manipulating one of the parameters on the web application. Furthermore, the original domain/web application that the victim is visiting remains intact, so the user does not see a different domain, even though they are visiting a different web application/domain. For example, let’s say the web application on redirects a user to when the user selects the Login icon. Hence, if the user visits and selects the Login icon, they are redirected to the bank’s login page at This is all good and legitimate, but if the web application is not validating the information in the Login parameter, an attacker can use this function to trick the user into visiting a page of their choice using the following link: might be a page that looks similar to the real login page of the bank (in order to trick the user into entering their login information), but really is a page that is controlled by the attacker (on the attacker’s web server).

The reason why it is important to address this issue in depth concerning mobile devices is quite simply the limited viewing space on mobile browsers. For example, many mobile handsets out there will not actually show the URL in the browser by default. The user has to select some option to see the URL (address bar) on the browser, rather than the content only. The reasoning is quite obvious: Real estate on mobile devices is limited, so the fewer browser parts shown in favor of the mobile content, the better the experience for the user. The negative is the security implications that result from removing the address bar. Under this scenario, a mobile application that is vulnerable to an HTTP redirect attack would not even show the address bar, taking out any secondary visual checks a user might make beforehand to ensure they are not being redirected somewhere else. Admittedly, most users would not be able to detect a hostile redirection on a regular browser because most users are trained to view only the main domain ( and not the items after it (?, but it does make the attacker’s life much easier if the address bar information is simply not shown. A good example of attackers who would want to take advantage of this flaw on mobile devices is phishers. HTTP redirects are a goldmine for phishers—many users are able to understand that is not legit, but the same does not hold true of (both being destinations under the attacker’s control). Hence, this vulnerability makes a phisher’s life a lot easier because the latter URL is something most user’s would have difficulty in detecting. However, in an environment where the address bar isn’t shown at all, the attack becomes much easier for the attacker. In order to get a better understanding of the attack scenario on mobile devices, complete the following steps. In this example, is the legitimate site and is the redirected site:

  1. Using the browser on your PC, visit Notice the var parameter is vulnerable to HTTP redirects, forcing users of to visit

    1. After entering the URL, notice your PC browser now shows It is obvious that you are no longer at, but on a different web page/web application.

  2. Using the browser on your mobile device, visit the same URL:

    1. Similar to step 1a, the browser will now go to; however, in most cases the browser on your mobile device will not show the address/URL field, but rather simply show you the contents of that page.

Although the attacks in steps 1 and 2 are exactly the same, it is more obvious in step 1, where the address bar is shown. In this example, was shown to verbosely demonstrate that the user is redirected to a different web page, even though it is coming from Imagine a page that looks similar to the original page on labs, making it very difficult for the user to distinguish the attack site from the legitimate site. Going back to our login example, an attacker would simply create a page that looks graphically similar to the pages on the legitimate application and then host that site on their own web server. When the user is redirected to that page on the mobile phone, they get the same look and feel of the legitimate site, but with no address bar. However, they are actually visiting the site controlled by the attacker.


Although not really an attack class, it is important to spend a few moments on phishing and mobile devices. Similar to the HTTP redirects attack class, nothing really new changes with phishing attacks on mobile devices—it just gets easier due to the smaller viewing area with less space to show critical information, not due to any other technology changes.

Most mobile devices with browsers also have an e-mail client. Similar to on a PC, the e-mail client is used for either personal or corporate mail outside of the web browser. It seems as though sending a phishing type of e-mail to a local e-mail client on the phone would not be as successful due to the client’s ability to see the actually URL in a hyperlink. For example, if an e-mail has a link that appears as, but really is a hyperlink to, it would show up as in a regular e-mail client, but seems to show up as <> in a few mobile e-mail clients. The latter obviously shows to the user that the real destination is, not However, if the same e-mail is displayed on a mobile web browser, it shows up as with a blue hyperlink. This webmail situation is friendly to phishers, because the real destination remains hidden.

This is nothing different from the PC world, but the one key is different user behavior. Consider a social networking site where users want to stay connected to each other by updating their page often, adding friends, and sending a note to a friend. This type of activity is quick and has high volume, so little things tend to get ignored. For example, if a friend invites you to be part of their social networking site, an automated e-mail generated by the legitimate social networking site will be short and filled with links for you to quickly select “Yes” and move on. A phisher, knowing this user behavior, might create an e-mail similar to the legitimate organization’s and send it out to millions of users, as phishers usually do. Unlike reading the phishing e-mail on a PC, the limited space and time constraints of reading the very same phishing e-mail on a mobile device will probably increase the likelihood of a user accidently clicking on a link, thinking it is from their friend, but it’s actually from a phisher banking on the fact that the e-mail is being read on a mobile device with limited screen space. Although this is a very low tech example of phishing, the whole attack class of phishing is simply social engineering, which becomes easier to do on a mobile device.

Session Fixation

Many WAP browsers have limited or no cookie support. In order to give the user a stateful user experience, many web applications track user sessions by using a session identifier in the URL. Oftentimes, the identifier is not reset after authentication, enabling attackers to target users with a session fixation attack. The attacker would perform this attack by sending the victim a specially crafted e-mail link and persuading them to follow it. The link contains the information from the legitimate organization, so there is a high probability the victim would see the link as trustworthy. Once the user logs in, the attacker can use the activated session ID to gain access to the user’s account. The attacker does not have to convince the user to provide their credentials or lure them to a malicious website.

Session fixation is mitigated by resetting the session identifier after the user logs in. The attacker will no longer have knowledge of the user’s session identifier and will be prevented from accessing the user’s account. Ideally, session ID should not be in a URL; even if it is reset after login, it could get leaked via other methods, such as referrer headers and non-SSL pages.

Non-SSL Login

Although not really a popular attack class on traditional web applications, the use of non-SSL forms on mobile HTML applications is still pretty common. The argument is that the initial SSL handshake between the client and the server is too performance heavy to use on mobile devices with limited CPU and memory capacities. The end result creates a situation where the same username and password that undergo a significant amount of protection on modern web applications are sent loosely in the clear over mobile HTML sites. One could argue that because the ability to sniff on a GSM or CDMA network is not as easy, clear-text transmission of credentials is not so big an issue; however, at some point, the communication medium will change from GSM/CDMA to Ethernet, usually after the WAP gateway/proxy, thus allowing attackers on the other side of the fence to capture the clear-text credentials. Although the exploit scenario is more difficult, the idea of a username and password (which provide the ability to move money from one entity to another) passing through the network in clear text is less than an ideal situation. A good way to test for non-SSL forms is simply to check for the use of HTTP (not HTTPS) on your mobile browser using the mobile HTML page.

  •  WAP and Mobile HTML Security : Authentication on WAP/Mobile HTML Sites & Encryption
  •  iPhone Application Development : Displaying and Navigating Data Using Table Views - Building a Simple Table View Application
  •  iPhone Application Development : Understanding Table Views and Navigation Controllers
  •  Windows Phone 7 Development : Revising WeatherRx to Manage Slow Data Connections
  •  Windows Phone 7 Development : Handling Data Connection Issues with Rx.NET
  •  Windows Phone 7 Development : Handling Errors in Rx.NET
  •  Windows Phone 7 Development : Using Rx.NET with Web Services to Asynchronously Retrieve Weather Data
  •  Windows Phone 7 Development : Media - Adding Sounds to an Application
  •  iPhone Application Development : Building a Multi-View Tab Bar Application (part 4) - Implementing the Summary View
  •  iPhone Application Development : Building a Multi-View Tab Bar Application (part 3) - Implementing the Volume View
  •  iPhone Application Development : Building a Multi-View Tab Bar Application (part 2) - Implementing the Area View
  •  iPhone Application Development : Building a Multi-View Tab Bar Application (part 1)
  •  Windows Phone 7 Development : Working with Video (part 2) - Coding the Application
  •  Windows Phone 7 Development : Working with Video (part 1)
  •  Windows Phone 7 Development : Plotting an Address on a Bing Maps Map and Working with the Bing Maps Service
  •  Windows Phone 7 Development : Using GeoCoordinateWatcher and the Bing Maps Control to Track Your Movements
  •  iPhone Application Development : Creating a Multi-View Toolbar Application (part 3) - Adding Toolbar Controls
  •  iPhone Application Development : Creating a Multi-View Toolbar Application (part 2) - Instantiating the View Controllers
  •  iPhone Application Development : Creating a Multi-View Toolbar Application (part 1)
  •  Windows Phone 7 Development : Using Location Services - Simulating the Location Service
    Top 10
    Build Up Your Dream House with PC (Part 2)
    Windows Mobile Security - Networking
    Understanding the SharePoint Server Roles
    Mobile Application Security : WebOS Security - Introduction to the Platform
    Windows Mobile Security - Permissions and User Controls
    Adobe Premiere Elements 10
    Windows Phone 7 Development : Understanding Trial and Full Modes (part 1) - Using the IsTrial Method
    Debugging Tools For Parallel Tasks
    Optimizing for Vertical Search : Optimizing for News, Blog, and Feed Search
    Algorithms for Compiler Design: PREDICTIVE PARSING ERROR RECOVERY
    Most View
    CPU System Workshop (Part 1)
    Active Directory Domain Services 2008 : Remove a User, Group, or Computer from the Password Replication Policy
    Joomla! Blogging and RSS Feeds : Commenting anyone?
    Create, Read, and Write a Text File
    Windows Server 2008 R2 monitoring and troubleshooting : Event Viewer - Configuring event-based tasks & Setting up event log forwarding
    Designing and Configuring Unified Messaging in Exchange Server 2010 : Unified Messaging Architecture (part 1)
    Choosing a super-zoom camera (part 2)
    Server 2008 : Hardening Server Security
    Programming Excel with VBA and .NET : Variables (part 1) - Names & Declarations
    Developing an SEO-Friendly Website : Redirects
    Mobile Application Security - BlackBerry Security - Permissions and User Controls (part 1) - RIM Controlled APIs
    Mobile Application Security : SymbianOS Security - Persistent Data Storage
    Mobile Viruses the risk keeps growing (Part 1)
    Using Non-Windows Systems to Access Exchange Server 2010 : Configuring and Implementing Entourage for the Mac
    Adding an Application Bar to a Windows Phone 7 Application (part 3) - Adding an Application Bar Using Managed Code
    Migrating from Legacy SharePoint to SharePoint Server 2010 : Using Visual Upgrade
    Using System Support Tools in Vista
    Gamepad - How It Works (Part 1) - Arcade fever
    Building and Deploying Applications for Windows Azure : Creating a Demo Project