web-dev-qa-db-ja.com

JavaScriptライブラリが安全かどうかを検証する方法は？

私はオープンソースのJavaScriptライブラリのメイン開発者です。そのライブラリは、私が働いている会社で、いくつかのクライアントのために使用されています。ときどき、聞いたことのないライブラリの実装に偏執的で、なぜこのコードを信頼すべきなのかと尋ねるクライアントがいます。

私は懸念を理解しており、通常はライブラリがホストされているgithubリポジトリをポイントし、同じライブラリを使用している他のプロジェクトとクライアントを示します。時々彼らはgithubでコードをレビューし、その後すべてがスムーズに実行されます。

しかし今回は、クライアントはもう少し偏執的です。彼は、ライブラリがどのようなセキュリティチェックを実施したかを尋ね、彼らのシステムは「上位10のOWASPチェック/スキャンで検証されている」と私に言った。

いくつかの調査の結果、私が見つけた最も近いものは OWASPによる2010年のWebアプリケーションのトップ10の脆弱性 をリストしたこのドキュメントです。

私はWebアプリケーションではなく、JavaScriptライブラリのみを提供しているため、これらすべてが当てはまるとは限りません。そして、私の理解では、これらの脆弱性はほとんどの場合、自動スキャンではなく、セキュリティ専門家が手動でチェックする必要があるということです。

今私の質問へ：

  • JavaScriptライブラリでセキュリティ標準を主張する方法はありますか？
  • JavaScriptをスキャンしてセキュリティの脅威を検出できるツールはありますか？

更新1

私はセキュリティの専門家ではありませんが、私はWeb開発者であり、Webアプリケーションに脆弱性を引き起こす可能性のある一般的な欠陥を理解しています。私が必要とするのは、このライブラリが少なくとも最小限の脅威と悪用についてチェックされ、実際に彼らのウェブサイトで使用するために安全であることを非技術者に特別に証明するいくつかの方法です。

私の頭に浮かぶのは、コードをレビューしてその品質を証明できるWebセキュリティに特化した中立的な会社またはコンサルタントかもしれません。これは一般的な方法ですか？

更新2

誰かが大きなJavaScriptファイルを渡して、統合の一部としてサイトに含めると想像してください。そのスクリプトはサイト内で実行されます。そのファイルがどこから来たのか、誰がそれを作成した開発者であったのかを確認したいと思うでしょう。 facebookの不正な開発者が、likeボタンスクリプト内に悪意のあるコードを挿入して、データが実行されているサイトからデータやcookieを盗むことを決定したとします。

よく知られている企業やオープンソースプロジェクトのライブラリを複数の人（jQueryなど）がレビューする場合、これは非常にまれなケースです。しかし、中小企業やソロ開発者からのスクリプトを含めると、それが問題であることがわかります。

私は何も含めていないので、自分のライブラリでエクスプロイトを探したくありません。どういうわけかコードが安全であることを証明したいので、ユーザーはコードを使用するときにこの種の心配はありません。

javascriptvulnerability-scanners
17
Eduardo Cereto

クライアント側のセキュリティ問題を回避するには、クライアント側のコードのセキュリティ要件と一般的な間違いについて学ぶ必要があります。 OWASPには優れたリソースがあります。 DOMベースのXSSについて必ず読んでください。これは、最も一般的なセキュリティの間違いの1つです。

セキュリティのベストプラクティスに関する限り、いくつかの提案があります。

  • XSSを回避するには、 Adam Barth on XSS-free web applications build building for XSS-free web applications にあるルールに従います。

  • setInnerHtml()および_.innerHtml =_は避けてください。代わりに、setInnerText()またはDOMベースの操作を使用します（スクリプトタグを導入しないように、つまりDOMベースのXSSを回避するため）。 document.write()は避けてください。

  • eval()は避けてください。その使用は、セキュリティ上の欠陥と相関する傾向があります。同様に、文字列をコードに変換して実行する他のAPI（文字列引数を指定したsetTimeout()、文字列引数を指定したsetInterval()、new Function()など）は避けてください。

  • JavaScript "strict mode" をオンにします。これは、以前にセキュリティの問題の原因となっていたJavaScriptの微妙な領域を回避するのに役立ちます。

  • コードが_script-src 'self'; object-src 'self'_などの厳密な コンテンツセキュリティポリシー （これは チュートリアル ）と互換性があることを確認してください。

関連トピックである clientside（Javascript） のセキュリティ上の懸念も参照してください。

JavaScriptをスキャンしてセキュリティの問題を探すための静的分析ツールを知りません。

JavaScriptの使用方法に関するDoug Crockfordの推奨事項（たとえば、彼の著書、Javascript：The Good Parts）に従っている場合、 JSLint を使用できます。それはかなり積極的な糸くずツールです。コードがJSLintクリーンである場合、それは肯定的なマークです。しかしJSLintは主にセキュリティに焦点を合わせていません。また、レガシーコードを使用してJSLintを実行すると、おそらく大量の警告が殺到します。

19
D.W.

標準的な方法はクライアントがセキュリティテストに従事することですが、クライアントに何らかの保証を提供するためにセキュリティテスターを雇う開発者が増えているようです。

しかし、「このコードは安全であることが保証されている」と言う方法はありません-「このコードは適切に安全であるように見える」または「目的に適合している」しかありません

5
Rory Alsop

1つのオプションは、JavaScriptのサンドボックス化または書き換えです。その方向にいくつかのことを示します。

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

Google JSandクライアントサイドでのJavaScriptのサンドボックス化

Maffeisによる信頼できないjavascriptのGoogle言語ベースの分離

1
Nick P

ほとんどの商用コードスキャナー（IBM、HP Fortify、Checkmarx、Veracodeなど）はJavaScriptをスキャンします。個人的にはCheckmarxを使用しただけで問題なく動作しますが、比較はしていません。

1
Doran

私はあなたが望むことは根本的に不可能だと思います-プログラムが悪意のある（不特定の）ことをするかしないかを言うことは停止の問題と同等です。特に、javascriptは相互作用するソフトウェアの複雑なエコシステムの一部であることを考慮してください。エクスプロイトは、steal_cookies_and_send_to_bad_guysと呼ばれる関数を書くほど単純ではありません。

したがって、不可能であるため、あなたができる最善のことは、マルウェアの「既知の種」を発見できるはずの誰かがコードを検査し、おそらくそれ以外の場合はそれが上にあり、よく書かれているという意見を形成することです。

1
ddyer