2014/7/8(火) アジャイルサムライ横浜道場 「具現化させる」に参加してきました。
DoorKeeper
http://yokohama-dojo.doorkeeper.jp/events/12145以下の書籍をターゲットとした勉強会(?)なのです。
場所は横浜市西公会堂 2号会議室です。
参加者は14人くらいでしょうか。
今回は5章「具現化させる」が範囲で、私が発表当番でした。
前回の道場の帰り際、駅で道場主からムチャ振りされたのであった!
■発表 by @makopi23
PCの調子が悪く、ドタバタしてスミマセンでした。。。
最後のスライドに7/12の横浜道場BBQの告知スライドを入れました。
去年は私、秋刀魚を持参して網で焼きました。あんときは秋刀魚もお肉もウィンナーも、美味しかったなぁ。。。
■ディスカッション3チームに分かれて5章の内容についてディスカッションを行いました。
休憩を挟み、私は2チームをハシゴしました。
■1チーム目インセプションデッキ全般をテーマに話し合いました。

ディスカッションで出た話題を挙げてみる。
---
- トレードオフスライダーは、「荒ぶる四天王+捉えどころのないもの」の全部を通して同じ目盛を許さないようにする。
- 「荒ぶる四天王」と「捉えどころのないもの」を分けてスライダーを作るのではない点に注意!
- トレードオフスライダーは、図で表現すると微妙な位置関係を表現できるので良い。
- 整数で1, 2, 3, ・・・のように数値化しないほうが良い。どうしても数値化するなら、小数点も許したほうが良いかも。
- プロジェクト期間中にインセプションデッキを見なおしたことがあったが、変わりにくいものと変わりやすいものがあった。
- 「トレードオフスライダー」と「やらないことリスト」の2つは、プロジェクトの状況に合わせて期間中に変更を入れた。
- トレードオフスライダーで表現した優先度は、誤解されないように注意する必要がある。
- 優先順位が低いからといって、それを重要視しないということでは決して無い。
- 際どい判断を迫られた究極の時の判断材料としてトレードオフスライダーは使うのだ。
- トレードオフスライダーがエンジニアの言い訳に使われないようにしないといけない。
- 例:品質より納期を優先したのでテストを省略しました、みたいな。
■2チーム目「インセプションデッキの良さ」をテーマに話し合いました。

インセプションデッキというよりも、KPTの話が多かったです。
ディスカッションで出た話題を挙げてみる。
---
- TOCの振り返り用ツールに「YWTM」というものがあるらしい。 By 道場主
- リーンには、「バリューストリームマップ」という振り返りのプラクティスがあるらしい。
- 振り返りに関する他の手法としては「タイムライン」というものがあるらしい。
- KPTでProblemが出ない場合どーする?
- 別にProblemが無くても良いのでは。
- KPTをやる事前に付箋を配っておき、予め考えてもらう時間を取るとProblemを思い出したりしやすいのでは。
★感想:今回も良い気付きが得られて有意義でした。
あと、発表も担当したし。発表当番すると、発表資料を作る過程で理解が深まるのが良いですね。
こーゆう副産物を狙って、あえて発表を志願するのも実は有効だと思うのです。
翌日は朝5時からワールドカップ準決勝 ブラジルvs ドイツがあったので、懇親会は行かずに帰宅しました。
この試合、ホント凄かったですね。。。
ドイツがブラジルから7点を奪うなんて試合、サッカー史上の伝説を目にした気がする~
次回8/5は、横浜道場2週目初の特別回だそうです。
アジャイルサムライ横浜道場 特別編「エンジニアのための現場で使えるコミュニケーション - チーム作り-」こちらも楽しみです。
スタッフ、参加者の皆様、ありがとーございました。
2014/7/3(木) SQLアンチパターン読書会 「SQLインジェクション」に参加してきました。
DoorKeeper
http://sqlap.doorkeeper.jp/events/12751以下の書籍をターゲットとした読書会なのです。
場所はいつもの湯島、株式会社アルティネットさんです。
いつも会場提供ありがとうございます。
参加者は9人かな。全員おなじみの方ばっかです。
この日は20章「SQLインジェクション」がターゲットでした。
■ 発表今回は @setoazusa さんが発表担当でした。
オフレコな内容満載ということで、非公開とのこと!ワロタw
■ディスカッション今回もディスカッションしたいネタをみんなで付箋に書き出しました。

