バリデーションには3種類のバリデーションがある 〜 セキュアなアプリケーションの構造 〜

バリデーション、と一言で言っても一種類/一箇所だけではありません。バリデーションには3種類のバリデーションがあります。

バリデーションは重要であるにも関わらず誤解が多い機能の筆頭だと思います。日本に限らず世界中でよくある議論に

  • バリデーションはモデルで集中的に行うべきだ!
  • なのでコントローラー(入力)でバリデーションなんて必要ない!
  • モデル集中型バリデーション以外の方法/場所でバリデーションするのは非効率で馬鹿馬鹿しい考えだ!

があります。どこかで見た事があるような議論ですが、世界的にこのような考えの開発者が多いことは、この入力バリデーション用のPHP拡張モジュールを書いた時の議論で分かりました。1

実際、多くのWebアプリケーションフレームワークは入力バリデーション機能をデフォルトでは持たず、アプリケーションレベルでの入力バリデーションを必須化していません。開発者が上記のような考えになっても当然と言えるかも知れません。しかし、必要な物は必要です。何故?と思った方はぜひ読み進めてください。

流石にこの時の議論ではありませんでしたが、以下の様な議論も見かけます(ました)

  • 入力データはバリデーションはできない!
  • どんな入力でもWebアプリは受け付けて”適切”に処理しなければならない!
  • 入力バリデーションにホワイトリスト型は無理、適用できない!
  • ブラックリスト型とホワイトリスト型のバリデーションは等しいセキュリティ対策!
  • 入力バリデーションはソフトウェアの仕様でセキュリティ対策ではない!

全てセキュアなソフトウェア構造を作るには問題がある考え方です。最後の「入力バリデーションはソフトウェアの仕様でセキュリティ対策ではない!」とする考え方の問題点は”セキュリティ対策の定義”2を理解していないと問題点は見えないかも知れません。

  • セキュリティ対策(=リスク管理)とはリスクを変化させる全ての施策で、多くの場合はリスクを廃除/軽減させる施策だが、それに限らない。

このセキュリティ対策の定義はISO 27000/ISMSの定義をまとめたモノです。

 

TL;DR;

入力対策と出力対策は両方必要でエスケープの知識はセキュアなソフトウェア構築には欠かせません。アプリケーションの入り口で入力検証をしていないアプリはセキュアでない構造です。入り口以外に入力検証がないアプリもセキュアではない構造です。セキュアなアプリには最低限、入り口でのデータ検証と出口でのデータ無害化(エスケープ/API/バリデーション)が必須です。

“バリデーションには3種類のバリデーションがある 〜 セキュアなアプリケーションの構造 〜” の続きを読む

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

「しっかり出力対策”だけ”するのがセキュリティ対策のベストプラクティス」とする考え方1があります。しかし、これはベストプラクティスどころかアンチプラクティスです。

アンチプラクティスをベストプラクティスと勘違いしている限り、満足のいくセキュリティ対策(=リスク管理)は不可能です。セキュリティ対策は総合的なリスク対策です。「これ”だけ”やれば良い」とするセキュリティ対策は大抵アンチプラクティス2です。

※ 今まで出力対策”だけ”がセキュリティ対策だと勘違いしていた方には確証バイアスが働きやすいようです。論理的/構造的にどうすればリスクを効果的に削減できるのか?を考えると理解るはずです。

“出力対策”のみ”のセキュリティはアンチプラクティス” の続きを読む

まだ誰も知らない脆弱性/攻撃に備える方法

セキュリティを考えると全ての入力データはアプリケーションがバリデーションすべきで、長さ/形式は厳格にバリデーションすべきです。1

厳格なバリデーションは開発者が意識/把握していない各種インジェクション脆弱性にも対応できること、インジェクション攻撃が持たらす被害が致命的であることが、その理由です。

適切なバリデーションは最強のセキュリティ対策の1つ2です。強いデータ型は弱いバリデーションの一種ですが、それでもセキュリティ対策として高い評価を得ています。にも関わらず強いバリデーションである厳格なデータバリデーションはコンピューターサイエンティストのセキュリティ専門家3以外にはあまり評価されていないように感じます。

今回は低レベルのライブラリにもコードインジェクション脆弱性のリスクがあること、その対策としてバリデーションが如何に効果的であるか紹介します。

