エンジニアなら分かる文字エンコーディングバリデーションの必要性

入力バリデーションで文字列の妥当性を検証(保証)しないと、不正文字問題の解決はできません。

よく「文字エンコーディングバリデーションは入力バリデーションしなければならない」と紹介はするのですが、その理由を詳しく解説していませんでした。これは文字エンコーディング攻撃の仕組みを理解してれば分かる事なのでしていませんでした。

しかし、文字エンコーディング攻撃の仕組みを理解していても必要なし、とする意見があるので理解り易く説明します。(理解りづらかったら教えてください)UTF-8のみですが、他の文字エンコーディングでも基本は同じです。

“エンジニアなら分かる文字エンコーディングバリデーションの必要性” の続きを読む

セキュリティ対策が論理的に正しいか検証する方法

全てのセキュリティ対策は緩和策だと考えるべきです。これは個々の対策が完全であるか検証することが容易ではないからです。例えば、SQLインジェクション1つとっても本当に完全であるか?検証することは容易ではありません。プログラムが本当に思っているように動作するのか?検証する研究は、まだまだ研究段階です。

しかし、容易ではないからといって諦める訳にもいきません。不完全であっても形式的な論理検証は容易にできます。

“セキュリティ対策が論理的に正しいか検証する方法” の続きを読む

SQLインジェクション対策 総”習”編 – 第五回関西DB勉強会

第五回 関西DB勉強会でお話しさせて頂いた SQLインジェクション対策 総”習”編 の公開用資料をSlideShareにアップロードしました。私のセッションを気に入って頂けた方が多かったようで何よりです。

関西DB勉強会、面白かったです。久々にお会いできた方もいました。超満員でもう少しで入りきれないほどでした。また参加できれば、と思っています。

PDFはこちらからダウンロードできます。

 

勉強会で使ったスライドは、面白おかしく柔らかい(?)スライドでした。あまり公開用には向いていません。実際に勉強会で使った資料が欲しい方はFacebookかメールで連絡してください。個別にお送りします。

完全なSQLインジェクション対策

不完全なSQLインジェクション対策だけで、SQLインジェクション対策は万全、と誤解しているケースが少なくないです。

  • プリペアードクエリ/プレイスホルダを使ったSQLインジェクション対策でOK

は誤りです。「とにかくプレイスホルダを使おう」では脆弱性は無くなりません。

簡単な証明:プリペアードクエリ”だけ”では、識別子(カラム/テーブル等)を使うソートクエリ、特定カラム抽出クエリを”原理的”に無害化できない。識別子のエスケープ/バリデーションが必須。(問題はコレだけはありません)

似たような間違いに「出力対策をするのがセキュリティ対策」だとする考え方があります。こういう考え方になる原因はセキュリティ設計や原則を理解していないことにあると思われます。

出力対策”のみ”のセキュリティはアンチプラクティス

アンチプラクティスであっても正しく動作するならまだ良い方です。しかし、論理的・原理的に出力対策”だけ”では正しく動作するアプリケーションは作れません

参考:

“完全なSQLインジェクション対策” の続きを読む

StackExchangeが攻撃されたReDoSの効果

StackExchangeがReDoS攻撃に遭いサイトがダウンした原因をStackExchangeのブログで紹介していました。

PHPへの影響があるか試してみました。結論を書くと、脆弱な正規表現を使っていて攻撃者が入力をコントロールできる場合、簡単に攻撃できるようです。PCRE、Onigurumaの両方で試してみましたがどちらも脆弱でした。

参考:正規表現でのメールアドレスチェックは見直すべき – ReDoS Onigurumaでは破滅的なReDoSが可能です。以前からメールアドレスのチェックに利用する正規表現には注意喚起していましが、どの程度浸透していたのだろうか?

“StackExchangeが攻撃されたReDoSの効果” の続きを読む

ほとんどのセキュリティ問題はインジェクション問題 – インジェクションパターンとして理解すると簡単

セキュリティ問題のほとんどはインジェクション問題と考えることができます。インジェクション問題として考えられるセキュリティ問題のモデル化を考えます。

実際のセキュリティ問題は多種多様で非常に複雑ですが、シンプルなモデルで考えると理解り易く、多くのセキュリティ問題を体系的に理解できます。

“ほとんどのセキュリティ問題はインジェクション問題 – インジェクションパターンとして理解すると簡単” の続きを読む

Memcachedのプロトコル仕様とセキュリティ – Memcachedでもインジェクションが可能

Memcachedはテキストプロトコルとバイナリプロトコルの二種類を持っています。デフォルトはテキストプロトコルです。テキストプロトコルを利用している場合、テキストインターフェース処理の基本を理解した上で利用しないとセキュリティ問題が発生します。こういった処理のセキュリティ対策を行う、確認するには実は標準の方が簡単で明解 – セキュリティ対策の評価方法も参考になります。

Memcachedはキーバリュー型なのでSQLインジェクションのような脆弱性とは無縁、と思っていた方は是非読んでみてください。

“Memcachedのプロトコル仕様とセキュリティ – Memcachedでもインジェクションが可能” の続きを読む

インジェクション対策、基礎の基礎

インジェクション攻撃には様々な手法があります。メモリ管理をプログラマが行うC言語などではメモリにインジェクションするバッファローオーバーフロー/アンダーフロー、テキストベースのインターフェースではテキストインジェクション(JavaScriptインジェクション、SQLインジェクションなど)があります。

これらのインジェクション脆弱性はなぜ発生するのでしょうか?

今回は「インジェクション対策、基礎の基礎」の話です。

“インジェクション対策、基礎の基礎” の続きを読む