/var/log/shinこの広告は、90日以上更新していないブログに表示しています。2014-03-04Webセキュリティメモセキュリティ何となく、自分の理解をまとめておきたくなったので、徒然と書き連ねます。セッションとCookie誰からのアクセスなのかを判別するためには何らかの識別子(ID)が必要である。それがセッションID。クライアントは、自分が誰であるのかを証明するために、通信の度にセッションIDをサーバへ送る必要がある。毎回送るという特性に親和性が高いため、通常、セッションIDはCookieで管理される。一部携帯電話(主にドコモのガラケー?)ではCookieが使えないため、GETパラメータで代用される事がある。GETで管理するということはURLにセッションIDが載るということ。よってURLのコピペでセッションIDが漏れることも有り得る。ガラケーの仕様上、使われるのは致し方無いが、そうでない環境では通常この手法は採用されない。セッションIDが盗まれると、セッションの有効期間が切れるまで、第三者が本人になりすまして不正アクセスすることが可能となる(セッションハイジャック)。HTTP通信の場合、Cookieは平文で流れる。セッションIDも平文で流れることになり、盗聴の危険性が生じる。Cookieにsecure属性を指定すると、HTTPS通信の場合のみ、Cookieが送受信されるようになる。最近はHTTPS通信前提でウェブサービスが構築されることが多く(Twitter、Facebook、...)、secure属性は良く使われる。Cookieのexpires属性で有効期間を指定したほうが、万が一の時により安全ではあるが、最近はCookieで長い間セッションIDが維持される設計のウェブシステムが増えている。ウェブブラウザを、スマホアプリなどと同列のクライアントアプリの一種と見なした設計とも言える。考えればスマホアプリと安全性は同程度である。text/htmlhttp://www.studyinghttp.net/cookiesAjaxとCookieAjaxの通信では、通信先URLにマッチしたCookieも送信される。Ajaxでは、ヘッダの値を参照できるので、Cookieも参照できる。XMLHttpRequest#setRequestHeader、XMLHttpRequest#getResponseHeaderCookieを参照できるということは、当然、中の値を参照することも出来る。セッションIDをCookieに入れている場合は、任意のサイトでAjaxによるセッションハイジャックの危険性が生じる。CookieにHttpOnly属性を付加すると、スクリプト経由(JavaScript、VBScript)でCookieを読み出すことができなくなる。イマドキのブラウザならほぼ対応しているので常に付加するのが無難か。SSLとMITMSSLには「通信の暗号化」と「相手(通信先)が信頼できる(本物である)ことの証明」の2つの役割がある。巷で使われるSSLは、主として「独自SSL」「共有SSL」「オレオレ証明書によるSSL」の3種類ある。独自SSLSSLの最も正しい形。証明書の発行所のグレードにより、信頼性は変わる。メジャーなウェブサービスや銀行などは*1老舗VeriSignのClass3という最高グレードの証明書を持っていたりする。そのような証明書は取得の手間と値段がバカ高く、審査も厳しい分、信頼性が非常に高い。共有SSLSSLの微妙な形。サイトのドメインに対する、共有SSLのドメインの名前つけのルールが明確であれば、相手を信頼出来ないこともないが*2、証明書がレンタルサーバーのものである以上、根本的に信頼性が高いとはいえない。レンタルサーバーによっては、サブドメインを用いない名前つけをされることが有る*3。そのような場合、同一ホスト上の他サイトからCookieを閲覧されうるため、Cookieの使用は出来ないと考えたほうが良い。共用SSLサーバの危険性が理解されていない実際の所、ウェブにかける予算の問題もあるので、残念ながら、個人や小企業では妥協することも多い。最近では電話番号や住所程度なら平文(HTTP通信)でも割りと許容される傾向にある(?)パスワードを使うサービスはHTTPS前提で考えるのが正しい。オレオレ証明書によるSSLSSLの一番アレゲな形。ほとんどのモダンブラウザで「信頼出来ない証明書」という警告が出る。フィンガープリントすら確認せずに、あのサイトは許可でオッケー、などと考えているとMITM(Man-in-the-Middle)攻撃(後述)を受けていることにすら気づくことが出来ないため危険。よって、歴とした団体でありたいなら、オレオレ証明書は使うべきではない。SSLには証明書が必要です...と。フィンガープリントもSSLで送れば大丈夫、と。信頼出来ない証明書を許容すると、SSLによる暗号化を破ることが出来る。脱獄)したスマホを用いれば、パズドラの通信内容を覗くことが可能。MITM前提の設計をするのであれば、お金が絡む部分など、クリティカルな処理はサーバー側に集約する必要がある。AliceとBobが、Bobのオレオレ証明書を使ったSSL通信を行う。Eveは中間者でAliceとBobの暗号通信を盗聴する。BobAliceがBobのオレオレ証明書をいつも信頼していると、Eveのオレオレ証明書にすり替わっていても、そのことに気づかない。Forgeries)端的に言えば「ユーザの意図しない自動投稿(submit)」。攻撃者は、CSRF対策されていないサイトに対して、適切なパラメータで適切なURLにGET/POSTするプログラムを書き、ばら撒く。手軽なのは、JavaScriptでAjaxで自動投稿するプログラムを書き、罠サイトを用意し、URLを拡散する方法。GET/POSTが出来さえすれば良いので、もちろんネイティブアプリで拡散しても良い。一般ユーザがばら撒かれたプログラムを実行すると、そのユーザのアクションとして、何らかのGET/POSTが行われる。CSRF対策されていないSNSでは、セッションが持続していたら、意図しないメッセージを投稿させられることになる。掲示板やブログコメントにおいても同様。犯行予告であれば誤認逮捕も有り得る。遠隔操作ウイルスの横浜市への犯行予告*4による誤認逮捕。ネット投票が荒らされる。ポケモンやイナイレの人気投票祭り。ショッピングサイトであれば意図しない注文をさせられる可能性も。お手軽な罠サイトのパターンを防ぐのであれば、リファラチェックが有効。Ajaxには前述の通りXMLHttpRequest#setRequestHeaderというメソッドがあるが、refererはセキュリティの都合上セットできない。(参考:セットできないヘッダのリスト)リファラが空の場合は拒否しなければならない。この点については賛否両論ある。リファラは偽装できるので、リファラチェックだけでは、リファラを偽装する専用ツールに対抗できない。専用ツール対策としてはhiddenフィールドを使った固定トークン方式が一般的。セッションIDは固定トークンであるが、HTMLのソース自体が流出する可能性も無いとはいえないので*5、セッションIDとは別の専用IDを作成して利用したほうが無難。クリティカルな処理の最後のステップでパスワードを入れさせるという手法もある。ワンタイムトークンを使う方法もある。CSRFに限らず、ツールによる自動投稿・登録の対策としてCAPTCHAがあるが、これはワンタイムトークン方式の典型的な例であり、もちろんCSRF対策にも利用することが可能。警察が殺人予告などにシビアになっているため、今後は、特に一般に投稿メッセージが公開される系のウェブサービスでは、対策が必須になるか。Scripting)外部からの入力シリーズ1システム外からの入力を用いてHTMLなどを構成し出力する時に起きうる脆弱性。単純な例「GETやPOSTで受け取ったパラメータを、そのままHTML出力する。」script要素を含んだパラメータを送ることで、レスポンス表示時に任意のプログラムをWebサイトに組み込み、実行することが可能。罠サイトを用意して、攻撃スクリプトを含むパラメータでGET/POSTすれば、セッションハイジャック等ができる仕組み。DBを経由するなど、間接的に入ってくる場合もある。対策方法は、出力時に適切にエスケープを行うこと。多重エスケープしないように、出力時にのみ行うように習慣づけることが重要。HTML以外でもスクリプトを実行する手段があるので、注意する。IEはCSSでJavaScriptを実行できる。SQLインジェクション外部からの入力シリーズ2システム外からの入力を用いてSQLクエリを構成し実行する時に起きうる脆弱性。XSSと似たような話。DBは個人情報の塊なのでXSSより深刻な被害になることが多い。StatementのPlaceholder機能を使うのが鉄板。手動でのエスケープは、DBによってエスケープの仕方が異なるなど、非常に危険。エスケープするにしても、DB提供のライブラリを使うべき。Statementを使っていても、NULL文字関係で脆弱性が生じることがあるので注意。blog言うまでもないが、SQLのみならず、いわゆるeval関数やsystem関数などでも注意が必要。バッファオーバーフローもしくはバッファオーバーラン。メモリを直接扱うレベル。その上に乗っているシステム全体を制御できる低レイヤだからこそ最も注意が必要な脆弱性。セキュリティは低レイヤを抑えたもの勝ち。典型的な例としては、想定よりも長い文字列が与えられて、スタックを上書きしてしまうなど。スタックフレームのreturnアドレスを攻撃プログラムの先頭に...OS側の対策としてアドレス空間を実行毎に変えたり*6...などの話は巷に溢れているので省略。要するにgetsやscanfは使ってはいけませんのお話。ポインタを扱う時は注意が必要ということ。バッファオーバーラン*7ではないが、最近のSSLのheartbleed脆弱性も似たようなお話。思いついたら書きます。*1:Facebook、Twitter、東京三菱UFJ銀行でさくっと確認*2:偽サイトではないと判別できるという意味で*3:最近は減ってきている。NSURLConnectionのまとめiOSでネットワーク通信をするのは初めてだったのでメモ。De...2014-03-08PSGI/Plackオレオレ入門ここ数日、Amon2を解読していたのですが、結局PSGI/Plackをちゃ...2014-02-12iOSアプリをリリースしてみたといっても現在レビュー待ちですが。»プロフィールid:s-shinプログラマブルな人間になりたい。(1)リンクヘルプはてなブログお知らせはてなブログをはじめよう!s-shinさんは、はてなブログを使っています。ブログを報告する引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。