“まだ誰も知らない脆弱性/攻撃に備える方法” の続きを読む

Railsユーザーが真っ先にするべきセキュリティチェック – Brakeman

Railsユーザーがソースコード検査やWebサイト診断を受ける前に真っ先に使った方が良いセキュリティ検査ツールがあまり使われていないように感じています。

Brakemanはかなり良くできたツールです。私は何年も前から補助的に使っています。

“Railsユーザーが真っ先にするべきセキュリティチェック – Brakeman” の続きを読む

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

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

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

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

 

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

なぜ強い型を持つ言語はセキュリティ的に強いのか? – データ型のバリデーションと構造化されたセキュリティ対策

強いデータ型を持つ言語は弱いデータ型の言語(PHPやJavaScriptなど)に比べよりセキュアなのか?「なぜよりセキュアなのか?」簡単に解説します。

結論から書くと「強いデータ型」はそれだけでは「強いセキュリティ構造」を作るモノではなく、少しだけ安全なコードを書く手助けくらいの効果しか期待できません。安全かつ正しく動作するプログラムを最小のコストで作りたい場合、契約プログラミングを行うのが効果的です。

“なぜ強い型を持つ言語はセキュリティ的に強いのか? – データ型のバリデーションと構造化されたセキュリティ対策” の続きを読む

正規表現でのメールアドレスチェックは見直すべき – ReDoS

前のエントリでStackExchangeがReDoSで攻撃されサイトがダウンした問題を紹介しました。少しだけ掘り下げて見たところ、正規表現だけでメールアドレスをチェックしている場合、壊滅的なReDoS(十分短い文字列で指数関数的に実行時間が増加する)が可能なことが判りました。

結論を書くと、正規表現でのメールアドレスチェックは見直すべき、です。(特にRubyユーザー)

追記:影響範囲はメールアドレスチェックに限らないので、正規表現チェックは全体的に見直さないと、どこが脆弱なのか判りません。見直してチェックしたとしても、それが完全であったと保証することは困難です。ネット検索して直ぐに見つかった検索パターンは非常に脆弱であったこと、メールアドレスのマッチパターンは脆弱になりやすい繰り返しの繰り返しが含まれること、これらがあったのでタイトルが「正規表現でのメールアドレスチェックは見直すべき 」になっています。

“正規表現でのメールアドレスチェックは見直すべき – ReDoS” の続きを読む

StackExchangeが攻撃されたReDoSの効果

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

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

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

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

セキュアなアプリケーションアーキテクチャ

セキュアなアプリケーションには共通したアーキテクチャがあります。基本的には防御的プログラミング(セキュアプログラミング)を行い、防御的プログラミングのテクニックの1つである契約プログラミングを実践したアーキテクチャがセキュアなアーキテクチャです。

アプリケーションのセキュリティ問題のほとんどはインジェクション問題です。インジェクション問題以外にもセキュリティ問題はありますが、ここではインジェクション問題のみを考慮します。

“セキュアなアプリケーションアーキテクチャ” の続きを読む

CERT Top 10 Secure Coding Practices

CERTは米カーネギーメロン大学に設置されたコンピュータセキュリティ対策を行う老舗の組織です。CERTが設立される前もセキュリティが無視されていたのではありませんが、CERT設立後と前ではコンピュータセキュリティ、特にソフトウェアセキュリティに対する考え方が大きく変わりました。詳しくはセキュアプログラミング(防御的プログラミング)の歴史をざっと振り返るを参照してください。

CERTはSecure Coding Standardsとして

を公開しています。その中でもセキュアコーディング(セキュアプログラミング/防御的プログラミング)で最も重要なトップ10をTop 10 Secure Coding Practicesとしてまとめています。

日本語訳が無いようなので資料として利用できるよう私訳しておきます。
(追記: 2017年からやっとIPAがCERT Secure Coding Practicesをセキュアコーディングの”原則”として紹介するようになりました。CERT版では当たり前に行う原則で重要度が低い原則として7番目に出力対策を記載しています。IPAは順序を変えて2番目にしています。トップ10の原則という場合に順序を入れ替えるのは混乱の元なのでオリジナルの順序のままにすべきだと思います。順序を変えると外国人とコミュニケーションが取れないリスクがあります。)

