入力の種類には3種類以上の種類、名前、電話番号、住所など沢山の種類があります。しかし、見方によってはたった3種類しかありません。この区別ができる／できない、で大きな違いができてしまいます。
カテゴリー: Secure Coding
-
SQLインジェクション対策 総”習”編 – 第五回関西DB勉強会
第五回 関西DB勉強会でお話しさせて頂いた SQLインジェクション対策 総”習”編 の公開用資料をSlideShareにアップロードしました。私のセッションを気に入って頂けた方が多かったようで何よりです。
関西DB勉強会、面白かったです。久々にお会いできた方もいました。超満員でもう少しで入りきれないほどでした。また参加できれば、と思っています。
PDFはこちらからダウンロードできます。
https://www.slideshare.net/yohgaki/sql-76168380
勉強会で使ったスライドは、面白おかしく柔らかい（？）スライドでした。あまり公開用には向いていません。実際に勉強会で使った資料が欲しい方はFacebookかメールで連絡してください。個別にお送りします。
-
アプリケーションのセキュリティと必要十分条件
セキュリティと必要十分条件については他のエントリでも書きました。以前書いたエントリではミクロの視点から単純な加算関数で考えました。今回はもう少し大きなマクロの視点、アプリケーションのセキュリティの必要十分条件を考えてみます。
論理的なセキュリティを考える為には必要なので書きました。ここに書いたことは読み物としては退屈かも知れませんが、重要な事だと考えています。
-
これから開発を始める場合のセキュリティ
取り敢えず言語とプログラミングの基礎を学習し終えて、これから本格的にソフトウェア開発をしよう、という場合に困るのが「セキュリティ」です。今回は簡単に、これから本格的に開発を行う、という方向けに知っておくべき事を紹介します。
初めてTeratailに回答した内容を多少まとめて加筆したモノになっています。
https://teratail.com/questions/74317
ブログにしたので、Tratailの回答は単純にこのエントリを参照するように修正するかも知れません。
-
信頼境界線の引き方と防り方 – セキュリティの構造と設計
信頼境界線（Trust Boundary）と境界防御はITセキュリティに限らず、セキュリティ対策の基礎中の基礎です。基礎中の基礎かつ最も重要な概念ですが習わないことが多いです。これが原因で「正しいセキュリティ対策」（≒効率的なセキュリティ対策）ができていないケースが多数あります。残念ながら”セキュリティに詳しい”とされている人でも全く理解していないケースが散見されます。
このエントリでは主に、ソフトウェアセキュリティに於ける信頼境界線の概念と引き方（≒セキュリティ構造/設計）、ついて紹介します。かなり長いエントリになりましたがお付き合いください。
-
コンピュータは数値さえ正確に扱えない
コンピュータで数値を正確に扱うのは「実は結構難しい」です。つまり「コンピューターは数値を正確に扱えない」という事です。「コンピューターが数値を正確に扱えない？！何を言ってるんだ？！」と思った方は是非読んでみてください。
-
PHPで整数オーバーフロー／アンダーフローをチェックする方法
ユーザーから整数値を受け取った時にその値が整数型の範囲内に収まるか、チェックしたいことがあります。
-
SQL識別子のエスケープ
SQLの識別子（テーブル名やフィールド名）はプリペアードクエリではエスケープできません。最近の開発者はSQLの”パラメーター”には注意を払うようになったので、SQLパラメーターによるSQLインジェクションはかなり少くなってきました。
この結果、相対的にSQL識別子によるSQLインジェクション脆弱性の割合が増えています。実際、私がコード検査を行っているアプリケーションでも識別子が原因でSQLインジェクションに脆弱であるケースが半数くらいになっています。
出力対策はセキュアコーディングの基本の１つです。プリペアードクエリだけでSQLによるインジェクションは防げません。DBMSに限らず、他のシステム（ライブラリも含む。特に文字列をパースする正規表現、XML処理など）にデータを送信する場合、完全に無害化する必要があります。
-
なぜ強い型を持つ言語はセキュリティ的に強いのか？ – データ型のバリデーションと構造化されたセキュリティ対策
強いデータ型を持つ言語は弱いデータ型の言語（PHPやJavaScriptなど）に比べよりセキュアなのか？「なぜよりセキュアなのか？」簡単に解説します。
結論から書くと「強いデータ型」はそれだけでは「強いセキュリティ構造」を作るモノではなく、少しだけ安全なコードを書く手助けくらいの効果しか期待できません。安全かつ正しく動作するプログラムを最小のコストで作りたい場合、契約プログラミングを行うのが効果的です。
-
パスワードのハッシュ化
HMACを使った鍵の生成（導出）方法を書いているので、念の為にパスワードのハッシュ化方法について書いておきます。一般にユーザー入力のパスワードをアプリケーションデータベース等に保存する場合、HMACやHKDFを使わずに、password_hash()を使うべきです。
参考：
-
ハッシュ（HMAC）を使って有効期限付きURL/URIを作る方法
より高度なCSRF対策 – URL/URI個別にバリデーションする方法でハッシュ（HMAC）を使えばデータベースを使わずに有効期限付きのURLを作れる、と紹介しました。今回は有効期限付きURL（URI）の作り方を紹介します。
-
ISO 27000の入力データ妥当性確認
セキュリティ標準では入力データの妥当性確認（入力バリデーション）が要求されています。具体的な方法はBS 7799（英国のJIS規格のような物、2000年に国際標準化）が作られた時（90年代後半）から記載されており、前の版までのISO 270001にも記載されています。2013年版のISO 27000ではセキュアプログラミングが普及したので具体的な方法などは省略しています。（日本では普及していないような。。）
セキュアプログラミングの基本中の基本がセキュリティ対策ではない、というような意味が全く解らない議論もあるのが現状です。
かなり昔に似たようなことを書いたようにも思いますが、記憶が定かではありません。今でも有効なので改めて（？）ブログにします。
-
完全なSQLインジェクション対策
不完全なSQLインジェクション対策だけで、SQLインジェクション対策は万全、と誤解しているケースが少なくないです。
- プリペアードクエリ／プレイスホルダを使ったSQLインジェクション対策でOK
は誤りです。「とにかくプレイスホルダを使おう」では脆弱性は無くなりません。
簡単な証明：プリペアードクエリ”だけ”では、識別子（カラム／テーブル等）を使うソートクエリ、特定カラム抽出クエリを”原理的”に無害化できない。識別子のエスケープ／バリデーションが必須。(問題はコレだけはありません）
似たような間違いに「出力対策をするのがセキュリティ対策」だとする考え方があります。こういう考え方になる原因はセキュリティ設計や原則を理解していないことにあると思われます。
https://blog.ohgaki.net/output-only-security-is-anti-practice
アンチプラクティスであっても正しく動作するならまだ良い方です。しかし、論理的・原理的に出力対策”だけ”では正しく動作するアプリケーションは作れません。
参考：