ikepyonのお気楽な日々〜技術ネタ風味〜 このページをアンテナに追加 RSSフィード

気になった日々のニュースとメモのためのリンクと戯言のページ

To Do(というかやりたいこと。何時終わることやら)
-ITIL導入のための成熟度チェックシートみたいなの(あると便利だよね?)
-Hacknotes Web Security Portable Reference和訳(出版社募集中)
-Webアプリケーションセキュリティ検査ツールの改良(一応完成)
-Hacker HighSchoolの資料の日本語訳
-OSSTMMの日本語訳
-「燃えるセキュアプログラミング」若しくは「サルでも分かるセキュアプログラミング」とか書いてみたいなぁみたいな。

これだけはチェックしときなはれ!!受入れテスト用セキュリティチェックリスト公開中
Webアプリケーションセキュリティはてなぐるーぷ(テスト中やで)
SQL Injectionの仕組みと対策公開中
RSS feed meter for http://d.hatena.ne.jp/ikepyon/
Secure Coding に入ろう!! [MLの詳細]
メールアドレス
SKUF Meeting なかのひと

2007-02-27 ぐったり

[]検査ツール 検査ツールを含むブックマーク 検査ツールのブックマークコメント

なんだかんだで、UIがらみのところまで出来てるかも、ここからが長そう_| ̄|○

いろいろ調べなあかんしなぁ

トラックバック - http://d.hatena.ne.jp/ikepyon/20070227

2007-02-26 ねむい

[]脆弱性発見と報告とIPA 脆弱性の発見と報告とIPAを含むブックマーク 脆弱性の発見と報告とIPAのブックマークコメント

http://shohoji.net/blog/archives/001633.html

ま、ほんとにいくつも脆弱性を確認しちゃってたら、釘刺されるわな。

脆弱性があるかもというのと、こうすれば出来ちゃいましたでは、大きく違うし。Exploitを見つける行為自体が、サービス破壊する可能性があるということを忘れてるのじゃないかな?この人。

脆弱性というのは、アプリケーションを異常状態にしてしまうことなので、場合によってはデータ破壊消失サービスの停止が発生する場合があると思う。例えばBOFなんか最たるもんだし。アレなんか成功すると多くの場合、サービスが停止してしまう。そうなったとき、サービス提供側は脆弱性発見した人に対して、損害賠償を請求できると思う。

だから、セキュリティ検査をやるときは必ず、可能なら、保守系、若しくは開発系で検査させてね。それが出来ないなら、バックアップを取ってね。でないとどうなっても知らないよ。あと、サービスが停止しちゃうかもしれないけど許してね。ということを契約時にお願いする。

それだけ、セキュリティ脆弱性検査という異常系の検査は何が起こるか分からないから、事前の取り決めをするんだけど・・・それをいきなり、やられたら、サービス提供側が怒ることもあるということを忘れちゃいけない。

そういったトラブルを防ぐために、脆弱性があるっぽいよというまでに止めてくれとIPAは言っていると思うんだけどなぁ。

トラックバック - http://d.hatena.ne.jp/ikepyon/20070226

2007-02-22 いとねむし

色々やっていたら、朝の4時orz

[]世界にご奉仕するはまちちゃんの話。そして、なぜセキュリティな人(の一部)は騒ぎを好むのか。 世界にご奉仕するはまちちゃんの話。そして、なぜセキュリティな人(の一部)は騒ぎを好むのか。を含むブックマーク 世界にご奉仕するはまちちゃんの話。そして、なぜセキュリティな人(の一部)は騒ぎを好むのか。のブックマークコメント

http://d.hatena.ne.jp/kusigahama/20070202#1170405271

勘弁してくれって感じ。

こういったこという人はADの教訓を知らないのか?

http://slashdot.jp/articles/04/01/04/1327206.shtml

http://slashdot.jp/security/article.pl?sid=04/02/04/0531248

これも、AD200xという場で、攻撃手法を公開しちゃった上に、個人情報が漏洩しちゃったから、問題になったのだ。

これから、報告制度が必要だよねという話になって、IPA音頭をとったと記憶している。実際、それ以前は、脆弱性発見して管理者に報告しても、なしのつぶてが多かったらしい(私はそんなことしてないので知らないけど)。

