InformAction Forums

When I attempt to launch sites through my work's SSO portal, I only get a blank new tab instead of the expected SAML handshake and page load. As we have heavily embraced SSO, this has a massive impact on my productivity throughout the day. I am using Firefox (tested against 100.0.1 and 100.0.2) + NoScript (11.4.5).

Since the page opens in a new tab, I can't use the normal "Web Developers Tools" view to see what's going on. Luckily, Firefox also has a "Browser Console" that allows you to see the same information across ALL tabs to track what's happening.

What I see in the console is a GET request to the launch page, with a 302 Found response and a red cancel/error circle ( \ ), but shown as "Blocked By Extension." I can see the full headers and cookies data. However, the request payload is scrubbed ("No payload for this request"), and obviously there is no response. I have both of the two domains involved in the handshake added to trusted sites, and I even turned off the XSS protection ("Sanitize cross-site suspicious requests" is unchecked) for the purposes of this test.

The only way I've successfully been able to get this to work is to Disable restrictions globally (completely undesired). Since the action automatically opens in a new tab, I don't have the ability to Disable restrictions for this tab without breaking the initial SAML request. I've tried restarting the browser and OS, as well as clearing cache and cookies. Once the initial request has gone through, and assuming my session has not ended, it does seem that I am able to launch additional SAML requests to the same target site with NoScript enabled, without any issues.

While I can't share details on the exact SAML process for obvious security reasons, I can share that the JS associated with launching the site+SAML request is hosted on a subdomain of cloudfront.net, under /hub-ui/

Could you please PM or email me your NoScript Options>Export file as well as an extract of your browser console (sanitized of any confidential data, if needed)? Thanks.

Sent via PM. Thank you.

concerneduser wrote: ↑Tue May 24, 2022 4:27 pm Sent via PM. Thank you.

Thank you.
Two things in your information prompt further inquiry:

1. In your DEFAULT preset the fetch capability is disabled (which is not the factory setting). Does turning it on fix your problem?
2. You've got the "Show full addresses" option enabled, and the blocked request is to cpm.[scrubbed].com. Was this domain (or .[scrubbed].com) explicitly set to TRUSTED?

Thank you again for looking into this.

I changed the preset for Default to include "fetch" and confirmed that cpm.site1.com (as well as the full domain site1.com) as well as site2subdomain.site2domain.com are explicitly added to the Trusted list. (If it matters, they are NOT set to match HTTPS only, although all requests are HTTPS anyway).

Unfortunately, the behavior hasn't changed, even after restarting the browser (and re-confirming the preset).

OK, let's try some more low-level debugging.
Could you please

1. check NoScript Options>Advanced>debug
2. about:debugging and click the [Inspect] button on the NoScript entry
3. select the Console section in the newly opened NoScript-specific dev toolbox tab
4. send me the console entries appearing when the problem happens?

Thanks!

Another PM sent. I appreciate your time spent assisting me!

concerneduser wrote: ↑Wed May 25, 2022 12:25 am Another PM sent. I appreciate your time spent assisting me!

And there another hint (which you noticed as well): you've got several WAN->LAN requests blocked.
Looking at your config again, I realize you've got another non-standard preset: in TRUSTED the lan capability is disabled, which is not the expected factory setting.
Could you try to enable it in TRUSTED (or CUSTOMize the domains which need it and you can see LAN-blocked) and report back?
Thanks!

Modifying the LAN setting did the trick. What's odd is I imported the configuration from my personal laptop, but confirmed both LAN and fetch are checked (in fact, everything is checked as per "factory settings") on the configuration for that machine. I don't know how it was changed, but that's not the focus of this request, and I now consider this issue resolved. Thank you!

Just to close the loop, I re-exported my configuration from the source machine, and "lan" is included in the TRUSTED configuration. So this was due to a now-restored change on the source side that I must have made months ago. I'm disappointed I didn't catch that in my initial analysis, but am very appreciative you showed me some new tools and insight to get there.