一般的なJavascriptライブラリのXSSセキュリティ。それでも心配すべき？

ダニエル・グレック

最もポピュラーなJavascriptライブラリに関しては、開発の歴史（Angularは9年、Reactは6年、Vueは5年）の中で、セキュリティ、特にXSS攻撃に対する脆弱性に関して、良いことがたくさんあったことを認めなければなりません。しかし、この記事では、開発者がまだ注意すべき小さな罠と原則について議論します。

エックスエスエス

私たちは、言語ではなくフレームワークの時代に生きている。このことは、プログラマーがセキュリティを含む開発の多くの側面について心配する必要がなくなることを意味している。現在のバックエンド・フレームワークの大半は、セキュリティ・モジュールを実装しており、外部の専門企業や大規模な学会によってテストされている。したがって セキュリティ意識の低下 例えば、若いプログラマーは、特にフリーランスという点で、製品に対してより大きな責任を負っている。

アプリケーションのクライアント側に対する一般的な攻撃の一つに XSS（クロスサイト・スクリプティング）があります。これは、実行可能なクライアント側スクリプトをウェブ・アプリケーションに注入することで実行され [1]、実装された HTML レンダリング手法やジャバスクリプトコードを実行するエバリュエータです。XSS は、セッション・クッキーやユーザ・データを含む様々なデータが収集される可能性があるため、比較的有利であり、キーロガーのような追跡アプリケーションをインストールすることができるため、ユーザとビジネス・オーナーの両方にとって危険です。時には、ページ上でXSSを許すために、次のような他の攻撃形態が実行されることもあります。 SQLインジェクション.

例

ページのログインフォームが、GETリクエスト内で送信されたloginNameパラメータをログイン名入力にレンダリングします。この値は、サーバ側でもアプリケーションのクライアント側でも処理されません。リクエストによって http://localhost:8080/login?name=<script>alert(document.cookies)</script>
コードが実行され、データが公開される

これはその一例である。 反射型XSS攻撃特別に用意されたURLアドレスを通じてスクリプトが注入され、サーバーのレスポンスに反映される。その他のよく知られた攻撃は以下の通り：

保存されたXSS 注入されたデータは、通常はアプリケーションで利用可能なフォームによって、サーバーサイドに保存されます。クライアントアプリケーションは、例えばデータベースに格納されているコードをレンダリングします。
DOM XSS は、サーバー・サイドを使用せずにXSS攻撃を行います。記事の後半では、この攻撃形態に焦点を当てます。

ReactおよびVueライブラリにおける現在の脆弱性

現在のReact/Vueバージョンでは、2つの大きな問題が検出されましたが、まだ公式には修正されていません。最初の脆弱性は、どのフレームワークでも同じ性質を持っており、テンプレート内で生のHTMLレンダリングを可能にするメソッドに関連しています： ブイエイチティー そして dangerouslySetInnerHTML、 に対して、それぞれ Vue およびReactを参照してください。各ドキュメント[2]は、賢明でない使い方はユーザーをXSS攻撃にさらす可能性があることを読者に知らせている。問題を解決するための他の選択肢がない場合は、データが次のようなものであることを確認してください。濾過そして エスケープ.危険ではあるが、これらの方法が修正されることを期待すべきではない。自己責任で使用してください。

2018年第1四半期、Reactでタグ要素のプロパティを設定することでコードを直接実行できる大きなバグが検出された。のような属性内でコード例を渡すと、そのコードを実行することができます。 javascript:alert(1) レンダリングされたリンクを実行すると、コードが実行されます。この問題[4]はまだ未解決で、修正プログラムも準備されていません。公式ディスカッションで提案されている例は、この問題を克服するいくつかの方法を示唆しています。

最新バージョンへのアップデートが不可能な場合は、コードが公開されないようにすることで、古い問題が問題を引き起こさないようにしてください：

子供ノードインジェクション - React, 使用方法 React.createElement [5]
サーバー側レンダリング - React/Vue [6］
CSSインジェクション [8]

それはまだJavascriptについてである。フロントエンドについて

フレームワークやライブラリそのものだけでなく、言語としてのJavascriptにも危険な機能があることを忘れないでください。それらは一般的にDOM操作やスクリプトの実行に関連しています。 eval() はこの種のフラグシップ関数を表しており、与えられた文字列化されたコードを直接実行するため、非常に危険である [9]。また、これらの関数を見つけたら、自分のコードをよく見てください：

ドキュメント書き込み
document.writeln
(要素）.innerHTML
(要素）.outerHTML
(要素）.insertAdjacentHTML

ここで、適切なルールが設定されたリンターを使うことは、そのような脆弱な箇所を発見するのに役立つかもしれない。また、開発されたコードのセキュリティ・ギャップを検出するのに役立つオープンな、あるいは、商用のコード・アナライザもたくさんあります。

どのライブラリ／フレームワークを選んだとしても、フロントエンド開発に関する基本原則を忘れてはならない。まず、注入する外部コードが信頼できるソースから来たものであることを常に確認してください。監査依存関係を賢く選びましょう。依存関係の中には、深刻な脆弱性を含んでいるものがあり、コードそのものには問題がなくても、あなたのコードを危険にさらす可能性があります。依存関係のセキュリティについては、こちらをご覧ください：

https://thecodest.co/blog/security-in-javascript-packages/

では...まだ心配する必要があるのか？

そして、セキュリティに関して、外部ライブラリや自分自身を決して信用しないよう、皆さんに強くお勧めします。あなたのソフトウェアがどんなに安全であると期待しても、一般的な攻撃形態 [10] を可能な限りテストする努力を常にしてください。

続きを読む

PHPでプロジェクトを維持する際に避けるべき5つの間違い

PHPの開発symfony コンソールコンポーネント - ヒントとコツ

なぜsymfonyのPolyfillが必要なのか(...そしてなぜ必要ではないのか)

ソフトウェア開発

将来を見据えたウェブ・アプリケーションの構築：The Codestのエキスパート・チームによる洞察

The Codestが、最先端技術を駆使してスケーラブルでインタラクティブなウェブアプリケーションを作成し、あらゆるプラットフォームでシームレスなユーザー体験を提供することにどのように秀でているかをご覧ください。The Codestの専門知識がどのようにデジタルトランスフォーメーションとビジネス...

ザ・コデスト