結果として、対策してくれないのなら、情報を公開して対処を促すしか方法はなかったらしいし、このような脅しで改修されたところも多いだろう。

しかし、情報を公開する側も、危険だと承知していたから、実際の攻撃手法は示さずに、どこそこのサイトには脆弱性があるよということしか出してなかったと記憶している。あの当時は、個人として修正しないサイトに対する圧力は情報公開くらいしかなかったけど、皆なるべくやりたくないことと思っていたと思う。

一方、こういうこと言う人や、行動しちゃう人って、どう贔屓目に見ても、啓蒙活動だという詭弁を使って、自分の行為を正当化し、祭りにして楽しんでいるようにしか思えないなぁ。彼らは、危険性や被害にあう人のこと考えて行動してるのか?自分が事件の被害者になったときも、冷静でいられるのか?

いきなりの攻撃手法までの公開はほんとにテロと同じだと思うなぁ。

[]脆弱性解説文 脆弱性解説文を含むブックマーク 脆弱性解説文のブックマークコメント

とある脆弱性解説文を見て思ったこと。

PHPアプリ脆弱性の説明にこんな注釈があった「攻撃が成功するには、magic_quotes_gpc が無効になっている必要がある。」

いやまあ、正しいっていやあ正しいんだけど、これだと「magic_quotes_gpcを有効にしておけば安全です」といってるようにしか見えないよなぁ。で、分からんチンは実際に設定変更で対策しそうだなぁ。と思った昼下がり。

[] を含むブックマーク のブックマークコメント

ソバまでにHibernateを使った場合のUnicodeがらみのテストプログラムを作っておきたいなぁ。

可能なら、デモ&プレゼンをするということで。

とりあえず、PreparedStatement版は前に作ったのがあるから良いとして、Hibernate版は作らんとなぁ。

まーまー 2007/02/25 11:55 ADのことなんて知らない人が多いと思いますよ?とある業界の一部の人たちが集まって行ったイベント、程度のものです。
その後の裁判沙汰も、そんなに記憶にはないんじゃないですかねぇ・・。そんなもんです、当事者以外は。

トラックバック - http://d.hatena.ne.jp/ikepyon/20070222

2007-02-21 ねむすぎ

今日も一日ダメでしょうw

[]まっちゃの資料 まっちゃの資料を含むブックマーク まっちゃの資料のブックマークコメント

朝の部で使った資料、公開はしませんが、欲しい人いれば、メールください。但し、レスが遅くなる可能性が高いですw

[]専門家が実証、JavaScriptコードルータを乗っ取る――対策はルータパスワード変更 専門家が実証、JavaScriptコードでルータを乗っ取る――対策はルータのパスワード変更を含むブックマーク 専門家が実証、JavaScriptコードでルータを乗っ取る――対策はルータのパスワード変更のブックマークコメント

http://opentechpress.jp/security/article.pl?sid=07/02/19/0842234

まあ、パスワードデフォルトから変更するのは当たり前です。

この攻撃って、結構簡単に決まりそうな気がする。

トラックバック - http://d.hatena.ne.jp/ikepyon/20070221

2007-02-19 ねむいorz

まっちゃに参加したので久しぶりに、動いた週末でした。

参加した皆さんお疲れさまでした。

しかし、そのおかげでくたくたです。

[]セキュリティセキュリティ本を含むブックマーク セキュリティ本のブックマークコメント

某氏とのお話で、思いついたんですけど、誰かセキュアな開発手法の実践的な内容の本書いてくれないかなぁ?

一応、ネタこんな感じで考えてみたので、内容書いてくれる人プリーズw

誰もいないなら、机上の空論でちょっとづつ書いてみようかなぁ?

[]RSS Feed Reader へのスクリプトインジェクション RSS Feed Reader へのスクリプトインジェクションを含むブックマーク RSS Feed Reader へのスクリプトインジェクションのブックマークコメント

http://openmya.hacker.jp/hasegawa/public/20070217/rss.html

まっちゃの朝の部の資料です。

色々考えないといけませんねぇ。

2007-02-16 ぐずぐずするorz

