「フェイルセーフ」とは何なのか?

「フェイルセーフ」よく聞く言葉です。最近では「フェイルセキュア」1と言われることもありますが、基本概念は同じです。よく聞く言葉&簡単な概念ですが、割と広く誤解されている概念の1つに見えます。

フェイルセーフを一言で言うと

何かに失敗しても致命的な問題に至らないよう安全に失敗させる

これがフェイルセーフです。可能ならば「失敗/故障しても、失敗/故障の影響を受けないようする」場合もあります。ITシステムならRAID5や失敗時のリトライなどがこのケースです。

Wikipediaの定義では

フェイルセーフ(フェールセーフ、フェイルセイフ、英語fail safe)とは、なんらかの装置・システムにおいて、誤操作・誤動作による障害が発生した場合、常に安全側に制御すること。またはそうなるような設計手法で信頼性設計のひとつ。これは装置やシステムが『必ず故障する』ということを前提にしたものである。

となっています。

こんな単純な概念は間違いようがないでしょ?

と思うかも知れません。しかし、ソフトウェア開発では当たり前に誤解されています。

“「フェイルセーフ」とは何なのか?” の続きを読む

RDBMSから学ぶデータセキュリティ

RDBMSはデータセキュリティを学ぶには良い題材です。RDBMSはできる限り正しいデータを保存する仕組みがあるからです。RDBMSからどのようにデータのセキュリティを保証するのか紹介します。

プログラムが正しく動作する為には

  • 正しいコードであること
  • 正しい(妥当な)データであること

絶対条件です。どちらが欠けてもプログラムは正しく動作しません。

SQLiteは手軽で良いのですが、組み込み型であるためデータセキュリティを学ぶには機能的に問題があります。SQLiteにはデータ型を保証する機能もデータの内容を検証する機能もありません。1

利用するRDBMSはPostgreSQLを用い、データセキュリティに関連性の強い機能のみを対象とします。

“RDBMSから学ぶデータセキュリティ” の続きを読む

SQLクエリと識別子エスケープの話

Facebookでこんなやり取りをしました。元々公開設定で投稿した物で、議論させて頂いた浅川さんにも「ブログOK」と許可も頂いたので、そのやり取りの部分だけを紹介します。

テーマは「SQLクエリと識別子エスケープ」です。

とあるブログの結論として

“「安全な静的SQLの発行方法」を開発者に啓蒙すればいいだけだ。つまり

  • プリペアドクエリでSQL発行は行うこと
    この場合変数のバインドは必ずプレースホルダを用いること。

SQL文の文字列操作は禁止であり、これほどシンプルなことも無いだろう”

と書かれていました。しかし、私はこの意見に対して

実践的なSQLクエリを書いたことが全くない開発者なのでしょう??
ソートカラム、抽出カラムを指定するSQLクエリでは「識別子(カラム名)が変数」になります。
初歩的なSQLクエリですが”自分が書いたことないから”といって一般的ではないと勘違いしています。行のソート順、抽出カラムを指定するSQLクエリは業務アプリでは”一般的”です。当たり前ですが。

こうやってベストプラクティスもどきのアンチプラクティスが使われて、喜ぶのはサイバー犯罪者とセキュリティ業者だけですよ。

とコメントしました。SQLのテーブルやジョイン結果を「表」として表示した際に、任意のカラムのソート順を指定するUIは、自分で作ったことが無かったとしても、ごく一般的だと分かると思うのですが・・・

“SQLクエリと識別子エスケープの話” の続きを読む

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

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

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

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

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

PostgreSQL 10のICUコレーションとJIS X 4061

PostgreSQL Advent Calendar 9日目用のエントリです。

PostgreSQL 10のICUコレーション(照合順序)サポートの概要と基本的な使い方は以下のエントリに記載しています。ICUコレーションの使い方は以下を参照してください。

PostgreSQL 10のICUコレーションを使うと日本語を普通にソートでき、更に文字順序までカスタマイズできる

今回は日本語ソート順のJIS規格である JIS X 4061-1996にどの程度対応しているのか確かめてみます。

“PostgreSQL 10のICUコレーションとJIS X 4061” の続きを読む

PostgreSQL 10のICUコレーションを使うと日本語を普通にソートでき、更に文字順序までカスタマイズできる

PostgreSQL 10からICU(International Components for Unicode)のロケール/コレーションがサポートされました。

