Httpの基礎とセキュリティ

わんくま同盟東京勉強会 #96

「ちょうだい」「あいよ」で学ぶ HTTP の基礎とセキュリティ

がる


自己紹介

• 本名が古庄道明、 Web では「がる」というハンドルでふらついております

• 本職は技術者。現役プログラマーやってます

• あわせて設計とかインフラとか教育とか( 占いとかイベンターとか ) 色々やってます

• 引っかかりやすい Google 向けキーワードとしては「古庄道明」「エンジニア親方」「エンジニア禅」「がる」あたりでしょうか。


本稿の目的

• 「今日１日、一切 HTTP とは関わりませんでした」がそろそろ難しくなってきた程度に、 HTTP は身近になってきました

• が、割とちょいちょい「落とし穴」があり、割と折々に「そこに落ちている」ニュースを以下略

• 落とし穴に、回避方法について「考察できる」基礎知識をお話できれば、と思っています


HTTP のド基本：通信は「１往復紙芝居」

鯖

ちょうだい

あいよ


リクエスト

レスポンス

鯖


URL

HTML( とか )

鯖


URL.html

HTML( とか )

鯖Apache


URL.php

HTML( とか )

鯖Apache

PHP


HEAD

BODY

HEAD

BODY

鯖Apache

PHP


HTTP のド基本２： GET と POST の違いと「大体の」方向性

• ちょうだい (request) には、 GET と POSTの二種類があります

• GET は…– URL パラメタとして貼り付けられる事も多い

• URL を伝えると「同じ情報」が ( 多分 ) 見れる• 所謂「ログインフォーム」を GET にすると………

– 「リソースの取得」：ようは read のイメージ– 環境変数によってプログラムに受け渡される

ことが多い• ので、長さ制限があるケースが多い


• POST は…– 表向きは、投げるデータが見えない

• request の body にデータが書かれている– 「リソースの書き込み」もよくある

• 「投稿」とか「入力」とか– 標準入力 (stdin) によってプログラムに受け渡

されることが多い• ので、長さ制限はあまりない• けど、おかげで DoS 的な事は可能


HTML と CSS の解釈＆画像とかがどうやって表示されるのか

• 一度目の「ちょうだい」「あいよ」では、まず「 HTML 」を取得します

• HTML の中を頭から解釈していきます– <link rel="stylesheet" href="hoge.css">

• CSS が外部ファイルだから「ちょうだい」「あいよ」

– <script src="hoge.js">• JavaScript が外部ファイルだから「ちょうだい」

「あいよ」– <img src="hoge.jpg">

• 画像が外部ファイルだから「ちょうだい」「あいよ」


• さて…では実際に「１枚の Page 」でどれくらいの「ちょうだい」「あいよ」が繰り返されるでしょうか？– おいちゃんところの Page では、自慢じゃあ