よく勘違いされているので書いておきます。入力対策と出力対策は”独立したセキュリティ対策”です。間違えないようにしましょう。

参考:

“CERT Top 10 Secure Coding Practices” の続きを読む

OWASP Secure Coding Practices – Quick Reference Guide

OWASPのガイドラインはPCI DSSでも参照するように指定されているセキュリティガイドラインです。その中でも比較的簡潔かつ体系的にセキュアプログラミングを解説した資料がOWASP Secure Coding Practices – Quick Reference Guide (v2) です。

日本語訳がないようなので一部未訳ですが訳しました。CC-BY-SAライセンスです。クリエイティブコモンズライセンスに従って自由に配布できます。

チェックリスト形式になっているので、自分のコーディング/開発スタイルがどの程度適合しているのか、簡単にチェックできるようになっています。コーディングスタイルのみでなく、運用はシステム構成に関連する物も含まれています。私が解説/紹介しているセキュリティ対策を行っている開発チームであればこれらの殆どに適合しているはずです。どのくらい適合していたでしょうか?

イントロダクションでは、開発者に対して少々厳しいことが書いてあります。

この技術的不可知論文書は一般的なセキュアコーディングを実践に必要な要素をソフトウェア開発ライフサイクルに統合可能なチェックリストとして定義します。

「技術的不可知論文書」(不可知論:物事の本質は人には認識することが不可能である、とする立場のこと)としているのは、この文書が取り扱うセキュアコーディングの本質が理解されていない、理解されることがない、と嘆いていることを意味します。セキュアコーディングの本質の解説は諦めて作ったチェックリストであることを示唆しています。私も同じ感覚を共有しています。興味がある方はぜひ以下の参考資料を参照してください。原理と原則を知った方が応用範囲が広がります。

正確な直訳より分かり易さを優先しました。見直しをする時間まではありませんでした。誤り、誤解を招く訳などの指摘を歓迎します。

参考資料:

“OWASP Secure Coding Practices – Quick Reference Guide” の続きを読む

今すぐできる、Webサイトへの2要素認証導入

Google、Facebook、Amazon(AWS)、Githubなど、大手Webサービス会社が2要素認証を取り入れてしばらく経っています。自分のWebサイトでも2要素認証を導入したい!と思ったことは無いですか?

簡単に可能です!

パスワード認証だけではもう安全とは言えません。ぜひ2要素認証を自分のサービス/プロダクトに導入してください。

“今すぐできる、Webサイトへの2要素認証導入” の続きを読む

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

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

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

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

安全なAPI過信症候群の処方箋 – execv/SQLite3編

またプリペアードクエリなど、安全とされるAPI万能と考えている方に会ったのでエントリを書きました。広く病気として治療すべき、と思いエントリを書きます。安全なAPI過信症候群と名付けました。

安全なAPI過信症候群(同類にプリペアードクエリ過信症候群など):「安全」とされるAPIを使えば安全と、盲目的に信用し考慮すべきリスクを考えない症候群。ITエンジニアが発症し最も重要なセキュリティ対策である入力バリデーションを「必要ない、できない、セキュリティ対策ではない」エスケープは「必要ない、有害である」とする場合、かなり重度の場合が多い。

このブログでは既に何度もプリペアードクエリクエリは不完全である、と指摘しています。プリペアードクエリを使っていれば安全と盲目的に信じている方向けの基礎知識を紹介します。コマンド実行APIのexecvと最も多く利用されているRDBMS、SQLite3が題材です。

現実を知れば安全とされるAPIを盲信することも危険だと解り、安全なAPI過信症候群を完治できると思います。

追記:普通のRDBMS編も作りました。SQLiteの仕様でデータ型がどうなっているか簡単に説明しました。

“安全なAPI過信症候群の処方箋 – execv/SQLite3編” の続きを読む

Rails ActriveRecordとSQLインジェクションと実際のアプリケーション

先日はActive RecordのSQLインジェクションパターンを紹介しました。今回は脆弱なコードを見つける事を試みようと思います。脆弱とは言っても攻撃可能であることは意味しません。コーディングとして脆弱であるという意味です。実際に攻撃可能であるかどうかまでは確認していません。

 

“Rails ActriveRecordとSQLインジェクションと実際のアプリケーション” の続きを読む