「10日でおぼえるPHP入門教室 第4版」はセキュリティ面で高評価
弊社本社の麻布十番移転に伴い、本社近くの麻布図書館を利用しています。麻布図書館は土地柄のイメージにあう瀟洒な建物で、蔵書がない場合は港区の他の図書館から取り寄せ（無料です）ができますので、よく利用しています。今回は、山田祥寛さんの「10日でおぼえるPHP入門教室 第4版 」を借りて読んでみました。一読して、本書がセキュリティにもよく配慮されていることがわかりましたので、以下にご紹介したいと思います。 クロスサイトスクリプティング(XSS) 表示の際にHTMLエスケープするという原則を忠実に守っています。そのため、下記の e() という関数を定義して呼び出しています。 function e($str, $charset = 'UTF-8') { return htmlspecialchars($str, ENT_QUOTES, $charset); } その他にもXSS対策として重要な下記の
ApacheのAddHandlerはセキュリティ上の懸念から使用すべきではない - このブログはURLが変更になりました
元ネタはこちら。 Apache AddHandler madness all over the place Gentoo Bug 538822 どういうことか 次のような指定は危険である。 AddHandler php5-script .php この時に指定される.phpはファイル名の末尾である必要はない。例えば、 aaa.php.html bbb.php.pngなどもphp5-scriptとして解釈されてしまうのだ。これは.XXX.YYYと複数の拡張子が書かれた場合、.XXXと.YYYもAddHandlerの対象となることが原因。 ちなみに次のような場合にはphp5-scriptとして解釈されない。 ccc.php_foo (.php_fooとして解釈されるため) ddd.php_bar.html (.php_barと.htmlとして解釈されるため)実はこのことはApacheのドキュメン
PHPのJSONのエスケープ
(Last Updated On: 2023年12月8日) 追記：最近のOWASPガイドの更新でJavaScript文字列はUnicodeエンコードで安全性を確保するよう変更されました。元々このブログでもUnicodeエスケープのまま利用するように書いています。他の言語のユーザーはUnicodeエスケープを利用しましょう。PHPもASCII領域の文字をUnicodeエスケープするようにした方が良いと思います。これは提案して実現するように努力します。 JSONはJavaScriptのオブジェクトや配列を表現する方式でRFC 4627で定義されています。メディアタイプはapplication/json、ファイル拡張子はjsonと定義されています。 PHPにJSON形式のデータに変換するjson_encode関数とjson_decode関数をサポートしています。 JSON関数がサポートされている
安全なPHPアプリケーションの作り方2013
PHPカンファレンス2013における徳丸のプレゼン資料です。後から、参考文献などを加筆しました。Read less
[PHP] preg_replace における //e があぶない話 - tokuhirom's blog
Malware Hidden Inside JPG EXIF Headers という話題がでていたので見てみたところ、単に preg_replace がセキュリティ上問題があるインターフェイスだという話であって、EXIF 云々は直接的に 関係がなく、釣りエントリであることが判明した。 preg_replace は第一引数に正規表現を渡すが、その際に外部からの入力をそのままわたすと危険という話。 なぜならば preg_replace は '/.*/e' のように、eval flag をわたすことができるからだ。 以下のコードをみよ。 <?php preg_replace('/.*/e', 'eval("echo 5960+3;")', ''); つまり、preg_replace($_POST['foo'], $_POST['bar'], '') のようなコードがあった場合、任意のコードが実行
SQLインジェクションについてのスライドを作成した - Kentaro Kuribayashi's blog
社内で、SQLインジェクションについてあらためて原理・原則から議論したいねという風潮がにわかに起こったので、ひとまずは叩き台として僕の方でまとめて皆で議論しましょうというわけで、以下のような資料を作成した。 社内勉強会用の資料なのだけど、僕は別にセキュリティに詳しいわけでもないし、ましてやPHPのことは素人なので、外部の識者にレビューしていただいて、できるだけ正しい知識に基づいて議論できればと思い、まずスライドを先行公開することにした。そうしたところ、Twitter上で多数の識者よりいろいろとご指摘いただいて、少くとも決定的におかしな内容にはなっていないものになったようだ。ありがとうございます。 僕らの職務のひとつに「セキュリティ関連」というものも謳われているので、そのあたりの知識普及・基盤整備についても、仕事のひとつとして行っている。先にも書いた通り、僕自身がその点についてよく理解できて
CodeIgniter の XSS 対策はどうあるべきか？ その2 - A Day in Serenity @ kenjis
CodeIgniter の XSS 対策はどうあるべきか？ では、ビューでの変数をデフォルトで HTML エスケープするという実装案を示しましたが、それだけで XSS 対策が完了するわけではありません。 今回は、現状の CodeIgniter でどのような XSS 対策をすればいいかについて考えてみます。なお、実際のサイトでは、入力値のバリデーションも必須ですが、ここでは割愛してます。 なお、CodeIgniter 標準の XSS フィルタに対する私の考えは、CodeIgniter ユーザが CodeIgniter の XSS フィルタについて知るべき 5つのこと に記載しています。 XSS 対策として以下のすべてを実施します。 CodeIgniter の文字エンコーディングは UTF-8 にする HTTP レスポンスヘッダの文字エンコーディングを正しく指定する HTML の属性値はすべて
もう面倒なユーザ認証機能は１から作らなくてよいかも？PHPのOSS「AuthManager」:phpspot開発日誌
もう面倒なユーザ認証機能は１から作らなくてよいかも？PHPのOSS「AuthManager」 2012年08月13日- AuthManager - StitchApps もう面倒なユーザ認証機能は１から作らなくてよいかも？PHPのOSS「AuthManager」。 ユーザ認証型のサイトを１から作るとなると面倒な上に、もう誰かが良い物を作ってるんじゃないかという事を誰もが作り直してる気がします。 こういうもの自体をオープンソースにしちゃって誰もが使えるっていうのは素晴らしいですね。 Facebookによる認証やreCAPTCHAによるスパム防止、メールアドレスの認証機能といった標準で必要な機能が入っており、便利に使えそう。 で、ユーザ登録できるのはいいんだけど、肝心の制限はどうやってかけるの？というところは、次のように簡単にやってね、ということらしくお手軽。 ($sesslife自体がどこか
5分でできるPHPセキュリティ対策 - ぼくはまちちゃん！
こんにちはこんにちは！！ Webプログラミングしてますか！ よく「PHPはセキュリティがダメ」とか言われてるよね。 でもそれって、べつにPHPが悪いんじゃなくて、 たぶん、セキュリティとかが、まだよくわからない人が多いだけなんじゃないかな。 がんばって勉強しようと思っても、なんだか難しい理屈が並んでいたりするしね…。 なので今日は、セキュリティ対策について、 「これだけやっとけば、わりと安全になるよ」ってことを、初心者むけに、大雑把に書いてみます！ 理屈がわからなくても、最初はコピペでも、 なにもやらないより、やったほうがきっとマシになる！ 1. XSS対策 動的なものを表示するとき、全部エスケープすればokです！ (NG) あなたの名前は <?= $name ?> ですね！ ↓ (OK) あなたの名前は <?= htmlspecialchars($name, ENT_QUOTES) ?>
広範なWebアプリ開発言語にDoS攻撃につながる脆弱性 － ＠IT
2012/01/06 情報処理推進機構（IPA）は1月6日、広くWebアプリケーション構築に用いられている開発言語やフレームワークに、DoS攻撃につながる脆弱性が発見されたことを踏まえ、緊急対策情報を公開した。 影響を受けるのは、PHPやRubyといった開発言語のほか、WebアプリケーションフレームワークのApache Tomcat、Microsoft .NET Frameworkなど。これらの言語が実装しているハッシュテーブル機構に脆弱性がある。わざとハッシュ値が同じ値になるようなパラメータを大量に送り付け、「ハッシュ衝突」状態を作り出すとDoS状態に陥ってしまう。いわゆる「Hashdos」という攻撃で、例えばPOSTフォームからこうしたデータを送信することで、Webアプリケーションが停止するなどの被害が考えられる。 この脆弱性を踏まえ、マイクロソフトは2011年12月30日に、Micr
PHPのイタい入門書を読んでAjaxのXSSについて検討した(1) - ockeghem's blog
このエントリでは、あるPHPの入門書を題材として、Ajaxアプリケーションの脆弱性について検討します。全3回となる予定です。 このエントリを書いたきっかけ twitterからタレコミをちょうだいして、作りながら基礎から学ぶPHPによるWebアプリケーション入門XAMPP/jQuery/HTML5で作るイマドキのWeという本を読みました。所感は以下の通りです。 タレコミ氏の主張のように、本書はセキュリティを一切考慮していない 主な脆弱性は、XSS、SQLインジェクション、任意のサーバーサイド・スクリプト実行（アップロード経由）、メールヘッダインジェクション等 脆弱性以前の問題としてサンプルスクリプトの品質が低い。デバッグしないと動かないスクリプトが多数あった 上記に関連して、流用元のソースやデバッグ用のalertなどがコメントとして残っていて痛々しい 今時この水準はないわーと思いました。以前
もし『よくわかるPHPの教科書』の著者が徳丸浩の『安全なWebアプリケーションの作り方』を読んだら - ockeghem's blog
たにぐちまことさんの書かれた『よくわかるPHPの教科書（以下、「よくわかる」）』を購入してパラパラと見ていたら、セキュリティ上の問題がかなりあることに気がつきました。そこで、拙著「体系的に学ぶ 安全なWebアプリケーションの作り方（以下、徳丸本）」の章・節毎に照らし合わせて、「よくわかる」の脆弱性について報告します。主に、徳丸本の4章と5章を参照します。 4.2 入力処理とセキュリティ 「よくわかる」のサンプルや解説では、入力値検証はほとんどしていません。しかし、入力値検証をしていないからといって即脆弱かというとそうではありません。徳丸本でも強調しているように、入力値検証はアプリケーション要件（仕様）に沿っていることを確認するもので、セキュリティ対策が目的ではないからです。 「よくわかる」の中で、私が見た範囲で唯一の入力値検証は、郵便番号のチェックをするものです。以下に引用します（「よくわ
第41回 PHP 5.3.4におけるセキュリティ上重要な仕様変更 | gihyo.jp
PHP 5.3.4のリリースは2010年12月にリリースされました。このリリースにはセキュリティ上重要な変更が追加されています。 Paths with NULL in them (foo\0bar.txt) are now considered as invalid. (Rasmus) パスに“foo\0bar.txt”などのようにNULLが含まれる場合は無効として処理される、とPHP 5.3.4のリリースノートには記載されています。PHP開発者の間でもあまり大きなニュースとして取り上げられていないので、この仕様変更をご存知でない方も多いと思います。2011年4月現在でもこの仕様変更はマニュアルには記載されていません。しかし、この修正はセキュリティ上非常に重要な意味を持っているので解説します。 仕様変更の必要性 PHP本体はC言語で記述されているため、ファイルを開く場合、最終的にはC言
PHPエスケープ関数の比較一覧 | 株式会社フォレスト・コンサルタンツ
CR … カーソルを文頭へ戻す制御コード（Carriage Return） EOF … ファイル終端を示す制御コード（End Of File） 黄色い部分が全部で４箇所、すなわち、htmlspecialchars($str)で変換できない文字が１つ、addslashes($str)で変換できない文字が３つあることが分かります。より安全なプログラムを心がけるには、htmlspecialchars($str)ではなくhtmlspecialchars($str, ENT_QUOTES)を、addslashes($str)ではなくmysql_real_escape_string($str)を使う必要があります。 また、クロスサイトスクリプティング対策とＳＱＬインジェクション対策では、変換すべき文字や、変換後の文字が異なることも一目瞭然かと。この２つは全く別物として考えるべきです。 と偉そうに書いて
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2012