• タグ検索するならPostgreSQLで決まり!

    PostgreSQL Advent Calender 2013、13日目のエントリです。

    表題の通り「タグ検索するならPostgreSQLで決まり!」です。

    追記:JSONの場合はPostgreSQLのJSONB型を利用してタグ検索を行うを参照

    (さらに…)

  • オレオレSQLセキュリティ教育は論理的に破綻している

    ツイッターでの議論を見て「SQLエスケープを教える必要はない」とする原因は「教育の基本」と「セキュリティの基本」の理解不足が「根本的な原因」だと解ってきました。この事についてもブログを書くかも知れませんが、今日は「オレオレSQLセキュリティ教育」、言い換えると「自分の環境に特化したSQLセキュリティ教育」について書きます。一般論・基礎としてのセキュリティ教育は、自分の環境に特化したセキュリティ教育では困る、という話です。

    このエントリは「貴方が普段言っている事が間違っている」と非難または攻撃しているのではありません。実務で「プリペアードクエリ・プレイスホルダ・ORMを使いましょう」と言うことは全く間違っていません。セキュリティ教育はこういう手順で教えたほうが解りやすいです、と提案しています
    (さらに…)

  • エスケープファースト、この順序は変えられない

    アプリセキュリティ対策の根本的なセキュリティ対策は教育です。セキュリティ対策を教育する場合、エスケープファースト(エスケープを一番)にすると最も高い効果を期待できます。汎用性もあり、自己解決する能力も付きます。

    (さらに…)

  • PHP文字列のエスケープ

    PHP文字列をテキストとして出力したい場合もあります。PHPの文字列型はバイナリセーフなのでどのようなデータでも保存可能ですが、プログラム中でPHP変数をPHPのテキスト(リテラル)として出力するにはaddslashes()によるエスケープ処理が必要です。

    【重要】エスケープ/API/バリデーション1は出力先に合った方法でないと意味がないです。一口にHTMLと言っても複数の”コンテクストがあります。

    • JavaScript(識別子、変数など)、CSS、タグ属性名、タグ属性値(URIコンテクストに特に注意。BASE64、JavaScriptを使う場合もある)

    があります。
    SQLクエリと言っても

    • 引数(更にLIKE、正規表現、JSON、XMLなどに別れる)、識別子、SQL語句

    などがあります。全てのテキストインターフェースにコンテクスト2があります。
    それぞれの”コンテクスト
    に適切なエスケープ/API/バリデーションを利用しなければ意味がありません

    (さらに…)
  • このブログのadsense

    毎日書いていると毎日書きたくなるものですね。最近はセキュリティ関係の物ばかり書いていたので、このブログのAdsenseについて書きます。

    (さらに…)

  • ジョブセキュリティ:セキュリティ業界の為のセキュリティ対策ではありませんか?

    追記:このエントリの背景となる根拠の一部となる開発者は必修、SANS TOP 25の怪物的なセキュリティ対策に書きました。こちらも合わせてご覧ください。

    今日のエントリは「セキュリティ業界ジョブセキュリの為のセキュリティー対策になっていないか?」という話です。

    ジョブセキュリティ

    知らないと仕事にならないような、雇用を守る作用を持つ手法や知識のこと。

    セキュリティ対策は様々な対象を守る為に行いますが、このエントリではアプリケーションセキュリティを維持することだけを考えます。

    (さらに…)

  • エスケープを無くせばOK、と勘違いして失敗した事例 XPath 1.0

    昨日のブログでは.NETにはSQLのエスケープAPIが無いので、セキュリティ対策として本末転倒な状態になっている事を紹介しました。もう一つXPath 1.0の失敗例を紹介します。
    (さらに…)

  • IPAの「安全なSQLの呼び出し方」が安全になっていた

    IPAは「安全なSQLの呼び出し方」(PDF)を以下のURLから公開しています。

    http://www.ipa.go.jp/security/vuln/websecurity.html

    「安全なSQLの呼び出し方」は危険である、とするエントリを書こうかと思い、内容を確認するとそうでもありませんでした。

    訂正:ツイッターで徳丸氏に確認したところ、徳丸氏もエスケープを含めたSQLインジェクション対策が必要であると考えられていた、ことを確認しました。徳丸氏にはセキュリティ専門家として大変不名誉な記述であった事を訂正し、深くお詫びいたします。内容についての修正は、識別子エスケープについてブログに書くとの事でしたのでブログの内容を確認してから修正します。

    別冊の「安全なSQLの呼び出し方」は基本中の基本である「正確なテキストの組み立て」によるセキュリティ対策も解説しており、概ね安全な解説書になっています。

    (さらに…)

  • 根本的なセキュリティ対策とは?

    何年間も下書きのまま塩漬けになっていたエントリを多少修正して公開します。

    プログラミングではホワイトリスティングが基本ではプログラミング/システム開発とセキュリティに対する基本的な考え方をまとめて説明していませんでした。手短にこれらの基本的な考え方・解決策を紹介します。

    このエントリでは「アプリケーション開発における根本的なセキュリティ対策」を考えています。

    (さらに…)

  • PHP 5.6の新機能

    PHP Advent Calender 2013、3日目の参加エントリです。前日のPHP の配列を使った手品とその種明かしに続き3日目です。PHPの配列(ハッシュ)のキーはバイナリセーフなので何でも入れられる、ということはあまり知られていないですよね。面白い話だったと思います。

    私のネタには面白さはありません。予めご了承ください :-)

    さて今日のテーマのPHP5.6新機能です。PHPプロジェクトのgitレポジトリでは既にPHP5.6用のブランチが作成されています。PHP 5.6は来春リリース予定です。

    大ニュース(?)だったので多くの方はご存知だと思いますが、PHPは毎年新しいマイナーバージョンをリリースします。メンテナンスされるのは2つのバージョンのみです。つまりPHP 5.6がリリースされるとPHP 5.4はEOL(メンテナンス停止。+1年のセキュリティフィックスのみ)になります。来春にPHP 5.3は完全終了です。皆さん、準備はできているでしょうか?(まだまだ色々機能を付けなければなりませんが、個人的にも困るのでアップグレードを容易にするPROVE for PHPというツールを開発しています。よろしければ試用してみてください。)

    前置きが長くなりましたがPHP 5.6の新機能を紹介します。

    (さらに…)

  • スクリプトアップロード対策(追加)

    スクリプトアップロード対策は既に書きましたが、書き漏らしていたので追加します。
    (さらに…)

  • WordPressの脆弱性調査プロジェクト Day of bugs in WordPress3 始まる

    Full Disclosureに以下のようなメールが投稿されていました。

    Day of bugs in WordPress3が始まるようです。
    (さらに…)

  • いまさら聞けないWebアプリセキュリティの基本ルール

    C言語の最も重要なセキュリティの基本ルールは「メモリをきっちり管理する」です。もちろん他にもプログラミングをする上で注意しなればならない事は山ほどありますが、C言語でプログラミングする上で最も基本的なセキュリティのルールは「正確なメモリ管理」です。

    Webアプリを作る上でのセキュリティの基本ルールは何でしょうか?

    今回はWebアプリセキュリティはもっとシンプルに考えよう!という話です。

     

    (さらに…)

  • フィルター/デコード時のセキュリティ対策の鉄則

    ブラックリスト型(サニタイズ型)のセキュリティ対策クイズ 解答編 ではバリデーション時の注意点をまとめに書きました。

    ホワイトリスト型のバリデーションを行う場合でも以下の項目に注意しなければなりません。

    • 特殊な意味を持つ文字を許可する場合、細心の注意を払う
    • そもそも特殊な意味を持つ文字は許可しない方が良い
    • 絶対の自信が無いのであれば、特殊な意味を持つ文字を許可してはならない

    ブラックリスト型(サニタイズ型)のセキュリティ対策クイズ 解答編 でパストラバーサルを禁止するようなフィルター処理(ブラックリスト型サニタイズ処理)は基本的には行うべきではありません。しかし、どうしてのフィルター/デコード処理が必要になる場合があります。
    (さらに…)

  • ブラックリスト型(サニタイズ型)のセキュリティ対策クイズ 解答編

    昨日のエントリのクイズです。今回はその解答です。もう一度問題を書いておきます。

    ブラックリスト型のセキュリティ対策は、どうしても仕方がない限り使ってはなりません。以下のサニタイズコードは “../” 、”..” を無効な文字列として取り除きます。このサニタイズコードを回避しカレントディレクトリよりも上の階層からのパスへアクセスするパストラバーサルを行う文字列を考えてみて下さい。(/etc/passwdなどにアクセスできる文字列を考えて下さい)

    レベル1

    <?php
    if ($_GET['filename']{0} === '/') {
       // 絶対パスは無効
       die('無効なファイル名が送信されました。');
    }
    // トラバーサルに利用される"../", ".."を削除
    // カレントディレクトリ以下のファイルだけ読み込む?
    $safe_path = str_replace(array('../', '..'), '', $_GET['filename']);
    readfile($safe_path);

    簡単すぎた方はレベル2をどうぞ。以下のコードはブラックリスト型チェックでパストラバーサルに利用される “.” が1つしか無いことでセキュリティを維持しようとするコードです。

    レベル2

    <?php
    if ($_GET['filename']{0} === '/') {
       // 絶対パスは無効
       die('無効なファイル名が送信されました。');
    }
    if (strpos($_GET['filename'], '.') !== strrpos($_GET['filename'], '.')) {
       // トラバーサルに利用される"."は1つしか許さない
       die('無効なファイル名が送信されました。');
    }
    // カレントディレクトリ以下のファイルだけ読み込む?
    readfile($_GET['filename']);

    まだ解いていない方は少しだけ時間を使って考えてみて下さい。

    (さらに…)