Even security experts have trouble detecting a potentially dangerous Website on a mobile browser, according to a recent study at Georgia Tech.
Users on mobile browsers are vulnerable to certain types of attacks because the browsers are not implementing all the recommended security indicators in the interest of conserving screen real estate, Patrick Traynor, assistant professor in Georgia Institute of Technology’s School of Computer Science, told SecurityWeek. Since the users don’t have the visual cues to alert them to attacks, it is more difficult to avoid becoming victims, he said.
Mobile Web Browsers were missing certain security elements and indicators that are common in desktop Web browsers, or things weren’t implemented consistently. The researchers figured that if they, as experts, had trouble figuring out what was going on in the browser, then it made sense that average users were at higher risk. The study was designed to find out whether the browsers provided enough information for even an information security expert to determine the site’s safety.
“With all 10 of the leading browsers on the market today, the answer was no,” Traynor said.
The researchers used a mix of devices and browsers for this study, including the Nexus One, BlackBerry Bold 9650 and Torch 9800, Nexus S, LG-C900, Nokia 701, the iPhone 4, Samsung Galaxy tablet, and an iPad 2. The tested browsers included the stock Android browser (2.3.3) , Chrome Beta, Firefox Mobile, Opera Mini, and Opera Mobile on Android, the Blackberry browsers on BB OS 5 and OS 6, Internet Explorer Mobile on Windows Phone 7, Nokia browser on Symbian, and Safari on iOS 4.1. These browsers accounted for more than 90 percent of the mobile browser market, Traynor said.
The mobile browser results were compared against five desktop browsers, including Chrome 15, Firefox 7, Internet Explorer 8, Opera 11.52, and Safari 5.1.1.
All 10 major mobile browsers failed to meet the security guidelines outlined by the World Wide Web Consortium for browser safety, Traynor said. Desktop browsers were “off the charts” in how the requirements were implemented, but every single mobile browser was missing at least one requirement. Mobile browsers also don’t apply the guidelines consistently, Traynor said. Users were vulnerable to at least one type of attack using mobile browsers, regardless of which one they used.
“When it comes to mobile, we are not doing as well as the desktop,” Traynor said.
The W3C has specific recommendations for how SSL indicators should be including within the browser, such as making the Website’s identity visible to the user at all times. Users should also be able to look at the site’s digital certificate to see the domain name and the reason why the information is trusted. Security information shouldn’t be obscured by the contents of the Website, and security indicators, such as the lock icon, should be shown only if the page is actually secure.
Researchers attempted to view a public Webpage’s root certificate from the each browser and found that none of the mobile browsers followed completely followed the W3C guidelines on how to display certificates. The IE Mobile, iPhone and iPad Safari, and Opera Mini and Mobile browsers did not have an interface for users to view trusted site certificates, the researchers found. If the site had an invalid certificate, all the browsers displayed an error message through which users could access the certificate.
The stock Android and Blackberry browsers, Chrome Beta, and Nokia’s browser actually had a certificate interface, regardless of whether they were trusted or untrusted, but it wasn’t clear how to access that screen. Users could view the certificate information by tapping on the lock icon in Chrome Beta and Blackberry (BOS 5) browsers, but other browsers hid the screen under “options” in the browser menu, the study found.
“It’s not like the desktop, where everyone knows where to tap to see the certificates. Depending on the [mobile] browser, it’s a different way to see the information,” Traynor said.
Even so, users were unable to see all the information on the certificate, the researchers found. With the exception of the Blackberry browsers, which displayed all the required parts, all the other did not explain why a particular certificate was trusted. “You can’t see who issued the certificate,” Traynor said.
The Dignotar breach is a good example of why it was important the user should be able to see all the certificate details. If the user sees that Diginotar issued the certificate for a Website, that user should be able to say “Ah! I know Diginotar was compromised, so I am not going to trust them,” Traynor said.
There were similar issues with how the URL was displayed and the use of the padlock icon to indicate the page was using a secure connection. In many cases, the browser doesn’t display the full domain name upfront, so a user may see “bankofamer” and the images on the site and think they are on a legitimate Bank of America site, as opposed to “bankofamericas” or “bankofamerica2,” Traynor said. This makes users vulnerable to phishing attacks on mobile devices.
Both Blackberry browsers and IE Mobile displayed a padlock icon on a Webpage that had both secure and insecure elements, which goes against W3C guidelines, the researchers found. The Android browsers displayed an open lock with a question mark inside the lock, and Chrome Beta displayed a closed lock with a cross on top. Android and Chrome users now need to “understand the meaning of the new symbols” in order to understand that the page included secure and insecure content.
The Android mobile browser does not follow W3C guidelines and displays the site’s favicon, a graphic that is often used to identify the Website, right next to the padlock icon, researchers found. This means an attack can trick the user into thinking the site is secure by displaying a lock as its favicon.
It also didn’t help that all mobile browsers in the study except Android, BlackBerry (BOS 6), Chrome Beta and IE Mobile displayed the lock icon on the title bar instead of inside the address bar, researchers found.
“Whenever a user starts interacting with a webpage, most mobile browsers hide the address bar to accommodate more content on the small screen,” according to the paper.
The mobile device’s smaller screen size has a lot to do with the “tension” between what to display and what the requirements say, Traynor said. There isn’t a lot of room on the screen to display all the security indicators in the same way as desktop browsers, so browser vendors independently decided on what to include.
However, it has created an environment where users don’t have the information needed to detect, and possible avoid specific attacks, the paper found.
Traynor was quick to point out that his team wasn’t advocating that mobile browsers have to do everything the same way as the desktop browsers, since screen size needs to be considered. But there is a catch-22 where if the security protections are implemented as required, users are vulnerable, and if they are, there’s less space on the screen.
Browser makers have to agree on the “right set of indicators” and make sure that list is implemented consistently, Traynor said. Since a certificate interface to view details can easily be on the secondary screen, it should be implemented on all browsers, he noted.