第五回 関西DB勉強会でお話しさせて頂いた SQLインジェクション対策 総”習”編 の公開用資料をSlideShareにアップロードしました。私のセッションを気に入って頂けた方が多かったようで何よりです。
関西DB勉強会、面白かったです。久々にお会いできた方もいました。超満員でもう少しで入りきれないほどでした。また参加できれば、と思っています。
PDFはこちらからダウンロードできます。
https://www.slideshare.net/yohgaki/sql-76168380
勉強会で使ったスライドは、面白おかしく柔らかい（？）スライドでした。あまり公開用には向いていません。実際に勉強会で使った資料が欲しい方はFacebookかメールで連絡してください。個別にお送りします。
セキュリティと必要十分条件については他のエントリでも書きました。以前書いたエントリではミクロの視点から単純な加算関数で考えました。今回はもう少し大きなマクロの視点、アプリケーションのセキュリティの必要十分条件を考えてみます。
論理的なセキュリティを考える為には必要なので書きました。ここに書いたことは読み物としては退屈かも知れませんが、重要な事だと考えています。
取り敢えず言語とプログラミングの基礎を学習し終えて、これから本格的にソフトウェア開発をしよう、という場合に困るのが「セキュリティ」です。今回は簡単に、これから本格的に開発を行う、という方向けに知っておくべき事を紹介します。
初めてTeratailに回答した内容を多少まとめて加筆したモノになっています。
https://teratail.com/questions/74317
ブログにしたので、Tratailの回答は単純にこのエントリを参照するように修正するかも知れません。
ずっと感じてきたことですが、ブログにしていませんでした。具体的には
戸締りする前に、金庫を買うセキュリティ対策
です。
IT技術者以外の方向けに書いています。最近問題だ、と話題のStruts2というソフトウェアを引き合いに書いていますが、技術的なことはほとんど書いてありません。
Googleは暗号を積極的に使っていることが知られています。暗号を積極的に使う理由を紹介します。
「信頼境界線の中で暗号を使っても、内部に侵入を許した時点で終わり」なので、「暗号を使っても意味がない」と考えているかも知れません。「リスクの廃除」だけが、セキュリティ対策ではありません。「リスクの緩和」もセキュリティ対策です。暗号は侵入を許してしまった場合のリスク緩和に効果的です。
前のエントリでFirefox + NoScriptによる内部ネットワークを守る方法を簡単に紹介しました。本当はネットワークを分離（物理的またはVLAN）し、それぞれに安全に利用できるプロキシーサーバー（ローカルネットワークのリソースにアクセスさせない、など）を用意して利用する方が良い、のですがこれには”それなりのモノと手間”が必要です。
Firefox + NoScriptだけでもかなり効果があるので改めて紹介します。前回紹介したのは10年も前ですね :D
信頼境界線（Trust Boundary）と境界防御はITセキュリティに限らず、セキュリティ対策の基礎中の基礎です。基礎中の基礎かつ最も重要な概念ですが習わないことが多いです。これが原因で「正しいセキュリティ対策」（≒効率的なセキュリティ対策）ができていないケースが多数あります。残念ながら”セキュリティに詳しい”とされている人でも全く理解していないケースが散見されます。
このエントリでは主に、ソフトウェアセキュリティに於ける信頼境界線の概念と引き方（≒セキュリティ構造/設計）、ついて紹介します。かなり長いエントリになりましたがお付き合いください。
最近、HMACハッシュ（hash_hmac）の使い方を書いてきたのでまとめです。
プログラム・コードが正しく動作する為の必要条件と十分条件を考えたことがあるでしょうか？
プログラム・コードが正しく動作する為の必要条件と十分条件とは何でしょうか？
映画などでPINコードを一桁づつ解析してドアを開錠する、といったシーンがあると思います。こんなのは”映画の世界だけ”と思っている方も多いと思います。しかし、タイミング攻撃を利用すると”実際にこれと全く同じ方法”で鍵となる情報を解析できます。
タイミング攻撃とはサイドチャネル攻撃の一種で、鍵情報を比較的簡単に解析する方法です。PHP 5.6からはタイミング攻撃に脆弱でない比較方法を提供しています。
結論から書くと、秘密の文字列を比較する場合
if ($secret_str !== $user_input) {
// ユーザー提供の秘密情報不一致
die('不正なアクセスです');
}
といった通常の文字列は比較は危険です。
if (!hash_equals($secret_st, $user_input)) {
die('不正なアクセスです');
}
上記のようにhash_equals関数を利用しなければなりません。
コンピュータで数値を正確に扱うのは「実は結構難しい」です。つまり「コンピューターは数値を正確に扱えない」という事です。「コンピューターが数値を正確に扱えない？！何を言ってるんだ？！」と思った方は是非読んでみてください。
ユーザーから整数値を受け取った時にその値が整数型の範囲内に収まるか、チェックしたいことがあります。
SQLの識別子（テーブル名やフィールド名）はプリペアードクエリではエスケープできません。最近の開発者はSQLの”パラメーター”には注意を払うようになったので、SQLパラメーターによるSQLインジェクションはかなり少くなってきました。
この結果、相対的にSQL識別子によるSQLインジェクション脆弱性の割合が増えています。実際、私がコード検査を行っているアプリケーションでも識別子が原因でSQLインジェクションに脆弱であるケースが半数くらいになっています。
出力対策はセキュアコーディングの基本の１つです。プリペアードクエリだけでSQLによるインジェクションは防げません。DBMSに限らず、他のシステム（ライブラリも含む。特に文字列をパースする正規表現、XML処理など）にデータを送信する場合、完全に無害化する必要があります。
Apache Struts2 の脆弱性対策について(CVE-2017-5638)(S2-045)は
という問題です。どうして「Content-Typeヘッダー」でコード実行ができたのか？気になったので調べたメモです。
コード実行ができた理由は「国際化（翻訳）用のメッセージ処理メソッドが、プログラミング言語のようにパースして実行する仕様」であったことでした。気にしていないとこのパターンでリモートコード実行ができてしまうコードも在ると思います。
強いデータ型を持つ言語は弱いデータ型の言語（PHPやJavaScriptなど）に比べよりセキュアなのか？「なぜよりセキュアなのか？」簡単に解説します。
結論から書くと「強いデータ型」はそれだけでは「強いセキュリティ構造」を作るモノではなく、少しだけ安全なコードを書く手助けくらいの効果しか期待できません。安全かつ正しく動作するプログラムを最小のコストで作りたい場合、契約プログラミングを行うのが効果的です。