OWASP TOP10の1位のセキュリティ脅威はインジェクションです。
https://www.owasp.org/index.php/Top_10_2013-A1-Injection
SQLインジェクション、コマンドインジェクションはリファレンスとして掲載されていますが、何故かLDAPインジェクションは掲載されていません。しかし、OWASPの別の文書では簡単に解説されています。
OWASP TOP10の1位のセキュリティ脅威はインジェクションです。
https://www.owasp.org/index.php/Top_10_2013-A1-Injection
SQLインジェクション、コマンドインジェクションはリファレンスとして掲載されていますが、何故かLDAPインジェクションは掲載されていません。しかし、OWASPの別の文書では簡単に解説されています。
大量に送信されてくるコメントスパムに対処できなかった為、コメント機能を無効にしていましたがFacebookのコメントプラグインを利用してコメントできるようにしました。このプラグインの導入はとても簡単でした。
https://developers.facebook.com/
にアクセスしてFacebookデベロッパーになり、画面上部の「Apps」メニューからコメントアプリを新規に作成し、
https://developers.facebook.com/docs/plugins/comments/
でページに挿入するコードを生成し、ブログテンプレートの適当な場所にペーストするだけで完了です。
1つだけ問題になったのはサードパーティークッキーです。
普段利用するWebブラウザではサードパーティークッキーを無効にしていたのですが、このプラグインにサードパーティークッキーは必須です。無効な場合、アバターは表示されていてもコメントを保存できません。なぜ「ログインしていない」とエラーになるのか、しばらく考えてしまいました。ご注意ください。
徹底攻略 PHP5 技術者認定 [上級] 試験問題集 [PJ0-200]対応 が手元に届きました。
私はPHP技術者認定機構として試験範囲に対応しているか、例として解説されている問題が適切であるか、などを監修者の1人としてお手伝いさせて頂きました。
試験対策本ですが、PHP開発者が自分の知識のチェック、より深くPHPを知るための本としても適していると思います。プログラミングを始めたばかり、PHPを始めたばかりの方にも、既にPHPでバリバリ開発されている方でも、どのレベルまでを習得すれば上級者と言えるのか?目標を定めるガイドラインとしても役立つと思います。
本書はPHPの使い方やPHPを使ったアプリの作り方を学ぶ本ではありませんが、技術者認定試験を受験するしないに関わらず、全てのPHP開発者にお勧めできる本だと思います。
本書はPHPを始めたばかりの方には難しすぎるかも知れません。PHPを始めたばかり方は「PHP公式資格教科書 PHP5技術者認定初級試験対応 (EXPERT EXPASS) 」、「徹底攻略 PHP5技術者認定[初級]試験 問題集 [PJ0-100]対応 (ITプロ/ITエンジニアのための徹底攻略)
」こちらも参考になると思います。PHP開発者として必要な基本的知識を持っているか、確認できます。
PHP技術者認定認定試験についてはこちらを参照してください。
http://www.phpexam.jp/summary/
初級認定にくらべ、上級認定はかなりの難関となっています。既に上級認定に合格された方は、論文審査によるウィザード認定にチャレンジしてください。現在、論文を受付中です。まだウィザード認定を受けた方は1人も居ません。最初の認定者となるのは貴方かも知れません。
PHP技術者認定試験はオンライン試験で全国どこでも、何時でも受験できます。上級認定試験を今から受けても間に合います。
第一回 中国地方DB勉強会の講師として参加させて頂きました。
MySQLも使っていますが奥野さんの発表は普段気にしていなかったことも多く、とても参考になりました。
私の資料もSlideShareにアップロードしました。
データベースセキュリティ
http://www.slideshare.net/yohgaki/ss-25042247
PostgreSQL 9.3
ブログを書き出すと、次々に書きたくなるので困ったものです。
徳丸さんに返信した前のエントリのリンクに「もう入力値検証はセキュリティ対策として *あてにしない* ようにしよう」とあったので補足しておきます。
そもそも入力バリデーションは「あてにする」ような物ではありません。セキュリティ対策としては「転んだ時に役立つかも知れない杖」と捉えるべきです。役立つか役立たないかは分かりませんが、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
前回公開したRails4セキュリティのスライドは誤解をされる可能性があるのでは?と指摘される方も居たので「Rails4セキュリティ リローデッド」として追加情報を加えたスライドを作ろうかと思っていました。確かに、今見直したら肝心な所で追加し忘れてる部分があって誤解しやすい、というか言いたい事が分からないかも知れません。
入力パラメータをバリデーションするとは、バリデーションするメソッドを作ってバリデーションする、ことです。必須・許可設定だけだとモデルに渡すデータがどれかしか分かりません。許可設定と同時にバリデーションする事が良い、という事です。少なくともここだけは直した方が良さそうです。
あまり時間が取れなかったのでスライドを作るために作ったメモを取り敢えず公開します。スライドにして欲しいという方が多ければスライドにするかも知れません。
メモを読む前に「モデルで処理に利用すべきパラメータが指定してある場合、モデルで指定外のパラメータをバリデーションすべきか?」を考えてから読むと解りやすいかも知れません。
関連エントリ
http://blog.ohgaki.net/rails4-security
岡山Ruby会議02が先週末の土曜日にありました。私は「Rails 4 セキュリティ」をテーマに講演させていただきました。
プレゼン資料だけでは分かりづらいと思いますが、参考までに公開します。
追記:肝心なところで記述漏れがあり、誤解もあったので解説を追加しています。こちらも合わせてご覧ください。
多分、WindowsにRails4をインストールしようとして困っている方も多い(?)と思うので簡単にエントリを書きました。
Rails4をWindowsで使うにはWindows版のRuby 2.0とDevKitがあれば良いとあったのでこれらをインストールした後に
gem install rails
を実行するとしばらくするとインストールが完了したが、テストアプリを作り実行しようとしたら (さらに…)
やっとPHPのセッションアダプション脆弱性を修正するパッチとプルリクエストを作りました。議論は済んでいるのでパッチを検証、調整してマージするだけです。
PHPに限らず、未初期化のセッションIDを正規のセッションIDとして受け入れてしまうセッション管理機構があります。(Javaとか)
サイトで稼働している全てのアプリが正しいセッション管理(ログイン後にセッションID作り直す。ログオフで廃棄。一定時間経過後、セッションIDを再生成)を実行していれば良いのですが、共有環境や複数のアプリが使われる事が多いPHPでは特にリスクが高くなっています。
未初期化のセッションIDを受け入れてしまうセッション管理機構は脆弱だと言って良いと考えています。セキュリティのベストプラクティスには確立されたセキュリティ手法(ベストプラクティス)はそのまま使うべき、というプラクティスがあります。つまり、信頼できるフレームワークのセッション管理機構をそのまま使いなさい、がベストプラクティスという事です。しかし、フレームワークとしてURLへのセッションID埋め込みをサポートしているのに、簡単に直せるセッションアダプションを修正しないフレームワークは到底「ベストプラクティスを実装している」と言える状態ではないと考えています。
セッションアダプション脆弱性についてはPHPのWiki(英語のみ)に書いています。詳しくは以下のWikiを参照してください。
PHP 5.5.0がリリースされました。
PHP 5.5のリリースにともないPHP 5.3の開発は終了し、今後一年間セキュリティフィックスのみが提供されます。
PHP 5.3/5.4で動作するPHPアプリケーションのほとんどはそのまま動作しますが、非互換な変更を含むリリースです。ChangeLogやマイグレーションガイドを利用してアップグレードが必要です。
個人的に特にお勧めしたい新機能はPHP 5.5から含まれるcrypt関数のラッパー関数であるpassword_hash関数です。この関数を利用すると、PHPのバージョンアップをするだけで互換性を維持しつつ最適なパスワードのハッシュ化が可能になります。
バイトコードキャッシュモジュールであるOpcacheも標準モジュールとして配布されるようになりました。OpcacheはZendOptimizer+としてZend社が商用製品として配布していましたが、Zend社から提供され標準バンドルされることになりました。APCとは全く別のモジュールなので注意してください。OpcacheはソースコードからビルドすればPHP5.3/5.4でも利用できます。
気になる性能ですが様々な最適化で少し速くなっています。
OpcacheはAPCより多少性能が良いです。元々Zend社が作っていたので特にZendFrameworkとは相性が良いようです。
ところでセッションアダプション脆弱性の修正は時間ができたらマージできる物を用意します。と、いうことでまだ少しお待ちください。
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勉強会で使ったスライドです。
最近の使い方だとMacBookはプレゼン、メモ、メール、それから時々コンパイルの確認とデバッグくらいに使っていす。
使えるところまでこのままの環境で使おう、と思っていたのですがHDD(512GB)がなんだか怪しそうだったので新しいHDD(1TB)に入れ替えました。起動できるHDDもあるのでWin/OSXの両方のOSをアップグレードしました。
1/19日に開催されたオープンセミナー広島2013にスピーカーとして参加しました。その資料を公開します。