Paid Advertising
web application security lab

The JavaScript Paradox

Last week I presented a talk at OWASP on how security and user interface often co-mingle. Amongst other issues, I talked about the fact that many sites require the use of JavaScript for key functionality (such as login). After the talk a woman came up to me and told me that her bank requires the use of JavaScript to login, and asked me if I thought if it would be a good idea for her to call her bank and ask them to remove that as a requirement. What an interesting question. It actually took me by surprise, and I was even more surprised with what I heard my mouth saying in response.

Without thinking I said that it wouldn’t make any difference if she did or didn’t. There are two types of people that this problem breaks the user public down into. People who surf with JavaScript turned on by default - and that represents about 99.99% of users (based on the last Omniture report I saw, which may or may not be accurate), and the users who inherently surf without it as a security precaution, which represents a hair of a fraction compared to the larger group. Now, let’s for a second assume that the bank did as she asked and removed the restriction on JavaScript for authentication. We have to assume the JavaScript was there for a reason. The JavaScript probably has some security functionality as it’s a bank. Maybe typing speed biometrics, for instance - who knows? So by disabling it, they actually remove one security function which may have some limited value. But what about the other users?

The way people most often disable JavaScript, that I’ve seen is through the use of Noscript. Noscript enables whitelisting by domain, so by turning it off per domain, you have effectively only opened yourself to those domains, which should be safe theoretically, given that you have agreed to open yourself up to them. So it would seem that the people who surf without JavaScript will continue to surf without JavaScript despite the fact that companies force them to at least temporarily enable it. In this case, the JavaScript has provided more good than bad, and forcing the bank to remove it has negatively impacted 99.99% of users by removing security functionality, rather than positively impacting them to mitigate the chance that they may stumble across something malicious elsewhere.

The reason we turn off JavaScript is to protect ourselves from XSS, session riding, history theft, and a barrage of other bad things. With the exception of credential theft and a few other things, attackers can do many of the same things with just straight HTML and CSS that they can do with JavaScript, so even that hasn’t helped much. Clearly turning off JavaScript does provide value from a security perspective - I don’t think many people would disagree there. But let’s say for a moment that we could rid the Internet of JavaScript dependencies, would that even solve the problem? People would still have it turned on by default.

Even if it wasn’t a dependency and people did all their validation server side, people still find it to be a convenience. So I doubt that 99.99% JavaScript user base would drop much. So herein lies the paradox - while turning off JavaScript is a security precaution, it doesn’t matter if everyone removes their dependencies on it from a security perspective. Additionally, disabling it may actually make the sites who depend on it less secure. The reason is that users will continue to demand the rich features of things like dynamic maps, real time updates, etc… They don’t turn it off, not because they are forced to keep it on, but because they want to keep it turned on. There might be a very small handful of people who don’t fall into that bucket who would turn it off if they could but refuse to use tools like Noscript, but that’s most likely a very small group of people that are the exception that proves the rule.

Of course, I have no idea how blind people using the Lynx browser use that bank, given that Lynx doesn’t render JavaScript - maybe they have to go and visit the bank in person, but I’m pretty sure that’s grounds for an ADA accessibility lawsuit. And even if Lynx did render JavaScript, how is a blind person going to “look for the lock” or the other visual cues that we tell our users to be wary of. But putting that aside, even though my mouth was talking ahead of my brain as I answered that question and even though I wasn’t sure I was right, after a week of reflection considering human nature and the statistics of the problem, I think I have finally come to terms with my own answer.

