Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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 should he 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.

Now to my questions:

  • Is there any way I can assert security standards in a JavaScript library?
  • Is there any tool that can scan JavaScript for security threats?

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 specially 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 specialized in web security that can review the code and attest it's 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 and. 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.

share|improve this question
    
possible duplicate of Security Concerns on clientside(Javascript) –  Rook Oct 26 '12 at 1:32
1  
@Rook That was unnecessarily rude. –  Terry Chia Oct 26 '12 at 2:30
    
Maybe I was not very clear about my question. I know about security risks on the web and javascript code. What I need is some way to prove/attest that the code is secure. Maybe a scanner that looks for security threats or a third party review of the code. –  Eduardo Cereto Oct 26 '12 at 2:48
    
dominator for firefox and domsnitch for chrome. They can be used for dom based xss and loading js from an invalid location. No tool is going to uncover CWE-602 violations. If you think client-side JS is biggest security threat then you probably implemented a CWE-602 violation. –  Rook Oct 26 '12 at 4:56
    
@Rook, I don't know what you mean, I never said that. It is just a JS library, not related to a specific application or website. CWE-602 doesn't even apply. –  Eduardo Cereto Oct 26 '12 at 5:58

5 Answers 5

up vote 4 down vote accepted

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'

share|improve this answer
    
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 8: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 8:49

Most of the commercial code scanners (IBM, HP Fortify, Checkmarx, Veracode, etc) scan JavaScript. I personally have only used Checkmarx and it works well, but I haven't made any comparison.

share|improve this answer

One option is sandboxing or rewriting the javascript. Here's a few things in that direction.

http://www.slideshare.net/phungphu/a-twotier-sandbox-architecture-for-untrusted-javascript

Google JSand Client-side sandboxing of javascript

Google Language-based isolation of untrusted javascript by maffeis

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
    
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 2: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 6:07

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.