yohgaki's blog

カテゴリー: Security

  • スクリプトアップロード対策（追加）

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

  • 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']);

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

    (さらに…)

  • SSLでの圧縮の利用は禁止

    他人のブログのコメントに書いて、自分のブログに書かないのも良くないので一応ここにも書いておきます。

    「SSLでの圧縮の利用は禁止した方が安全」です。

    (さらに…)

  • JavaScript: / の \ によるエスケープのみによるセキュリティ対策は禁止

    RFC 4696をもう一度読みなおしてみると/もエスケープ可能文字に定義してありました。JavaScriptのエスケープシークエンスの処理の部分も間違っていたので全面的に書き直します。

    (さらに…)

  • エンジニア必須の概念 – 契約による設計と信頼境界線

    少し設計よりの話を書くとそれに関連する話を書きたくなったので出力の話は後日書きます。

    契約による設計（契約プログラミング）（Design by Contract – DbC）は優れた設計・プログラミング手法です。契約による設計と信頼境界線について解説します。
    (さらに…)

  • LDAPエスケープ – PHPのldap_escape関数

    OWASP TOP10の1位のセキュリティ脅威はインジェクションです。

    https://www.owasp.org/index.php/Top_10_2013-A1-Injection

    SQLインジェクション、コマンドインジェクションはリファレンスとして掲載されていますが、何故かLDAPインジェクションは掲載されていません。しかし、OWASPの別の文書では簡単に解説されています。

    (さらに…)

  • 第一回 中国地方DB勉強会の資料

    第一回 中国地方DB勉強会の講師として参加させて頂きました。

    MySQLも使っていますが奥野さんの発表は普段気にしていなかったことも多く、とても参考になりました。

    私の資料もSlideShareにアップロードしました。

    データベースセキュリティ

    http://www.slideshare.net/yohgaki/ss-25042247

     PostgreSQL 9.3

    http://www.slideshare.net/yohgaki/postgre-sql-93

  • 入力バリデーションはセキュリティ対策として＊あてにする＊ものではありません

    ブログを書き出すと、次々に書きたくなるので困ったものです。

    徳丸さんに返信した前のエントリのリンクに「もう入力値検証はセキュリティ対策として *あてにしない* ようにしよう」とあったので補足しておきます。

    そもそも入力バリデーションは「あてにする」ような物ではありません。セキュリティ対策としては「転んだ時に役立つかも知れない杖」と捉えるべきです。役立つか役立たないかは分かりませんが、SANS/CWE TOP 25で「怪物的な緩和策」（Monster Mitigation）のNo 1として挙げられているセキュリティ対策です。

    つまり、毎年多数登録されるソフトウェア脆弱性データベースであるCVEデータベースのセキュリティ問題に対して、最も効果があるセキュリティ対策である、という事です。運任せでも統計的に役立つ事が実証されているセキュリティ対策を導入しないのは効果的なセキュリティ対策であるとは言えません。

    入力バリデーションは「あてにする」ような物ではありませんが、セキュリティ対策として必ずやるべき対策です。運任せなので、より幸運にも脆弱性が攻撃できない状況になるよう、ホワイトリスト方式で厳格にバリデーションするのが正しいやり方です。

  • 入力バリデーションはセキュリティ対策の基本

    徳丸さんとはホワイトリスト VS ブラックリストの議論から楽しく話をしています。私はホワイトリスト型で対処する方がよりセキュアであると考え、徳丸さんはブラックリストも変わらない。としています。考え方が反対なので楽しいのです。残念ながらあまりブログなどに時間を取りなくないのですが、わざわざ徳丸さんがブログを書いた、とツイッターで教えていただいたので簡単に返信しておきます。

    http://tumblr.tokumaru.org/post/55587596019

    私は「バリデーションはセキュリティ対策とは言えない」と思っているのですが、実は「世界の常識」という点に異論があるわけではなくて、話は逆なのです。「従来からバリデーションはセキュリティ対策としてとらえられてきて『世界の常識』となっているが、実はそれはおかしいのではないか?」という問題提起をしているのです。なので、「世界の常識だろ」と言われても、それでは反論になっていません。

    結論からいうと入力パラメータのバリデーションは世界のセキュリティ専門家によって非常に有用なセキュリティ対策だと認められています。

    ホワイトリストの基本中の基本は”デフォルトで全て拒否する”であることに注意してください。全て拒否した上で、許可するモノ、を指定しないとホワイトリストになりません。

    参考：プログラムが正しく動作するには、正しい「データ」と「コード」両方が必須。データのバリデーション（＝セキュリティ対策）がない対策はあり得ない。

    https://blog.ohgaki.net/software-security-without-data-security-is-impossible

    (さらに…)

  • Sessionアダプション脆弱性の修正

    やっとPHPのセッションアダプション脆弱性を修正するパッチとプルリクエストを作りました。議論は済んでいるのでパッチを検証、調整してマージするだけです。

    PHPに限らず、未初期化のセッションIDを正規のセッションIDとして受け入れてしまうセッション管理機構があります。（Javaとか）

    サイトで稼働している全てのアプリが正しいセッション管理（ログイン後にセッションID作り直す。ログオフで廃棄。一定時間経過後、セッションIDを再生成）を実行していれば良いのですが、共有環境や複数のアプリが使われる事が多いPHPでは特にリスクが高くなっています。

    未初期化のセッションIDを受け入れてしまうセッション管理機構は脆弱だと言って良いと考えています。セキュリティのベストプラクティスには確立されたセキュリティ手法（ベストプラクティス）はそのまま使うべき、というプラクティスがあります。つまり、信頼できるフレームワークのセッション管理機構をそのまま使いなさい、がベストプラクティスという事です。しかし、フレームワークとしてURLへのセッションID埋め込みをサポートしているのに、簡単に直せるセッションアダプションを修正しないフレームワークは到底「ベストプラクティスを実装している」と言える状態ではないと考えています。

    セッションアダプション脆弱性についてはPHPのWiki（英語のみ）に書いています。詳しくは以下のWikiを参照してください。

    (さらに…)

  • Webノウハウシェア2013のスライド

    5月24日（金）に開催されたWeb担当者向けのセミナーの「Webノウハウシェア2013」にBOSS-CON JAPANのPHP Security AlianceのCTOとして講演してきました。その講演のスライドです。


    http://www.slideshare.net/yohgaki/boss-conphp

    Javascriptを利用した内部ネットワークのスキャンが可能である事は良く知られていると思います。ここ数年セキュリティ研究者は更に企業ネットワーク内の奥深くに侵入する手法を研究しています。

    企業内のシステムはインターネットに公開するシステムに比べると甘いセキュリティ対策が採用される事が多いですが、インターネットと同様のセキュリティ対策を行わないと思わぬリスクが発生します。特にSSRFの脅威は広範囲に渡ります。正しく理解しておく必要があります。

    追記：PHPユーザに取って重要な事の1つを紹介しておきます。

    PHP-FPMを利用する場合、php_admin_value, php_admin_flagでphp.iniを設定する方が良いでしょう。手元のFedora18のNginx+PHP-FPMでPoCをそのまま実行した所、エラーになって攻撃は成功しませんでしたが、php.iniの設定をリモートから変更できるとする情報もあります。

    追記：ブログアプリ変更でリンクが無くなっていたので、SlideShareの方に公開しました。

  • セッションID管理は結局どうすれば良いのか？

    脆弱性やセキュリティ対策について技術的な話ばかりしていたので「それで結局PHPのセッション管理どうすれば良いの？」と思われた方も多いと思います。簡単にまとめます。漏れや追記した方が良い事などがあったらご指摘ください。

    (さらに…)