Okay, on my website, I have a lot of embedded pages for Twitch. Below all the embeds, I also have an authorization flow so that people can log into Twitch and click a follow button.
Normally, the flow would start at: mydomain.com/channel/name, and at the end of the flow, they would be returned to mydomain.com/auth. Originally, I had it so that the start URL would be stored in browser session storage using javascript; and then when they reach the final auth endpoint, I would use the javascript and pull the session storage and relocate them back to the original URL.
This has been working great... however, one of the features I have on my website is the ability to use custom canonical urls to proxy to their channel on my website. So someone could use theirdomain.com to proxy to mydomain.com/channel/them.
This created an issue with the session storage since session storage follows cross-domain restrictions. They would start at theirdomain.com and end at mydomain.com/auth. Since the domains don't match, I can't access the session storage to forward them back to the original URL.
I am using PHP, so I'm wondering what would be the best way to get around this. I figure instead of storing the start URL in session storage, I can save it using AJAX to temporary storage using PHP, linked to their IP addresses. However, I don't know how to do this.
Does PHP have some sort of temporary storage system with definable TTL? That also works across multiple domains? (it would be the same server)
If the request is proxied to the same application then the session is accessible, it's just the session identifier (which is stored in a cookie, hence the cross domain issue) which is causing the problem.
What you can do is pass the session identifier from one domain over the transition to the other domain, as part of a get request, so when you do the leap from theirdomain.comto example.com do it with a link formatted as http://example.com/blah/?session_id=[session_id_from cookie] (ideally using https).
Then on on example.com grab the session_id and use that to set the session_id in the cookie for that domain, and it will load the session from the source domain.
This can be used for session hijacking, but so can having your session_id in a cookie, so it's generally OK to do, though using https endpoints will improve security.
Collected from the Internet
Please contact [email protected] to delete if infringement.
Comments