これは私のはじめてのWEBサイトです。
----- ソース中の改行はHTMLでは無視されますので、改行してもブラウザでの表示に は影響しません。多くの場合ブラウザは適切な位置で自動的に改行しますが、単 語の途中などでは出来る限り改行せず、「。」の後ろなどで改行するようにした 方が無難です。 HTMLは「タグ」を用いて文章構造を定義します。タグはのような開始タ グとのような終了タグを総称して「タグ」と呼びます。<と>に囲まれたh tmlのような文字を「エレメント」（要素）と呼び、langなどの要素の後に続くも のを「アトリビュート」（属性）と呼び、この例では言語を指定しています。ま た、lang="ja"のjaのようなものを「バリュー」（値）と呼び、この例では日本語 を表しています。開始タグと終了タグの間に挟まれた部分を「コンテント」（内 容）と呼びます。タグの中には終了タグを省略できるものや、終了タグを書いて はならないものもあります。 ちなみに、エレメント名やアトリビュート名は大文字、小文字で識別はされま せん。このレポート内では見やすさのため、すべて小文字で書いてあります。HT MLの仕様書の中ではエレメント名は大文字で、アトリビュート名は小文字で記述 されていますが、これに習う必要性はありません。 また、バリューは"（ダブルクォーテーション）で囲むようにしてください。バ リューに使用できるものは""で囲まれた文字列かname tokenだけです。name tok enは英数字と「.」、「-」、「:」、「_」で構成された文字列で、よくわからな いならすべて""で囲んだほうが無難です。 HTML文書は大まかにわけて、次の3つの部分に分けられます。 ●DOCTYPE宣言 DOCTYPE宣言（文書型宣言）はそのHTML文書がどのDTD（Document Type Defini tion：文章型定義書）にのっとって書かれたものなのかを明示します。前述の例 ではの部分で、空白文字と注釈宣言、処理命令を除いてHTML 文書の最初に記述します。これはHTMLにおいては必須で、DOCTYPE宣言を省略する ことはできません。 ○DOCTYPE宣言の詳細 HTMLにもバージョンがあり、バージョンによって使えるエレメントやアトリビ ュート、キャラクタセットなどが異なります。こういった情報はすべてDTDに明記 されています。つまりDOCTYPE宣言はHTML文書がどのバージョンやDTDに沿って書 かれたものなのかをユーザエージェントに知らせる役割を持ちます。DOCTYPE宣言 もいくつかの部分に分けることができます。 ・ マーク宣言終了区切り子です。これによりマーク宣言が終わりであることを表 します。 ○HTML4.0で参照されるDTD このレポートを執筆している2006年2月20日現在で最新バージョンのHTML4.0に は、さらに3つの規格があり、それぞれ参照するDTDなどに違いがあります。 ・Strict 通常HTML4.0といえばこの規格をさします。厳格な決まりがあり、非推奨のエレ メントやアトリビュート、バリューなどを一切使わないだけでなく、それぞれの エレメントの配置位置なども厳格に規定されています。また、Strictはフレーム 内に出現することはできません。Strictの場合のDOCTYPE宣言は次のようになりま す。 ・Transitional Strictよりもルーズな規格です。非推奨のエレメントやアトリビュートの使用 ができますが、framesetエレメントを使用することはできません。Transitional の場合のDOCTYPE宣言は次のようになります。 ・Frameset Trasitioalで規定されたエレメントやアトリビュートおよびframesetエレメン トを使用することができます。フレームでWEBサイトを構成する場合に使用します。 Framesetの場合のDOCTYPE宣言は次のようになります。 ●ヘッド部分 ヘッド部分はHTMLではheadタグによって分けられます（〜の部分）。 ヘッド部分にはそのHTML文書のタイトルやメタ情報（文書の中身以外の情報）、 スタイルシートやスクリプトなどを記述します。この中でtitleタグは省略するこ とができません。titleエレメントはそのHTML文書の概要を簡単に述べるためのも ので、ブラウザの上部に表示されたり、お気に入りの名前になったりします。厳 密にはheadエレメントは省略可能ですが、通常省略するべきではありません。 また、ヘッド部分のメタ情報はmetaエレメントで指定することができます。me taエレメントは文書のプロパティ（著者、キーワードなど）を設定したり、それ らのプロパティのバリューを設定するのに用いることができます。例えばメタ情 報は次のように記述されます。 ----- ----- これは著者がDefolosであることを表すメタ情報です。nameのバリューはプロパ ティ名となります。contentのバリューはプロパティに設定される値となります。 プロパティやそのバリューは自分で定義することもでき、その場合プロパティと プロパティに設定されたバリューがどういった意味と関連付けられているのかは headエレメントのplofileアトリビュートで指定されたリファレンス（URIで指定） に記載されることになります。metaエレメントは必ずプロパティとバリューのペ アで用いられ、nameやhttp-equivアトリビュートでプロパティを指定し、conten tアトリビュートでバリューを指定します。 meteエレメントのアトリビュートは次のものがあります。 ・name プロパティ名を識別するものとなります。name="keywords"でそのWebサイトに 含まれるキーワードを表したり、name="description"でWebサイトの簡単な説明を 表したりできます。 ・contet プロパティのバリューとなり、プロパティに設定される値を指定します。 ・scheme プロパティのバリューを翻訳するために利用するスキームの名前を指定します。 メタ情報の翻訳上の文脈をより多くユーザエージェントに提供します。例えば日 付データに「10-12-05」というフォーマットで情報を設定した場合、これは「20 05年10月12日」を表すものなのか「2010年12月5日」を表すのか不鮮明です。そこ でscheme="Month-Day-Year"を指定することで「2005年10月12日」を表すものだと いうことをユーザエージェントに明示することができます。 次の例はcontentがISBNだということをschemeを使って明示した例です。 ----- ----- schemeアトリビュートのバリューはnameで指定されたプロパティやprofileでプ ロパティに関連付けられた意味に依存します。 ・http-equiv nameアトリビュートの代わりに用いられます。HTTPサーバーはHTTPレスポンス のメッセージヘッダーの情報源としてこのアトリビュートを参照します。例えば 次のようなメタ情報をご覧ください。 ----- ----- このメタ情報の場合、HTTPレスポンスのメッセージヘッダー中のエンティティ ヘッダーに「Content-Type: text/html: charset=SHIFT_JIS」というヘッダーが 付加されることになります。HTTPのヘッダーについてはRFCなどを参照してくださ い。 metaエレメントは開始タグは必須で、終了タグを書くことは禁止されています。 ●本文 本文はHTMLではbodyタグによって分けられます（〜の部分）。本 文にはそのHTML文書の本文を記述します。前述の例ではこれは私のはじめての Webサイトです。
の部分が本文ということになります。このHTML文書は「これ は私のはじめてのWebサイトです。」という内容が段落を表すpエレメントでマー クアップされており、ひとつの段落からなる文書であることがわかります。body エレメントも厳密に言えば省略は可能ですが、省略するべきではありません。 ■0x06.) エレメント エレメントはタグがどのような意味を持つものかを定義します。エレメントは ブロックレベルエレメントとインライン（テキストレベル）エレメントに大別さ れます。 ●ブロックレベルとインライン 通常ブロックレベルエレメントのコンテントはインラインエレメントと他のブ ロックレベルエレメントになります。また、通常インラインエレメントのコンテ ントはデータか他のインラインエレメントのみになります。これはブロックレベ ルエレメントはインラインエレメントよりも「大きな」構造を創り出すという構 造上の特徴によるものです。例えば、段落を表すpエレメントはブロックレベルエ レメントで、強調を表すemエレメントはインラインエレメントですので次のよう な記述は文法エラーとなります。 -----強調です
----- ブロックレベルエレメントはインラインエレメントと比べて特異性があります。 通常ブロックレベルエレメントは独立した行に配置されます。インラインエレメ ントは通常その前後で改行されたりせず、その続きに他のデータが続きます。 ブロックレベルエレメントは見出しや段落などの他のデータと独立させる必要 性のあるものであり、インラインエレメントは強調やリンクなどの文章中の装飾 のようなものです。次の例を見て見ましょう。 -----ようこそいらっしゃいました。これは私のはじめてのWEBサイトです。 まず始めにこのサイトについてをお読みください。
----- h1エレメントは最も重要な見出しを表すブロックレベルエレメントで、emエレ メントとリンクを表すaエレメントはインラインエレメントです。h1エレメントは ブロックレベルエレメントですので独立した行に配置され、pエレメントもブロッ クレベルエレメントですので複数行にまたがりますが独立した行に配置されます。 一方emエレメントやaエレメントなどはインラインエレメントですので前後で改行 などは行われません。 ●汎用エレメント HTMLでは汎用エレメントはdivとspanがあります。divはブロックレベルエレメ ントの汎用エレメントで、spanはインラインエレメントの汎用エレメントです。 ちなみにdivはDivisionの略で、区切りのことです。 汎用エレメントとは特に意味を持たないエレメントです。これまで出てきたエ レメントはタイトルや強調を表すエレメントなど、なんらかの意味を持っていま した。しかし汎用エレメントはそういった意味を持ちません。では汎用エレメン トは何のために存在しているのでしょうか。 これらの汎用エレメントは後述するidアトリビュートやclassアトリビュートを 一緒に用いることで意味をなします。例えばHTMLには「電話番号」を表すエレメ ントは存在しませんが、spanエレメントにclass(id)を設定することで「電話番号」 を表すことができます。また、同じように「警告」を表すようなエレメントは存 在しません（強調を表すエレメントは存在します）が、divエレメントを用いるこ とで「警告」を表すことができます。次の例をご覧ください。 -----電話番号：0120-00-0000
ケヴィン=ミトニックはエフ・ビー・アイをクラックして end up in prisonになった。
----- 少々むちゃのある例でしたが、このように日本語として指定したの段落の中に 英語が入ってくるような場合に「end up in prison」の部分が英語であることを 明示するのにspanエレメントを用いて言語指定をすることができます。 divエレメントは開始タグ、終了タグともに必須で、コンテントはブロックレベ ルエレメントとインラインになります。spanエレメントも開始タグ、終了タグと もに必須で、コンテントはインラインです。 ■0x07.) アトリビュート アトリビュートとは前述のように属性と訳せ、のlang="ja"の ような部分です。そのエレメントの付加情報のようなものです。エレメントによ って書くことのできるアトリビュートは決まっており、エレメントによっては必 ず書かなければならないアトリビュートもあります。これらはDTDに明記されてい ます。 アトリビュートの中には、ほぼすべてのエレメントに書くことができる共通ア トリビュートと呼ばれるものも存在しています。 lang、dir、style、title、id、classアトリビュートなどは非常に多くのエレ メントに共通して指定することができるため、共通アトリビュートと呼ばれてい ます。共通アトリビュートの種類はインターナショナリゼーション、コアアトリ ビュート、イベントアトリビュートの3種類に分かれます。 ●インターナショナリゼーション インターナショナリゼーションは国際化のことで、internationalizationと綴 ります。あまりに長いのでi18n（iとnの間に18文字あるという意味）と省略され ます。HTML4ではRFC2070を統合してHTMLを国際化しているため、これらのアトリ ビュートを指定することができます。i18nのアトリビュートにはlangとdirがあり ます。 ○lang langアトリビュートはlang="ja"のように言語コードをバリューにとり、エレメ ントのコンテントがどういった言語で書かれたものなのかということをユーザー エージェントに伝えます。もしエレメントにlangが指定されていない場合は親要 素から言語情報を継承します。 ○dir dirアトリビュートはltrかrtlをバリューとしてとり、文字が左から始まる（l tr）のか、右から始まる（rtl）のかをユーザーエージェントに伝えます。西洋諸 国語や日本語などは文字は左から始まりますが、アラビア語などは右から書きま すので、日本語の段落の中にアラビア語を含める場合などに指定することになり ます。 ●コアアトリビュート id、class、style、titleがコアアトリビュートに含まれます。これらはHTML4 ではほとんどすべてのエレメントに指定することができます。 ○id エレメントに固有のIDをつけます。スタイルシートやスクリプトの対象になっ たり、リンクのアンカーになったりします。IDはひとつの文書中に重複してつけ ることはできません。idのバリューにはアルファベットから始まり、それに続く 数字、"-"、"_"、":"、"."が指定できます。これらは大文字小文字で識別されま す。 ○class エレメントにクラス名をつけます。主にスタイルシートの対象として用いられ ることがほとんどです。文書中に何度でも出現可能であり、ひとつのエレメント にスペースで区切って複数のクラス名をつけることも可能です。classのバリュー にはHTML2.xでは英数字と "."、"-"のみが使えましたが、HTML4では制限がなくな っています。 ○style スタイルシートを直接エレメントに指定するためのアトリビュートです。詳し くはCSSの説明で述べますが、カスケーディングの最下層になります。CSSの利点 を崩すことになりかねないので、できる限りこのアトリビュートは使わないほう がいいでしょう。ちなみにこのアトリビュートを使うときはヘッド部分でを指定する必要がありま す。 ○title エレメントにタイトルをつけます。タイトルは読み上げられたり、カーソルを 持っていったときに表示されたりすることが予想されます。わかりにくいエレメ ントには積極的に利用して細く情報を付けるようにしましょう。 ●イベントアトリビュート スクリプトなどを使った動的なWebサイトを作る際に、イベントアトリビュート にある事象が発生したときにイベントアトリビュートのバリューのスクリプトが 実行されます。 著者であるDefolsoがスクリプトは所詮プラグインであるなどの理由からスクリ プトの使用に否定的であるため、動的なWEBサイトについてはここでは言及しませ ん。ですので今回は省略させていただきます。 ■0x08.) 非推奨と廃止 HTMLにはバージョンがあり、バージョンによって使うことができるエレメント やアトリビュート、それらを配置してよい場所などが異なります。前のバージョ ンで採用されていたのに新しいバージョンでは採用されなかったエレメントやア トリビュートは廃止されたことになり、今後の新しいバージョンでも出現するこ とは基本的になくなります。 一方、非推奨は今後廃止される可能性があり、使うべきではないとされるもの です。非推奨となるにはいくつかの条件があります。 1：物理的に見栄えを指定するだけの要素や属性である 2：スタイルシートで代用可能である これらの条件に合致するものは非推奨となりますが、W3Cの仕様書では後方互換 のためにブラウザベンダは非推奨となったエレメントやアトリビュートにも対応 するべきだと言及されています。それゆえにブラウザでは非推奨のエレメントな ども表示できたりしますが、将来廃止されたとき書き直す手間が増えたり、グラ フィカルなブラウザにしか情報が伝わらなかったりと不利益しか得ることができ ません。出来る限り非推奨となったものは使わないようにしましょう。 例として非推奨の代表格、fontエレメントを例にとって解説しましょう。font エレメントはネットスケープブラウザが独自拡張したエレメントでしたが、HTML 3.2で正式採用され、HTML4.0で非推奨となりました。などの ようにアトリビュートを指定することで文字の色を変えたり、の ように文字の大きさを変えたりすることができます。一見便利そうに見えますが、 このエレメントには多くの弊害があります。 fontエレメントはそれ自体が論理的な意味を持たないエレメントです。次のソ ースをご覧ください。 -----ポートスキャンは不正アクセス予備行為 となることがあります。
----- 上記のソースをグラフィカルブラウザ以外でアクセスした場合、赤い色という だけの情報では強調を表しているのか引用なのか気まぐれで赤くしたのか判断で きなくなってしまいます。もし仮にこれが強調したいために赤くしたのだとすれ ば、次のように書くことでグラフィカルブラウザ以外でも情報が伝わります。 -----ポートスキャンは不正アクセス予備行為 となることがあります。
----- 上記の例はfontエレメントで色を指定した場合と同じように表示されますが、 グラフィカルブラウザ以外でアクセスした場合でもブラウザが強調を表している ことを読み取り、強調だと分かるように、大きな声で読み上げたり文字を括弧で くくったり、しかるべき出力を行ってくれます。 非推奨とされるものはこのようにスタイルシートで代用が可能です。出来る限 り論理要素＋スタイルシートでマークアップするようにしましょう。 このレポートの次の章では実際のソースを例としてエレメントやアトリビュー トの使い方を解説していきますが、非推奨となったエレメントやアトリビュート は紹介しません。これは非推奨となったものを知らなくても正当なHTMLを記述す ることができるからです。本来、非推奨のものも知っておくことは大切ですが紙 面の都合上、愛割とさせていただきます。 ■0x09.) 実際のコーディング それでは実際のソースコードを元にエレメントやアトリビュートなどの解説を 行っていきましょう。次のサンプルは「ハッキングラボラトリ」のWebサイトです。 html、head、meta、title、body、div、spanエレメントと共通アトリビュートは すでに解説済みなため省略します。 ●index.html -----ようこそいらっしゃいました。これは私のはじめてのWEBサイトです。 まず始めにこのサイトについてをお読みください。
----- ○h1, h2, h3, h4, h5, h6 (Headings level 1-6) 見出しとそのレベルを表します。h1が最も重要な見出しで数字が下がるにした がって重要さが低い見出しになります。決して文字の大きさを表すエレメントで はありません。 ブロックレベルエレメントで開始タグ、終了タグともに必須です。コンテント はインラインのみです。 ○hr (Horizontal Rule) 水平線を配置します。水平線はどういった目的で引かれているかわかりにくい ため、titleアトリビュートで補足することが勧められます。 ブロックレベルエレメントで開始タグは必須、終了タグを書くことは禁止され ています。 ○ul (Unordered List) 順不同のリストを定義します。順序つきリストを定義する場合はolエレメント を使います。ulはリスト定義だけですので、項目は別に定義する必要があります。 項目を定義するにはliを使います。 ブロックレベルエレメントで開始タグ、終了タグともに必須です。コンテント はひとつ以上のliエレメントだけです。最低でもひとつliエレメントが必要なた め、ulエレメントだけが出現することもできません。 ○li (List Item) リスト項目を表します。単体で用いることはできず、ul、olエレメントのコン テントとしてのみ現れます。 ブロックレベルエレメントで開始タグは必須、終了タグは省略可能ですが省略 するべきではないでしょう。コンテントはブロックレベルとインラインです。 ○a (Anchor) ハイパーテキストの最大の特徴であるリンクを実現するエレメントで、アンカ ーを表します。よく利用されるアトリビュートには次のようなものがあります。 ・href リンク先のURIを指定します。 ・name リンク元となるアンカー名を指定します。idアトリビュートも同じように使用 することができます。 ・hreflang リンク先の言語を明示します。 ・type リンク先のMIMEタイプを明示します。リンクはHTML文書だけに限らず、画像や 動画などにも設定できるため、MIMEタイプを明示するアトリビュートがあります。 ・charset リンク先の文字セットを明示します。 ・rel この文書から見たリンク先の文書の関係を指定します。例えばシリーズになっ ているなら、ひとつ前の文書などです。 ・rev リンク先の文書から見たこの文書の関係を指定します。例えば例えばシリーズ になっているなら、ひとつ先の文書などです。 ・tabindex タブを押したときのリンクがフォーカスされる順番を指定します。1から数字が 小さい順にフォーカスされます。詳細はいずれ、アクセシビリティについてで解 説します。 ・accesskey リンクに[アクセスキー]＋[英字１文字]でリンクをクリックした時と同じよう にアクセスすることができるショートカットを指定します。詳細はいずれ、アク セシビリティについてで解説します。 リンクはWWWの基本概念として勝手にどこにでもはるものなので、決して「リン クは勝手にはらないでください」などと書かないでください。WWWの考案者である Tim Berners-Leeは「Links and Law: Myths」の中で、「リンクは著作権を侵すも のではなく、事前報告は必要ない」、「リンクになんらかの支払いを求めてはな らない」、「リンクは他人のプライバシーを侵害することはない」と結論付けて います。詳しくはLinks and Law: Myths（http://www.w3.org/DesignIssues/Lin kMyths.html）を参照してください。 インラインエレメントで開始タグ、終了タグともに必須です。コンテントはaエ レメントを除くインラインです。 ○p (Paragraph) 段落を表します。pエレメントで囲んだコンテントがひとつの段落になります。 コンテントはインラインのみなので、このサイトはHTMLの解説用に作られたサイトです。主にハッキング技術とゴミプログラムのソースを公開しています。
リンクはWWWの発案者
Tim Berners-Leeの主張に従って、どこでもご自由にどうぞ。
報告も必要ありません。
バナーは次のものを用意しております。
挨拶します。char型のstring配列に文字列を格納し
#include <stdio.h>
int main()
{
char string[] = 'Hello, hackers!!';
printf ("%s", string);
return 0;
}
このプログラムは次のように実行します。
$ ./hello.exe
実行結果は次のようになります。
Hello, hackers!!
標準入出力関数のひとつ。stdio.hをインクルードしておく必要がある。
参考文献:http://ruffnex.oc.to/defolos/test.html
----- ○<、> これは文字参照のうちの文字実体参照です。特殊な文字はそのままではソース 中に書くことができないので、このような文字参照を利用します。文字参照はユ ーザーエージェントで表示されるときには文字参照が指し示す文字に置き換えら れています。この例ではそれぞれ<と>に置き換えられます。文字参照には数値文 字参照と呼ばれる&文字番号;のように文字番号で指定する方法と文字実体参照と 呼ばれる&文字実体;のように文字実体で指定する方法の2通りあります。アルファ ベットの「a」を指定する場合、文字番号で指定するとåのように何を表して いるか一見わかりませんが、文字実体で指定するとåのようにわかりやすく なります。 詳細はW3Cの24 Character entity references in HTML 4（http://www.w3.org /TR/html4/sgml/entities.html）を参照してください。 ○dnf (Defining Term) 他の場所で定義されている用語であることを表します。注釈などに用いものだ と思っています。 インラインエレメントで開始タグ、終了タグともに必須です。コンテントはイ ンラインのみです。 ○pre (Preformatted Text) 整形済みのテキストであることを表し、改行やスペースをそのまま表示します。 preの中でもマークアップは有効なため、次のようにマークアップすることができ ます。 -----クラッカーはハッカーと違い、破壊活動や 非生産的なことに技術を使う。----- また、トークンをワンタイムのものとするため、処理2においてCookieのトーク ンをダミー値に置き換える。 CSSXSS脆弱性はレスポンス1に含まれるクッキーの値を取得できないので、この ようにすることでリクエスト1でGETを使用できることになる。 英語で書かれたウェブサイトや文献ではCSRF対策の基本としてワンタイムトー クン方式がまっさきに挙げられていることが多いが、CSSXSS脆弱性の存在までを 考慮したものは現時点（2006年3月）では見あたらなかった。 ■0x08.) 正しい対策その2: パスワードの再入力を求める方法 この方法はアプリケーションがユーザIDやパスワードを用いたいわゆる「ログ イン」機能を持つ場合のみ使用できる。 ワンタイムトークンを使用する場合と異なり、レスポンス1にはトークンのよう な秘密情報が含まれない。そのため、この方法はCSSXSS脆弱性の影響を受けない。 また、レスポンス1がキャッシュに残っても問題が生じない。そのため、リクエス ト1はGETでもPOSTでもよい。 処理1は何も行わない。 ユーザは画面1においてパスワードを入力する。そしてパスワードを含むリクエ スト2が送信される。画面2の中のリンクなどからリファラーを通じてパスワード が漏洩してはまずいので、このリクエスト2はPOSTでなければならない。 処理2において、サーバー側プログラムは送信されてきたパスワードが正しいか どうかをサーバー側のデータベースなどの情報を用いて照合する。パスワードが 間違っていればエラーとして扱い、処理を停止する。 以上でパスワード再入力によるCSRF対策の処理が完了する。続いて「日記を書 き込む」などの、アプリケーション本来の機能を実行する。 以上が正しい対策その2である。 ■0x09.) 正しい対策その3: CAPTCHAを正しく使用する方法 CAPTCHAはトークンの一種である。トークンがhiddenフィールドに格納された文 字列ではなく、画像データとしてクライアントへ送られるという点が上で説明し たワンタイムトークン方式との違いだ。CAPTCHAは本来、HTTPクライアントを操作 しているのが人間なのか、あるいは自動化されたプログラムなのかを判別するた めに使われる技術であり、CSRF対策とは無関係だ。ただ、CAPTCHAはトークンの一 種であるので、正しくワンタイムトークンとして使われれば、結果としてCSRF攻 撃を防ぐことができる。 CAPTCHAを使用する方法はつまりはワンタイムトークン方式である。そのため、 上記で説明したhiddenフィールドを使ったワンタイムトークン方式に比べ、CSRF 対策としての利点はない。また、ユーザビリティや実装の複雑さで劣るため、進 んでCAPTCHA方式を採用する理由は存在しない。それがワンタイムトークンである ことを知らずに「CSRF対策にはCAPTCHAを使おう。画像だから安全だ。」と考える のは明らかに誤りなのである。 それでもCAPTCHA方式を採用する場合には、それが正しくワンタイムトークンと して動作するよう、次のように実装する必要がある。 レスポンス1にはトークンのような秘密情報が含まれない。そのため、リクエス ト1はGETでもPOSTでもよい。 レスポンス1にはCAPTCHA画像へのリンクが含まれる。そのため、自動的にCAPT CHA画像へのHTTPリクエストが発生する。このリクエストをリクエスト1.5とする。 リクエスト1.5はPOSTでなければならない。理由はワンタイムトークン方式と同 様、CSSXSS対策と、キャッシュ対策を兼ねる。リクエスト1.5は仕組み上最初にG ETで送られるので、再度POSTを用いてリクエストをしなおすような内容のレスポ ンスを返す必要がある。 CAPTCHA画像を含むレスポンス（レスポンス1.5とする）はキャッシュされない よう適切なヘッダーフィールドを持つ必要がある。 CAPTCHA画像に含まれるトークンはセッションと結びつけた形でサーバー側で保 存しておく。 ワンタイムトークン方式と同様、リクエスト2はGETでもPOSTでもよい。 処理2はワンタイムトークン方式と同じように行う。 以上が正しい対策その3である。これはCSRF対策として正しく機能するが、先述 の理由により推奨しない。 ■0x0A.) Basic認証の場合 Basic認証を用いて「ログイン」機能を提供しているアプリケーションでも、必 要なCSRF対策は変わらない。Cookieを使ったセッション管理を行い、上で説明し た対策のうちのひとつを正しく実装することでCSRF対策を行うことができる。 ■0x0B.) リファラーについて リクエスト2のリファラーをチェックすることでCSRF対策が行えるのではないか、 とする説明が存在する。しかしこのリファラー方式は、正規ユーザのウェブブラ ウザがきちんとリファラーを送ってくる場合のみ機能する。アンチウイルスソフ トウェアやユーザ自身の意向によりリファラーを送出しない設定で使用されてい るブラウザも多く存在するため、この方式は現実的には機能しないケースが多い。 利用者が限定されており、その全員にブラウザをリファラーを送るような設定で 使用するように求めることができるケースでは、リファラー方式はCSRF対策とし て正しく機能する。 リファラー方式を採用する場合には次のように実装する。 処理2においてリクエスト2のリファラーを調べ、それが外部サイトのものであ ればエラーとして処理する。また、リファラーが存在しない場合も同様にエラー として処理する。 また、リファラーを調べることにより、攻撃者がCSRF攻撃のために仕掛けた罠 ページを発見できる可能性がある。そのため、実際にCSRF攻撃が行われているの かどうかを把握したい場合には、リクエスト2のリファラーを（外部サイトからの ものに限り）記録しておくとよい。 ■0x0C.) SSLについて SSLの使用はCSRF対策には基本的には関係がない。しかしHTTPSの通信はキャッ シュされない、また盗聴されにくくなるなどの利点もあるため、可能な場合には 上記で挙げたCSRF対策と合わせて利用するのがよい。 ■0x0D.) 採用すべきでないCSRF対策 ここからは筆者がウェブサイトや書籍で見つけた、採用すべきでないCSRF対策 について説明する。これらの対策は意味がなかったり、かえってシステムを危険 な状態にしてしまうので、実施してはいけない。 ■0x0E.) 採用すべきでない対策その1: セッションIDをトークンとして使う 2006年3月の時点で、国内の多くのウェブサイトや書籍などで紹介されている方 法である。 この方法は「ブラウザに脆弱性がない」ことを前提として考案されたものであ る。しかし現実にはIEにCSSXSS脆弱性という「Cookieにはアクセスできないが、 hiddenフィールドの値にはアクセスできる」バグが存在している。そのためこの 方法を採用したウェブサイトは、リクエスト1でGETを使える場合、CSSXSS脆弱性 を悪用することによりセッションIDが盗まれ、結果としてセッションハイジャッ クされてしまう可能性がでてくる。セッションハイジャックは明らかにCSRFより も深刻なセキュリティ上の脅威である。つまりこの方法を採用することは、ウェ ブサイトを（対策を行わない状態に比べて）危険な状態にさらしてしまうことに なるのだ。CSRF対策をしたつもりが結果としてセッションハイジャック可能なセ キュリティホールを作り込むことになってしまうという、なんともやりきれない 状態となる。そのため、この対策は採用してはならない。 仮にウェブブラウザの脆弱性が存在しなければ、この方法はCSRF対策として機 能するかもしれない。しかしその場合でも、リファラからセッションIDが漏洩し ないようにするため、リクエスト2は必ずPOSTである必要がある。この方式を紹介 しているウェブサイトや書籍ではこのことが明記されていない場合が多い。 また、「わざわざ機密情報である（Cookieの）セッションIDをhiddenフィール ドに格納する意味があるのか？ ハッシュ値などでよいのでは？」と思う感性は エンジニアにとって大事だと考える。この方式においてセッションIDそのものが トークンとして使用されているのは処理2においてセッションとトークンの結びつ きを確認するのが簡単であるというだけの理由しか持たない。わずか数行のコー ドを省略するために危険をおかす意味はない。 この方式は日本語圏独自のものであり、英語圏ではこの方式をCSRF対策として いる記述は見つからなかった。 セッションIDそのものをトークンとして使うことには利点がないばかりか危険 （CSSXSS脆弱性で現実になったように、何かのきっかけでセッションハイジャッ クに繋がるおそれがある）なので、この方式は採用してはならない。 ■0x0F.) 採用すべきでない対策その2: 誤ったワンタイムトークン方式 ワンタイムトークン方式では、トークンは必ずセッションと結びつけて扱う必 要がある。そうでない場合、攻撃者自らが画面1にアクセスして取得したトークン を罠のページに埋め込む「トークン固定攻撃」が可能となってしまうためだ。そ のため、このような実装をしてしまうとCSRF対策にならない。誤ったワンタイム トークン方式とは、このような「セッションとトークンの結びつき」を持たない 方式を指す。 ■0x10.) 採用すべきでない対策その3: リクエスト2をPOSTにする IMGタグなどを利用したCSRF攻撃の例を見ると、「ではリクエスト2がPOSTで送 られるようにすればよい」と考えてしまいがちだが、 JavaScriptを利用すること で攻撃者は罠のページからPOSTリクエストを送らせることができるので、この方 法は対策にならない。具体的には次のようなコードが使われる。 ----- ----- ■0x11.) 採用すべきでない対策その4: 確認画面を挟む 確認画面を挟む方法には2通りの実装が考えられる。ひとつは確認画面がhidde n属性で全ての（確認画面に対してsubmitされた）フォームの値を持ち、3画面目 （実行画面、あるいは決定画面）にジャンプする際に再度それをsubmitするとい うもの。もうひとつは確認画面を表示する時点でサーバー側のセッションオブジ ェクトなどにフォームの値を保存しておき、3画面目を処理する際にそれを取り出 してデータベースなどを更新するものである。 1つめの方法は罠のページから直接3画面目にCSRF攻撃を行うことで回避されて しまうので、対策にはならない。 2つめの方法は罠のページをフレームなどで分割し、それぞれに読み込まれる別 の罠のページから確認画面と3画面目へのCSRF攻撃を（必要があれば時間差をおい て）それぞれ行うことで回避されてしまうので、これも対策にならない。 それでは、元々の作りとして確認画面を含んだ3画面によって構成されるアプリ ケーションでは、どのようにCSRF対策を行えばよいのだろうか。これは先述の通 り、ひとつの機能は2画面で構成されるという原則に沿って考えるとよい。1画面 目と2画面目（確認画面）によって「ユーザが入力した内容を表示する」というひ とつの機能が実現されている。さらに2画面目と3画面目で「ユーザが入力した内 容をデータベースに登録する」のような別の機能が実現されている。つまり、こ こではひとつではなく、2つの機能が連続して実行されているのだ。 従って、CSRF対策の基本であるワンタイムトークン方式を、それぞれの機能に ついて適用すればよい。 まずひとつめの機能に対するCSRF対策として、1画面目でワンタイムトークンを 発行し、2画面目を表示する際の処理でこのトークンが正しいかどうか確認する。 これによって、ひとつめの機能に対するCSRF対策が実現する。そしてこの2画面目 を生成する処理の際にさらに異なるワンタイムトークンを発行し、 3画面目でこ の2つめのトークンが正しく送られてくることを確認する。これによって2つめの 機能に対するCSRF対策が実現し、結果としてこの3画面によって実現される（ひと つに見えるが実は2つからなる）機能全体のCSRF対策が実現されることになる。 ■0x12.) 採用すべきでない対策その5: セッションIDを細かく変更する 処理1でセッションIDを切り替え、このセッションIDを持たない場合には処理2 を行わないようにする、という方式である。「確認画面を挟む」方式と同様に、 罠のページをフレームなどで分割し、画面1と画面2に連続してCSRF攻撃を行うこ とで回避されてしまうので、この方式は対策にならない。 ■0x13.) CSRF用メーリングリスト 筆者が本稿を書いた目的は、本当に正しいCSRF対策とは何なのかという疑問の 答えを得ることである。また、CSRFにまつわる情報の混乱を解決したいという思 いもある。現時点では本稿に記した対策方法が正しいものであると考えているが、 誤っている可能性ももちろんある。内容に誤りがあれば、その都度修正していき たい。修正する場合、本稿は新しい文章として書き換えてしまい、古いものは古 いバージョンとして別名で保存し残していく形をとるつもりだ。 本稿の内容についての意見や指摘などは大歓迎である。CSRFを中心にウェブア プリケーションセキュリティについて話し合うための場所として、メーリングリ ストを作成した。本稿に対するレスポンスがある場合にはこのメーリングリスト を使用して頂ければありがたい。CSRFに関しては広くアンテナを張っているつも りなので、ブログなどで言及してもらった場合にも反応するつもりだ。 Sea Surfers ML MLへの参加はこちらから: http://www.freeml.com/ctrl/html/JoinForm/seasurfers@freeml.com/ MLのトップページ http://www.freeml.com/ctrl/html/MLInfoForm/seasurfers@freeml.com また、本稿で取り上げていない、ウェブサイトや書籍の中の細かい気になる点 についても、このメーリングリストの中で触れたいと考えている。 ■0x14.) 関連リンク おさかなラボ http://kaede.to/~canada/doc/ PHPサイバーテロの技法（書籍） http://www.amazon.co.jp/exec/obidos/ASIN/4883374718/ PEAK XOOPS Support&Experiment http://www.peak.ne.jp/xoops/md/news/ 俺専用mxxi :: ぼくはまちちゃん！ http://mxxi.hamachiya.com/ hoshikuzu | star_dust の書斎 http://d.hatena.ne.jp/hoshikuzu/ 児童小銃 .456 http://d.hatena.ne.jp/rna/ INNOCENT CODE（書籍） http://www.amazon.co.jp/exec/obidos/ASIN/0470857447/ 2006年4月4日 Version 1.2 HTML版URL: http://www.jumperz.net/texts/csrf.htm x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x --- 第7章：お知らせ --- x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x ○Wizard Bible（http://akademeia.info/wizardbible/）では随時、執筆ライタ ーを募集しています。 扱う内容のテーマは広義での「under ground」です。例えば、ハッキングから サリンガスの合成法などと幅広い内容を考えています。また、各種、特殊な職業 や趣味を持った方のレクチャーなども含まれます。 一回きりでも構いません。また、必ず、毎回連載する義務もありませんのでで きる範囲で構いません。気軽に声をかけてください。もちろん一回書いたことが ある人も気軽に声をかけてください（全く気にしていない性格なので）。 ○Kenji AikoさんがQ&Aを作ってくれました。初めて参加する人でもわかりやすく 書かれていますので、参考にしてください。 http://akademeia.info/wizardbible/wbQandA.html ○支援者、参加希望者用のスレッドを立てました。 http://ruffnex.oc.to/ipusiron/cgi/forum/patio.cgi?mode=view&no=17 x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x ---- 第8章：著者プロフィール --- x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x ■copyman ●Job:Student ●Web:N/A ●Mail:copyman@hotmail.co.jp ●Team（Group):N/A ●Comment: どうも、今回初参加させてもらったcopymanです。 名前はKaz99さんの日記からパクリました、ただのファンです、あしからず。 今回ピッキングツール作成方法について書かせてもらいましたが、実はピッキ ングに関しては素人です。これからは今回作ったピッキングツールを使って、ピ ッキングの腕を上げていこうと思います。 ●PC以外の趣味: パチスロです。1年前から始めたんですが、毎日パチスロに行ってました。とい うのも一時期プロを目指して、必死にパチスロの勉強をして、毎日データを取り に行ってました。今は暇な時や、新しい台が出たときにチョロっと打つ程度です。 最近ハマってる台は「パワーボム」です。昔あった台のリニューアル版だそう ですが、昔の台を知らなくても楽しめます。なんといってもボーナス中のBGMがた まりません。久々に打ってて楽しい台です。 ■Forging ●Job:インチキ機械設計屋 ●Web:村の鍛冶屋（http://www.geocities.jp/kajiya_forging/） ●Mail:kajiya_forging@yahoo.co.jp ●Team（Group）:N/A ●PC以外の趣味: オートバイです。週末の度に警察主催の講習会に通い、講習会ヲタと化していま す。でも免許は中型限定(いわゆる限付免許)。早く大型に乗りたい! オフロード車に乗っているのですが、オフロードはすっかりご無沙汰になって しまい、挙句のはてにタイヤまでオンロード用にしてしまいました。 ■Narusase ●Job: Student ●Web: (裏)雑学の博物館（http://k-o-m.hp.infoseek.co.jp/） ●Mail: narusase@mcn.ne.jp ●Team（Group): N/A ●Comment: こんにちわ、Narusase（ナルサス）です。今回でhoneydの基本的な機能に関し ては説明が終了しました。ここから先のことですが、現在、かなり忙しい状況で 今後の予定がどうなるか予測すらできない状況です。場合によっては連載の中断 も考えなければならない状況になるかも知れません。私も可能な限り頑張ってい きますが、そうなった際は申し訳ありません。今後、連載が可能であれば、当初 の予定通りほかのソフトの話をするか実際の運用の話にシフトしていくかと思い ます。 サイトの方はまあ、ヘタレな文章と、未熟な技術、ヘボいプログラムを紹介す るサイトということで、暇があったらあら探しでもしてみてください。誤植とか ミスとかはBBSにでも書いてくだされば、こっそり修正しときます（笑 ●PC以外の趣味: PC以外の趣味と言われるとまず思いつくのは読書です。これはかれこれ15年ぐ らい続いてる趣味なのでおそらく一生の趣味と言えるのではないかと…。なぜか 私の周りにはIPSIRONさんを初めとして読書家な人が多くいますのでその人たちと 比べると（漫画等を含めた）蔵書数はそう多いほうではありませんがそれでも1, 600冊前後の蔵書があります。 まあ、私の周りの人間はみんなPCは2〜3台はもってて普通とか、本は本棚に入 りき らないのが基本とか言う人がいっぱいです。 そんな訳で世間一般で言う一般人の方と比較すると蔵書数は多い部類なのでし ょうけど、とてもとても周りの連中には勝てないっす…(汗。 ■Defolos ●Job:Student ●Web:http://ruffnex.oc.to/defolos/ ●Mail:defolos@ruffnex.oc.to ●Team（Group）:none ●Comment: こんにちは、Defolosです。 最近、Wizard Bibleに書く記事の分野がバラバラになってきているように感じ ます。そのうち自分の「専門分野」がなくなってしまいそうで恐いです。(^^;) 話は変わって、先日ノートPCのOSをDebianにしました。本格的にデスクトップ 用にLinuxを使うのは初めてです。これからは、慣れないデスクトップLinux生活 を無理矢理エンジョイしていきたいと思います。 ●PC以外の趣味について: もともと、ものを作ることが好きだったからでしょうか、ナイフ作りやレザー クラフトなど、何かを作ることを趣味としています。 もし、何かがあったときには「自分自身でものを作れる」ということが重要に なってくると考えています。ですので、作り方の手順が明記されているものを作 る場合でも、できる限り、その原理を理解しようとしながら作ります。 なかなか時間がとれませんが、これからも積極的に趣味を続けていきます。 ■MaD（うんこはげまど） ●Job:DATA HOUSE ●Web:http://www.data-house.co.jp/ ●Mail:mad@data-house.co.jp ●Team（Group）:h@cksection,ruffnex ●PC以外の趣味: PCなんか趣味じゃないもーん。PCなんか壊してまえばええねん。ほかせ、ほか せ！ 脳みそ腐るだけやって。ほんだら、スーパーハカーの趣味を教えてたる！ いいか、よくきけ！ 寝ること。気持ちイイー！ じゃぁ、またね！ けーろよーん！ ■金床 ●Job: プログラマー ●Web: http://guardian.jumperz.net/、http://www.jumperz.net/ ●Mail: anvil@jumperz.net ●Comment: 今回の原稿はいつにもまして気合い入ってます。CSRFは奥が深い。ていうかマ ジで疲れた。久しぶりにメーリングリストなど立ち上げてみました。ウェブアプ リ系ハックネタに興味ある方の参加お待ちしてます。 ●PC以外の趣味: PC以外の趣味は音楽と映画と釣りです。音楽はThird Eye Blindとか。映画は バニラ・スカイとか12モンキーズとか。釣りは夏から秋の回遊魚をルアーで狙い ます。----- ブロックレベルエレメントで開始タグ、終了タグともに必須です。コンテント はインラインですが、imgやsub（上付き文字）などの整形済みという概念に反す るエレメントは書けません。また、コンテントにタブ文字を書くことは非推奨で す。 ○code (Computer Code) このエレメントはハッカーの方に是非活用してほしいエレメントです。コンピ ュータプログラムのソースコードを表すエレメントです。 インラインエレメントで開始タグ、終了タグともに必須です。コンテントはイ ンラインのみです。 ○var (Variable) プログラムの変数のように値が変わり得るものを表します。ソースの解説など で用います。 インラインエレメントで開始タグ、終了タグともに必須です。コンテントはイ ンラインのみです。 ○kbd (Keyboard) キーボードからの入力を表します。ソフトの使い方解説などでユーザが入力す る部分に使います。 インラインエレメントで開始タグ、終了タグともに必須です。コンテントはイ ンラインのみです。 ○samp (Sample) プログラムなどの出力サンプルを表します。コードのサンプルはcodeエレメン トを用います。これもコンピュータ技術の解説などではよく用いられるエレメン トです。 インラインエレメントで開始タグ、終了タグともに必須です。コンテントはイ ンラインのみです。 ○cite (Citation) 他の権文献からの引用や参考などの出典を表します。文献名やURIなどがコンテ ントになり、論文やレポートで用いるべきものでしょう。 インラインエレメントで開始タグ、終了タグともに必須です。コンテントはイ ンラインのみです。 ○blockquote (Long Quotation) 引用文を表します。句の引用を表す場合はqエレメントを使います。ブラウザの 中にはインデントで表示するものがありますが、インデント目的でこのエレメン トを使うと環境によっては「次の文章は引用です」と表示される可能性もありま す。また、コンテントはbodyエレメントと同じなので直接文章を書くことはでき ません。指定できるアトリビュートには次のようなものがあります。 ・cite 引用の出典を記載します。文献名やURIを記述することになります。 ブロックエレメントで開始タグ、終了タグともに必須です。コンテントはブロ ックレベルエレメントとSCRIPTです。 ●hack.html -----ハッキングラボラトリ - ハッキング技術 ハッキングラボラトリ ハッキング技術
----- ○dl (Definition List) 定義型のリストを定義します。定義型とは例のように、ある用語についての解 説などのように、用語と解説が交互に出てくるようなリストのことです。 ブロックレベルエレメントで開始タグ、終了タグともに必須です。コンテント はひとつ以上のdtあるいはddです。 ○dt (Definition Term) 定義型リストの用語の部分を表します。dlのコンテントとしてのみ出現します。 開始タグは必須、終了タグは省略可能ですが省略するべきではないでしょう。 コンテントはインラインのみです。 ○dd (Definition Description) 定義型リストの解説の部分を表します。dlのコンテントとしてのみ出現します。 開始タグは必須、終了タグは省略可能ですが省略するべきではないでしょう。 コンテントはブロックレベルエレメントとインラインです。 ○q (Quotation) 引用句を表します。グラフィカルなユーザエージェントではコンテントの言語 に応じた引用符で囲まれて表示されるはずです。例えば日本語の場合引用符は「 」です。また、二重に引用されることもあり、その場合も正しい引用符の関係で 囲まれることになります。 ・デカルトの言葉に「我思う故に我はあり」という言葉があります。 ・その文献で「カエサルはルビコン川を渡る前に『賽は投げられた』と言った」 という文章を見た。 仮に言語が英語であった場合は次のようになります。 ・Descartes said "Cogito Ergo Sum". ・I saw "Caesar said 'Iacta alea est' before he across The Rubicon" in the book. 指定できるアトリビュートは次のようなものがあります。 ・cite 引用の出典を記載します。文献名やURIを記述することになります。 インラインエレメントで開始タグ、終了タグともに必須です。コンテントはイ ンラインです。 ■0x0A.) 参考文献 ・「HTML 4.01 Specification」 http://www.w3.org/TR/html4/ ・「Some early ideas for HTML」 http://www.w3.org/MarkUp/historical ・「HTML鳩丸倶楽部」 http://www.ne.jp/asahi/minazuki/bakera/html/hatomaru ・「Project Xanadu」 http://xanadu.com/ ・「URIとファイルディレクトリ -- ごく簡単なHTMLの説明」 http://www.kanzaki.com/docs/html/htminfo-uri.html ・「大阪市立大学 インターネット講座 第12回デジタル技術時代のテクスト(3) ハイパーテクストとテクスト」 http://www.tufs.ac.jp/ts/personal/yamaguci/inet_lec/lec12/98med12.html ・「XaQ JP」 http://web.sfc.keio.ac.jp/~yukihiko/XaS/XaQjp.html ■0x0B.) さいごに 皆様、いかがでしたでしょうか。HTMLは学術的な歴史を持ち、仕様書が公開さ れているにもかかわらず不適切な内容の書籍が多く、正確な文法を知ることは難 しいです。学術的な歴史を重んじてHTML文書を作成するために、このレポートを 役立てていただけると幸いです。 今回はHTMLについて基本的なところを執筆しましたが、大体の場合ここで取り 上げた知識だけで正当なHTML文書を作成することができます。しかし、今回取り 上げた部分はHTMLの仕様書のごく一部ですので、詳しくはW3CのHTML Specificat ionを参照してください。次回は今回のレポートで触れることができなかった、よ り細かい技術やアクセシビリティについて執筆したいと思います。 それではまたお会いしましょう。 x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x --- 第5章: ハッカーの達人で吠える --- 著者：MaD（うんこはげまど） x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x ■0x01.) はじめに なんや、おまえら！ まどさんがスーパーハカーだって言ったら、スーパーハ カーなんだって！ 自分で言わんで誰が言ってくれるんじゃ！ お前ら全員！ きょうつけ！ 腕立て100回！ 腹筋100回！ わかったか！ このうんこはげ！ とりあえず、DoSアタックでPCを破壊してから能書きたれてくれや！ ……ということで、ここ最近、ご機嫌のいい、うんこはげまどさん。 いやぁ、久し振りの快挙だよ。というか、数名で喜んでいるだけなんだけどさ。 ハッカーの達人だよ、ハッカーの達人！ ヾ(*ΦωΦ)ノ ヒャッホゥ ・ハッカーになるための教室１推奨環境：WindowsXP →http://www1.bbiq.jp/hackersroom/ まぁ、とかく、自分の考えを実ハンで堂々と述べる自信がないハカーもどきが 大勢の中、達人の行動は目をひくだけのものはある。ちょっとアホで若いだけだ。 いいじゃん、それくらい。 要は“やるか、やらないか”。それだけなんだって。 アカデメイアにしてもそう。IPUSIROMさんには悪いけど、サイトのスタート時 点のレベルなんて大差ないって。いろいろなことを学び、それを継続できるかど うかは次の問題ということで。 ただ、なんぼ頑張ってもアカデメイアに追いつくのは無理そうなので、まどさ んはアンチIPUSIROMとなり、ハッカーの達人を生温かく応援して、ともに沈没し たいと思っている。ぷげら 若者よ！ 恥を怖れるな！ 前へ進め！ 表に出ろ！ そして継続せよ！ 腹 筋100回！ 今回は、昔のアングラなんかについて振り返りつつ『ハッカーになるための教 室１推奨環境：WindowsXP』で起こった面白いネタを紹介しる。 ■0x02.) アングラとハカー まず、アングラとハカーの歴史を振り返りながら伝説となった日本のアングラ ＆ハカーなサイトを簡単に紹介しとくね。最近、あまり語る人がいなくなったし で、いい機会かと。 今でこそ「アングラ」と「ハカー」はそれぞれカテゴライズされているが、当 時はまだ混沌としてた。 ・http://www.ugtop.com/ ・http://www.blackout.org/ ・http://www.infovlad.net/ まず、この3つだね。この3つのサイトのURLだけは今でもタイプできるくらいハ ッキリと記憶している。 ここらで活躍した人たちは、次のコミュニティで名前を挙げておいたので見て おいて。某ハカーの悪口ばかり書いているから非公開にしてるけど、誰でも参加 できるので。 ・mixi＞ハッカー＞好きなハカーとクラカー そして、こうした大御所サイトに対して、新しい方向性を目指したのが次。 ・http://www.backsection.net/ 元をただせば、やっぱり先に挙げた3大サイトにリスペクトして立ち上げられた ニュータイプのネットヤンキー集団。 現在は、どこのサイトも地味に再構成しているようなのでチェックしておいて。 あとは、Team404があったけど、ここはもうなくなっているからURLなし。 それ以降にできたサイトに関しては記憶に残っていないため割愛する。 そうした意味では、アカデメイアがコミュニティ再編成の担い手になって欲し いけど、まだまだ。 がんがれ！ IPUSIROM！！！（編注） 【編注】「M」は誤植ではありません。ハッカーの達人の教室に偽物のMが実際に 登場したことがネタになっているようです。 ■0x03.) ハッカーになるための教室１推奨環境：WindowsXP さて、忘れかけてた本題。 「アングラとハカー」をふったのには理由があって、その筋の人たちが初日の 授業から参戦となった。 今回のミッションの根底にあるものは、いうまでもない「大人のギスギス」で ある。決して、煽らず、いやらしい質問を浴びせて凹ませつつ、達人をリスペク トするという戦法だ。「氏ねボケうんこ」は、チリメンジャコでも言えるわけで、 それじゃ、アホ過ぎ。アングラにおける真の煽りはコレですよ、コレ。 ●授業一日目 ---------- 入室中：ＩPUSIRON IPUSIROM ぶーん ひろゆき＠２ｃｈ管理人 YUKA くも kn0wledge はる nad まひん mad 匿名 UNYUN ゴイック hal 右 ｍad Will ROMばいや〜2nd＠Team0721 ---------- なんか、やたら同じような名前（全角・半角の違い）があるけど気にしない。 元t404、Krackers、backsectionという感じ。ちなみに「UNYUN」というのは成り 済まし。本人ではないので念のため。 まぁ、セオリー通り、機嫌を損ねないようジワジワと絞めたという感じ。 だが、達人は上機嫌で授業を進めていた。なかなかの大物だ。これじゃないと ね。 詳細な内容は書かない。しんどいし。詳しくはコチラｗ →http://mixi.jp/view_diary.pl?id=107202087&owner_id=100281&full=1 ★MVP：t404 ●授業二日目 ---------- 入室中：k00L,ぶ〜ん＾＾,entry yar name,HAC DRUG,BEAMZ,RHS, ハッカーの達人◆rXO2VZp4eo,まふぃあ,☆ｋｉｒｂｙ☆,まひん,kaeru,黒豆, ととりん先輩,堀江縫合,トールバズ,hail,くも,アク,ignorance,栗 ---------- ちなみに「k00L」と「BEAMZ」は成り済まし。本人ではないので念のため。k00 Lが「BEAMZ」に化けて、MADが「k00L」に化けてということで、わけわかめ。 IPUSIROM氏と2人で会議を行い、達人そっちのけで「黒豆」で入ったIPUSIROM氏 が、ものすごい勢いで生徒の質問に答えていくというミッションを遂行すること となった。 ===== ハッカーの達人◆rXO2VZp4eo 黒豆さんはハッカーですかね？？もしかしたら私を超えてるかもしれないスーパ ーハッカーかもしれないですね ===== ===== ハッカーの達人◆rXO2VZp4eo 黒豆さんへ すごいじゃないですか 私なんて最初から自分で勉強しましたよ ===== IPUSIROMさんは、すでに『ハッカーの達人』のハンドルをパクって入室してい たため、達人からスパイと見なされアクセスできなくされていた。そのため、串 というハカーを使い入室していたから、レスポンスが若干悪かった。しかし、な んとかミッションは成功した。 この教室では「〜をハッキングする」とは言ってはならない。「〜をハッカー する」というのが基本となっている。 さて、この日は、すげー盛り上がりで名言バシバシという感じで、まさしくハ カーレイヴ！ では、その名言をいくつか紹介しておこう。 ===== Macはスニッフィングの達人でうらやましいです ===== ===== OSは作ったませんよ 買いました ===== 意味を理解していないのはいいけど、日本語もあやしいため意味不明な発言が グルーブを作りだしている。しかも、常に揺るぐことない自信のオーラが漂って いる。コレだよ、コレ！ 詳細な内容は書かない。しんどいし。詳しくはコチラｗ →http://mixi.jp/view_diary.pl?id=108213703&owner_id=100281&full=1 ★MVP：backsection ●授業三日目 なんと、PONさんまで登場。ケリ入れたり、パンチ入れたり、おまけで権限取っ たりしないかとヒヤヒヤ。 でも、とてもよい生徒で安心した。 この三日間で、もっとも名言が連発した授業だった。 ===== 別にどんなOSでもアンチウイルスさえあれば大丈夫です ===== ===== DELLはあまり攻撃対象ではないです（なかったと思います） ===== ===== WindowsXPは攻撃対象外です ===== ===== 世界でひとつだけのサイトです http://akademeia.info/main/tool/dos.htm ===== ===== ポートスキャナーはポートをハックするためのツールです ===== ===== 電話番号のようなものです（電話番号ではありません） ===== ===== rootはPCを操作できることができる権限です あなたのことです ===== まぁ、このレイヴに参加していない人には伝わりにくいと思うが、3分に1回は フキだすエンターティメントであったことは間違いない。 ただ、残念なのは、後半に荒らしがきたこと。 ===== hoshou2157 > しょうもないことばっかり教えやんといてくれますか？？ ===== だから、お前らには興味ないからRFCでも読んで、家でネトゲーでもしとけ！ 詳細な内容は書かない。しんどいし。詳しくはコチラｗ →http://mixi.jp/view_diary.pl?id=108710372&owner_id=100281&full=1 ★MVP：UGTOP x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x --- 第6章: 開発者のための正しいCSRF対策 --- 著者：金床 x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x ■0x01.) はじめに ウェブアプリケーション開発者の立場から見たCSRF対策について、さまざまな 情報が入り乱れている。筆者が2006年3月の時点において国内のウェブサイトやコ ンピュータ書籍・雑誌などでCSRF対策について書かれている記事を調べた結果、 おどろくべきことに、そのほとんどが誤りを含んでいたり、現実的には使用でき ない方法を紹介したりしていた。そこで本稿ではウェブアプリケーション開発者 にとっての本当に正しいCSRF対策についてまとめることとする。また、採用すべ きでないCSRF対策とその理由も合わせて紹介する。 ■0x02.) あらゆる機能がターゲットとなりうる ウェブアプリケーションの持つ全ての機能がCSRF攻撃の対象となりうる。まず このことを認識しておく必要がある。 AmazonのようなショッピングサイトやGoogleのような検索サイト、そしてはて なダイアリーやMixiのような日記やブログを書くサイトなど、ウェブアプリケー ションにはさまざまなものが存在する。そしてそれぞれのアプリケーションは細 かい「機能」の積み重ねによって成り立っている。 例えばショッピングサイトは、次のような機能の集まりである。 ・ログインする ・商品を検索する ・商品の情報を表示する ・商品をカートに入れる ・送り先の住所やクレジットカードの番号などを入力する ・確認のため注文内容を表示する ・精算を決定する ・ログアウトする 現実のケースとしてCSRF攻撃の対象になるのは「商品をカートに入れる」など の「攻撃者にとってうまみのある機能」であることが多いが、理論的にはアプリ ケーションに存在する機能は全てCSRF攻撃の対象となりうる。CSRF対策を考える 上でまず行うべきことは「アプリケーションのうち、どの機能についてCSRF対策 を行うか」を決定することである。すべての機能について対策を施してもよいし、 重要と思われるいくつかの機能だけに絞って対策を行うという選択肢もあるだろ う。 「データベースを更新する機能のみCSRF対策をすればよい」のような考えは正 しくない。どの機能について対策を行うかは、ウェブアプリケーションの運営者 や開発者が決めるべきことである。 ■0x03.) ひとつの機能は2画面で構成される それがどんな機能であれ、ひとつの機能は基本的には2画面で構成される。CSRF 対策を考える上で、このことをしっかり認識しておく必要がある。 例としてまず「ログインする」という機能について考えてみる。ユーザーはロ グインしたいサイトのトップページなどにアクセスする。するとブラウザにはユ ーザーIDとパスワードの入力欄を持つ画面が表示される。これが「画面1」である。 次にユーザーはユーザーIDとパスワードを入力し、「ログイン」のボタンをクリ ックする。するとブラウザには「ようこそ金床さん。」のようにログインに成功 したことを示す画面が表示される。これが「画面2」である。 2つめの例として「日記を書く」という機能について考えてみる。ユーザは日記 を書くためのページへアクセスする。するとブラウザには日記を記入するための テキスト入力欄を持つ画面が表示される。これが「画面1」である。ユーザはテキ スト入力欄に日記を書き、「書き込む」というボタンをクリックする。するとブ ラウザには「日記を書き込みました」などの画面が表示される。これが「画面2」 である。 3つめの例として検索エンジンを使った「検索する」という機能について考えて みる。ユーザーはGoogleやYahoo!などのサイトのトップページにアクセスする。 するとブラウザにはキーワード入力欄を持つ画面が表示される。これが「画面1」 である。次にユーザは検索したいキーワードを入力し、検索ボタンをクリックす る。するとブラウザには検索結果が表示される。これが「画面2」である。 最後の例として「ログアウトする」という機能について考えてみる。ユーザー はすでにウェブアプリケーションにログイン済みである。そのため、ブラウザに 表示されている画面の隅には「ログアウトする」というリンクやボタンがある。 この画面が「画面1」である。ユーザが「ログアウトする」をクリックすると、「 ご利用ありがとうございました」などの画面が表示される。これが「画面2」であ る。 HTTPレベルで考えると、まず画面1を表示する際に一度リクエストとレスポンス のやりとりが発生する。そして画面2を表示する際に、さらに一度リクエストとレ スポンスがやりとりされる。これらをそれぞれ次のように呼ぶことにする。 ・リクエスト1 ・レスポンス1 ・リクエスト2 ・レスポンス2 サーバー側に存在するプログラムは、リクエスト1を受信すると何かしらの処理 を行い、レスポンス1を送信する。また同様に、リクエスト2とレスポンス2の間に も処理を行う。これらの処理をそれぞれ次のように呼ぶことにする。 ・処理1 ・処理2 また、レスポンス1、レスポンス2によってブラウザに表示される画面をそれぞ れ次のように呼ぶことにする。 ・画面1 ・画面2 ■0x04.) 「CSRF以前の問題」については考えない CSRF対策を考える上で、非常識的な「CSRF以前の問題」が存在すると考えてい ては話が先に進まない。「CSRF以前の問題」とは次のようなものだ。 ・アプリケーションにXSS脆弱性が存在する ・攻撃者が正規ユーザのトラフィックを盗聴可能な状態である ・正規ユーザのマシンにスパイウェアが入りこんでいる ・正規ユーザが悪意あるプロキシサーバーを経由して通信している ・正規ユーザが催眠術で攻撃者に操られている このような仮定の下ではCSRF対策を議論する意味がない。以下の説明ではウェ ブアプリケーションを取り巻く状況はごく常識的なものであるとする。 ■0x05.) CSSXSS脆弱性を無視しない CSSXSS脆弱性はIE（Internet Explorer）に存在するバグである。これを悪用す ると攻撃者が仕掛けた罠のページにレスポンス1のボディ部分の内容が読み込まれ、 hiddenフィールドに格納されたワンタイムトークンなどの値が攻撃者の手に落ち ることがある。これは深刻なバグであるにも関わらずパッチがリリースされてお らず、2006年3月の時点で既に数ヶ月もの間脆弱なままの状態が続いている。 「いちいちウェブブラウザのバグを気にしていてはCSRF対策など行うことがで きない。これはいわゆる（上の項で説明した）『CSRF以前の問題』なのではない か」という意見はもっともだ。しかしIEは9割近いシェアを持っているため、この バグを無視したCSRF対策を行っても、実際には1割の利用者しか保護できないとい うことになる。あなたはウェブサイトの利用者に対して「私たちのサイトではCS RF対策を行っています。しかしIEのバグについては関知しません。その結果とし てIEの利用者に対してはCSRF攻撃が可能です」などと説明できるだろうか。 せっかくCSRF対策を行おうとしているのだから、利用者全体に対して安全を提 供できるような方法を採るのがよいだろう。本稿ではこのような考えの元、 CSS XSS脆弱性も考慮に入れてCSRF対策を行う。 ■0x06.) 正しいCSRF対策 それでは、筆者が安全だと考える具体的なCSRF対策について説明する。これら の方法のうち、どれかひとつだけを採用すればよい。ここではCookieを利用した セッション管理を行うアプリケーションを対象とする。ここで注意してほしいの は、ユーザIDやパスワードを使ったいわゆる「ログイン」機能があるかないかは、 あまり重要ではないということだ。Cookieでセッション管理が行われているかぎ り、CSRF対策は「ログイン」という概念の存在に左右されない。 ちなみに、hiddenフィールドにセッションIDを格納し全ての画面遷移にPOSTを 用いるアプリケーションには、CSRF攻撃は通用しない。リクエスト1がPOSTであ ることからCSSXSS脆弱性の影響も受けない。 ■0x07.) 正しい対策その1: ワンタイムトークンを正しく使用する方法 まずひとつめはワンタイムトークンを使う方法である。ここで題に「正しく使 用する方法」と付けたのには理由がある。ひとくちに「ワンタイムトークンを使 う」といっても開発者によって実装方法がまちまちであり、場合によってはCSRF 対策とならないワンタイムトークンの使い方をしてしまうことがあるのだ（後ほ ど実例を挙げる）。そこでここでは押さえるべきポイントを明確にした、ワンタ イムトークンの正しい使用方法を紹介する。 まず、アプリケーションの作りとして、リクエスト1が必ずPOSTを用いるような 形にする。これによってCSSXSS脆弱性を利用したhiddenフィールドの情報の抜き 取りを防ぐことができる。また、通常POSTリクエストに対するレスポンスはキャ ッシュに残らないため、hiddenフィールドの内容がキャッシュとして残ってしま う可能性を下げることにも繋がる。処理1においてリクエスト1のメソッドを判別 し、GETの場合は処理を行わないようにする。または、再度POSTを用いてアクセス しなおすようなレスポンスを返すようにしてもよいだろう。 リクエスト1を受信後、サーバー側のプログラムは処理1を開始する。処理1にお いて、もしまだセッションが開始されていなければ、セッションを開始する。 トークンを生成する。トークンにはセッションIDなどと同様に充分な長さを持 つ予測不可能な文字列を使用する。 トークンをセッションと結びつけた形でサーバー側で保存する。いわゆるセッ ションオブジェクトに格納するのが分かりやすい方法だ。セッションオブジェク トではなくデータベースを利用する場合には、トークンとセッションIDが1対1で 対応付けされた状態で格納する。 hiddenフィールドにトークンを格納したレスポンス1をクライアントへ送信する。 この際、レスポンス1がキャッシュに残らないようにするため、適切なヘッダーフ ィールドを付ける。 処理1は以上となる。 続いてクライアントはトークンを含んだリクエスト2を送信してくる。このリク エストのメソッドはGETでもPOSTでもよい。 リクエスト2を受信後、サーバー側プログラムは処理2を開始する。まず、送ら れてきたトークンとセッションが正しい組み合わせであることを、処理1の際にサ ーバー側に保存しておいた情報を用いて確認する。この組み合わせが正しくない 場合にはエラーとして扱い、処理をそこで終了する。組み合わせが正しい場合に は次にすすむ。 サーバー側で保存していたトークンの情報を破棄する。これによってトークン が「ワンタイム」であることになる。 以上でワンタイムトークンの処理が終了する。続いて「日記を書き込む」など の、アプリケーション本来の機能を実行する。 以上が正しい対策その1である。 リクエスト1がGETでも安全に動作するようにしたい場合は、処理1においてトー クンをhiddenフィールドには格納せず、Cookieに格納してクライアントに渡すよ うにする。そしてレスポンス1を受信したブラウザがJavaScriptを使ってCookieか らトークンを取り出し、hidden フィールドにその値を格納するようにする。具体 的には次のようなレスポンス1を返す。 ----- HTTP/1.0 200 OK ...（略） Set-Cookie: token=8a23f9d44351895a48e15d26a8897eec;Path=/
- ポートスキャン
ホストのどのポートが開いているかを調べることで、そのホストがどういったサービスを提供しているのかを予測します。クラッキングの予備調査としての位置付けで法律に触れる恐れもあります。
- スニッフィング
ネットワーク上を流れるパケットを盗聴する行為です。TELNETなど平文で通信を行うプロトコルでスニッフィングだけでパスワードが盗まれる危険性もあります。
- ソーシャルエンジニアリング
電話などで巧妙な身分偽証と口先のテクニックで相手をだまし、必要な情報を入手する行為です。Glazheim Lykeionでは次のように表現しています。
ソーシャルエンジニアリングとは巧妙な詐欺のようなものであるさらにゴミ漁りやピッキングなどもこれに分類されます。