これまでサポートされてきた、libcのja_JPロケールの貧弱な日本語ソート機能とは比べ物にならないくらい高機能な文字比較をサポートしています。日本語や他の言語での照合順序を柔軟に変更できます。

  • マトモな日本語ソート順でソートする(かなり重要)
  • 数字を後にソートする
  • 大文字を先にソートする
  • 仮名を先にソートする
  • 自然ソートする
  • これらをまとめて特別なソート順にする

といったことがPostgreSQL 10から行えます。

“PostgreSQL 10のICUコレーションを使うと日本語を普通にソートでき、更に文字順序までカスタマイズできる” の続きを読む

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

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

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

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

本当にプリペアードクエリだけを使っていますか?

SQLクエリにはプリペアードクエリを使いましょう!と言われて久しいです。私もプリペアードクエリを積極的に使うべきだと考えています。

  • 多くの場合、速い
  • SQLパラメーターを分離して書くので「ついうっかり」が起こりにくい
    • 特に初心者は「ついうっかり」が多い

しかし、「プリペアードクエリだけを使っていれば良いので、エスケープは要らない」という意見には賛成できません。なぜ賛成できないのか?コードを見れば分かります。

何年か前に議論になった話題です。自分のエントリを検索して、たまたま見つけたのですが物がありました。

 

“本当にプリペアードクエリだけを使っていますか?” の続きを読む

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

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

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

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

 

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

SQL識別子のエスケープ

SQLの識別子(テーブル名やフィールド名)はプリペアードクエリではエスケープできません。最近の開発者はSQLの”パラメーター”には注意を払うようになったので、SQLパラメーターによるSQLインジェクションはかなり少くなってきました。

この結果、相対的にSQL識別子によるSQLインジェクション脆弱性の割合が増えています。実際、私がコード検査を行っているアプリケーションでも識別子が原因でSQLインジェクションに脆弱であるケースが半数くらいになっています。

出力対策はセキュアコーディングの基本の1つです。プリペアードクエリだけでSQLによるインジェクションは防げません。DBMSに限らず、他のシステム(ライブラリも含む。特に文字列をパースする正規表現、XML処理など)にデータを送信する場合、完全に無害化する必要があります。

参考: CERTトップ10セキュアコーディング習慣7. 他のシステムに送信するデータを無害化する

“SQL識別子のエスケープ” の続きを読む

StackExchangeが攻撃されたReDoSの効果

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

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

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

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

PostgreSQLでもカウンター処理を簡単に実装できる!

PostgreSQL 9.5がリリースされました。これに含まれるUPSERT機能を使えばPostgreSQLでも簡単にカウンター処理を実装できます。以前でもトリガーやルール、CTE(Common Table Expression)を使って実装できましたが、追加されたUPSERT機能を使った方が簡単です。

“PostgreSQLでもカウンター処理を簡単に実装できる!” の続きを読む

OWASP Secure Coding Practices – Quick Reference Guide

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

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

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

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

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

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

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

※ Agnostic(不可知論)について: このガイドは2010年に公開された文書です。最近、agnosticは「〜に依存しない」「〜に関わらず」「〜を問わず」「汎用的」「プラガブル」「詳しく知らなくても使える」といったコンテクストで割と一般的なIT用語として利用されています。2010年頃は哲学的意味が強かったと思いますが、現在は先に書いたような意味で使われているケースが多くあります。

参考資料:

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

不整合が起きてはならない場合、トランザクションはシリアライザブル

リレーショナルデータベースが優れている点はトランザクションをサポートしている点です。トランザクションは手続きが一貫性ある形で実行されることを保証してくれます。しかし、トランザクションを使えばOK、という物ではありません。

もしトランザクションさえ使っていればOKと思っていた方はトランザクション分離レベルを理解してください。

“不整合が起きてはならない場合、トランザクションはシリアライザブル” の続きを読む

PHP7で追加される整数型、浮動小数点型タイプヒントの問題点

PHP7では整数型、浮動小数点型、配列型のタイプヒントが追加されます。データ型をより厳格に取り扱うようになるのは良い事ですが、データ型を変換してしまうため問題となる場合もあります。

データ型は指定した型に変換すればよい、という単純な物ではありません。私はデータ型を変換しない方のRFCを支持していました。残念ながらこちらのRFCでなく、問題が多い方のRFCが採用されることになりました。

参考

“PHP7で追加される整数型、浮動小数点型タイプヒントの問題点” の続きを読む

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

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

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

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