Jul 13, 2020 Client Side Fail: 20+ Years of Not Securing the Web Client Side
Almost since the inception of the commercial Internet, security compromises exploiting the ability to hijack dynamic code content have plagued us. I think cross-site scripting, a form of client-side attack, has been on OWASP’s annual top 10 web security threat list since the list’s creation. How can something be a top security issue for the Web for so long? The answer is simple: client-side security has always been a moving target, was and is complicated, and fixes have to be effective without breaking the incredibly powerful model built around dynamic coding, across all platforms.
Enterprise Security Includes Client Side Security
Enterprise weakness on securing the client side of web consumption was perhaps excusable when the web was primarily dispensing static content and providing a PR face to the company — that is, around the year 2000 (the very year in which the term cross-site scripting was introduced, as it happens). As the enterprise web became steadily more dynamic through the rise of intense scripting, and throughout the evolution of the current hypercomplex network of partners supplying web page script content dynamically, that weakness has become steadily less excusable. With SaaS supplying about 30% of enterprise applications these days, most in-house enterprise applications working through a browser window, and enormous amounts of customer-facing function supplied via web applications, the need is clear and indisputable, and growing.
Securing the Client Side Starts in Development
There are many layers to securing the client side. The first layer is in the development of a web application, and depends not just on mechanical issues like proper handling of material passed in from end users (e.g., not allowing users to send HTML tags when you are not expecting it, and limiting the ones they can use where you do expect it), but on design issues as well. The most important design-driven question is probably, does this application handle sensitive data? If so, the enterprise should have a policy of eliminating all non-essential code from the pages that handle that information: if it is not homegrown, or supplied by a partner critical to handling the sensitive information (e.g. a payment processor), it does not belong on the page. No ads, nor anything else extraneous to the operation in question, in order to minimize the opportunity for compromise.
Secure design principles and techniques have to be backed up with a security-centered development approach. SecDevOps is a good example, emphasizing security everywhere in the process and organization, and pushing for multiple types of automated security testing for all code in all advancement through the development pipeline.
Standards Can Help Client Secure Itself
Certainly, the slow pace of security standards development for the client side hasn’t helped, but it’s come a long way since 2000. Leveraging standards to the fullest would make a huge dent in overall enterprise vulnerability to attack and risk of protected customer data being exposed. But as slow as standards development has been, enterprise embrace of those standards has been even slower. Things like content security policies do an enormous amount to secure the client aide, but they are not easy to deploy. This is because CSPs are not just a “set and forget” kind of thing; they require careful construction and ongoing maintenance to serve their purpose. And, they are not a panacea — other changes in design and construction of web sites are crucial, as are the use of adjacent tools such as secure web gateways and web application firewalls.
Enterprises must take client side security more seriously, and must think holistically about dealing with it: everything from secure development philosophies like SecDevOps to embrace of security standards to deployment of an ecosystem of cooperating tools. Making the web safe for the enterprise is no longer optional.