Security – ページ 15 – yohgaki's blog

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

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

Security

SSLでの圧縮の利用は禁止

11月 19, 2013 #脆弱性投稿者 yohgaki

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

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

Security

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

11月 16, 2013 投稿者 yohgaki

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

Computer, PHP Security, Programming, Secure Coding, Security

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

11月 3, 2013 #セキュアコーディング論理, #ゼロトラスト, #ベストプラクティス, #信頼境界, #入力バリデーション, #出力対策, #契約プログラミング投稿者 yohgaki

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

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

PHP Security, Security

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

10月 28, 2013 #LDAP, #エスケープ, #セキュアコーディング技術投稿者 yohgaki

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

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

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

Database, Security

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

8月 8, 2013 #MySQL, #PostgreSQL, #SQLite, #SQLインジェクション, #プレゼンテーション投稿者 yohgaki

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

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

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

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

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

PostgreSQL 9.3

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

PHP Security, Security

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

7月 16, 2013 #入力バリデーション投稿者 yohgaki

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

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

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

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

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

PHP Security, Security

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

7月 16, 2013 #アンチプラクティス, #セキュアコーディング論理, #入力バリデーション投稿者 yohgaki

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

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

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

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

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

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

データのセキュリティ対策が無いセキュリティ対策？！

Computer, Programming, Security

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

6月 26, 2013 #PHP, #セッション管理, #脆弱性投稿者 yohgaki

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

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

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

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

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

Computer, Development, PHP Security, Programming, Security

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

6月 1, 2013 #PHP, #プレゼンテーション投稿者 yohgaki

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の方に公開しました。

PHP Security, Security

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

12月 14, 2012 #PHP, #セキュアコーディング技術, #セッション管理, #認証投稿者 yohgaki

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

カテゴリー: Security