[]O/Rマッピングバインメカニズム O/Rマッピングとバインドメカニズムを含むブックマーク O/Rマッピングとバインドメカニズムのブックマークコメント

なんでO/Rマッピングバインメカニズム(PreparedStatement)がSQLインジェクション対策に有効化というと、どちらも、扱うデータの型を自動的に判断してくれるからだと思う。

O/Rマッピングの場合は、設定ファイルで、テーブルの項目の型を指定する。また、バインメカニズムの場合は、コードの中で、プレースホルダ「?」に自動若しくは、プログラマが型を意識して代入する。

その結果、これらの仕組みが自動的にエスケープ処理を行ってくれて、SQLインジェクション耐性が強い。

一方、文字列としてSQL文を扱って、検索条件などをプログラム外部由来のデータから作っている場合、O/Rマッピングや、バインメカニズム自動的にやってくれる型の判断及び制御をプログラマが意識して行わなければならない。

結果としてエスケープ処理が漏れSQLインジェクション耐性が弱い。

というわけで、O/Rマッピングバインメカニズムを使えば万々歳というわけには行かないのが、ちと困ったところ。とはいえ、ここからは検証が必要なんだけど、DBが扱う文字コードと、アプリ側(若しくはフレームワーク言語側)が扱う文字コードが異なる場合、困ったことが発生することがある。特にフレームワーク側の文字コードUnicodeDB側がSJISやらJISEUCの場合は適切に処理してくれない。とりあえず、JavaMySQLの場合のバインメカニズムは試したけど、他も要検証。多分、他も同じだと思う。

結論としては、DBアクセスが必要な場合、O/Rマッピングか、バインメカニズムを作った上で、アプリ側とDB側の文字コードは全て統一しようと言うことで。

2007-02-15 そろそろか?

妙に目が痒いし、鼻水が出てくるorz

そろそろかふんちょうか?

眠いしなぁ(これはちと違うか)w

[]開発のセキュリティ 開発のセキュリティを含むブックマーク 開発のセキュリティのブックマークコメント

ふと思いついたけど、設計での対策として、デバッグオプションをどう実装するか?というのも考えておいた方が良いかもしれない。

良くあるのが、クエリパラメータに「debug=on」とかあるとデバッグモードにするという奴。実際、以前検査した中で幾つかあったしw

こういうのはいらん情報を攻撃側に与えてしまうので、はっきり言ってよくない。かといって、開発中にはどうしてもデバッグするために、内部情報を出したいというのがある。最終的に、デバッグモードを全部削除してからリリースすればいいのだけれど、そうするとまた一からテストが必要になったり、削除漏れがあってよくないわけで・・・

じゃ、いっそのこと設計思想として、デバッグオプションを設定ファイルや、環境変数記述してしまうとしてしまったほうが攻撃側がデバッグモードへの移行をコントロールできにくい(他の脆弱性があったら別なんで絶対に出来ないとは言い切れない)ので、安全だろう。

こういうのも、設計で対応できる対策のひとつだと思うんだよなぁ。

コードだけで対策しようとするのは、ぶっちゃけ、それこそTipsでしかないわけでw

セキュリティ対策をするには、部分的なものだけを見るのではなく、全体的に見て最適な対策をとる必要があるんで、設計というのが重要になると思うんだけど、そこらへん考えている開発者ってどの程度いるんだろう?

コーディングにだけ脆弱性の発生源があるんじゃない、脆弱性の発生源は開発工程の全てにあるんだw

[] を含むブックマーク のブックマークコメント

どうでもいいことなんだけど、オブジェクト指向言語でうれしいことって、関連のあるメソッドを1つのクラスにすることで、必要な変数を共有できることだと思う(これだけじゃないけど)。で、インスタンス毎に共有している変数が別物として扱えるので、非常に扱いが楽になると思うんだな。

だから、関数型言語を知らない人が、いきなりオブジェクト指向とか言われてもすごい混乱するだけだと思うんだけど、どうなのかなぁ?

少なくとも、私は関数型言語を知っていた所為で、オブジェクト指向の考え方がすんなり頭に入ったんだけど、というかやりたかったことはこれだと思ったんだけどね(だからといってオブジェクト指向を100%理解しているかというとそういうわけじゃないし)。

