0

Very simply we have a ton of websites at our company behind SSO.

I am having a hard time figuring out what security issues there are if we open cross-site sharing between these sites but wanted to get a broader view. This is really a result of browser updates around cross site sharing in iframes in chrome and IE a few months back. With those security features disabled at the browser level (yes we will not have users do that) iframing within our sites work fine.

Let me give you context of the specific problem:

  1. example.com - main site
  2. subdomain1.example.com - subdomain we have a ton
  3. subdomain2.example.com - another sub
  4. example.login.com - SSO server we authenticate to
  5. example.cms.com - random vendor that uses our SSO

So right now as long as the servers in 1, 2, and 3 allow cross site sharing iframes work... as long as your cookie/token is already active. If it is not active then it just errors out trying to connect to example.login.com.

We are discussing changing the CORS/sharing settings on the login server and others brought up possible security issues. I just don't see how there are issues with clickjacking or anything else when we control all of the sites ourselves. Am I missing something here? Are there security issues with sharing between controlled tenets? Let me know if I need to provide anymore info.

  • possible security issue Can you be more specific? – John Wu Oct 23 '20 at 5:37
  • @john wu - Should a company be worried about iframing its sites within each as a security vulnerability? If so what would be the main risks? – blankip Oct 23 '20 at 5:47
  • if you are logging on a single sign on with passwords, a lot depends on how these passwords and other data is being communicated or stored within the linked sites. You mentioned iframe, is that using X-Frame options? From the information here I can't really comment much though, it is a bit to vague. – Coderxyz Oct 27 '20 at 20:26
  • @Coderxyz - all of the sites are run through us and stored by us. as far as user/pass. What is vague - I can get very specific if you need something. – blankip Oct 28 '20 at 0:51
0

According to your description, I think what you are looking for is Content Security Policy (CSP). This header is can be specified by the web developers or administrators in the response, to declare approved origins of content, a specific browser should be allowed to load on a website. The intention was to provide a standard way to mitigate code injection attacks like XSS and clickjacking.

Almost all the modern browsers support this.

Refer this To get an idea on how to test if this works on the client side.

More info on the header can be found here

  • I get this. I don't get how my site could get injected from other sites under our umbrella that have the same policies and behind SSO (not public). This answer explains how to police this better but doesn't really answer what security flaws there are between sites that you manage yourself. – blankip Oct 30 '20 at 3:34
  • @bankip SSO and not public means two entirely different things. SSO means when your users sign in to a one site, they don't have to sign in to other sites when they visit those sites. Think of google services. when you sign in to Gmail, if you use the same browser you don't have to login to other services. Not public means different things in different contexts. Can you elaborate? Also SSO does not protect you from XSS attacks if your users are not completely isolated from public internet. A malicious script may infect the machine that injects code in to web forms or specially iframes. – Sithum Oct 31 '20 at 23:38
  • @sithium - iframes are not disabled, they are disabled between these specific sites. That's all I am asking about. What do you need me to elaborate on? I think you think the question is simple - it isn't. I have years in the field and I am looking for a real answer generic things. – blankip Nov 1 '20 at 7:30
  • Yes I get the iframes are not disabled. And the question is vague and talks about SSO which does not provide any security measure against XSS attacks, if a user already has legitimate access. What happens if the attacker hijack a user session? All I'm saying is that, there is no perfect security. Just like security attacks are also multilfaceted. Given that I would say others' concerns are valid. – Sithum Nov 1 '20 at 9:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.