りませんが１ set で足ります ( 笑– では「真っ当な」 Page だと…

• ヒドイと 100 超えますねぇ…• この辺は「チューニング」の文脈でも重要です

– １ Page あたり「同時に２ ( ～６ ) 接続」まで• 紳士協定です！破ると石斧が飛んできます ( 笑


チューニングほんのり指針

• CSS– import で以外と「ちょうだいあいよ set 数」増加

–出来れば「１ファイルにまとめる」！• JavaScript

– 同じく「出来れば１ファイルにまとめる」！• 画像

–特にアイコンに注意 ( 数が多いから… )• 複数画像を１枚に (CSS スプライト )• <img src="data:image/png;base64,...> なんて書式

も


• ソーシャルメディア連携の部品に注意– 「ブログパーツ」とかいいます– Facebook とか Twitter とかとつなげるやつ– iframe使ってることが多いので、「ちょうだ

いあいよ」のセット数が増える


いわゆる「認証」でログインしてみる

• ID とパスワードを付けて「ちょうだい」• 認証できたんでその結果を「あいよ」

• ( さっき認証したしなぁ )MyPage を「ちょうだい」

• ……… あんただれ？


• HTTP は「一往復完了完結」のやりとりです

• つまり「さっきの情報」とかないです！全ては「今」だけ、なのです！

• 格好良くいうと、こ～ゆ～のを「 stateless(状態を持たない ) 」といいます– このためにサーバの負担が少なく、相対的に

「少量のサーバで大量のアクセス」が捌けます

• … でも認証できなくない？


• 割と有名な「 BASIC認証」の場合– ID とパスワードを付けて「ちょうだい」–認証できたんでその結果を「あいよ」

– ID とパスワードを付けて「ちょうだい」–認証できたんでその結果を「あいよ」

• 毎回「 ID とパスワードを流す」事で片付けます– わりと力業です (苦笑


• 通常は「セッション」を使う事が多いです– ID とパスワードを付けて「ちょうだい」–認証できたんでその結果を「あいよ」＋割り符

– ( 割り符を付けて ) 「ちょうだい」– 割り符が識別できたんでその結果を「あい

よ」

• この「割り符」を、「セッション ID 」といいます


割り符の所在

• Cookie って呼ばれる所にある事が多いです– 「 URL に付ける」やり方もあって、 Doxxmo

のガラケーとかが「 Cookie使えない」んで使われてましたが、大変に危険でした

• 場所的には「ちょうだい」と「あいよ」の head 部分にそれぞれ、 Cookie用の領域というか書式があります– 「ちょうだい」では、自分が持ってる Cookie

を渡す– 「あいよ」では、「この Cookie持っとい

て」ってデータがくる


• ちょっと暗転

– 「他人の割り符」を盗んだり推測したり↓

– (不正に入手した ) 割り符を付けて「ちょうだい」

– 割り符が識別できたんでその結果を「あいよ」

• 何がおきるでしょう？


セッションをクラックしてみる

• 割り符とはいっても文字列です

• 例 ) セッション ID は２桁の数字です• 例 ) セッション ID は 128桁の 16進数で

す

• どっちがクラックしやすいでしょう？• 「絶対にクラックできない」のはどちら

でしょう？


• ログインセッションは「不可侵」ではありません

• 後は「どれくらいの確率で破られるか」です– まぁセキュリティはどこまでも「確率」です

が• HTTP は機構的に「認証などの statue を持つには不向き」なのを無理矢理に実装しているので、それなりに気をつけないと「簡単になりすます」事ができます


hidden の値を書き換える系のクラック

• hidden は「 HTML の中にあって、見えない情報」です。

• 入力フォームなんかで割と見かけます– 入力 Paga をちょうだい

• あいよ– ( 情報入力して )確認 Page をちょうだい

• あいよ–完了 Page をちょうだい

• … 入力データは？


• 正しい入力フォーム– 入力 Paga をちょうだい


• あいよ： hidden に入力されたデータ–完了 Page をちょうだい

• (hidden に情報入ってるから処理完了 ) あいよ


• 正しい入力フォーム ( くわしく )– 入力 Paga をちょうだい


• ( データチェックして問題なければ ) あいよhidden に入力されたデータ

–完了 Page をちょうだい• (hidden に情報入ってるから処理完了 ) あいよ


• 暗転した入力フォーム– 入力 Paga をちょうだい


• ( データチェックして問題なければ ) あいよhidden に入力されたデータ

– (hiddenの中身を書き換える )–完了 Page をちょうだい

• (hidden に情報入ってるから処理完了 ) あいよ

• ……… あれ？


• hidden も含めて、全ての外部入力は「不適切な内容」の可能性があります–前述の Cookie も「ユーザの HDD にデータが

ある」んで書き換えが可能です• 「常に stateless 」で、１往復使い切りの

通信であることを、しっかりと肝に銘じておきましょう

• いわゆる「普通の」プログラムと同じように考えると、思いがけない所からクラックされます


DNS ポイゾニング基礎

• 前提として「 TPC 」と「 UDP 」を抑えておきます– TCP は「信頼があるけどちょっと重い」– UDP は「軽い、早い」を重視

• DNS は「ドメイン名を IP アドレスに変換する」サービスで、インターネットの裏側としては「最重要クラス」のブツになります


• DNS 通信の基本– このドメインの IP ちょうだい– (IP を ) あいよ

• もうちょい丁寧に– このドメインの IP ちょうだい ( 識別番号

123)– 識別番号 123 、この IP であいよ

• 識別番号は「１台のサーバが沢山質問をする」から、どの質問かを識別する用途


• DNS その２：多段構造です• 「 www.wankuma.com 」を知りたい

– 「 com 」を問い合わせ– 「 wankuma.com 」を問い合わせ– 「 www.wankuma.com 」を問い合わせ

• 毎回だと面倒だし通信コストもかかるので、実際には適宜キャッシュします


• 「 www.wankuma.com 」を知りたい– 「 com 」を問い合わせ

• 「 com 」を管理してる DNSサーバをキャッシュ– 「 wankuma.com 」を問い合わせ

• 「 wankuma.com 」管理 DNSサーバをキャッシュ– 「 www.wankuma.com 」を問い合わせ

• 「 www.wankuma.com 」の IP をキャッシュ

• TTL 、という値で「データの寿命」を管理


ちょっと暗転

• 一部切り出し– 「 wankuma.com 」の IP をちょうだい：識別

123– 識別 123 ：この IP だよあいよ

• 「 wankuma.com 」管理 DNSサーバをキャッシュ

• 暗転– 「 wankuma.com 」の IP をちょうだい：識別

123– 識別 123 ：この IP だよあいよ (嘘サーバ )

• 「 wankuma.com 」管理 DNSサーバをキャッシュ


• DNS の「ちょうだい」「あいよ」は UDP• そのため、攻撃側は

– キャッシュさせたい鯖 A に「問い合わせ」を投げる

– 鯖 A は「問い合わせ」をどこかに問い合わせる

–攻撃側は「偽装した " あいよ " 」を鯖 A に投げる

– 鯖 A は「偽装した " あいよ " 」を受け取って、嘘情報をキャッシュしてしまう

• 識別子、 16ビットなんで 65536 通りなの orz


CSRF

• くろすさいとりくえすとふぉーじぇり、といいます

• 幾分面倒な仕組みなのですが、割としゃれになんない問題を抱えるので、ちょっと前、割とスポットライトがあたってました– 古くは「ぼくはまちちゃん」というアタック

で–少し前だと「脅迫的な書き込みでの誤認逮捕」が


CSRF仕組み

犠牲者 A

悪意ある鯖

掲示板

12

4

3


• 1)攻撃者のサーバの Page にアクセス• 2) レスポンス

