OWASP Top 10：2013年度版と2017年度版の変更点について

数年に一度、OWASPはウェブアプリケーションの10のリスクに関するドキュメントを改定しています。現代のアプリケーションにまつわる主な問題について触れており、ウェブ開発やセキュリティコミュニティからの情報を元にリストが作成されます。10万以上のウェブアプリからデータを収集し、脅威からアプリを保護する方法について記載されています。

2017年度にOWASPから発表された10の脆弱性の改定点がこちらです。 OWASP Top Ten Project ページ から、2013年度と2017年度をご覧いただけます。参考ページや早見表へのリンクページも記載されています。

新たに発表されたリスク

2017年度版では、新たなリスクが3点追加されました。XXE、オブジェクトインジェクション、不十分なロギングとモニタリングについてです。

A4: XML 外部エンティティ参照 (XXE)

サーバーからのデータ抽出のために構成されたXMLパーサの弱点を利用したサーバ攻撃です。外部実体参照を利用した攻撃が特徴で、XMLに関するデータを元に特定されたドキュメントが標的となります。XMLパーサが情報にアクセスし、目当ての該当データであればDoS攻撃を受ける可能性が高くなります。

XXE攻撃の実態

アタッカーは、機密ファイルの保存場所などの情報を含んだXMLドキュメントを作成します。POSTデータとしてサーバーにドキュメントが送信され、XMLパーサがエンティティを含んだデータとすり替えます。XMLドキュメントを含んでいる場合には、アタッカーによりエンティティのデータにアクセスされます。

XXE攻撃からアプリケーションを守るには

JSONやYAMLなどのデータフォーマットは、XXE攻撃に対して脆弱性があります。XMLが必要となる場合は、XMLパーサから外部実体をオフ にしてください。また、パーサーへ送信する前に今一度攻撃を受けていないかチェックしましょう。詳細は、XXE攻撃からの保護方法をご覧ください。

A8: 安全でないデシリアアライゼーション

デシリアライゼーションは、データの保管や変換に適したフォーマットの変換を行うプロセスのことです。例えば、ウェブアプリケーションがセッショントラッキングを行い、ユーザーセッションに関するデータをサーバーのHDと連携させます。反対に、デシリアライゼーションとは、変換されたデータを元の形式に戻すプロセスのことです。 攻撃に対し脆弱性のあるデシリアライゼーションを使用すれば、アタッカーがシリアライズされたデータをサーバーに送信し、任意コードを実行しデシリアライゼーションのプロセスに利用し、DoS攻撃を行います。

デシリアライゼーションの実態

特殊なIDを利用しユーザーセッションのトラッキングを行うWebアプリがあるとします。ユーザーがウェブサイトにアクセスした際、IDがサーバーにデシリアライズ・自動的に有効なユーザーとして無断でログインされ、アタッカーがそのIDを任意のあるコードとすり替えます。ウェブサイトを開いた際に、サーバーがユーザーのデータをデシリアライズし任意のあるコードを実行してしまうことで攻撃が起こります。

デシリアライゼーションからアプリケーションを保護するには

JSONやXMLのような脅威となるコードを含んでいないデータ形式を使用し、シリアライズを避けることが一番の安全策です。もしシリアライズが必要な場合は、その前に厳格なデータチェックを行いましょう。より小さい権限のユーザーアカウントを利用するか、アプリケーションのコードを分割しデシリアライゼーションプロセスの分離を行いましょう。詳細情報は、こちらから

A10: 不十分なロギングとモニタリング

セキュリティツールでは、ログとモニターが十分に重要視されているケースが多くあります。これらの動作の中でトラブルが起きた場合でも問題解決にはならない一方で、疑いのあるアクティビティ、パフォーマンス傾向を理解する上では手掛かりとなります。効率的なモニタリングでは、ログとモニターで攻撃が実行されている間でもすぐに通知されます。ロギングに脆弱性があれば、アタッカーは簡単に攻撃の検出を避けてしまいます。

　不正なロギングとモニタリングの実態

アタッカーは自動プログラムを使用し、ウェブアプリのログインページを表示させようとします。サーバーのページにアクセスを行おうとするほど、アタッカーのサーバーデータへの侵入率が100％まで増加していきます。サーバー自体はモニターされておらず、攻撃は検出される事はありません。ログイン失敗は記録に残らないため、何百万回ものログイン失敗が見逃されています。

不正ロギングとモニタリングの対策

現在、ほぼ全てのプログラミング言語にロギング・フレームワークが含まれています。少なくとも、ユーザー認証やコントロールエラーにアクセスするなど、特殊な識別子でセキュリティ関連のイベントにログを行うことで対策を行いましょう。そのデータを収集し、疑いのあるアクティビティを監視、ある動作パターンを検出時にアラートを通知できるように統合ログ管理システムを使用してください。詳細は、こちらからご覧ください。

