i have no idea

I have no idea

bibouroku

やる気の出ない情報セキュリティ10 「Webセキュリティ」

Webセキュリティ

Webの基本的な構成要素

WebページはHTMLという言語によって、文書の論理構造を記述します。

Webにおけるデータ転送には、HTTPという通信プロトコルが用いられています。

Webクライアントは、HTTPを使ってWebサーバーからHTMLファイルや画像ファイルなどをダウンロードし、Webページのレイアウトを解析して、表示・再生します。(IE,Firefox,Google Chrome等)

Webサーバは、Webブラウザからのリクエストに応じて、HTML等で記載されたデータをWebページとして返信します。(Apache, IIS等)

Webアプリケーションサーバは、Webサーバに付随し連携するもので、Webクライアントからのリクエストを受け付け、「動的にWebページを作成するシステム」のことを指します。

f:id:yabicon:20210516012709p:plain
Webの基本的な構成要素

Webブラウザで静的なページを参照する際は、Webサーバ上にあるHTMLファイルがHTTP通信によりダウンロードされますが、動的なWebページを参照する際は、Webサーバを経由してWebアプリケーションサーバにより動的に生成されるWebページがHTTP通信によりダウンロードされます。
Webブラウザは、HTTPを利用して、Webサーバにユーザネームなどのデータをアップロードすることも可能です。