– 中には、 iframe などで (3) の URL が書いてある

• 3) iframe などに従って、掲示板にアクセス– GET パラメタなどに「脅迫文」が書いてある

• 4) 掲示板は「書き込みをした」旨をレスポンス– iframen のサイズが 0 だったりすると見れな

い orz


CSRF の怖いところ

• 「お前の IP からの書き込みだからお前が書いたんだ！」って言われちゃう orz

• iframe経由とはいえ「正当なルートからのアクセス」なので Cookie( 割り符 ) が届いちゃうので「本人として」色々、宜しくない行動を強要させられちゃう orz


おまけ

• あなたの知らない世界– または「事実は小説よりも奇なり」

• とあるゲーム作成での、実話です• いわゆる「アプリ」なので

–ガジェットが「ちょうだい」して–サーバが「あいよ」します

• ガジェットを「 front 」っていう事があります


• がちゃを引く– front ：「がちゃを引く」処理を内部で行う– front: 鯖に対して「このカードを引いた」で

通信• 通信情報は「ユーザの ID 」と「カードの ID 」

– 鯖：指定されたユーザに対して、指定されたカードの付与を行う

• …ユーザが「悪意をもって」パラメタを偽装したら？– 「お高いカード ID 」とか指定したくありませ

ん？ ( 笑


まとめ

• http は「シンプルに作る」ことで、スケーラビリティなどに大変優れたプロトコルです

• ただ「鬼ほどにシンプル」なので、本来できることは少ないです

• そこに「山盛りの下心」を現在盛り込んでいるので (認証とか ) 。設計者が気をつけないと、危険な香りが「むせっかえる」くらいに漂います

• 「ちょうだい」「あいよ」を理解して、付け入る隙間にはちゃんとパテを埋めましょう！！！

Httpの基礎とセキュリティ

Engineering

Transcript of Httpの基礎とセキュリティ