Templarbitは、ウェブアプリケーションのアクティビティの監視を行い、不正ロギングを防ぎます。 [無料トライアルはこちらから]((https://www.templarbit.com/signup)

OWASPの削除点

今年度のOWASPでは、2点が削除となりました。クロスサイトリクエストフォージェリ（CSRFs)・未検証のリダイレクトとフォワードです。

A8: クロスサイトリクエストフォージェリ(CSRFs)

多くのブラウザは、ログインデータをキャッシュし自動的に以前アクセスしたことのあるウェブサイトを表示します。しかし、これは言い換えれば第三者がキャッシュされたクレデンシャル情報へのアクセスが可能であるということなのです。CSRFsは、このようにセキュリティに関して知識の少ないユーザーを利用し、ウェブサイト上でサーバー攻撃を行います。

OWASPからCSRFsが削除された理由

CSRFsが妥当である一方で、この攻撃からアプリケーションを保護しやすくなってきています。ウェブアプリケーションでは、内蔵のCSRF保護を含んでいることが多くなっており、またHTTPヘッダーを比較 することによりリクエストの元データを特定可能になってきました。 ブラウザは、ユーザーがあるウェブサイトから別のウェブサイトにアクセスを行った際のクッキーの読み込みをブロックし、SameSite属性でCSRF保護を行います。

A10: 未検証のリダイレクトとフォワード

多くのウェブアプリケーションは、ユーザーがある操作をした際にリダイレクトとフォワードを行い、別のエリアにアクセスします。例えば、ログインページからプロフィールページにリダイレクトされるとします。リダイレクトされたページからのアクセス先のURLなどに不審な要素があった場合には、アタッカーがユーザーに知られることなく、元のアクセスページから危険性のあるサイトにユーザーを誘導できるケースがあります。

未検証のリダイレクトとフォワードがOWASPから削除された理由

今年度版から削除された大きな理由は、URLリダイレクトを行った場合にのみユーザーインプットが行われ、このサーバー攻撃が行われるからです。この攻撃からアプリケーションを保護するには、ユーザーのパラメータを削除し、アプリケーションロジックのURL目的地を指定します。または、ユーザーのインプットの安全性・許可されたURLのホワイトリストをチェックしてください。別のリンク先にアクセスする際にユーザーへ注意を促すページを追加するのも良いでしょう。詳細は、未検証のリダイレクトとフォワードについてをご覧ください。

OWASPのさらなる変更点

2013年度のOWASPレポートに記載されていた2点（安全でないオブジェクト直接参照と機能レベルアクセス制御の欠落）が、今年度版では1つに統合されました。2017年度版では、アクセス制御の不備として記載されています。また、クロスサイトスクリプティング(XXS攻撃)に関して、より詳細な情報が追加されています。

A5:アクセス整備の不備

アクセス制御の不備は、2013年度版に記載されていた安全でないオブジェクト直接参照・機能レベルアクセス制御の欠落の2つのリスクが統合されたものです。アクセス制御の不備は、ユーザーが外部のリソースにアクセスする際に許可・拒否する機能に脆弱性が見られるケースのことです。例えば、オンライン上のフォーラムで匿名のユーザーがページURLを知っている場合でも、メンバー限定のページへのアクセスがブロックされます。アクセスが不正に操作された場合は、ユーザーがURLを入力するだけでページを表示されてしまいます。

これら二つが統合された理由

2013年度のレポートでは、アタッカーのアクセスを制限するべきウェブアプリケーションのアクセス権限をコントロールする動作が両方に含まれていました。脆弱性のあるオブジェクトがあれば、アタッカーがパラメータ値を変更することでページにアクセスが可能になります。またアクセス制御に弱点があれば、ユーザーの権限を乗っ取ることもできます。これらの脆弱性の特徴が類似しているため、2017年度のレポートでは一つに統合されました。

A7: クロスサイトスクリプティング（XSS）

XSS攻撃は、OWASP Top 10によれば二番目に多く普及している攻撃で、全体の3分の2のウェブアプリケーションが被害を受けています。 XSS攻撃では、脆弱性のあるベクターを利用し、脅威のあるスクリプトが送信されます。ユーザーがそれに気づかず、スクリプトをダウンロードしてしまうのです。ハッカーは、ユーザーのブラウザにアクセスし個人データの盗難や攻撃を行うことができます。

XSSは、攻撃を発生させやすく保護が難しいことから、最も広がっている脆弱性を利用した攻撃の一つです。攻撃を検出・保護するツールがなければ、ユーザーインプットを使用している殆どのウェブアプリケーションがXSS攻撃に晒される危険性があります。攻撃の危険性があるHTMLやJavaScriptのタグなど、ユーザーインプットを全てセキュリティチェックに回すことで対策をとりましょう。ベクター攻撃の危険性のある要因は無数にあり、最も普及しているサーバー攻撃です。

変更された理由

2017年度のレポートでは、XSS攻撃は三つのカテゴリーに分類されています。

• __Reflected XSS_：ユーザーがセキュリティチェックが行われていないHTMLやJavaScriptにアクセスしブラウザで表示した場合、埋め込まれたスクリプトに攻撃コードが含まれており、ウェブ上で作動し起こる攻撃を指します。
• Stored XSS：反射型XSSと同様に、ウェブ上で動作するもので、持続的であることが特徴です。
• DOM XSS：HTMLのサーバー動作ではなく、DOM内で攻撃が発生するのが特徴で、 危険性のあるアクティビティとして検出が困難な攻撃です。

2017年度のレポートでは、これらの攻撃に対する対策が挙げられており、具体的にXSS対策が内蔵されているフレームワークを使用することと、ユーザーインプット要素をエンコードすることが記載されています。詳細は、XSS攻撃に対する保護方法をご覧ください。

Templarbitは、コンテンツセキュリティポリシー（ CSP）です。 RubyやPython、Node.jsやGolangのライブラリで、ウェブアプリケーションとの統合は数分で完了し、これらの攻撃からの保護が万全に整います。フリートライアルはこちらから