WebブラウザからWebアプリケーションサーバへデータを送信する際は、GETメソッドやPOSTメソッドを使います。
GETでは、URIの一部として送信するデータを末尾に追加する(クエリ文字列)という手法もあります。
( http://XXXXXXX/search.php?usename=taro みたいなかんじで)
セキュリティの観点からクエリ文字列を使うのはあまりよろしくないみたいです。


Webアプリケーションサーバは、Webブラウザユーザインタフェースや画面デザインを提供するソフトウェア(フロントエンド)と、DBMS(Data Base Management System)等のソフトウェア(バックエンド)、その中間に配置されてロジックと呼ばれるふるまいを記述したソフトウェアから構成されます。(3階層システム)

Webアプリケーションサーバーには、サーバー上で実装するCGI(Common Gateway Interface)、PHPJava ServletJSP(Java Server Pages)、ASP(Active Servcer Pages)や、
スクリプト(javascript, Flash, Java Applet)等のクライアント上で実行されるプログラムを配信するサーバも含まれます。

上で述べたように実現方式には、いろいろあります。
PHPでの実行方式と、javascriptでの実行方式を図で示します。

f:id:yabicon:20210516012749p:plain
PHP

f:id:yabicon:20210516012813p:plain
Javascript

Webにおける認証

認証している状態をWebサーバやWebアプリケーションサーバに伝える方法はいくつかありますが、
古典的な方法は、HTTPにおけるBasic認証もしくはDigest認証です。また、cookie(クッキー)なと呼ばれる技術を用いる方法があります。

  • Basic/Digest認証
    Basic/Digest認証は、認証が要求されるページにアクセスするたびに、WebサーバもしくはWebアプリケーションサーバにあらかじめ登録しておいたユーザ名、パスワードを
    Webブラウザからのリクエストの際のHTTPヘッダに埋め込む方式です。

  • クッキーを用いるセッション管理と認証
    クッキーは、ユーザーの識別やセッション管理などを行うための最大4キロバイト程度の情報です。

    クッキーは、Webアプリケーションサーバ上で作成された後、Webブラウザに発行され保存されます。
    そのあとのHTTP通信において、Webブラウザから当該のWebアプリケーションサーバへ アクセスする際には、毎回、このクッキーがHTTPヘッダに含まれた形で送信されます。

    Webアプリケーションサーバは戻ってきたクッキーを用いて、WebブラウザとWebアプリケーションサーバ間のセッションを管理することができます。
    クッキーを用いることで、WebクライアントとWebアプリケーションサーバとの通信で状態を持てるので、その状態に応じたWebページを動的に作成することができます。

    クッキーが第3者に漏れることで「なりすまし」をされる可能性があります。そのため、クッキーを用いて認証されたセッションを管理する場合は、SSL/TLSにより通信路を保護する必要があります。

    またクッキーにsecure属性を付与し、SSL/TLSで保護されたHTTP通信でしかクッキーを送信しないようにするようにすることが必要です。

XSS攻撃とその対策

Webアプリケーションサーバの実装における代表的な脆弱性のうちにXSS(Crosss Site Scripting, クロスサイトスクリプティング)があります。

XSSとは、動的にWebページを生成するWebアプリケーションサーバにおいて、利用者からの入力に対して必要な入出力チェックをしていないことが原因で、そのWebアプリケーションサーバ上で 悪意あるスクリプトが送信されてしまうこと、もしくは、その脆弱性のことをいいます。

XSS脆弱性を悪用すると、任意のスクリプトを被害者のWebブラウザ上で実行させることができます。XSS攻撃により、改変したページを閲覧させたり、入力情報を攻撃者のもとへ送信させるように 仕組んだりすることも可能になります。

XSS攻撃の最大の驚異の一つは、認証されたセッションの管理を行うクッキーを盗み出すことが可能になることです。

XSSの対策をしていないWebアプリケーションを考えます。ユーザーネームを入力すると、ユーザが存在するかどうかを調べ、結果を返すというシステムの場合、
ユーザーネームの入力部分にスクリプトを追加することで、XSS攻撃を仕掛けることができます。

f:id:yabicon:20210516012911p:plain
XSS攻撃の例


Webブラウザからのリクエストに含まれるスクリプトコードをWebアプリケーションサーバが元のWebブラウザに送り返すものを反射型XSS攻撃、

XSS脆弱性のあるサイトに攻撃用のスクリプトコードを埋め込んで置き、利用者をそのサイトへ誘導するタイプの攻撃を格納型XSS攻撃といいます。

XSS脆弱性は、静的なページでは基本的に起こりません。利用者がWebページを通して値を入力し、Webアプリケーションサーバが何かしらの処理をして出力する際に、発生します。
なので対策としては、入力チェック、エスケープ処理があげられます。

入力チェックでは、文字長や英数字であるかなどの判断を行います。
エスケープ処理は、「>」「&」などのメタ文字を「<」「&」などに変換させてしまうということです。
そうすることで、scriptのコードが実行させることはなく、そのままの文字列で表示されます。


SQLインジェクションとその対策

SQLインジェクションとは、Webアプリケーションサーバにおけるセキュリティ上の不備を悪用して、Webアプリケーションサーバの開発者が想定しないSQL文を構成して実行させることにより、 Webアプリケーションサーバ、もしくは接続されたDBMSを不正に操作する攻撃方法のことを言います。また、その攻撃を可能とする脆弱性を指す場合もあります。

SQLインジェクションが及ぼす脅威は以下の通り大きく3つあります

  • 機密情報の漏洩
    DBに含まれるデータがすべて抜き取られる可能性があります。アクセス制御が適切でない場合、DBMSが動いているサーバのファイルへのアクセスも可能となります。

  • 重要情報の改ざん
    DBをもとにしてWebページを作成している場合、DBやそこから作成されるWebページを攻撃者の意図通りに書き換えることが可能となります。
    DBやそこから作成されるWebページにウイルスやワームを埋め込むことがあります。

  • 認証処理のバイパス(不正な迂回)
    利用者からのIDとパスワードをDBと突き合わせることで認証を行っている場合、SQLインジェクションにより認証を回避することが可能となります。

SQLインジェクションの仕組みを見てみます。

① 利用者が検索したいユーザーネームとしてtaroを入力して検索ボタンを押すと、URIのリクエストが検索サイトであるWebアプリケーションサーバへ送信されます。
② それを受け取ったWebアプリケーションサーバは、クエリパラメータのusernameから検索する文字列であるtaroを取り出し、それを用いてSQL文を構成してバックエンドのDBMSに発行する
DBMSSQL文を実行し、検索結果を返信します。

f:id:yabicon:20210516012943p:plain
SQLインジェクションの例

SQLインジェクションではブラウザで入力する文字列をtaroではなく、taro ' or 'A' = 'A みたいに悪意あるコードを付け足します。

SQLインジェクションの対策

SQLインジェクション脆弱性の原因は、XSS脆弱性と同じように、攻撃者が、Webアプリケーションサーバの作成者が想定しない値を送信することにあります。

それにより、Webアプリケーションサーバの設計者の意図と違った動きをすることになります。
よって対策法は、SQL文を組み立てる際に、Webアプリケーションサーバの設計者が想定しない分にならないようにすることです。以下の方法があります

バインドメカニズムでは、Webアプリケーションサーバにおいて、利用者からの入力を埋め込んでSQL文を組み立てる際、プリペアドステートメント(準備されたSQL文) を使用します。プリペアドステートメントとは、各種プログラム言語に用意された値埋め込み用APIからなる、解析済みのSQL文のひな形です。

プリペアドステートメントはあらかじめDBMSに登録され、ユーザが入力した値は、SQL文としてではなく値としてDBMSに送信され、DBMSプレースホルダにバインドします。

f:id:yabicon:20210516013023p:plain
プリペア度ステートメント

エスケープ処理は、想定外のSQL文を構成しないようにエスケープ処理をすることにより、SQLインジェクションを防ぐ方法です。
ユーザが入力した値の特殊文字SQL文としてではなく、普通の文字列として送信されます。


CSRF攻撃とその対策

CSRF(Cross Site Request Forgeries)とは、攻撃者が用意したドメインのWebサイトの閲覧中に、Webブラウザの利用者の意図に関係なく、別のドメインのWebサイト上で何らかの操作(掲示板への書き込みなど)を行わせる攻撃のことです
被害例としては以下のようなケースが想定できます。

  • 会員制サイトの退会処理
  • 会員制サイトへの意図しない書き込み
  • Webインターフェースを持つ機器の設定変更
CSRF攻撃の仕組み

会員制サイトでは、認証を行うWebアプリケーションサーバにあらかじめ利用者のIDとパスワードが登録されています。
① 会員制サイトへログインし、ページを閲覧します
② ページを閲覧します
③ 会員制サイトからログアウトします。

CSRF攻撃では、会員制サイトとの間でセッションが張られた状態で、 攻撃者は、会員制サイト上で悪意あるアクションを引き起こす罠サイトのページに利用者を誘導します。
利用者が、会員制サイトにログインしたままの状態で罠サイトのWebページをダウンロードすると、会員制サイトでの不正な処理を行われる可能性があります。

f:id:yabicon:20210516013058p:plain
CSRF攻撃

CSRF攻撃を防ぐには、Webアプリケーションサーバー側で、当該のリクエストが利用者が意図したアクションによるものか否かを確認する必要があります。以下の対策方法があります。

  • リクエストに秘密情報を埋め込む
  • 利用者のアクションに対してパスワードなどの入力を求める
  • WebブラウザからのリクエストのRefererをチェックする

秘密情報を埋め込む方法

f:id:yabicon:20210516013120p:plain
秘密情報を埋め込む対策

パスワードを入力させる方法
CAPTCHAなどが使われます

f:id:yabicon:20210516013145p:plain
パスワードを入力させる方法

Web2.0技術のセキュリティ

Web技術は登場した当初から進化してきました。Web2.0技術とは、新しいWeb技術ということです。

従来のWebページは単純なHTMLによる情報構造のみで作成されていたため、脆弱性が入り込む余地はWebサーバかWebアプリケーションサーバだけになかったのですが、Web2.0では、 Ajaxに代表されるような高度な技術の集合体となっています。

それまでサーバ側だけの開発だったのが、Webブラウザ上のコードと合わせた開発が当たり前となり、特にクライアント側ではサーバ側とは異なる技術が注目される場合もあります。

結果としてサーバ側だけでなくWebブラウザ側にも脆弱性が入り込みやすくなっています。

さらにWebAPIと呼ばれる技術の進化によって、Webサイトの構築において様々な外部のサービスを利用することが一般化しました。
開発者にとって外部サービスという新たばブラックボックスが増えただけでなく、様々な要素技術が複雑に絡み合うことでWebセキュリティの範囲も広がりました。


Web2.0における特徴的なセキュリティの事例として、DOM Based XSSという脆弱性があります。

DOM Based XSS とは、DOM(Document Object Model)を通じたHTML操作の結果として、意図しないスクリプトが実行されることや、それを許す脆弱性を指します。
※ DOMとは、プログラム(スクリプト)からWebページの文書の内容や構造、スタイルに動的にアクセス・更新できるインターフェースのことを言います。

Ajaxなど、Webアプリケーションサーバと連携して、Webページを動的に更新する機能において、その脆弱性が入り込みます。
DOM Based XSS脆弱性は、JavaScriptによるWebページへの出力処理に不備があることが原因のケースと、JavaScriptライブラリに起因するケースとがあります。

例として、javaScriptのプログラムコードの中の変数dataに対して値を動的に代入し、document.write(data)というコードを使用するWebページへの攻撃について考えます。

ここで、document.write(data)関数は、呼び出されるとWebページのリロードなしで動的に追記されます。攻撃のためのスクリプトを含むデータが悪意のあるWebサイトからdataに格納され、それを契機にDOMを用いた攻撃が成立するといった可能性があります。

このようなDOMを用いることによるXSS攻撃をDOM Based XSSと呼びます。これは、Webブラウザ上で実行されるJavaScriptのプログラムコードの脆弱性です。
document.writeのほかにも注意が必要な関数があります。


同一生成元ポリシー

インターネット上で公開されているWebサイトのコンテンツを用いて自前のWebコンテンツを作成する手法(マッシュアップ技術)を用いたWebページが数多くあります。

マッシュアップ技術は単にリンク、iframeを用いたWebページの作成だけではなく、JavaScript、XHR(XMLHttpRequest)を用いたWebコンテンツの実現も特徴です。
※XHRは、JavascriptのHTTP通信機能で、標準的なブラウザに実装されているAPIの一つです。

XHRのコードが組み込まれたWebページの読み込み後、WebブラウザからXHRを用いて、HTMLなどのデータをWebアプリケーションサーバと送受信することができます。

XHRには一つ制約があって、それは同一生成元ポリシー(same origin policy )です。
これは、スクリプトを取得したドメイン(オリジン)と、オリジンと異なるドメイン(クロスオリジン)との通信を認めないという考えのことを指します。
これは一方が悪意のあるサイトの場合の攻撃を防ぐために定められます。

f:id:yabicon:20210516013230p:plain
同一生成元ポリシー

最近では、クロスオリジンの場合でも一定の条件の下で通信を可能とするXHR2という技術も利用されています。