Httpの基礎とセキュリティ

わんくま同盟東京勉強会 #96
「ちょうだい」「あいよ」で学ぶHTTPの基礎とセキュリティ
がる

自己紹介
• 本名が古庄道明、Webでは「がる」というハン
ドルでふらついております
• 本職は技術者。現役プログラマーやってます
• あわせて設計とかインフラとか教育とか(占い
とかイベンターとか)色々やってます
• 引っかかりやすいGoogle向けキーワードとし
ては「古庄道明」「エンジニア親方」「エンジニ
ア禅」「がる」あたりでしょうか。

本稿の目的
• 「今日１日、一切HTTPとは関わりませんでし
た」がそろそろ難しくなってきた程度に、HTTP
は身近になってきました
• が、割とちょいちょい「落とし穴」があり、割と
折々に「そこに落ちている」ニュースを以下略
• 落とし穴に、回避方法について「考察できる」
基礎知識をお話できれば、と思っています

HTTPのド基本：通信は「１往復紙芝居」
鯖
ちょうだい
あいよ

リクエスト
レスポンス
鯖

URL
HTML(とか)
鯖

URL.html
HTML(とか)
鯖
A
p
a
c
h
e

URL.php
HTML(とか)
鯖
A
p
a
c
h
e
P
H
P

HEAD
BODY
HEAD
BODY
鯖
A
p
a
c
h
e
P
H
P

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」といいます

割り符の所在
• Cookie って呼ばれる所にある事が多いです
– 「URLに付ける」やり方もあって、Doxxmoのガラ
ケーとかが「Cookie使えない」んで使われてまし
たが、大変に危険でした
• 場所的には「ちょうだい」と「あいよ」のhead部
分にそれぞれ、Cookie用の領域というか書式
があります
– 「ちょうだい」では、自分が持ってるCookieを渡す
– 「あいよ」では、「このCookie持っといて」ってデー
タがくる

• ちょっと暗転
– 「他人の割り符」を盗んだり推測したり
↓
– (不正に入手した)割り符を付けて「ちょうだい」
– 割り符が識別できたんでその結果を「あいよ」
• 何がおきるでしょう？

セッションをクラックしてみる
• 割り符とはいっても文字列です
• 例) セッションIDは２桁の数字です
• 例) セッションIDは128桁の16進数です
• どっちがクラックしやすいでしょう？
• 「絶対にクラックできない」のはどちらでしょ
う？

• ログインセッションは「不可侵」ではありません
• 後は「どれくらいの確率で破られるか」です
– まぁセキュリティはどこまでも「確率」ですが
• HTTPは機構的に「認証などのstatueを持つ
には不向き」なのを無理矢理に実装している
ので、それなりに気をつけないと「簡単になり
すます」事ができます

hiddenの値を書き換える系のクラック
• hiddenは「HTMLの中にあって、見えない情
報」です。
• 入力フォームなんかで割と見かけます
– 入力Pagaをちょうだい
• あいよ
– (情報入力して)確認Pageをちょうだい
• あいよ
– 完了Pageをちょうだい
• …入力データは？

• 正しい入力フォーム
• あいよ
• あいよ：hiddenに入力されたデータ
• (hiddenに情報入ってるから処理完了)あいよ

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

• 暗転した入力フォーム
• あいよ
• (データチェックして問題なければ)あいよ
hiddenに入力されたデータ
– (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」のIPをちょうだい：識別123
– 識別123：このIPだよあいよ(嘘サーバ)

• DNSの「ちょうだい」「あいよ」はUDP
• そのため、攻撃側は
– キャッシュさせたい鯖Aに「問い合わせ」を投げる
– 鯖Aは「問い合わせ」をどこかに問い合わせる
– 攻撃側は「偽装した"あいよ"」を鯖Aに投げる
– 鯖Aは「偽装した"あいよ"」を受け取って、嘘情報
をキャッシュしてしまう
• 識別子、16ビットなんで65536通りなの orz

CSRF
• くろすさいとりくえすとふぉーじぇり、といいます
• 幾分面倒な仕組みなのですが、割としゃれに
なんない問題を抱えるので、ちょっと前、割と
スポットライトがあたってました
– 古くは「ぼくはまちちゃん」というアタックで
– 少し前だと「脅迫的な書き込みでの誤認逮捕」が

CSRF仕組み
犠牲者A
悪意ある鯖
掲示板
1
2
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の基礎とセキュリティ

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (20)

Httpの基礎とセキュリティ