20

I'm the main developer for an Open Source JavaScript library. That library is used in the company I work for, for several clients. Every now and then there is a client that feels paranoid about implementing a library he has never heard about and ask me why he should trust this code.

I understand the concern and usually I point them to a github repository where the library is hosted and show other projects and clients that are using the same library. Sometimes they review the code on github, and everything runs smoothly after that.

But this time the client is a little bit more paranoid. He asked me what kind of security check the library has gone through and told me that their systems are "validated with the top 10 OWASP checks/scans".

After some research the closest thing I found is this document that list top 10 vulnerabilities in web applications in 2010, by OWASP.

I think not all of these apply, since I'm not providing a web application but just a javascript library. And my understanding is that these vulnerabilities most of the time need to be checked manually by a security specialist rather than an automated scan.

  • Is there any way I can assert security standards in a JavaScript library?

UPDATE 1

Even though I'm not a security expert I'm a web developer and I understand the common flaws that can cause vulnerabilities on Web Applications. What I need is some way to prove especially for a non-technical person that this library has been checked at least for minimal threats and exploits and is in fact secure to be used on their website.

What comes to my mind is maybe a neutral company or consultant specializing in web security that can review the code and attest to its quality. Is this a common practice?

UPDATE 2

Imagine someone hands you a large javascript file to include in your site as part of an integration. That script will be running inside your site. You probably want to make sure where that file comes from and who was the developer that created it. Imagine some rogue developer at Facebook decided to inject some malicious code inside the like button script to steal data or cookies from sites where it's run at.

When you include libraries from well-known companies or Open Source projects that are reviewed by multiple people (like jQuery) this is a very unlikely case. But when you include a script from a small company or a solo developer I can see that as being a concern.

I don't want to look for exploits in my library as I know I have included none. I just want to prove somehow that the code is safe, so users don't have this kind of concern when using it.

schroeder
  • 123,438
  • 55
  • 284
  • 319
Eduardo Cereto
  • 335
  • 1
  • 2
  • 7

3 Answers3

22

To avoid client-side security issues, you need to learn about the security requirements for client-side code and the common mistakes. OWASP has good resources. Make sure you read about DOM-based XSS, as that is one of the most common security mistakes.

As far as security best practices, I have several suggestions:

  • To avoid XSS, abide by the rules found in Adam Barth on Three simple rules for building XSS-free web applications.

  • Avoid setInnerHtml() and .innerHtml =. Instead, use setInnerText() or DOM-based operations (to make sure you don't introduce script tags, i.e., to avoid DOM-based XSS). Avoid document.write().

  • Avoid eval(). Its use tends to be correlated to security flaws. Similarly, avoid other APIs that turn a string into code and execute it, like setTimeout() with a string argument, setInterval() with a string argument, or new Function().

  • Turn on Javascript "strict mode". It helps avoid some subtle areas of Javascript that have been responsible for security problems before.

  • Make sure your code is compatible with a strict Content Security Policy (here's a tutorial), such as script-src 'self'; object-src 'self'.

See also Security Concerns on clientside(Javascript), which is on a related topic.

I don't know of any static analysis tools to scan Javascript and look for security problems.

If you follow Doug Crockford's recommendations about how to use Javascript (e.g., as per his book, Javascript: The Good Parts), you could use JSLint. It's a pretty aggressive lint tool. If your code is JSLint-clean, that's a positive mark. But JSLint is not focused primarily on security. And, if you take legacy code and run JSLint on it, you're probably going to get inundated with a pile of warnings.

Community
  • 1
D.W.
  • 98,420
  • 30
  • 267
  • 572
  • This is a terrific answer. Thank you very much. I use jshint every time I commit code and it is "strict mode" compatible. I own a copy of Crockford's and I have all the points you noted covered. I believe my code is secure but it's hard to prove to clients. How can I prove to my client that the code is secure specially if it's a non-technical person. The only thing that comes to my mind is possibly a code review for security risk from a neutral third party. Is this a common practice? – Eduardo Cereto Oct 26 '12 at 02:45
  • 1
    @EduardoCereto, sadly, I don't know of any standard, common practices that demonstrate your code is secure. You may need to talk to your client to determine what will be acceptable for them. Yes, hiring someone to conduct a security review for you is a possible direction, but it'll be expensive. Probably more normal practice would be to allow the client/customer to perform a security review or hire their own expert, at their own expertise. But this probably comes down to: talk to the client, and assess whether it's economically desirable to meet their requirements. – D.W. Oct 26 '12 at 06:07
7

Standard practice is for your client to engage a security test, but I am seeing more developers hiring security testers to provide some assurance to the client.

But there is no way to say 'this code is guaranteed secure' - there is only 'this code seems appropriately secure' or 'fit for purpose'

Rory Alsop
  • 61,367
  • 12
  • 115
  • 320
  • Thanks Rory, that's exactly what I had in mind as well. Just wanted to double check if there was any common practice to attack this problem. I guess it's more an educational than a technical issue. – Eduardo Cereto Oct 26 '12 at 08:22
  • You can use secure coding techniques, validated by code review, but you are right education is key. @D.W.'s answer is on the money here. – Rory Alsop Oct 26 '12 at 08:49
2

I think what you want is fundamentally impossible - saying that a program does or doesn't do some (unspecified) thing malicious is equivalent to the halting problem. Especially consider that javascript is part of a complex ecosystem of interacting software. Exploits are not necessarily as simple as writing a function called steal_cookies_and_send_to_bad_guys.

So since it's impossible, the best you can do is have the code inspected by someone who ought to be able to spot some "known species" of malware, and perhaps form an opinion that it is otherwise above board and well written.

ddyer
  • 1,974
  • 1
  • 12
  • 20