というわけで、いきなりJavaとか教えるの反対してみるw

[]はてなGoogle はてなとGoogleを含むブックマーク はてなとGoogleのブックマークコメント

最近、なんかはてなアンテナGmailの調子が悪いなぁ?

アンテナはてなダイアリ更新情報が全然反映されないし、gmailはちょくちょくつながらないし

まーまー 2007/02/16 23:44 ikepyonさんって大規模案件の開発現場って、経験あるんでしたっけ?

ikepyonikepyon 2007/02/16 23:47 大規模開発のコーダーならありますが、設計は中規模程度でしょうか。

トラックバック - http://d.hatena.ne.jp/ikepyon/20070215

2007-02-14 誰がなんと言おうと今日は、「煮干の日」

[]開発のセキュリティ 開発のセキュリティを含むブックマーク 開発のセキュリティのブックマークコメント

http://d.hatena.ne.jp/ripjyr/20070214/1171403597

まっちゃさんが書かれてますけど、結構フレームワークコードジェネレータ使えば、Injection系の攻撃や、CSRFなんかのロジック破壊系の攻撃は防げると思います。というか、某所でいくつか実験したら、防げました。

ただ、そういったものは制約が多いわけで・・・検証アプリを作った人は苦労してたみたいです。

この内容については、そのうちどこかで発表することになるでしょうが、こうご期待w

ちまっとしたことはソバのときに話せそうです。

また、設計なんかでもかなり防ぐことは出来るでしょうし。ちょっと考えただけでも、入力データの整合性チェックなんかが思いつきますよね(ま、これはセキュリティ対策ではなく、セキュリティ対策にもなりうる設計だけど^^;)。ホスト系の開発だとこんなん必要なんか?と思うぐらい入力データの整合性チェックをしてた記憶があります。これがWebアプリとなると・・・orz

こっちの方の検討もそのうち文書として出したいなぁと思ってますが、いつになることやらw

[]まっちゃ139の朝の部 まっちゃ139の朝の部を含むブックマーク まっちゃ139の朝の部のブックマークコメント

そういえば、今週末はまっちゃだなぁ。でも朝の部って何やるんだろう?ワクワクw

トラックバック - http://d.hatena.ne.jp/ikepyon/20070214

2007-02-09 ぐったり

[]OSコマンドインジェクション OSコマンドインジェクションを含むブックマーク OSコマンドインジェクションのブックマークコメント

http://itpro.nikkeibp.co.jp/article/COLUMN/20070130/260021/?ST=security&P=2

うそかくなよ。

OSコマンドインジェクションとディレクトリトラバーサルは関係ないし・・・

PATHが通ってたらフルパス書く必要ないんだからさぁ。

あんまりわかってないよなぁ、この人。

ま、私も分かってない人間ですが・・・

つうか、この連載、少なくとも攻撃手法の解説ダメダメですわorz

[]コードジェネレータ、フレームワークDBへのアクセス方法 コードジェネレータ、フレームワークのDBへのアクセス方法を含むブックマーク コードジェネレータ、フレームワークのDBへのアクセス方法のブックマークコメント

OpenXava

 Hibernate

middlegen

 Hibernate

jag

 Hibernate

appfuse

 Hibernate

WebLang

 Entity Bean

PHPCodeGenie

 パラメータを直接SQL文に埋め込み

ということで、PHPCodeGenieはダメっぽいorz

トラックバック - http://d.hatena.ne.jp/ikepyon/20070209

2007-02-08 眠すぎ

[]納入時に品質を確保する「受入テスト」と「総合テスト納入時に品質を確保する「受入テスト」と「総合テスト」を含むブックマーク 納入時に品質を確保する「受入テスト」と「総合テスト」のブックマークコメント

http://www.atmarkit.co.jp/im/cpm/serial/quality/03/01.html

受け入れテストセキュリティテストも必要だよなぁ。となると、仕様書になんかかいとかないといけないし。

ya_taya_ta 2007/02/08 12:47 >仕様書になんかかいとかないといけないし。
つ ワークフロー
#納入先の人間がわかってる・やってくれるとは限らない。
#だから、半自動(全自動でもいいけど)なワークフローを。

