CHAPTER 9
WAP and Mobile HTML Security
Wireless Application Protocol (WAP) and Mobile HTML websites represent a growing trend. As end users migrate to their mobile phone from traditional PC-based for Internet activities, such as checking/sending e-mail, checking bank accounts/transferring money, and updating the status of their social networking page, the more users will assume security has been built in using rigorous standards. To address the current state of security, this chapter discusses WAP and Mobile HTML security. Although, a few principles for WAP security will be discussed, the chapter’s main focus will be on Mobile HTML security on PDAs/smartphones because the latter seems to be the platform most new mobile content is written for. Here is a quick definition of terms for both items:
WAP A web destination highly based on the Wireless Markup Language (WML) only. Usually targeted for mobile devices that are not smartphones but rather regular mobile phones that support text-based web destinations. WAP comes in two versions:
WAP 1.0 Heavily based on WML. Limited support of security rich content, including encryption (WTLS only).
WAP 2.0 Richer support than WAP 1.0, including xHTML, CSS, and full Transport Layer Security (TLS) encryption.
Mobile HTML Mobile HTML sites are usually slimmed-down versions of regular websites for mobile use. The look and feel will be similar to the full-blown application.
The use of Mobile HTML sites is growing in popularity, as most new mobile devices can support slimmed-down versions of HTML sites, use CSS, and contain limited cookie support.
Similar to the early generations of web content on the Internet, where the idea was to get something up and running and worry about security later, the same idea, to some degree, can be found in the WAP and Mobile HTML world. Many large organizations are aiming to get something up and running that’s easy for their customers to use. During that speedy process, important security principles are being bent along the way—many of the same principles that would not be up for discussion in the traditional web application world (for example, foregoing the use of encryption and strong passwords). In many situations in the WAP and Mobile HTML world, security is still an afterthought. It should be noted that many WAP and Mobile HTML sites have limited functionality to balance out the reduced security measures used on the sites; however, as history shows, features on these sites will probably continue to grow while the security standards remain static.
This chapter discusses the security of WAP and Mobile HTML sites. Here’s a list of the key areas covered:
WAP and Mobile HTML basics
Authentication
Encryption
Application attacks on Mobile WAP/HTML sites
WAP and mobile browser weaknesses
WAP and Mobile HTML Basics
Wireless Application Protocol provides a method to access the Internet from mobile devices. WAP architecture includes a few items, such as a WAP browser on the mobile device, the destination application/HTTP web server, and a WAP gateway in between the mobile device and the application/HTTP web server. A WAP gateway is an entity that acts much like a proxy server between a mobile device and the HTTP server. Its job is to translate content from web applications in a form readable by mobile devices, such as with the use of WML.
WAP has two major versions: WAP 1.0 and WAP 2.0. It should be noted the WAP gateways are required in WAP 1.0 but are an optional component in WAP 2.0. Figure 9-1 shows a WAP architecture.
In the early days of WAP, which used WAP 1.0, Wireless Markup Language (WML) was solely supported. WML was based on HTML, with limited to no support for cookies. WAP websites heavily relied on WML to display content to users, but quickly ran out of all the bells and whistles that users/developers desired. About four years later, WAP 2.0 was established. WAP 2.0 supported more items that make the web experience similar to the PC, such as xHTML, CSS, TLS, and wider support for cookies. Furthermore, WAP 2.0 no longer required a WAP gateway, which alleviated some security concerns with WAP 1.0 (discussed in the WAP 1.0 section). As the industry continued to evolve, so did mobile devices. Nowadays, WAP 2.0 and Mobile HTML sites dominate mobile web applications. Mobile HTML sites are slimmed-down versions of tradition web applications, but viewable on devices with limited view screen and storage capacities (usually with a smartphone or PDA).
Authentication on WAP/Mobile HTML Sites
One of the many problems that WAP and Mobile HTML developers have with mobile devices is the keyboard. PDA-style phones come with a mini-keyboard that looks similar to traditional keyboards, containing letters A–Z and support for every number (0–9) and many special characters by using a SHIFT-style key (see Figure 9-2).
On the other hand, non-PDA phones have the traditional 0–9 keys only, with letters above numbers 2–9 and special character support under number 1 or 0 (see Figure 9-3).
Although the use of PDA-style mobile phones is increasing every day, non-PDA mobile devices are the most popular, which have the traditional 0–9 keys only. The limitation of the 0–9 keys creates a significant challenge to WAP and Mobile HTML developers in terms of user experience and authentication. For example, banking and e-commerce organizations want to make authentication to their sites as easy and secure as possible, thus making the adoption rate high. Traditionally, strong passwords are often required for banking and e-commerce sites, often requiring numbers, letters, and a special character. Although these standards are great when a traditional keyboard is available, they become very difficult when only the 0–9 keys are available on traditional handsets. For example, using the keyboard in Figure 9-2, the relatively simply password of isec444 would only require selecting the letters i-s-e-c, selecting the SHIFT key, and then selecting the number 4 three times, requiring a total of eight key presses. On the flip side, the same password used with the keys shown in Figure 9-3 would require selecting the number 4 key four times (to get to i), the number 7 key five times (to get to s), the number 3 key three times (to get to e), the number 2 key four times (to get to c), and then the number 4 key three times, for a total of 19 keypresses. The latter option requires more than double the effort to enter a simple password and virtually kills the user sign-on experience.
Figure 9-3 Non-PDA-style keyboard
In order to create a better and easier experience, mobile WAP/Mobile HTML sites have introduced the use of a mobile PIN, which replaces the password; however, this also lowers the security of the authentication process. For example, many WAP/Mobile HTML sites allow a phone to be registered to an account. After a phone is registered via a web application, the mobile phone number can be used instead of a username, and a mobile PIN can be used instead of a password. Unlike traditional passwords, the mobile PIN can only be numbers and is usually four to eight values in length (with at least one major bank limiting PINs to only four numeric values only). The use of a numeric-only value for the PIN increases the user experience by significantly reducing the amount of keypresses to use the mobile device (the same idea holds for the username, by the use of a numeric phone number instead of an alphanumeric username). In either case, when the username is replaced with a phone number and the password is replaced with a PIN, the user experience is improved, but security is reduced. In this use case, a site that usually takes a unique username and strong password has just been reduced to a phone number and numeric value. Although low tech, an attacker could simply enter several phone numbers to see which ones are registered to use the WAP/Mobile HTML site. Furthermore, most WAP/Mobile HTML sites give verbose error messages (again, for a strong user experience but bad security practice), so entering the incorrect mobile number will let the attacker know that a number has not been registered. The attacker can then enter the next number on their list until they receive an error message that states the PIN is not correct instead of an error message that says the phone number is unregistered. Once they have identified a valid phone number that has been registered already, the attacker now has to brute-force the PIN.
Admittedly, brute-forcing a weak PIN is not the full responsibility of the banking/e-commerce site, but how many users will simply use “1234” if they are required to have numbers only and four values? Further, how many users will simply use their seven-digit phone number as the password, which still fits into the number-only restriction of four to eight values. The examples could go on, but with a key space drastically reduced from A–Z, 0–9, and special characters to 0–9 only, the likelihood of an attacker hijacking a user’s account by brute force significantly increases. A possible mitigation to brute-forcing weak PINs is for the organization to enforce a password policy different from its online web application. For example, the organization could mandate that the account is locked out after three failed attempts. It could also reject physical keypad sequences such as 2580 and repeating numbers, and it could restrict certain numbers such as the seven-digit phone number or the last four digits of the phone number. Each of these steps would help reduce the basic brute-force attack from being successful.
It should be noted that some WAP/Mobile HTML sites provide limited functionality, often just one or two functions with little account information available; however, the ability to buy/sell items or transfer dollars is available in most of these sites, and this is likely to increase in functionality rather than decrease (at least one major bank has full functionality with only a four-digit number PIN). Regular PC-based banking/e-commerce websites had very limited capabilities as well when they were first introduced and quickly blossomed into full-fledged web applications, but the enforcement of strong authentication lagged behind here too.
Adding to the “user experience versus security tradeoff” theme, another avenue of exposure is the crossover use of SMS and WAP/Mobile HTML applications. For example, some WAP/Mobile HTML sites allow the use of SMS to retrieve sensitive information. The general idea involves using a predefined destination number (registered earlier in the web application) and sending messages with specific words in them, such as balance, transactions, history, status, and accounts. The receiving entity then returns specific information back to the user, based on the request. Obviously, the use of SMS is important if non-PDA phones are used because e-mail is not really a strong option. After a mobile device is registered (that is, the user has registered their mobile phone number and a correlating PIN using the regular web application), the site allows the user to send SMS messages to a specific number and retrieve certain data, such as account balances and transactions. During this process, a user is not challenged with a user ID or password/PIN, but is simply verified with the caller ID value. For example, sending an SMS message to a predefined number (assigned by the bank or e-commerce organization) will return an account balance as long as the caller ID value is correct.
The key control here is the caller ID, which is thought of as a trusted value. However, a simple search on spoofing/faking an SMS message will turn up a lot of results (this can also be done using an Asterisk PBX). Hence, if a handset/phone number has been registered to receive/send information using SMS, an attacker can simply spoof the caller ID, send an inquiry to the known/predefined phone number, and then get the legitimate user’s sensitive information (such as their bank balance). One might argue that a handset must be registered first, but that should not be considered a protection layer because sending 20,000 SMS messages, where 10,000 are unregistered, does not affect a focused attacker much. Furthermore, any information that is given to the user, whether it is an account balance or a trusted/unique URL, based on the caller ID value should be not considered trusted. For example, some organizations will give a unique URL to every user that must be used with a valid PIN to access a WAP/Mobile HTML site. Unlike with SMS, the PIN is required to enter the mobile site; however, the unique URL can be obtained over SMS. Similar to the “balance” request, an attacker can send a request via SMS for the unique URL for any victim. Once the attacker has the unique URL by spoofing the caller ID, they can then begin the process of brute-forcing the PIN. Either way, using SMS to identify a user is very difficult and should not be considered the most secure option.
Encryption
The use of Secure Sockets Layer (SSL) and/or Transport Layer Security (TLS) is a critical aspect of online security. SSL/TLS is used often by web applications to keep sensitive information private over the Internet, bringing confidentiality and integrity to HTTP (via HTTPS). The need for transport security, via SSL/TLS, between a user’s mobile device and its destination is equally important, as a growing number of sensitive online activities take place on the mobile device and not the PC. This section will review the use of encryption in both WAP 1.0 and WAP 2.0.
WAP 1.0
In the early days of the mobile WAP world (WAP 1.0), TLS was used, but not end to end. WAP 1.0 used a three-tiered architecture, including the WAP mobile device, which in turn used a WAP browser, a WAP gateway (also known as a WAP proxy server), and the web/application server on the Internet. WAP 1.0 mobile devices mostly spoke Wireless Markup Language (WML), which is similar to HTML. The WAP gateway would translate HTML from the web/application server on the Internet to WML for the WAP browser on the mobile device. The use of the WAP gateway was fairly important in the early days because it would encode/decode all the data to/from application servers to fit the data, size, and bandwidth restraints of the mobile devices. In terms of security, the WAP gateway also played an important role. Due to the limited horsepower on mobile devices (including bandwidth, memory, battery, and CPU), full TLS connectivity between the mobile device and the web/application server was not used. Instead, Wireless Transport Layer Security (WTLS) was used between the mobile device and the WAP gateway, and SSL/TLS was used between the WAP gateway and the web/application server (see Figure 9-4).
Before we go further, we should pause and talk a bit about WTLS. WTLS is similar to TLS and provides transport security between mobile clients and WAP gateways. It is based on TLS, but is used for low-bandwidth data channels that would normally not be able to support a full-blown TLS implementation. Similar to TLS, WTLS provides confidentiality and integrity using standard block ciphers and MACs.
The WAP 1.0/WTLS architecture brought up several concerns for mobile users and security professionals, due to the absence of full end-to-end security. The process of converting communication between WTLS and TLS would occur at the WAP gateway (encrypting/decrypting), making it an entity that performs a man-in-the-middle attack, although legitimately. This meant that sensitive information was left in a plain-text format, either in memory or in cache, or even written to disk, on the WAP gateway itself. Because the WAP gateway is an entity that is owned and managed by an ISP, not by a bank or e-commerce institution, the ISP would have access to plain-text data from any user using their gateway. Although trusting every ISP in the world and their WAP gateways may have looked great on paper, the idea did not float too well with many sending and receiving entities. This scenario—known in some circles as the “WAP gap”—was not an acceptable option to many organizations because the ISP’s WAP gateway could see all the decrypted information to/from the mobile device. Whether it is a hostile ISP or simply bad practice, the idea of sensitive information being decrypted and then reencrypted between two trusted entities did not sit well with many banking institutions and e-commerce vendors.
Figure 9-4 WAP 1.0 and transport encryption
SSL and WAP 2.0
Due to the security concerns of the WAP gateway (WAP gap) and its legitimate use of a man-in-the-middle attack, full end-to-end security was supported in WAP 2.0. In the WAP 2.0 world, the WAP gateway was no longer required and became an optional device. Full TLS end-to-end encryption is supported between the mobile device and the web/application server, due to HTTP 1/1 support. A WAP gateway could still be used, but for optional supporting purposes such as optimization. Its role became more similar to a standard proxy-type device rather than a required translation device. With the full end-to-end support of TLS between the mobile device and web/application server, WTLS is no longer needed. Figure 9-5 shows an example of TLS connections in the WAP 2.0 architecture.
Figure 9-5 WAP 2.0 and transport encryption
Application Attacks on Mobile HTML Sites
Some of the first things many security professionals will want to know about Mobile HTML sites are how much is new, how much is old, and what they should care about. The previous two sections on authentication and encryption discussed what is new in the WAP world, and this section will address what is new in the Mobile HTML world, specifically which traditional web application attacks will work on mobile devices or mobile applications. The traditional web application attacks discussed in this section are not exhaustive, but will cover the most popular or pertinent attack classes currently in use.
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.
NOTE
This demo will purposely execute JavaScript from the book’s test site on the PC and the mobile device browser.
1. Using your PC, visit ht://labs.isecpartners.com/MobileApplicationSecurity/XSS.html.
2. A pop-up box appears, showing a proof-of-concept session ID (see Figure 9-6).
Figure 9-6 Cross-site scripting on a PC browser
3. Now using the browser on your mobile device, visit the same link in step 1.
4. 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 9-7). Although the picture is a bit fuzzy, notice the JSESSIONID in the Alert box.
5. 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:
a. Download and unzip ES40 from http://eise.es40.net/.
b. Double-click on the icon after the files are unzipped.
c. Once the emulator is up and running, insert http://labs.isecpartners.com/MobileApplicationSecurity/XSS.html in the text box under “URL you want to test: http://.”
d. The emulator will then visit the demo page, showing the local session cookie in an alert box (see Figure 9-8).
Figure 9-7 Cross-site scripting on a mobile browser
Figure 9-8 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:
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:
Add-in for Firefox: wmlbrowser (https://addons.mozilla.org/en-US/firefox/addon/62)
WAP browser: www.winwap.com/downloads/downloads
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:
For Firefox, SQL Inject Me: https://addons.mozilla.org/en-US/firefox/addon/7597
For Internet Explorer, SecurityQA Toolbar (SQL Injection module): www.isecpartners.com/SecurityQAToolbar.html
3. Visit the Mobile HTML page of the application you wish to test, such as:
m.<domainname>com
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:
a. On the menu bar, select Tools | SQL Inject Me | Open SQL Inject Me Sidebar.
b. On the sidebar, select “Test all forms with all attacks.”
c. Review the results after the testing is completed.
For SecurityQA Toolbar (SQL Injection module), follow these steps:
a. On the toolbar, select Data Validation | SQL Injection.
b. After the test is completed, select Reports | Current Test Results.
c. 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 www.isecpartners.com/files/CSRF_Paper.pdf. 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 m.gmail.com. Log in with your username/password.
2. Visit three to five other pages, such as the following:
3. Now revisit m.gmail.com. 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 (https://addons.mozilla.org/en-US/firefox/addon/62).
2. Install the TamperData add-on (https://addons.mozilla.org/en-US/firefox/addon/966).
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: http://morecowbell.cybervillains.com:8001/hello/csrf.
a. Select Charge Me.
b. 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 www.isecpartners.com. 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 http://labs.isecpartners.com/ MobileApplicationSecurity/CSRF.html.
a. Select the “The Latest News” hyperlink. After you make that selection, you’ll be redirected to www.isecpartners.com/news.html.
3. Open up the address bar again and enter the original site (do not hit any back button options): http://morecowbell.cybervillains.com:8001/hello/csrf.
a. 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 http://morecowbell.cybervillains.com:8001/hello/csrf?pay=Charge+Me%21 on behalf of the user, which was “logged in” during step 1, and then redirected the user to isecpartenrs.com/news.html.
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 www.mybanksite.com redirects a user to form.mybanksite.com when the user selects the Login icon. Hence, if the user visits www.mybanksite.com and selects the Login icon, they are redirected to the bank’s login page at www.mybanksite.com? Login=form.mybanksite.com. 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: www.mybanksite.com?Login=form.attackersite.com. Form.attackersite.com 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 (www.mybanksite.com) and not the items after it (?Login=form.attackersite.com), 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 www.attackersite.com/mybanksite.html is not legit, but the same does not hold true of www.mybanksite.com?Login=form.attackersite.com (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, labs.isecpartners.com is the legitimate site and espn.go.com is the redirected site:
1. Using the browser on your PC, visit http://labs.isecpartners.com:8001/hello/responseSplit?var=espn.go.gom. Notice the var parameter is vulnerable to HTTP redirects, forcing users of labs.isecpartners.com to visit espn.go.com.
a. After entering the URL, notice your PC browser now shows espn.go.com. It is obvious that you are no longer at labs.isecpartners.com, but on a different web page/web application.
2. Using the browser on your mobile device, visit the same URL: http://labs.isecpartners.com:8001/hello/responseSplit?var=espn.go.com.
a. Similar to step 1a, the browser will now go to espn.go.com; 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, espn.go.com was shown to verbosely demonstrate that the user is redirected to a different web page, even though it is coming from labs.isecpartners.com. 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.
Phishing
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 www.isecpartners.com, but really is a hyperlink to espn.go.com, it would show up as www.isecpartners.com in a regular e-mail client, but seems to show up as www.isecpartners.com <espn.go.com/> in a few mobile e-mail clients. The latter obviously shows to the user that the real destination is espn.go.com, not isecpartners.com. However, if the same e-mail is displayed on a mobile web browser, it shows up as www.isecpartners.com 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 Browser Weaknesses
A tremendous amount of research still needs to be done on the security of WAP and mobile browsers—the field is still very green from a security perspective. Overall, the restriction of the WAP or mobile browser and what it’s able to support will expose new attacks surfaces that were previously mitigated in traditional browsers. The following items are known limitations to date of WAP and mobile browsers, but this list should not be considered exhaustive.
Lack of HTTPOnly Flag Support
Traditional mitigations to cross-site scripting, such as the HTTPOnly flag, may or may not be possible on mobile browsers. Although Internet Explorer and Firefox both support the use of the HTTPOnly flag, which helps mitigate XSS attacks, the protection will be of little help unless a mobile browser supports the flag. For example, if a web application is relying on the HTTPOnly flag solely for its defense of XSS, an attacker might force the victim to view a vulnerable page on a mobile browser instead, where the protection does not live, and thus complete the attack despite the use of the flag.
Lack of SECURE Flag Support
Similar to the HTTPOnly flag, the mobile browser may or may not support the SECURE flag. The WAP or mobile browser’s treatment of this flag will affect the security of the site. For example, if a site should use SSL, such as in the login part of the site, but the browser does not honor the SECURE flag on the sensitive cookies, the browser should fail and not complete the request. In the case where the browser does not honor the SECURE flag but does not fail, it will let the sensitive cookie pass in the clear. Thus, an attacker can perform a downgrade attack to a non-SSL page and sniff the sensitive cookies over the wire. Hence, the protection held on a web application on PC systems has been totally eliminated once the same site has been accessed by a WAP or mobile browser.
Handling Browser Cache
Most mobile web applications are implemented without any specific client-side components. The risk of data being exposed on a lost phone is low and dependent on the behavior of the web browser on the user’s phone. Most web browsers will not cache pages served using HTTPS, which further reduces this risk. Unfortunately, as a performance optimization, some mobile browsers ignore Cache header directives and will cache all pages. If this is the case, make sure your mobile web application has the appropriate mitigation. Options include removing the cache from the phone often and disabling the “back” button feature. Both of these cache-clearing solutions are best efforts and only work in some browsers.
WAP Limitations
WAP browsers do not fully honor all HTML specs, thus exposing security weaknesses. For example, the AUTOCOMPLETE directive in <FORM> tags is not honored by most/all WAP browsers, which puts all login pages at risk. Further, many WAP browsers cache page directives not honored by the browser, which combined with the AUTOCOMPLETE exposure, will put sensitive data at risk.
Conclusion
As mobile devices continue to evolve, there will be a direct correlation between increased Internet activity and increased security risk. The day when users can check their e-mail, transfer funds from one bank account to another, read the latest news story, and simply update their Facebook profile using five or fewer clicks on the mobile device is not too far away, and the idea of securing this use case presents a significant challenge. As always, the need to have user-friendly WAP and mobile HTML sites will win over their protection, so the use of strong passwords, session timeouts, and even encryption will win over security. Organizations will make security decisions that are not consistent with the same decisions made on traditional web applications, thus making the WAP and mobile HTML sites a greenfield for attacks. Although early versions of these sites have limited support—some often not showing any account details—the limited functionally will soon disappear in favor of 100 percent support of all features/functions, similar to how web users demanded that all functions that one could do inside a bank be supported within their banking web applications. As the demands for richer and stronger WAP and mobile HTML applications increase, will security be allowed to ramp up as well? It is honestly too early to tell, but early indications are mixed, where some sites have taken security seriously in mobile environments, whereas others are simply dabbling to see how far they can stretch the issue.
In summary, this chapter touched on the major ideas a user should be aware of when using a WAP or mobile HTML site. Concerns about authentication, encryption, and web application attacks were addressed, but these topics barely scratch the surface in this space. As you saw in this chapter, many of the details within these three categories do not provide a consistent picture yet for the WAP/Mobile HTML industry. Instead, there’s room for improvement for developers, as well as many possibilities for attackers.