httpの基礎とセキュリティ
TRANSCRIPT
わんくま同盟 東京勉強会 #96
自己紹介
• 本名が古庄道明、 Web では「がる」というハンドルでふらついております
• 本職は技術者。現役プログラマーやってます
• あわせて設計とかインフラとか教育とか( 占いとかイベンターとか ) 色々やってます
• 引っかかりやすい Google 向けキーワードとしては「古庄道明」「エンジニア 親方」「エンジニア 禅」「がる」あたりでしょうか。
わんくま同盟 東京勉強会 #96
本稿の目的
• 「今日1日、一切 HTTP とは関わりませんでした」がそろそろ難しくなってきた程度に、 HTTP は身近になってきました
• が、割とちょいちょい「落とし穴」があり、割と折々に「そこに落ちている」ニュースを以下略
• 落とし穴に、回避方法について「考察できる」基礎知識をお話できれば、と思っています
わんくま同盟 東京勉強会 #96
HTTP のド基本2: GET と POST の違いと「大体の」方向性
• ちょうだい (request) には、 GET と POSTの二種類があります
• GET は…– URL パラメタとして貼り付けられる事も多い
• URL を伝えると「同じ情報」が ( 多分 ) 見れる• 所謂「ログインフォーム」を GET にすると………
– 「リソースの取得」:ようは read のイメージ– 環境変数によってプログラムに受け渡される
ことが多い• ので、長さ制限があるケースが多い
わんくま同盟 東京勉強会 #96
• POST は…– 表向きは、投げるデータが見えない
• request の body にデータが書かれている– 「リソースの書き込み」もよくある
• 「投稿」とか「入力」とか– 標準入力 (stdin) によってプログラムに受け渡
されることが多い• ので、長さ制限はあまりない• けど、おかげで DoS 的な事は可能
わんくま同盟 東京勉強会 #96
HTML と CSS の解釈&画像とかがどうやって表示されるのか
• 一度目の「ちょうだい」「あいよ」では、まず「 HTML 」を取得します
• HTML の中を頭から解釈していきます– <link rel="stylesheet" href="hoge.css">
• CSS が外部ファイルだから「ちょうだい」「あいよ」
– <script src="hoge.js">• JavaScript が外部ファイルだから「ちょうだい」
「あいよ」– <img src="hoge.jpg">
• 画像が外部ファイルだから「ちょうだい」「あいよ」
わんくま同盟 東京勉強会 #96
• さて…では実際に「1枚の Page 」でどれくらいの「ちょうだい」「あいよ」が繰り返されるでしょうか?– おいちゃんところの Page では、自慢じゃあ
りませんが1 set で足ります ( 笑– では「真っ当な」 Page だと…
• ヒドイと 100 超えますねぇ…• この辺は「チューニング」の文脈でも重要です
– 1 Page あたり「同時に2 ( ~6 ) 接続」まで• 紳士協定です! 破ると石斧が飛んできます ( 笑
わんくま同盟 東京勉強会 #96
チューニングほんのり指針
• CSS– import で以外と「ちょうだいあいよ set 数」増加
–出来れば「1ファイルにまとめる」!• JavaScript
– 同じく「出来れば1ファイルにまとめる」!• 画像
–特にアイコンに注意 ( 数が多いから… )• 複数画像を1枚に (CSS スプライト )• <img src="data:image/png;base64,...> なんて書式
も
わんくま同盟 東京勉強会 #96
• ソーシャルメディア連携の部品に注意– 「ブログパーツ」とかいいます– Facebook とか Twitter とかとつなげるやつ– iframe使ってることが多いので、「ちょうだ
いあいよ」のセット数が増える
わんくま同盟 東京勉強会 #96
いわゆる「認証」でログインしてみる
• ID とパスワードを付けて「ちょうだい」• 認証できたんでその結果を「あいよ」
• ( さっき認証したしなぁ )MyPage を「ちょうだい」
• ……… あんただれ?
わんくま同盟 東京勉強会 #96
• HTTP は「一往復完了完結」のやりとりです
• つまり「さっきの情報」とかないです!全ては「今」だけ、なのです!
• 格好良くいうと、こ~ゆ~のを「 stateless(状態を持たない ) 」といいます– このためにサーバの負担が少なく、相対的に
「少量のサーバで大量のアクセス」が捌けます
• … でも認証できなくない?
わんくま同盟 東京勉強会 #96
• 割と有名な「 BASIC認証」の場合– ID とパスワードを付けて「ちょうだい」–認証できたんでその結果を「あいよ」
– ID とパスワードを付けて「ちょうだい」–認証できたんでその結果を「あいよ」
• 毎回「 ID とパスワードを流す」事で片付けます– わりと力業です (苦笑
わんくま同盟 東京勉強会 #96
• 通常は「セッション」を使う事が多いです– ID とパスワードを付けて「ちょうだい」–認証できたんでその結果を「あいよ」+割り符
– ( 割り符を付けて ) 「ちょうだい」– 割り符が識別できたんでその結果を「あい
よ」
• この「割り符」を、「セッション ID 」といいます
わんくま同盟 東京勉強会 #96
割り符の所在
• Cookie って呼ばれる所にある事が多いです– 「 URL に付ける」やり方もあって、 Doxxmo
のガラケーとかが「 Cookie使えない」んで使われてましたが、大変に危険でした
• 場所的には「ちょうだい」と「あいよ」の head 部分にそれぞれ、 Cookie用の領域というか書式があります– 「ちょうだい」では、自分が持ってる Cookie
を渡す– 「あいよ」では、「この Cookie持っとい
て」ってデータがくる
わんくま同盟 東京勉強会 #96
• ちょっと暗転
– 「他人の割り符」を盗んだり推測したり↓
– (不正に入手した ) 割り符を付けて「ちょうだい」
– 割り符が識別できたんでその結果を「あいよ」
• 何がおきるでしょう?
わんくま同盟 東京勉強会 #96
セッションをクラックしてみる
• 割り符とはいっても文字列です
• 例 ) セッション ID は2桁の数字です• 例 ) セッション ID は 128桁の 16進数で
す
• どっちがクラックしやすいでしょう?• 「絶対にクラックできない」のはどちら
でしょう?
わんくま同盟 東京勉強会 #96
• ログインセッションは「不可侵」ではありません
• 後は「どれくらいの確率で破られるか」です– まぁセキュリティはどこまでも「確率」です
が• HTTP は機構的に「認証などの statue を持つには不向き」なのを無理矢理に実装しているので、それなりに気をつけないと「簡単になりすます」事ができます
わんくま同盟 東京勉強会 #96
hidden の値を書き換える系のクラック
• hidden は「 HTML の中にあって、見えない情報」です。
• 入力フォームなんかで割と見かけます– 入力 Paga をちょうだい
• あいよ– ( 情報入力して )確認 Page をちょうだい
• あいよ–完了 Page をちょうだい
• … 入力データは?
わんくま同盟 東京勉強会 #96
• 正しい入力フォーム– 入力 Paga をちょうだい
• あいよ– ( 情報入力して )確認 Page をちょうだい
• あいよ: hidden に入力されたデータ–完了 Page をちょうだい
• (hidden に情報入ってるから処理完了 ) あいよ
わんくま同盟 東京勉強会 #96
• 正しい入力フォーム ( くわしく )– 入力 Paga をちょうだい
• あいよ– ( 情報入力して )確認 Page をちょうだい
• ( データチェックして問題なければ ) あいよhidden に入力されたデータ
–完了 Page をちょうだい• (hidden に情報入ってるから処理完了 ) あいよ
わんくま同盟 東京勉強会 #96
• 暗転した入力フォーム– 入力 Paga をちょうだい
• あいよ– ( 情報入力して )確認 Page をちょうだい
• ( データチェックして問題なければ ) あいよhidden に入力されたデータ
– (hiddenの中身を書き換える )–完了 Page をちょうだい
• (hidden に情報入ってるから処理完了 ) あいよ
• ……… あれ?
わんくま同盟 東京勉強会 #96
• hidden も含めて、全ての外部入力は「不適切な内容」の可能性があります–前述の Cookie も「ユーザの HDD にデータが
ある」んで書き換えが可能です• 「常に stateless 」で、1往復使い切りの
通信であることを、しっかりと肝に銘じておきましょう
• いわゆる「普通の」プログラムと同じように考えると、思いがけない所からクラックされます
わんくま同盟 東京勉強会 #96
DNS ポイゾニング基礎
• 前提として「 TPC 」と「 UDP 」を抑えておきます– TCP は「信頼があるけどちょっと重い」– UDP は「軽い、早い」を重視
• DNS は「ドメイン名を IP アドレスに変換する」サービスで、インターネットの裏側としては「最重要クラス」のブツになります
わんくま同盟 東京勉強会 #96
• DNS 通信の基本– このドメインの IP ちょうだい– (IP を ) あいよ
• もうちょい丁寧に– このドメインの IP ちょうだい ( 識別番号
123)– 識別番号 123 、この IP で あいよ
• 識別番号は「1台のサーバが沢山質問をする」から、どの質問かを識別する用途
わんくま同盟 東京勉強会 #96
• DNS その2:多段構造です• 「 www.wankuma.com 」を知りたい
– 「 com 」を問い合わせ– 「 wankuma.com 」を問い合わせ– 「 www.wankuma.com 」を問い合わせ
• 毎回だと面倒だし通信コストもかかるので、実際には適宜キャッシュします
わんくま同盟 東京勉強会 #96
• 「 www.wankuma.com 」を知りたい– 「 com 」を問い合わせ
• 「 com 」を管理してる DNSサーバをキャッシュ– 「 wankuma.com 」を問い合わせ
• 「 wankuma.com 」管理 DNSサーバをキャッシュ– 「 www.wankuma.com 」を問い合わせ
• 「 www.wankuma.com 」の IP をキャッシュ
• TTL 、という値で「データの寿命」を管理
わんくま同盟 東京勉強会 #96
ちょっと暗転
• 一部切り出し– 「 wankuma.com 」の IP をちょうだい:識別
123– 識別 123 :この IP だよ あいよ
• 「 wankuma.com 」管理 DNSサーバをキャッシュ
• 暗転– 「 wankuma.com 」の IP をちょうだい:識別
123– 識別 123 :この IP だよ あいよ (嘘サーバ )
• 「 wankuma.com 」管理 DNSサーバをキャッシュ
わんくま同盟 東京勉強会 #96
• DNS の「ちょうだい」「あいよ」は UDP• そのため、攻撃側は
– キャッシュさせたい鯖 A に「問い合わせ」を投げる
– 鯖 A は「問い合わせ」をどこかに問い合わせる
–攻撃側は「偽装した " あいよ " 」を鯖 A に投げる
– 鯖 A は「偽装した " あいよ " 」を受け取って、嘘情報をキャッシュしてしまう
• 識別子、 16ビットなんで 65536 通りなの orz
わんくま同盟 東京勉強会 #96
CSRF
• くろすさいとりくえすとふぉーじぇり、といいます
• 幾分面倒な仕組みなのですが、割としゃれになんない問題を抱えるので、ちょっと前、割とスポットライトがあたってました– 古くは「ぼくはまちちゃん」というアタック
で–少し前だと「脅迫的な書き込みでの誤認逮捕」が
わんくま同盟 東京勉強会 #96
• 1)攻撃者のサーバの Page にアクセス• 2) レスポンス
– 中には、 iframe などで (3) の URL が書いてある
• 3) iframe などに従って、掲示板にアクセス– GET パラメタなどに「脅迫文」が書いてある
• 4) 掲示板は「書き込みをした」旨をレスポンス– iframen のサイズが 0 だったりすると見れな
い orz
わんくま同盟 東京勉強会 #96
CSRF の怖いところ
• 「お前の IP からの書き込みだからお前が書いたんだ!」って言われちゃう orz
• iframe経由とはいえ「正当なルートからのアクセス」なので Cookie( 割り符 ) が届いちゃうので「本人として」色々、宜しくない行動を強要させられちゃう orz
わんくま同盟 東京勉強会 #96
おまけ
• あなたの知らない世界– または「事実は小説よりも奇なり」
• とあるゲーム作成での、実話です• いわゆる「アプリ」なので
–ガジェットが「ちょうだい」して–サーバが「あいよ」します
• ガジェットを「 front 」っていう事があります
わんくま同盟 東京勉強会 #96
• がちゃを引く– front :「がちゃを引く」処理を内部で行う– front: 鯖に対して「このカードを引いた」で
通信• 通信情報は「ユーザの ID 」と「カードの ID 」
– 鯖:指定されたユーザに対して、指定されたカードの付与を行う
• …ユーザが「悪意をもって」パラメタを偽装したら?– 「お高いカード ID 」とか指定したくありませ
ん? ( 笑