ikepyonikepyon 2007/02/08 12:52 いや、「なんか」とはセキュリティ仕様のことだったんです^^;
それをどう書くかというのが難しいなぁということで。
ワークフローもありかもしれませんが・・・

トラックバック - http://d.hatena.ne.jp/ikepyon/20070208

2007-02-07 調子に乗りすぎてたら、寝れなかったorz

コード書き書きに調子乗っていたら4時前だったorz

[]安全な開発手法 安全な開発手法を含むブックマーク 安全な開発手法のブックマークコメント

ということで、一日考えたトピックを書き出してみた

http://www.geocities.jp/ikepy0n/SecureDevelopment.pdf

いいのか?というのは、アレですが・・・

こんなねたの資料、誰か書いてくれないかなぁ?

[]情報セキュリティ関連の資料 情報セキュリティ関連の資料を含むブックマーク 情報セキュリティ関連の資料のブックマークコメント

http://cgi36.plala.or.jp/tera5/

ちょっと色々読んでみる

トラックバック - http://d.hatena.ne.jp/ikepyon/20070207

2007-02-06 なんか調子悪い

[]複数人での開発におけるテストの勘所 複数人での開発におけるテストの勘所を含むブックマーク 複数人での開発におけるテストの勘所のブックマークコメント

http://www.thinkit.co.jp/free/article/0611/2/5/

ちょっと内容が面白かったので。

設計段階からセキュリティ対策を行っていれば、セキュリティ検査が必要ないんじゃないかという人がいるのだけど、実際はそうじゃない。実装したセキュリティ対策がきちんと実装されているか、対策に漏れが無いかを確かめるために、どうしてもセキュリティ検査セキュリティテストといったほうが良いかも)が必要となる。

これは、要求仕様どおりの動きをするかを確認するテストが必要なのと同じ理由なんだけどねぇ。

[]Web application logic exploitation Web application logic exploitationを含むブックマーク Web application logic exploitationのブックマークコメント

http://www.liquidinfo.net/cgi/validate.cgi?4

Webアプリロジック上の脆弱性についての文書らしい。後で読む。

しかし、CGIプログラムがまずいのか、一旦ファイルを保存してからPDFファイルとしてみる必要がある。

指摘するのが面倒なので(ォィ)放置の方向でw

[]Writing Software Security Test Cases Writing Software Security Test Casesを含むブックマーク Writing Software Security Test Casesのブックマークコメント

http://www.qasec.com/cycle/securitytestcases.shtml

セキュリティテストケースの作成方法?についてかな。後で読む。

[]Identifying Risks in the Development Cycle Identifying Risks in the Development Cycleを含むブックマーク Identifying Risks in the Development Cycleのブックマークコメント

http://www.qasec.com/cycle/developmentcyclerisks.shtml

開発工程に存在するリスクについてかな?後で読む。

[]サニタイズ言うなキャンペーン サニタイズ言うなキャンペーンを含むブックマーク サニタイズ言うなキャンペーンのブックマークコメント

サニタイズ」という言葉イメージの問題なのかなぁ?

私の場合、サニタイズ=出力直前(自分が作ったコード、というか自分で制御できるコード、から別の人が作ったコード、例えばRDBMSとか自分で制御できないコード、にデータを渡す直前)に行うことというイメージが強いんだよねぇ。

普通は、関数とか、メソッドの引数が正しいデータ(例えば、数値項目には数値データしか入ってないかとか、文字数が想定範囲内かとか)のみから構成されているかどうかの確認が、そのデータを使う前に、必要だと思うんだけど・・・(そうしないとバッファオーバフローは防げない、というか、出来なくはないけど、あまり美しくない気がする)。これは「サニタイズ」ではないと思うんだよね。

サニタイズ」はあくまで、データとしては正しいんだけど、そのデータが含まれていると、出力先のコードで、開発者が予期しない動きをするのを防ぐためのもの(追記:これを全て「エスケープ処理」というのはかなり抵抗がある。「エスケープ処理」は、一括してデータに含まれるAという文字列をBという文字列に、変換して、意図どおりの動きをさせるというイメージがあるので。場合によってはそういった変換をしたくないときもあるだろうし・・・。あくまで私のイメージということで、と書いてて矛盾があるような気がしてきた^^;)だと思うので、出力直前にやるのは当然で、今一「サニタイズ言うな」キャンペーン意味が分からなかったりする、今日この頃

