Skip to content

Posts tagged ‘leakage’


Mobile Web Identity Leakage in HTTP Headers

This year has seen some interesting research (Mulliner and xuf) into the way mobile carriers modify users’ HTTP traffic when surfing the web. Unlike most ISPs, which provide you with a direct pipe to the internet (with little or no filtering), mobile phone carriers behave in a much more gateway-like fashion. As such, mobile carrier proxies tend to add information into the headers of HTTP traffic, some of it just for session-tracking, others containing interesting data.

Of all the information added into HTTP headers, by far the most interesting is the inclusion of the user’s handset IMEI (a unique identifier) or mobile telephone number. These are inserted into headers, such as X-Network-info, and is then available to anyone with access to the network traffic. If a website is so inclined, they can log the headers associated with HTTP requests and then use this information to further track and/or advertise to you. If I were so inclined, I could wait for a mobile browser to leak the visitor’s telephone number and give them a call!

Your browsing activities are already very trackable thanks to a number of things including browser fingerprinting, but this issue now makes you potentially personally identifiable – and trackable. Mulliner’s set up a simple Privacy Checker, where you can see what headers your mobile browsing creates.


Safari AutoFill Information Disclosure (with PoC)

Thanks to Safari’s nifty AutoFill feature, it has long been susceptible to an information disclosure vulnerability which could allow an malicious web page to extract various details stored in your personal vCard in Address Book.

This was highlighted a while back, and today re-emphasized by Jeremiah Grossman with a proof-of-concept attack.

The issue exists due to the way that Safari tries (by default) to auto-populate some of your details, including name, address, telephone number, etc, when you fill out forms. This can only happen if you have ‘AutoFill web forms’ enabled in Safari’s preferences, as shown in the screenshot below:

Uncheck these boxes to prevent this attack… but note that you’ll have to type your own info in afterwards! It’s not a high-risk vulnerability, but if you’re concerned about your privacy whilst browsing and in general, do what I do and don’t actually set an empty card as your personal card in Address Book. You can do this by creating a new card (enter some dummy info if you want), selecting it, and then choosing “Make this my card” from the Card menu.

Apple’s been notified of the issue, however as this is a ‘feature’ and not a bug, it’ll be interesting to see whether they’ll actually choose to do anything about it.