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.
A pop-up box appears, showing a proof-of-concept session ID (see Figure 1).
Now using the browser on your mobile device, visit the same link in step 1.
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.
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:
Double-click on the icon after the files are unzipped.
The emulator will then visit the demo page, showing the local session cookie in an alert box (see Figure 3).
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:
Use the following steps for a quick method to test for SQL injection in Mobile HTML sites:
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.
Download and install some freeware SQL injection tools that can be added to the browser, such as the following:
Visit the Mobile HTML page of the application you wish to test, such as:
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:
On the menu bar, select Tools | SQL Inject Me | Open SQL Inject Me Sidebar.
On the sidebar, select “Test all forms with all attacks.”
Review the results after the testing is completed.
For SecurityQA Toolbar (SQL Injection module), follow these steps:
On the toolbar, select Data Validation | SQL Injection.
After the test is completed, select Reports | Current Test Results.
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:
On your mobile browser, visit m.gmail.com. Log in with your username/password.
Visit three to five other pages, such as the following:
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:
Using Firefox, install the wmlbrowser add-on (https://addons.mozilla.org/en-US/firefox/addon/62).
Install the TamperData add-on (https://addons.mozilla.org/en-US/firefox/addon/966).
Visit the mobile HTML site of the application you wish to test and log in with a valid username/password.
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).
Enable TamperData (Tools | TamperData | Start Tamper).
Change the e-mail address on the page and select ENTER.
When the Tamper Data pop-up appears, select Tamper.
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.
Select OK and then Stop Tamper.
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:
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:
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.
