5 ms·
This attack is far more serious than that example reveals. Instead of directing user's elsewhere, you could replace the contents of the page to look like an iCl
by rjmunro 5y ago
This attack is far more serious than that example reveals. Instead of directing user's elsewhere, you could replace the contents of the page to look like an iCloud login form while remaining inside the apple.com domain.
Depending on how the rest of Apple.com's site is configured, you could steal cookies and allow yourself to login without even needing a fake login page. You might be able to directly manipulate and make changes to the user's account.
- planb 5y agoI wouldn’t even be surprised if there are cookies for *.apple.com that you can read this way…
- ronsor 5y ago> replace the contents of the page to look like an iCloud login form while remaining inside the apple.com domain Indeed, and with the history.pushState() API, you can even change the URL to be more realistic.
- benkaiser 5y agoYou would still be scoped to the same domain (found.apple.com).
- iudqnolq 5y agoWould you really be suspicious of found.apple.com/login? Many companies have login flows through subdomains. Google redirects their main login flows through YouTube for some reason.
- pests 5y agoMy guess? The Google login system got complicated when they tried to merge your YouTube and Google account for G+ back in the day. YouTube probably has some say in the authorization or permissions for YT original accounts.
- bayindirh 5y ago> Depending on how the rest of Apple.com's site is configured, you could steal cookies and allow yourself to login without even needing a fake login page. You might be able to directly manipulate and make changes to the user's account. IIRC every process inside the iOS has its own cookie jar and browser container, so application X cannot read iOS Safari's or application Y's cookie jar or any cache in that regard. So, every application's web view is so-called alone on the OS.
- avianlyric 5y agoThat’s irrelevant. The AirTag opens a link in Safari, and allows you to run efficiently arbitrary JavaScript in the page that’s opened (iCloud). Containers and cookie jars don’t help you if the malicious code is running inside the container your sensitive data lives in. In this specific example, if the iCloud cookies are marked as JS visible, and there no content security policy preventing inline JS, then the JS injected could grab the iCloud cookie and exfiltrate it to an attacker domain.