16 Responses to “The JavaScript Paradox”

  1. Giorgio Maone Says:

    Thanks, a truly enjoyable reading.

    A similar tune in a different key:

    Personally, while I trust my anti-XSS filters, I would still appreciate if my bank did not forced me to enable its broken, IE-only and utterly useless JavaScript :)

  2. Dimitry Says:

    My local bank decided to go the AJAX route, and it became impossible to navidate without javascript. Although I understand the convenience feature, I think Web 2.0 is not for banks ( yet? ), at least not for login and other sensitive mechanisms. Personally, I’d much rather be bothered with Java applets at this point then extensive OSK and other
    validation they do.

  3. Mephisto Says:

    That’s an unusual perspective for you RSnake, that javascript can actually enhance security. The truth is, like you said, even if js is turned of, it still doesn’t make a user’s surfing safe as basic html can still perform a lot of the malicious activity.

  4. RSnake Says:

    I know, bizarre huh? I wouldn’t have thought I would have ever believed it until I heard my mouth saying it. Alas, there are security functions built into JavaScript, like machine identifiers, biometrics etc… that companies use to detect if someone is the right person or not. Not that I think that software is good but even if it is an incremental increase in security, it’s better than nothing - which is what people have most of the time when they are surfing around with JS turned on.

  5. Kyran Says:

    I guess RSnake has finally reached Acceptance stage in the 5 stages of Web App Security grief. ;)

  6. Spikeman Says:

    Actually, in the case where Javascript helps secure the site, I’d say leave it required. That way us paranoid people with NoScript can look through the source and see that it’s not malicious and temporarily enable it.

    Of course, you’d have to ask the question when is using Javascript actually benefiting security? If you know anything about it, you know that Javascript can be easily changed (through FireBug, or other ways). I wouldn’t call that secure.

  7. RSnake Says:

    Right, hence why I said “Not that I think that software is good” but it may provide some incremental value from the newbs who don’t know how to circumvent it.

  8. ntp Says:

    i run firefox with multiple instances and each instance has localrodeo, cookiesafe, safehistory/safecache, web developer, and noscript installed. some profiles have other things installed as well.

    none of the instances allow anything by default using cookiesafe or noscript. when i go to a website that requires cookies or javascript, i open a new instance and then enable the specific features necessary (if i trust the site in the first place). but that’s all i do in that browser instance. then i go to instance two/three/four and do my other work over there. the only exception is in my browser instance with bookmarklet, which usually (after start and logging in) has allowed to run javascript, but that will require another site (which I turn on, and then turn off) when i go to bookmark something with it. i’ve become used to working in this manner, plus i’ve had some interesting findings doing this after restoring sessions.

    i’ve said it before that is my one weak spot, yet i continue to use it. i used to be even more thorough about looking at javascript with the web developer plugin (information -> view javascript) before even enabling a site for noscript (mostly to learn rather than to find things like xss or javascript malware). i guess i could start doing that with before i bookmark something. firekeeper might be an additional nice thing to have there as well.

    anybody else as paranoid as i am? i can use the web freely in this way without significant worry about attacks that rsnake and jeremiah dream up - but there are other worries… for example intrinsic browser issues such as the ones that zalewski finds on a near-regular basis and hdmoore got bored of last year. these sorts of problems make me want to switch to links or elinks (no, rsnake, not lynx which has serious bugs just as bad as the others).

    i like to use links and curl because they are relatively safe compared to lynx and wget. did you know that elinks (one of the evolutions of links) has support for javascript? i guess that might help those blind people login to their bank, for all you blind people out there reading this blog right now. it doesn’t support ajax, though, and i’m not sure if there are plans to - which additionally breaks other sites. also note: flash support and java support are also required in many many cases. even activex is required for more sites than we wish… and maybe vbscript as well, and who knows what else? my point is that it’s not just javascript and if javascript went away - one of these other in-browser scripting or plugins (adobe acrobat anyone?) will be found to be insecure with regards to xyz feature in possibly a similar or exact way as xss.

  9. RSnake Says:

    Hahah… okay, time to download elinks. ;) And yes, there are many people who are just as paranoid as you. Unfortunately not nearly enough, which doesn’t move the needle much on that 99.99%

  10. Ronald van den Heetkamp Says:

    BTW: The most used screenreader is JAWS and it support Javascript for 100% cause people who have it, have a normal browser, the screenreader only interpet things. I tested it last year, preety cool stuff. I always tought it woud not support scripts and such, but it does, probably the biggest usability myth on this planet I can think of :)

  11. Kartones Says:

    My bank requires javascript too, but for a simple reason: To type the PIN access number, it uses a random digit-to-letter virtual keyboard to avoid keyloggers (of course you can click the buttons with a mouse too).
    It works fine under IE6-7 & Firefox and I prefer it to be present, it’s surely safer than typing the code as is.

  12. SilentBob Says:

    Ahh…the question of why banks use JavaScript for login purposes….
    On 10/12/2005 FFIEC issued guidance to (US) banks that some form of multi-factor authentication be deployed for internet banking by 12/31/2006. While a year seems like a lot of time, it really isn’t all that much to figure out the appropriate technology, get cost estimates, a deployment schedule, etc.
    Consequently, most banks chose the easiest (and least secure) type of multi-factor authentication which is simple challenge/response questions when a user is coming from an unregistered computer.
    There are a number of large security vendors who sell these types of systems to banks. And they are all based on the same basic technology. And all of these systems utilize javascript to provide the authentication server with additional details about a clients computer. The authentication server aggregates this data, with other collected data (factors like computer name, IP address, browser user agent, time zone settings, persistent cookie, etc.) and then makes additional calculations about when the user last logged in, how far away they were geographically, whether the IP address is a blacklisted IP, etc. I’ve even seen auto-generated javascript that pushes computations that the server expects to receive back as form inputs to complicate automation attacks. And it then decides whether or not to prompt the user with additional challenge questions.

    Without JavaScript to collect additional details about a machine, the user would be unable to register a computer and would have to provide their response questions every time they logged in.

    This would not only be a hassle for the user, but it would also cause an additional security risk since users would constantly be submitting their challenge/response questions they would be more likely phishing candidates as well as from password stealing trojans, etc.

    So it is likely that in this case, JavaScript is indeed benefiting the security of the bank’s website.

  13. ntp Says:

    The problem is not Javascript. XSS is not a Javascript “use” problem in the same way that buffer overflows are not a C/C++ “use” problem. You don’t stop using a very popular language just because it didn’t originally take into account a vulnerability class.

    XSS and buffer overflows may be significant weaknesses to the Javascript and C languages, but both languages and the applications surrounding them can be written in such a way that prevents these weaknesses from being exploited.

    C evolved into Java and C#. Javascript will also evolve, in fact the ECMAScript specification 4 is still in progress. C programs can also be compiled with CCured or Cyclone with little modification (if any), and mygcc ( may even find its way into the existing gcc codebase.

    I think it’s safe to say that mistakes can be made with any language, but it’s up to the developer and the tools he/she is armed with. He/she allows the application to make the grade, security-wise, or not. Of course, environmental (i.e. configuration file) factors can change this, and this is up to the operators to verify security in practice.

    The FFIEC regulations did not require Javascript, and I’m not sure that it did make things easier for banks just to blindly enable it and require it across their website. Most of the things that SilentBob mentions do not require Javascript at all. IP blacklisting can just as easily be accomplished with any network device that has middlebox control into the IP header.

    However, I have to agree with him that Javascript can benefit the security of any website. C can benefit the security of any website. It’s not the infrastructure that comes into question when building a web application, especially not one as complex as a bank. The process, the people, training them, educating users, passing the experience up to management so that they can make informed decisions - and integrating all of this with your community, within your organization and everyone you work with - THAT is the hard part. Technology doesn’t build itself yet; and it doesn’t break itself yet either.

  14. Manly Tears Says:

    I think people with vision impairments usually use JAWS, and it has JavaScript.

  15. lslinnet Says:

    Instead of worrying about if the website you are visiting is containing malware XSS etc. then install a virtual machine to do your banking, another machine to do your casual surfing and perhaps a third to do you work related surfing, saves alot of stress.
    And if one of the virtual machines starts to slow down you can just reset it to it’s default state. this is not the solution for the common user i know, and it might require some learning and geeking around but the solution works really well when it’s up and running!

  16. RSnake Says:

    Islinnet - I think you may be missing the point. This isn’t about us security people protecting ourselves. This is about the Internet as a whole. In that case virtual machines are useless unless they work for everyone. I agree, they are a great idea for guys like you and me, but they aren’t super practical for the layman in the implementation you just described - at least not yet.