以下、復習用のメモ~
---
■ SQLインジェクションもろもろ- GitHubの普及により、SQLインジェクションの脆弱性があるコードを気軽に検索できる時代になっている。
- (ここで @setoazusa さんがGitHubから探してきたコードを晒す!やべぇ・・・)
- ORMが普及しているが、ORMの使用は強制できない。よって、executeQueryを直接呼び出すコードを完全には防げない。
- エラーメッセージをエラー画面で表示させるようにしていると、SQLの情報から攻撃者にヒントを与えることになる。
■ ブラインドSQLインジェクション- Information SchemaとJOINして、スキーマ構造(システムに存在するテーブル名など)を先に抜いてからアタックする手法。
- DBMSによってInformation Schemaを抜く構文は決まるので、候補はDBMSの数パターンに絞れる。
- 参考: @IT 深刻な「ブラインドSQLインジェクション」の脅威
■ セカンドオーダーSQLインジェクション- 20.3節の"「ルール31」:後部座席に気をつけよう"の例が該当する。
- 入力した時点ですぐに効力を発揮せずに、次にアプリケーションで利用されたときに効力を発揮するようにする攻撃のこと。
- 画面から入力された値がいったんDBに格納され、その値を元にSQLを動的に組み立てるような場合に発動する。
■ 脆弱性診断ツール- 脆弱性が無いにもかかわらず有りと判定する、偽陽性(False Negative)なツールが多い。
- DBやプログラムをブラックボックスとして扱わざるを得ないため。
- 診断ツールを掛ける際、探査シナリオで状態爆発することがある点に注意。
- 診断ツールに探査させるときは、ログレベルをDebugからInfoにするなどしないと、ログが膨大に出力されて爆発する。
- FindBugsなどの静的解析ツールやWAF/IPSも偽陽性なものが多い。
■ 動的IPアドレスを使った攻撃- 動的IPアドレス使った攻撃は、攻撃のたびにIPアドレスが変わるので、攻撃元の見分けがつかない。
- 動的IPアドレスのおかげで一般人が巻き添えを食らう。
■ 値のエスケープ- 引用符文字を2つ重ねるのと、バックスラッシュを使用するのは、同じ効果。
- MySQLはバッククォートもエスケープで使用する。
- P.223の例で、カラム「account_id」が数値型だった場合、引用符文字列で囲んで'123 OR TURE'のようにしてしまうと、比較の成否はDBMS依存になってしまう。
- ちゃんとキャストしましょう。
■ SQLインジェクションの早期検知- まず権限を絞り、WebアプリからアクセスするユーザにはInformation Schemaにアクセスできないよう制限をかける。
- deleteなど、想定外の構文が使用された場合は検知できるようにしておく。
- まず規約で絞りましょう。
- 静的解析ツールでも生SQLを発行しているプログラムはチェックできる。
- 高価な代金を支払ってチェックツールを導入したり、コンサルテーションをお願いしたりすることもある。
- NDA契約を結んで、セキュリティの有識者にソースコードをレビューしてもらうのも有効。徳丸さんとか。
- セキュリティの検証は、テスト環境でやるか本番環境でやるかで、価格が全然違ってきたりする。
- ソーシャルゲームとかの開発はスピード重視で、3ヶ月で打ち切りとかもあるので、ぜんぜん検証しないこともある。
- Brakeman PluginというJenkinsのプラグインがあり、Webアプリの脆弱性をチェックしてくれる。
■ 20.5.4 ユーザの入力をコードから隔離する- 20.5.4 の解決策は、外部からの動的注入を連想配列で置き換えるという手法。
- プログラマが指定した文字列しかSQLに入れさせないよう連想配列で通訳させる。
■20.5.3 動的値を引用符で囲む- 引用符を入れたSQLをワザと書いて、オプティマイザが実行計画を最適化しやすいようにすることがある。
- この場合は特殊ケースで、PreparedStatementをあえて使わない。
- 昔は、オンラインの開始時間をバッチが突き抜けないよう、わざとPreparedStatementを避ける事があった。
- ただしこの対策は非推奨。本当にこの対策が必要かどうか、まず計測してから判断すべし。
■ SQLインジェクションの解決策- 解決策 = 「20.5.2 動的値のパラメータ化(PreparedStatement)」 + 「20.5.4 コードからの隔離」
- これに尽きる。
- 「20.5.1 入力のフィルタリング」は危険。21世紀なのにありえない!(欄外注釈にも危険性を書いた)
■ P.221の4コマ漫画- 海外では有名なサイト。
- OpenSSLのバグ「Heartbleed」の説明は、このサイトの4コマ漫画が一番分かりやすかった。
- xkcd.com/1354/
■ 徳丸本
★感想:みなさんのお話、オフレコな内容が多くてワロタw
ブログに書けないような結構スレスレ、というかアウトな経験をされているようで~
痛い目を見てから気をつけるようになる、黒歴史駆動開発の深淵を見た気がする・・・
前回19章のリーダブルパスワードでも話がありましたが、「自分のシステムをパスワードリスト攻撃のスタート地点にされないようにする」という点はSQLインジェクションも共通ですね。
この日で20章が終わり、残り5章。終わりが見えてきました~
皆勤目指して頑張ります。
みなさま、ありがとーございました。
■おまけ:過去の「SQLアンチパターン読書会」ブログ1章:SQLアンチパターン読書会 「ジェイウォーク」に参加しました
http://makopi23.blog.fc2.com/blog-entry-65.html2章:SQLアンチパターン読書会 「ナイーブツリー」に参加しました
http://makopi23.blog.fc2.com/blog-entry-70.html3章:SQLアンチパターン読書会 「IDリクワイアド」に参加しました
http://makopi23.blog.fc2.com/blog-entry-73.html3章:SQLアンチパターン読書会 「続・IDリクワイアド」 に参加しました
http://makopi23.blog.fc2.com/blog-entry-77.html4章;SQLアンチパターン読書会 「キーレスエントリー」 に参加しました
http://makopi23.blog.fc2.com/blog-entry-84.html5章:SQLアンチパターン読書会 「EAV(エンティティ・アトリビュート・バリュー)」に参加しました
http://makopi23.blog.fc2.com/blog-entry-90.html6章:SQLアンチパターン読書会 「ポリモーフィック関連」 に参加しました
http://makopi23.blog.fc2.com/blog-entry-94.html7章:SQLアンチパターン読書会 「マルチカラムアトリビュート」に参加しました
http://makopi23.blog.fc2.com/blog-entry-97.html8章:SQLアンチパターン読書会 「メタデータトリブル」 に参加しました
http://makopi23.blog.fc2.com/blog-entry-105.html9章:SQLアンチパターン読書会 「ラウンディングエラー」 に参加しました
http://makopi23.blog.fc2.com/blog-entry-109.html10章:SQLアンチパターン読書会 「サーティーワンフレーバー」に参加しました
http://makopi23.blog.fc2.com/blog-entry-115.html11章:SQLアンチパターン読書会 「ファントムファイル」に参加しました
http://makopi23.blog.fc2.com/blog-entry-118.html12章:SQLアンチパターン読書会 「インデックスショットガン」に参加しました
http://makopi23.blog.fc2.com/blog-entry-121.html13章:SQLアンチパターン読書会 「フィア・オブ・ジ・アンノウン」に参加しました
http://makopi23.blog.fc2.com/blog-entry-128.html14章:SQLアンチパターン読書会 「アンビギュアスグループ」に参加しました
http://makopi23.blog.fc2.com/blog-entry-130.html15章:SQLアンチパターン読書会 「ランダムセレクション」に参加しました
http://makopi23.blog.fc2.com/blog-entry-133.html16章:SQLアンチパターン読書会 「プアマンズ・サーチエンジン」に参加しました
http://makopi23.blog.fc2.com/blog-entry-134.html17章:SQLアンチパターン読書会 「スパゲッティクエリ」に参加しました
http://makopi23.blog.fc2.com/blog-entry-136.html18章:SQLアンチパターン読書会 「インプリシットカラム」に参加しました
http://makopi23.blog.fc2.com/blog-entry-138.html19章:SQLアンチパターン読書会 「リーダブルパスワード」に参加しました
http://makopi23.blog.fc2.com/blog-entry-140.html