ほぼ全てのインジェクション攻撃を無効化／防止する入力バリデーション 〜 ただし出力対策も必須です 〜
(Last Updated On: 2019年2月18日)入力バリデーションはセキュリティ対策として最も重要なセキュリティ対策です。なぜセキュリティ対策であるのか？を理解していない方も見かけますが「ほぼ全てのインジェクション攻撃を無効化／防止する入力バリデーション」の効果と拡張方法を見れば解るのではないでしょうか？ ソフトウェア開発者が知っておくべきセキュリティの定義／標準／ガイドで紹介しているセキュリティガイドラインでは入力バリデーションが最も重要なセキュリティ対策であるとしています。 厳格な入力バリデーションを行うと、開発者が意識しなくても、非常に多くの脆弱性を利用した攻撃を防止できます。今回は比較的緩い入力バリデーション関数でも、ほとんどのインジェクション攻撃を防止できることを紹介します。 重要：セキュア／防御的プログラミングでは入力と出力のセキュリティ対策は”独立”した対策です。ど
PHP7の現状
(Last Updated On: 2018年8月13日)PHP7が今年の秋リリースされる予定です。まだまだ多くの変更が行われる予定ですが、現状を簡単にまとめてみたいと思います。代表的な物のみ取り上げています。 ご存知ない方の為に書いておきます。現在リリースされているPHPはPHP5です。次のPHPはPHP7になり、PHP6はリリースされません。PHP6をUnicodeをネイティブ文字列としてサポートするバージョンとして開発されましたが、文字エンコーディングチェックを内部で自動的に行おうとするなど、無駄が多く遅いため破棄されました。（文字エンコーディングのバリデーションは本来アプリでするものです）このため、PHP6はスキップされ次のPHPはPHP7になります。 追記：PHP7.0は既にリリースされています。概要はPHP 7.0の概要・新機能・互換性、詳しくはマイグレーションドキュメントをご
ジョブセキュリティ：セキュリティ業界の為のセキュリティ対策ではありませんか？
(Last Updated On: 2018年8月4日)追記：このエントリの背景となる根拠の一部となる開発者は必修、SANS TOP 25の怪物的なセキュリティ対策に書きました。こちらも合わせてご覧ください。 今日のエントリは「セキュリティ業界ジョブセキュリの為のセキュリティー対策になっていないか？」という話です。 ジョブセキュリティ 知らないと仕事にならないような、雇用を守る作用を持つ手法や知識のこと。 セキュリティ対策は様々な対象を守る為に行いますが、このエントリではアプリケーションセキュリティを維持することだけを考えます。 セキュリティで飯を食べるには脆弱性が量産されればされるほど困る事はありません。脆弱性を量産するには基本的なセキュリティ対策を教えないことが最も効果的です。 SANS/CWE TOP 25では、ソフトウェアの脆弱性を無くす為に最も効果的なセキュリティ対策は「確実な入
IPAの「安全なSQLの呼び出し方」が安全になっていた
(Last Updated On: 2018年8月4日)IPAは「安全なSQLの呼び出し方」（PDF）を以下のURLから公開しています。 http://www.ipa.go.jp/security/vuln/websecurity.html 「安全なSQLの呼び出し方」は危険である、とするエントリを書こうかと思い、内容を確認するとそうでもありませんでした。 訂正：ツイッターで徳丸氏に確認したところ、徳丸氏もエスケープを含めたSQLインジェクション対策が必要であると考えられていた、ことを確認しました。徳丸氏にはセキュリティ専門家として大変不名誉な記述であった事を訂正し、深くお詫びいたします。内容についての修正は、識別子エスケープについてブログに書くとの事でしたのでブログの内容を確認してから修正します。 別冊の「安全なSQLの呼び出し方」は基本中の基本である「正確なテキストの組み立て」によるセ
セキュリティ専門家でも間違える！文字エンコーディング問題は難しいのか?
(Last Updated On: 2018年8月13日)一見徳丸さんのブログは分かりやすいように思えますが、それは単純な実験により分かりやすいように見えるだけで複数の間違いがあります。 その間違いとは 意図の取り違い – 誤読 言語の仕様と実装の理解不足 HTTPやPHP仕様の理解不足 セキュリティ対策をすべき場所の理解不足 です。(※0) 徳丸さんは非常勤とは言え、国の出先機関の研究員であるし、その出先機関は職務放棄とも言える文書（「例えば、PHPを使用しない」と勧める文書）を公開している(いた?)のでしっかり反論しておく必用がありますね。IPAのあの文書は職務放棄と言える文書だと思っています。これについても後で意見を述べます。 意図の取り違い – 誤読 最初の間違いは私のブログのエントリ「何故かあたり前にならない文字エンコーディングバリデーション」に対する理解です。特にPHPユーザに
PHP4.4.9のセキュリティ状態
(Last Updated On: 2018年8月13日)PHP4のサポートは2008/8/8を持って終了しました。サポート終了に合わせて、最後のPHP4リリースとなる4.4.9がリリースされています。サポートが終了していますが、稼動中のPHPの半分はまだPHP4であるとる統計情報もあり、まだまだ現役です。 PHPプロジェクトのサポート終了したため、PHP 4.4.9のセキュリティ脆弱性はCVEなどでも報告されなくなりました。この為、普通にセキュリティ情報を収集していてもPHP4.4.9に対する脆弱性情報は入手できません。 PHP4セキュリティ保守サービスではPHP 4にも対応しています。サポートしている脆弱性の概要は、弊社のお知らせをご覧下さい。 まだまだ、SQLインジェクションが無くなっていない事は非常に残念です。PHP4で作られたWebアプリケーションはSJISやEUCを文字エンコー
現行版のPHPに任意メモリ参照バグ – 攻撃コード付き
(Last Updated On: 2018年8月13日)随分前から共有型Webホスティングサービスでは安全性を確保できないので、安全性を重視するサイト(ECなど)は最低限でも仮想ホスト型の共有サービスを利用すべきである、と言っています。 今回のエントリはPHPをApacheモジュールで共有型ホスティングサービスを利用しているユーザに影響します。SSLを利用している場合は秘密鍵を盗まれます。このバグはPHP 5.2.8でも修正されていません。当然ですがPHP 4.4.9でも修正されていません。 Milw0rmのアドバイザリ http://www.milw0rm.com/exploits/7646 には、そのまま使える、任意のアドレスのデータを参照するコードまで付いています。秘密鍵を盗むことは簡単です。 誤解してはならない事ですが、これはPHPに限った問題ではありません。PHPでは度々このよ
PHP開発者とユーザが知っておくべきシェルコマンドエスケープの内部処理
(Last Updated On: 2018年8月13日)これから紹介する脆弱性はPHP 5.2.6で修正されています。修正された、とは言え注意が必要です。 PHPは古くからシェルコマンドとシェル引数をエスケープ処理する為に、escapeshellcmd関数とescapeshellarg関数を提供しています。 この関数はマルチバイト文字にも対応しているのですが、ビルドや環境によっては対応できていないときがあります。 escapeshellcmd/escapeshellarg関数ではC99で定義されてるmblen関数を利用しています。一般的なUNIX系システムではmblen関数は利用可能でると考えられるので、問題となる事は少ないと思いますが、PHPではphp_mblenマクロが以下のように定義されています。 #ifndef HAVE_MBLEN # define php_mblen(ptr,
SET NAMESは禁止
(Last Updated On: 2018年8月13日)MySQLには文字エンコーディングを変更する「SET NAMES」SQL文が用意されています。（PostgreSQLも同様のSQL文、SET CLIENT_ENCODINGがあります）この機能はSQLコンソールからは使ってよい機能ですが、アプリケーションからは使ってはならない機能です。SQLインジェクションに脆弱になる場合があります。 Ruby on Railsの本を読んでいて、ActiveRecordを説明している部分にMySQLの文字エンコーディングを変更する場合の例としてSET NAMESが利用されていました。アプリケーションからはSET NAMESは使ってはならない事を周知させるのは結構時間が必要かなと思いました。 PHPも5.2の途中からMySQLモジュールにlibmysqlの文字エンコーディング設定APIのラッパー関数が
プログラミングではホワイトリスティングが基本
(Last Updated On: 2018年8月8日)「ホワイトリスト方式の優位は神話」と題するエントリに私のブログホワイトリストはどう作る? が引用されている事を教えていただきました。 ホワイトリストの基本中の基本は”デフォルトで全て拒否する”であることに注意してください。全て拒否した上で、許可するモノ、を指定しないとホワイトリストになりません。 誤解されないように書こうとすると、どうしても長文になります。暇な方だけお付き合いください。 参考： セキュリティを論理的に構築する方法 （こちらは科学的なセキュリティの基本構造の作り方の話です。ぜひどうぞ） 意地悪なブログエントリと書籍の文章 まず、ちょっと意地悪なブログエントリと書籍の文章を同列に比較されても困ります。言い訳ですが著書の”Webアプリケーションセキュリティ対策入門”では金床さんと同様の表現になっています。90年代にホワイトリ
誤解を招く記事 – LAMPセキュリティを強化する4つの方法
(Last Updated On: 2014年12月5日)LAMPセキュリティを強化する4つの方法 http://enterprisezine.jp/article/detail/311 書いてある情報は有用な事も記載されていますが、偏狭な視点からの記述により誤解を招く記事になっていると考えられます。著者はセキュリティの専門家ではないようなので仕方ないかも知れませんが、間違った認識は有害です。 # 原本は読んでいません。もしかすると日本語訳にも問題があるのかも知れません。 実行できる最も重要な対策は、PHPを使わないことです。腐った果物を導入する前に、以下に目を通してください。 後にPerl/Ruby/Pythonの方がかなり安全である旨の記述があります。メモリ管理が必要ない同じスクリプティング言語のレベルで「Perl/Ruby/Pythonを使えばセキュアなアプリケーションができる」と考
ホワイトリストはどう作る?
(Last Updated On: 2018年8月13日)まずホワイトリストの基本中の基本は”デフォルトで全て拒否する”であることに注意してください。全て拒否した上で許可するモノを指定しないとホワイトリストになりません。 例えば、CSPはホワイトリストで不正なJavaScriptの実行を防止する仕組みです。2016年のGoolgeの調査によると95%のCSP定義が、実際にはJavaScriptインジェクション脆弱性の防止に役立っていない、との調査結果を発表しています。原因はホワイトリストの作り方の基本、全て拒否した上で許可するモノを指定する、を理解していないことにあると考えられます。1 私はいつも基本的に能動的なセキュリティ対策2を選択するようにお勧めしています。能動的なセキュリティ対策とは全ての入力値の厳格なバリデーション処理であり、出力時に過剰とも言えるエスケープ処理です。入力／出力の
UPnPルータ+Flash=深刻なセキュリティ問題
(Last Updated On: 2008年1月18日)GNUCITIZENは重要なセキュリティ問題を次々に公開しているのでセキュリティに興味がある方はチェックしているのでご存知とは思いますが、 Hacking The Interwebs http://www.gnucitizen.org/blog/hacking-the-interwebs に非常には深刻なセキュリティ問題が解説してあります。具体的な攻撃方法などはGNUCITIZENを参照してください。日本でもいろいろ書かれるかな、と思っていたのですが予想より少ないのでブログに書くことにします。ここでは重要な部分だけ要約して書きます。 攻撃 Flashを利用したUPnPルータの攻撃シナリオは以下になります。 UPnPが有効なルータがある 悪意のあるFlashをWebブラウザで参照する UPnPルータの設定を変更するSOAPリクエストを
Webアプリスキャナの性能
(Last Updated On: 2013年12月3日)NTOSpider, AppScan, WebInspectとメジャーなWebアプリスキャナの性能を比較した方がいるようです。結果のPDFは以下のURLです。 クリックしてCoverageOfWebAppScanners.pdfにアクセス Forty Tracerを使ってスキャン中のコード実行カバレッジを利用してアプリケーションスキャナの性能を評価しています。 結論はNTOSpiderがダントツの性能のようです。AppScan、WebInspectは同じ程度となったようです。いずれにせよWebアプリスキャナは「セキュリティを維持」する為のツールではなく「最低限のセキュリティが維持できているかチェック」する為のツールなので多少の性能差ならそれほど気にする必要はないでしょう。しかし、多少と言える性能差ではないのでIBMとHPには頑張って
yohgaki's blog - いろいろ変わったXSSがありますが...
(Last Updated On: 2007年10月12日)私が知らなかっただけかもしれませんが、これにはかなり驚きました。いろんな所で問題が指摘されていますが、ECMAScriptにXML機能を追加したのはどうなんでしょうね…. 確かにかなり便利なのですが以下のコードでスクリプトが実行されることはほとんど知られていないでしょうね。 <script> 123[”+<_>ev</_>+<_>al</_>](”+<_>aler</_>+<_>t</_>+<_>(1)</_>); </script> 好むと好まざる関係なくFirefox 1.5から使えるのでWeb開発者は知っておかなればならないです。 日本語訳 http://www.ne.jp/asahi/nanto/moon/specs/ecma-357.html 原文 http://www.ecma-international.org/pu
サーバシグニチャは隠すのが当たり前
(Last Updated On: 2007年9月4日)私も何年も前からセミナーではサーバ、モジュールバージョンは隠すようにと言っています。何故こんな事で賛否両論になるのか全く理解できません。犯罪者がどのように攻撃するか？を考えればなぜ隠す必要があるのか理由は明白です。サーバのバージョン情報が詳しく公開されていれば、その情報を使うに決まっています。攻撃に使える情報は全て使わない訳がありません。 最新版を使っているから安全ではない事も明白です。サーバに0day攻撃の脆弱性が発見された場合どの情報を使います？公開または推測できるバージョン情報に決まっています。 フィンガープリンティングでかなりの確率で推測可能、という議論もあるとは思います。しかし、適切に運用／設定されているシステムなら細かいバージョン番号までは推測できない場合が多いと考えられます。 犯罪者が攻撃に利用している、利用する可能性が
SHA1でハッシュ化したパスワードは危険になった
(Last Updated On: 2018年4月3日)パスワードを平文で保存するのは論外で、MD5やSHA1でハッシュ化するのは当たり前です。しかし、SHA1を2000倍早くクラックする方法などが発見され「SHA1は脆弱だ」（ちなみにMD5はもっと危険）とされてからしばらく経ちます。アメリカ政府や大手企業はSHA1は使わない、としています。 Slashdot.orgにまた載っているので更に高速化できた、ということか? 参考： RainbowテーブルによるMD5ハッシュのクラック（英語） RainbowテーブルによるSHA1ハッシュのクラック（英語） 前のエントリ PostgreSQLでSHA1 でPostgreSQLでSHA1を使う方法の一つを紹介していますが可能であればSHA512など、より強いハッシュ関数を利用したり、Saltを利用する、等の方法を採用した方が良いと思います。 備考：
httpOnlyをFirefoxで
(Last Updated On: 2018年8月13日)PHP 5.2.0のsetcookie/setrawcookie関数からhttpOnly属性をクッキーにつける事ができるようになりました。httpOnly属性はMicrosoftが独自に拡張した仕様で、JavaScriptからクッキーの値を使用できなくする機能です。httpsでのみクッキーを送信するsecure属性に似ています。 Microsoftの独自拡張なのでIEでは利用できましたがFirefoxでは利用できません。しかし、アドオンを使用することでhttpOnly属性をFirefoxでも利用できるようです。 httpOnly by Stefan Esser Adds httpOnly cookie support to Firefox by encrypting cookies marked as httpOnly on the
まちがった自動ログイン処理
(Last Updated On: 2018年8月20日)問題：まちがった自動ログイン処理の解答です。このブログエントリは最近作られたアプリケーションでは「問題」にしたような実装は行われていないはず、と期待していたのですがあっさり期待を破られたのでブログに書きました。このブログの方が詳しく書いていますけが「Webアプリセキュリティ対策入門」にも正しい自動ログイン処理を書いています。 参考：自動ログイン以外に2要素認証も重要です。「今すぐできる、Webサイトへの2要素認証導入」こちらもどうぞ。HMACを利用した安全なAPIキーの送受信も参考にどうぞ。 間違った自動ログイン処理の問題点 まず間違った自動ログイン処理を実装しているコードの基本的な問題点を一つ一つ順番にリストアップします。 クッキーにランダム文字列以外の値を設定している クッキーにユーザ名が保存されている クッキーにパスワードが保
また別の文字エンコーディング問題
(Last Updated On: 2006年6月23日)HTTPヘッダでASCIIを文字エンコーディングに設定していてもISO-8859として解釈してしまうブラウザ（Firefox、Operaなど）とASCIIとして解釈するブラウザ（IE）とが在るためIPSなどのフィルタをすり抜けられるかも知れない、という話。珍しくIEの方が標準に厳格(?)に対処しています。 リンク先のページをIE 6で表示すると7bit ACSIIでは無視されるべき8ビット目が無視され読める文字列が表示されますが、Firefox 1.5では8ビット目を無視せずISO-8859として解釈してしまい文字化けしているように表示されます。IEの動作の方が仕様的には正しいように思えますが、Firefox、Operaの動作の方が安全ですね。 どちらかと言うとWeb開発者が注意すべき問題ではなく、JavaScriptの脆弱性を利用
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
