CSRF attacks, the Cookie Snatcher
Who wants your cookies? Besides the usual suspect (a little levity despite the serious topic), anyone who wants to bet on the chance that you're logged into numerous sites across many browser tabs at the same time.
The nefarious approach called a CSRF attack (cross-site request forgery) does just this. It exploits the likelihood that you have logged into your bank site on one tab and are viewing a forum on cat videos in a second tab.
If the attacker can get you to click a link to a website they control, they can cause your browser to make a "blind" request to your banking website that can (for example), request a funds transfer. The browser would blithely attach your session cookie to the request (it came from your browser after all!) and you would appear authenticated to the banking website.
But fear not! There are numerous ways of detecting and preventing CSRF attacks. Most security-aware products like PortalGuard (and even some banking websites) implemented CSRF prevention tactics years ago.
SameSite cookie attribute
About four years ago, the sages of the internet introduced a technical specification recommending a method that could put an end to CSRF attacks. They called it the "SameSite" cookie attribute. It effectively provides a way for websites to better control their cookies and prevent the scenario described above. The good news is that this recommendation is now becoming a general practice. Most major web browsers have added some level of support for it, but it was Google's Chromium that was the first to enter the fray. After numerous delays and much handwringing, SameSite support was recently released to the kingdom in Chrome version 80.
But wait. Why would there be any angst or handwringing?
There are already some excellent resources on how the SameSite attribute affects cookies, but suffice it to say that there are certain use cases where the default cookie passing behavior differs. Embedded resources like iframes are affected, but more importantly (for our PortalGuard product) some fairly common SSO mechanisms are rendered "broken" as well.
The specifically affected scenario is where an application sends an SSO request to PortalGuard via POST. If the end user has not yet logged in, they are prompted to do so, as usual. So far so good. However, if the user already has a valid logon session with PortalGuard, the cookie representing that session is held back by the browser. The user can continue by logging into PortalGuard a second time, but SSO is broken.
In a superb irony, a new mechanism designed to eliminate an attack method (SameSite support) breaks an existing technology (SSO) that has its own significant security benefits.
Happily ever after
Fortunately, there is a happy ending to the CSRF prevention story. The engineers at PistolStar were able to address these issues in PortalGuard by some simple configuration changes, ensuring the SSO use case above still works as it did previously. Here is our knowledge base article that walks through the required changes.
And to the fraudsters who preyed on unsuspecting internet denizens over the years with these cookie-based attacks, good riddance! This new web browser behavior is here to stay, and Chromium is the stalwart keeping us all safe yet again.
Implementing SAML SSO
Thinking about SameSite cookies or Single Sign-On in general, organizations will need a product that can create a single or federated authentication process to handle multiple local and cloud applications, while providing a centralized point of secure access. Implementing a SAML (Security Assertion Markup Language) SSO option with PortalGuard as the Identity Provider achieves the goal of eliminating password issues while providing more:
- Reduce the number of passwords users are required to remember and manage.
- Implement and enforce configurable password policies.
- Reduce password-related Help Desk calls related to password and access issues, and many more.
Read more about the benefits of an SAML SSO option in our eBook here.