• Skip to main content
  • Skip to primary sidebar
  • Skip to footer

DevelopSec

  • Home
  • Podcast
  • Blog
  • Resources
  • About
  • Schedule a Call

January 4, 2016 by James Jardine Leave a Comment

Unsupported Browser Support

Ok, so the title is a bit counter-intuitive. I recently saw an article talking about the end of support for some of the Internet Explorer versions out there (http://www.computerworld.com/article/3018786/web-browsers/last-chance-to-upgrade-ie-or-switch-browsers-as-microsofts-mandate-looms.html) and got to thinking about the number of sites that still require supporting some of these older versions of browsers. This is typically more common in the big corporate enterprises, as they have the legacy systems and tend to move slower upgrading internal software.

The unfortunate reality is that, in some environments, you are stuck supporting outdated browsers. Whether it is an internal application with requirements for the network, or your client base is just slow to move on. This requirement also puts those users, and potentially the company network at risk since there are no more security updates for these browsers.

Over the past few years, browsers have been taking on some of the burden of stopping some forms of application security attack vectors. We saw the addition of the cross-site scripting filters added a while back to help detect and neutralize some reflective cross-site scripting attacks. We also saw browsers start to support custom response headers to indicate content security policy, frame handling, etc.. Some of these protections are supported across all browsers, while others are limited to specific browsers, or versions of browsers. As we see these unsupported browsers still out there, it reminds us that as developers, we cannot rely just on browser functionality for security.

While we may not be able to control what version of a browser we support, well we can but we can’t, we can still make sure that our application is as secure as possible. Lets take cross-site scripting as an example. Sure, for reflected XSS, we could just sent the X-XSS-Protection response header and hope for the best. It might neutralize a few instances, but that is a pretty poor defense mechanism. First, there have been numerous bypasses for these types of client-side blocking attempts. Second, it is our responsibility, as developers, to properly handle our data. That starts with good input validation and ends with properly encoding that data before we send it to the browser.

I am not advocating not using the different response headers. Bugs can be missed and having another control there to help reduce the chance of a vulnerability being exploited is a good thing. But the first effort should be spent on making sure the output is encoded properly in the first place. This is where testing comes into play as well, making sure that we are validating that the encoding is working as expected.

By properly protecting our apps with good application security practices, it shouldn’t matter what browser the client is using. Does the end user run a higher risk, in general, by running out of date software. You bet. That doesn’t mean our application has to be the source of that added risk.

If you are stuck supporting out dated browsers due to corporate compliance or other reasons, take the time to analyze the situation. Determine why that browser is needed and what possible solutions are there. Raise the issue up within the organization, identifying the risks that are exposed due to the use of outdated browsers. While the organization may already know this, it doesn’t hurt to say it again.

Filed Under: News Tagged With: application security, developer, developer awareness, developer security, qa, secure coding, security, testing

Reader Interactions

Leave a Reply

You must be logged in to post a comment.

Primary Sidebar

Contact Us:

Contact us today to see how we can help.
Contact Us

Footer

Company Profile

Are you tackling the challenge to integrate security into the development process? Application security can be a complex task and often … Read More... about Home

Resources

Podcasts
DevelopSec
Down the Security Rabbithole (#DTSR)

Blogs
DevelopSec
Jardine Software

Engage With Us

  • Email
  • GitHub
  • Twitter
  • YouTube

Contact Us

DevelopSec
Email: james@developsec.com



Privacy Policy

© Copyright 2018 Developsec · All Rights Reserved