と今更ながらに書いてみる。

[]セキュアな開発手法 セキュアな開発手法を含むブックマーク セキュアな開発手法のブックマークコメント

要件定義から、運用保守まで、ぼーっと一日かけて(ォィ考えていたら、なんとなく1冊の本になりそうな気がしてきたw

さすがに、そんな能力はないけど・・・

とはいえ、一度本は出版してみたいなぁ。

はせがわはせがわ 2007/02/06 16:04 つ http://takagi-hiromitsu.jp/diary/20060115.html

ikepyonikepyon 2007/02/06 16:17 この文章読んでも分かったような、分からないような漢字なのですよw
基本、自分の書いたコードの中で0から作り出したデータ(forループのカウンタとか、定数を代入した変数とか)以外のデータ(環境変数、ファイル、DBのデータ等々)はどんなデータが含まれているか分からないから、想定していないデータが入ってないか確認して、使うことは普通だし、外部に渡すデータは必ず想定している動きしかしないようにすることも普通だと思うのですよ。
まあ、これが必ずできるかというとサボっちまうんですがねf^^;。
で、そういったところから問題が出来てしまうというわけでw

ikepyonikepyon 2007/02/06 16:23 じゃ、なんで、出力時のデータをきっちり確認するかというと、出力先のコードが、信頼できないから(出力先のコードにそのデータが正しいものかどうかの判断が出来ないので)、想定した動きを必ずさせるために必要だからというのが理由だと思うんです。

aa 2007/02/06 17:24 そういう出口での対策は「エスケープ」であってサニタイズ(入り口での消毒)ではないし、それを「サニタイズ」と言ってしまっては言葉の意味が広がりすぎて「セキュリティ対策」と同程度に広い語になってしまうので「サニタイズという言葉を使うな」というのが氏の主張。
- 出口(というか使う直前)でのエスケープは推奨
- 入り口での消毒(=サニタイズ)はするな
- 出口でのエスケープをサニタイズと言うな ← いまここ!

ikepyonikepyon 2007/02/06 18:03 ま、「サニタイズ」という言葉自体の意味があいまいすぎというのは分からんでもないです。
でも、何でもかんでも「エスケープ」とも言ってないような気がします。
言葉の定義を厳格にと言うことなのだとは思いますが、話が発散していて今一分からないのです。

masamasa 2007/02/07 12:38 それぞれの処理系に対応したエスケープをすることで、セキュリティ対策をしましょう。という主張だと思います。
ここで、数値データのチェックとか、範囲チェックとかはどうするの?という話が出てくるのですが、それは業務要件だからセキュリティとは関係ない。という主張が今後展開されるのではないでしょうか。
サニタイズ言うなキャンペーンより大きな波紋を呼びそうな気がしますが。

ikepyonikepyon 2007/02/07 13:31 ふむふむ、なんとなく分かった気がしてきました。
どうやら言葉のイメージが膨らみすぎというのがアレだということと理解しました。

トラックバック - http://d.hatena.ne.jp/ikepyon/20070206

2007-02-05 眠すぎるorz

トラックバック - http://d.hatena.ne.jp/ikepyon/20070205

2007-02-02 今日は一日研修だった

[]PHPバインメカニズム PHPのバインドメカニズムを含むブックマーク PHPのバインドメカニズムのブックマークコメント

http://jp2.php.net/manual/ja/ref.pdo.php

PDOオブジェクトを使えばいいらしい。ここらあたりを使えばある程度安全になりそう。

ただ、PHPってマルチバイトコードの取り扱いが微妙だから、実験せんとあきませんが・・・

ここら辺使ってジェネレータ書き換えてくれないかなぁ?

他力本願になってみるw

トラックバック - http://d.hatena.ne.jp/ikepyon/20070202

1900 | 01 | 06 |
2003 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2004 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2005 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2006 | 01 | 02 | 03 | 04 | 05 | 06 | 08 | 09 | 10 | 11 | 12 |
2007 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2008 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 | 04 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2010 | 02 | 03 | 04 |
2011 | 01 | 02 |