Skyscanner - Hotel Search 2.2.2 (iOS / App Store) on 2016-4-22

privacymeteronline
22 апр. 2016 г.
4 мин. чтения

Let's go back to Skyscanner. Developers released not only application for looking flights and but for hotels too. So, we have two separate applications. This application hasn't been updated since Sep 16, 2015 and has similar protections techniques. What does this app offer:

Key features: Compare hundreds of thousands of hotels, resorts, apartments and hostels. Find hotels near your current location. Even search last minute hotels for tonight. Share hotel details via email and text message, to keep travel companions in the loop. See inspiring photos and consumer reviews, to help you find the ideal room. Exclusive new Apple Watch functionality, including a great new 'find your way back to your hotel' feature.

You may notice that average values are bit higher than Skyscanner (flight) ones due to less data types were found with a bad protection level. The following data groups were found: Booking'n'Purchasing and Travel Information, Account and Credentials Information, Payment and Analytics Information. You can find this information on the first pic attached to this post and available via Pinterest. Second pic shows what specific data types assigned to each group were found in this app.

First pic includes info about data items combined into groups and best protected items found.

Second pic includes info about data items separately from group and worst protected items found.

Here all travel data types have hotel & accommodations meaning.

Locally stored data (DAR). All items have the same level of system protection that equals 6 and don't have developer own protection techniques implemented, therefore the average value is 3 points. It means data types stored in plaintext app folder and protected only by sandbox. Credentials information such as tokens, secret tokens and ID (usually email address). Also, each app saves the screen of application window when you're switching to another application that means the screenshot might have a sensitive information. Comparing to Skyscanner (flights) the following data weren't found locally stored Application Configuration Data items, detail information about your device, geo data, your personalization info - your search requests you've done while using this app.

As the system protection level is 6 points, this is good protection, because it means your data can be extracted from backups according to wide available tools. However, as we mentioned above, if you have jailbroken iOS device it decreases level down to 0. Also, keep in mind there're lot of non-public solutions how to get your data. Warning, if your iOS < 8.3 this data can be accessed without jailbreak even. Since 8.3 this vulnerability was fixed, however it wasn't officially vulnerability almost 4 or 5 years. So, it would be better to have data additionally protected in this case, right :) ? Transferred data (DIT). All items have the very low average value below 2, while the system DIT protection is a bit higher 3 points and own is 3. Let us explain our findings. Most of data here transferred as is without any kind of protection or encoded in base64 or compressed by default if http-compressing is on. List of non-protected data includes: travel details transferred to Skyscanner servers and 3rd party, and personalization data (your search requests). Comparing to Skyscanner (flights) the following data weren't found in non-protected state: application configs, device data (more general than details), orders and reservation history, geo-media data (pics of famous places depend on city you're looking to travel) and sort of data collected by analytics library - device data, travel data (general info about your trip), environment (misc info about your OS)

Comparing to Skyscanner (flights) the following data (List of encoded (mainly compressed) data) weren't found too: geo data, personalization stored on skyscanner servers, travel details, order & reservation details. It doesn't mean your data protected, because (de-)compressing it default feature of http libs.

Rest of data has 4 points and requires your device to have installed fake certificate to perform MITM attacks. It includes full card information (incl. cvc) used to perform purchasing, sessions details of booking and orders history & details information, device data & details sent to ads & analytics servers, credentials (ID, password, tokens, secret tokens) sent to Skyscanner server, account details (your profile), your favourites 'n' tracked data. Comparing to Skyscanner (flights) were found more data . Talking about credentials, the best practice is using customer password once and switching to token then, however this app continues using your password after log reconnection. Talking about card, paying via browser or internal browser as a part of mobile app has only 4 points because doesn't prevent MITM if you've a fake certificate installed but also doesn't protect you if you don't have it installed but only informs about untrusted certificate and if you accepts this fake certificate your data would be stolen. Warning each data type with 4 points has both 4 points per system and own protection, except card full info & sessions details, because these data shown via internet browser and has only system protection without own protection (so sys - 4 points, own - 0 points). No good news - no best protected data, but there're worst protected data type were found. All worst items have points below 2 mentioned above as List of non-protected data. Once again, keep in mind, that the latest app version and build was examined on the last iOS and if you use older iOS version < 9 you might have found that app doesn't secure enough and data might be accessed without actions from you side (= the average level for transferred data would be equal 2). Also, older iOS versions < 8.3 don't provide enough protection for app data locally stored to allow access app data (except system like keychain) without jailbreak access. And, even good but template-based MITM protection could be patched too.