Are You Prepared to Deal with the XSS Threat?

Cross-site scripting (XSS) is a flaw in Web applications that allows attackers to insert their own client side script and redirect users or bypass access controls.

Most recently it came to light, according to Full Disclosure by SecLists, that XSS and SQL injection attacks are possible in OpenText Document Sciences xPression (formerly EMC Document Sciences xPression). If you believe your organization may be susceptible to the flaw, read on.

The XSS threat

The XSS vulnerability has been around for some time. The endgame for using XSS is simple: it allows attackers to consume privileged data or content by impersonating legitimate users. It's accomplished by taking cookies from a user that has authenticated into the Web service, and using those cookies as a sign the malicious source is trusted. Attacks such as these bypass traditional security controls, when cookies are used for authentication.

I can simply place a link on a Web page containing my XSS and when you click on it, your session's cookies (along with the required trust) gets sent to me. I can now use your trusted relationship established from your last authentication with the stolen cookies.

This should give us pause. Is there any doubt that identity has become the new perimeter?

Steps to take now

There are three things organizations can do to mitigate XSS vulnerabilities:

Implement 'zero trust'
Use strong authentication (viz. 2FA)
Automate policy management

With zero trust, we can get around the cookie problem. In this design, cookies are no longer a legitimate arbiter for authentication - everything must be verified. The user must re-verify at every turn, so the stolen cookies are meaningless for the thief. Additionally, strong authentication (usually in the form of 2FA), forces the user to have a point-in-time challenge to access content.

Two-factor authentication comes in three ways: 1) something you know (like a challenge question), something you are (like biometrics) or something you have (like a number key). Using 2FA adds another step in the process to curtail unauthorized access.

Most importantly, organizations can automate their policy controls. Once you have segmented networks and established zero trust within and throughout, automating policy management is your linchpin. If each task to block or grant access is a manual effort, it can be a daunting exercise. Organizations moving to zero trust can make it practicable by automating policy controls that govern this new array.

Cookies are dangerous for authentication

XSS vulnerabilities affects users and organizations by abusing the convenience of cookies. Cookies are saved in the browser for the user's convenience, allowing them to come and go with continuous access to content. By using the steps above, however, you can automate the security measures so the experience is the same for the user. I am only proposing that cookies be removed as a source of authentication.

Initially, users can become annoyed with steps to re-verify their identities and their privileges to access content. Automobile drivers were also originally annoyed by laws requiring seatbelts. After a little time, we all became accustomed to the safety measures, because we acknowledged its effectiveness to keep us alive.

quote "Initially, users can become annoyed with steps to re-verify their identities and their privileges to access content. Automobile drivers were also originally annoyed by laws requiring seatbelts."

"Josh Mayfield, FireMon

When we integrate these security measures, they become the 'new normal'. No one wants to see their identities stolen, their files held hostage or credit evaporate. Just like I don't particularly like the idea of not being protected in a vehicular crash. Buckling up is now integrated into my driving process - so too, for zero trust and strong authentication.

The role of vendors

Earlier I mentioned convenience as the primary driver for browsers to store cookies for later use. Vendors want to produce a web service that is seamless for the end user. So, they may reason, "Why not use cookies for authentication? Seems like it would be good for our users..." This is a feature, not a bug.

However, vendors are taking strides to have better authentication for the users. For example, SAML has changed the lives of so many users by removing the need for passwords (which tend to be weak) and bringing the user to their content securely and quickly.

Let's imagine though you own vendor products that are behind in the security game. Still, you can control access with policies and rules. You can achieve the security you want and reduce your risk with better policy management. This adaptive policy management is possible by automating steps to ensure the right user is accessing the right content across the right protocol at the right time.

It is not as though vendors are lazy or unsympathetic to an organization's security needs, they simply want an easy user experience. Given this vendor inclination, organizations can take their own steps toward zero trust and get the same result (ease, convenience) without sacrificing security.

Security by design

First, products should be able to run wherever the organization wants to run them, which means products need to have flexible deployment models allowing organizations to place the product wherever they are most comfortable. Often, one measure of comfort is being able to place a product within the controls the organization prefers.

Second, vendors should stop being na‚Äö√†√∂‚àö√≤ve about security. Prior to release, vendors should try to 'break' their own security with Red Teaming, and stop seeing security checks as an impediment. Which is worse, delaying a release for a moment to confirm security or lose every customer you have because of a missed vulnerability? Back to the seatbelt example (in the early days when auto manufacturers didn't want to install them). Which is better, adding a little time and cost to install seatbelts or losing all of your customers who are unable to use your product safely?

It's a good bargain to opt for security.

About the Author
Josh Mayfield is platform lead for Immediate Insight, FireMon's security analysis platform. He works with global security leaders to improve security analysis using big data principles and automation. Josh's work has been featured in industry-leading publications, including Information Age, ISACA, and IT Security, Europe. Josh holds two master's degrees. Before coming to FireMon, Josh held positions at top performing organizations in technology, information security and consulting.