気が付いたらチームリーダーやることになってた、どうしてこうなった
まぁ楽しかったからいっか。
疲れすぎて帰った後ポプテピ3話を思いっきりスルーして爆睡したけど。
Attack & Defenseとは何か、すごくざっくり言うとセキュリティ技術の向上を目的としたイベントで、今回だと4人前後のチームを編成して、チームごとに簡単な、そして脆弱性だらけのWebシステムを1個ずつ与えられ、それを競技時間中他チームのシステムを攻撃(Attack)したり自チームのシステムを守(Defense)ったりして、システムを守れた時間や攻撃の結果得られた情報をポイントに換算してその点数を競うもの、という理解をしました。
CTFだとちょっと定義が変わるのかな。CTFのいち形態としてAttack & Defenseが存在する、っていう感じかもしれない(曖昧)。
というわけで前回も見学だけはしてたんですが、ただ見てるのと実際チームに入ってやるのではやっぱり違いますね。岡目八目とはよく言ったものです。結構いっぱいいっぱいでした。
環境に制約があって時間もない中なので、攻撃されたときのインパクトとか諸々の観点で優先順位決めて対応することになるから「仕掛けられたらイラッとするけどルールの性質上実害が小さそうな脆弱性」っていう類の対応優先度は必然的に下がるし(腹が立ったのでやったけど)、本職の人が思い描く(はずの)本来あるべき姿にまで持って行くのは競技自体にも相応に慣れていないとかなり難しいと感じました。
出来ればIDE使いたかったんですがやっぱダメかなぁｗ 今回は素直に諦めてサーバ内のviで作業してました。
やってて感じたコツ(？)としては特に今回競技時間としては3h程度の短時間だったので、時間稼ぎ的対応が意外に有効だったりしてサクッとやれるならどんどん試してみるといいかもしれないなーと。どうせ競技時間の間に出来ることなんか限られているんだから、とにかく落ち着くこと。
この辺はなんというか競技プログラミング特有のスタイルなのでしょうか、大学の授業でしかそれっぽいのやったことないんだけど(しかも出題側)。
本気のセキュアプログラミングのお勉強、という観点では「ちゃんと直すにはどうしたらいい？」っていう復習回があるといいかもなーと思った*1。
それから脆弱性としては定番であろうSQLインジェクションでDBを潰されまくった件について。
SQLインジェクション脆弱性自体は山ほどあるものの実際どこでやられているのか見当がつかず、地道にそれっぽいところを潰しながらフレームワークのマイグレ機能を使って「ラピュタは滅びぬ！何度でも蘇るさ！」を地で行くようなことを1人で1時間くらいやってたのですが。よく考えたらいくつかの場所で使われていたSQL投げるメソッド、1回の呼び出しでクエリ複数実行できたじゃん*2、ということに全部終わってから気付くという体たらく… だって普段そんな使い方しないもん！ORマ(以下自粛) ※もちろん負け惜しみの言い訳です
というわけで、極端な例ではあるけど「フレームワークを使ってたら脆弱性なんか出ない」なんて嘘だよなーとつくづく思う素敵な問題*3でした。だからみんなちゃんとセキュアプログラミングの勉強しようね！
ところで今回のチームメイトは全員学生さんで、先生に連れてこられたとか色々あったみたいですがみんな勉強熱心で偉いなーと思いました。県外から来てたりとか。
ただ誰もメイン問題で使った言語については経験が無いみたいだったので正直どうなることやらと思ったのですが、みんな最後まで前向きに取り組んでくれてとてもよかったです。てゆーか脆弱性探っていろいろ共有してくれたり、サクッと攻撃スクリプト書いてくれたり、コード読みまくって終了ギリギリまでチューニング問題頑張ってくれたりとかさ、すごいよ、多分わたし学生の頃同じことやれって言われても出来なかったってほんと。
最後の休憩時間がもうちょっと長かったらお菓子買ってきてあげたかったくらいには本当に頑張ってました。きっちり結果も出たしね。2位だぜ2位。なので「何も出来なかった」なんて言わずに胸張ってくださいな。それからもし将来こっちの業界に来るならいいエンジニアになってね。
というわけで参加者のみなさま、スタッフのみなさま、お疲れ様でした&ありがとうございましたー。
*1:お前がやれ、と言われたらやる心の準備は一応出来ております
*2:フレームワークによっては複数実行できず、SQLインジェクションを仕込めたとしてもただのエラーとして扱われることもあるのです。それはそれで良くないんだけども。
*3:つまりプロダクトコードとしてはかなりアカンやつなので、真似しちゃだめだよ！
