psl-problems

to something similar to this invalid scenario: 1. Alice operates a web store at alice.example. 2. To make purchases, alice.example makes HTTP requests to api.alice.example from within the browser. 3. api.alice.example doesn’t pay attention to Host headers. 4. Mallory operates a malicious website at mallory.example. 5. Mallory cannot make requests to api.alice.example from mallory.example—that would break the same-origin policy. She works around this by configuring api.mallory.example as a CNAME to api.alice.example. 6. Bob has an account at alice.example, and is currently logged in. 7. Mallory tricks Bob into visiting mallory.example. 8. The content loaded by mallory.example makes a request to api.mallory.example indicating that Bob is making a purchase. This doesn’t work—Bob is safe, and Mallory doesn’t score any loot. When the browser makes the request to api.mallory.example, it will pass cookies from api.mallory.example and mallory.example, not api.alice.example and alice.example. The browser pretends it has no idea that api.mallory.example and api.alice.example point to the same server. In order for this to work, Bob would need to log in again, but this time at mallory.example—and this brings us back to my original point; it’s easier and more effective to set up a standard phishing page without any CNAME shenanigans. While I agree with most of the author’s points, this one baffles me. I don’t see any realistic security implication of what the author has described in this scenario. There are theoretical implications, but in every case it seems there are far easier and more effective attacks. Furthermore, it’s nearly impossible to solve the problem described here; the proposed solutions the author mentions for replacing the Public Suffix List don’t resolve the CNAME threat I’ve described. Edit 2: I’ve opened an issue asking for clarification: https://github.com/sleevi/psl-problems/issues/4