Thanks for pointing out what i was about to ask. The browser sends the cookie for SIMPLE.COM to SIMPLE.COM, not S1MPLE.COM. If the malicious web app sends the GET request to SIMPLE.COM, it does not know the cookie that is set for SIMPLE.COM from the server. If S1MPLE.COM redirects the users browser to SIMPLE.COM, the browser will send to cookie to SIMPLE.COM. The browser will never send the cookie for SIMPLE.COM to S1MPLE.COM. There is no way S1MPLE.COM gets the cookie for SIMPLE.COM „helpfully supplied“ by the browser „since it is the right domain“ (what domain?!). Next up, i do not see a difference between the cookie passed around in a HTTP header and a „session token header attached to each request“. Regarding security, it is the same. Both are HTTP header values.
Then suddenly, focus switches to MITM attacks and using HTTPS instead of HTTP, which is completely orthogonal to the topic of using session cookies. Finally, session ids logged to a file only visible to the web app developer are the problem.
This conglomeration of topics feels like someone wants to spread FUD by enumerating some vague and unrelated spotlights on some security topics one might have heard of. But the scenario described here is plain wrong. Claiming that the scenario describes a CSRF attack is plain wrong. What is the rationale?
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for pointing out what i was about to ask. The browser sends the cookie for SIMPLE.COM to SIMPLE.COM, not S1MPLE.COM. If the malicious web app sends the GET request to SIMPLE.COM, it does not know the cookie that is set for SIMPLE.COM from the server. If S1MPLE.COM redirects the users browser to SIMPLE.COM, the browser will send to cookie to SIMPLE.COM. The browser will never send the cookie for SIMPLE.COM to S1MPLE.COM. There is no way S1MPLE.COM gets the cookie for SIMPLE.COM „helpfully supplied“ by the browser „since it is the right domain“ (what domain?!). Next up, i do not see a difference between the cookie passed around in a HTTP header and a „session token header attached to each request“. Regarding security, it is the same. Both are HTTP header values.
Then suddenly, focus switches to MITM attacks and using HTTPS instead of HTTP, which is completely orthogonal to the topic of using session cookies. Finally, session ids logged to a file only visible to the web app developer are the problem.
This conglomeration of topics feels like someone wants to spread FUD by enumerating some vague and unrelated spotlights on some security topics one might have heard of. But the scenario described here is plain wrong. Claiming that the scenario describes a CSRF attack is plain wrong. What is the rationale?