Security considerations of single signon in context of XSS when you think of it at first it sounds like a great idea. All you have to do is set a global cookie for the main domain and based on that perform authentication. User will be able to go from subdomain to dubdomain and still remain authenticated.
Unfortunately there is second side to this story : )
Why would anyone do it?
So the motivation is very simple, you want your customer to be able to jump between subdomains and still remain logged in. For example you have a admin panel for your clients on admin.mydomain.com and then you have customer support at cs.mydomain.com and then you have affiliates programme etc. etc.
You want your client to login once and be able to go from web app to web app remaining logged in.
Global cookies
What people would do is create global session id and store it in main domain like
.mydomain.com
then cookie is send by the browser to any request in the subdomains so you can verify it on server side and check who is the logged in user.
Consequences
Finally we get to the troublesome part. Since cookie is attached to all requests in all sub domains you have to make sure that all of the subdomains are fully secure now! if you have forum.mydomain.com and other 3rd party software or some old forms you have to make sure they are all protected from XSS attacks.
Making single signon this way forces you to treat all sub domains like they were your main admin panel. One mistake may result in stolen sessions and customer accounts!
How exactly does single signon increase XSS risk?
Single signon is not a problem its just that enterprises usually grow with time so you will have tons of deprecated web properties. Some old forms or abandoned sections of your sites. If you use single signon this way you will have to make sure none of these sites are XSS vulnerable. If they are then hackers will be able to use them to create XSS attack url and steal customer sessions.
Summary
If you still have to do it make sure you validate each request as tightly as possible. Best way is to check user agent string against the one saved in session as well as check source IP address. This should protect you from session hijacking.
Comments
Post new comment