PHP 5.4から利用できるtraitの利用例
(Last Updated On: 2018年8月13日)PHP5.4からtraitが利用できるようになる事をご存知の方も多いと思います。 traitはコードの水平再利用を可能にする仕様拡張です。Rubyのmixinのような機能と言えば分り易いかも知れません。 誰でもtraitを利用したくなるようなコードをinternals@php.netのMLで見かけたので紹介しよう、と思って書いたのですがコピペしたコードをしっかり読んでなくておかしな所があった事を @sotarok さんに教えてもらいました。 元のコードは色々問題があるので書き直しました。こうやればアクセサーを沢山書く必要が無くなります。 https://gist.github.com/1379592 （読みやすいコードはこちらをどうぞ） <?php trait Accessors{ public function __get($na
PHPセッションアダプションをスクリプト側で修正する方法
(Last Updated On: 2018年8月13日)PHPのスクリプトを使ってアダプティブなPHPセッションをアダプティブにしない方法を紹介します。 このブログで紹介していたかどうか覚えていないですが、セッションアダプション対策としてsession_regenerate_id()が導入された時に議論・紹介されているので知っている方も多いと思います。（というより、PHPerの常識ですよね？） まずはセッションアダプションの原理と対策の復習をしておきます。 原理： 未初期化のセッションIDを受け入れる 対策： 初期化済みセッションIDのみ受け入れる session_regenerate_id()は新しいセッションIDを生成して新しいセッションクッキーを作成して、セッションデータを保存するようになっています。session_regenerate_id()を呼んだだけでは、なんらかの方法で複
PHP 5.4の文字エンコーディング設定
(Last Updated On: 2018年8月13日)PHP 5.4 RC1が公開されています。PHP 5.4のリリースが近いです。PHP 5.3の–enable-zend-multibyeの問題でバグレポートをした関係でinternals MLでメールのやり取りをして分った事とその他をまとめておきます。主にSJISを使う場合の注意点です。間違い・勘違いもあるかも知れないので気が付いたらコメントを下さい。 PHP 5.4はデフォルトの内部エンコーディングがISO-8859-1になる SJISでコードを書く場合はzend.script_encoding=SJISを書く SJISでコードを書く場合は内部エンコーディングをSJIS(mbstring.internal_encoding=SJIS)に設定する SJISで出力する場合はmbstring.http_output=SJIS (outp
DOMベースXSSの検出ツール
(Last Updated On: 2011年11月3日)久しぶりにブログを更新すると色々書きたくなるものですね。ということでまだこのブログでは紹介したことがないDOMベースXSSのオープンソースツール、DOMinatorを紹介します。最近の商用ツールも類似の機能をサポートしています。 http://code.google.com/p/dominator/ DOMベースXSS： JavascriptはDOMを利用してHTMLを動的に変更できます。この機能を利用するとブラウザ側のJavascriptで動的に変化するWebサイトを構築できます。HTMLなどを修正するとデータにユーザが入力が含まれているとプログラマが意図しないJavascriptが実行できます。 要はクライアントサイドのJavascriptインジェクション攻撃の事です。 Javascriptは非常に柔軟な言語で便利な反面、セキュ
PROVE for PHP 0.4.0-dev リリース
エレクトロニック・サービス・イニシアチブのWebシステムのコンサルタントのブログです。Webシステムを対象としたセキュアコーディング／セキュアプログラミング、SAMM、ソースコード検査、Webシステム開発、パフォーマンスチューニングの技術支援、コンサルティング、セミナー開催、書籍などの執筆、PROVE for PHPの開発、PHP4.x/5.xレガシーPHPセキュリティパッチサービスなどを行っています。 ブログのサブタイトルを「書かない日記」としているのは、ブログを始めた時にあまり書かないつもりで始めたのでこのサブタイトルになっています。 氏名：大垣 靖男 私が記述したブログ中のコードは記載が無い場合はMITライセンスです。その他のコードは参考リンクなどのライセンス情報を参照ください。 ご依頼・ご相談は info@es-i.jp まで。
もうバージョンアップで困らない – PROVE for PHP
(Last Updated On: 2018年8月14日)昨年のPHPカンファレンスで紹介したPORVE for PHP 開発版の公開を始めました。PROVE for PHPはこんなテストが出来ます。 PHPをアップデートしてアプリに影響が無い事を検証する PHPアプリをアップデートしても以前と同じように動作する事を検証する 使い方もとても簡単です。 テストケースの作成はブラウザからアプリを利用するだけ ロードバランサを用いて実運用サーバからのテストケースも作成可能 テストの実行はプログラムを実行するだけ 違いが在った場所はプログラムの何処か確実＆簡単に判明 http://www.provephp.com/ 現状 CUIとコマンドツールでの管理のみ GUI（Web、GTK）は順次整備予定 PROVEを利用すればPHPのセキュリティパッチがリリースされた場合に、アプリケーションの動作チェック
php – 短縮URLを一行で展開する
エレクトロニック・サービス・イニシアチブのWebシステムのコンサルタントのブログです。Webシステムを対象としたセキュアコーディング／セキュアプログラミング、SAMM、ソースコード検査、Webシステム開発、パフォーマンスチューニングの技術支援、コンサルティング、セミナー開催、書籍などの執筆、PROVE for PHPの開発、PHP4.x/5.xレガシーPHPセキュリティパッチサービスなどを行っています。 ブログのサブタイトルを「書かない日記」としているのは、ブログを始めた時にあまり書かないつもりで始めたのでこのサブタイトルになっています。 氏名：大垣 靖男 私が記述したブログ中のコードは記載が無い場合はMITライセンスです。その他のコードは参考リンクなどのライセンス情報を参照ください。 ご依頼・ご相談は info@es-i.jp まで。
gihyo.jpのRasmusさんインタビューの補足
(Last Updated On: 2011年1月9日)私がインタビューアーと執筆を担当させて頂いたRasmusさんへのインタビュー記事は好評だったようです。 http://gihyo.jp/news/interview/2010/rasmus この記事の中で「美しいツールは美しい問題を解決するためには非常に効果的かも知れませんが，多くの場合は必要がありません。さまざまなルールを作り，フレームワークを使い，モデルやビューを使って解決できない問題があるのです。」の部分は解説が無いと理解できないかも知れません。Rasmusさんなら私と同じようにこう思っているハズという補足なので外している可能性もありますが、この部分の意図を補足します。 Rasmusさんもパフォーマンスについてはかなりうるさい方です。RasmusさんがYahooの為に働き出した頃「statシステムコールが多すぎて遅くなる」と文句
PHPカンファレンス2010 ビジネスデイの講演資料(PORVE for PHP)
(Last Updated On: 2011年1月9日)PHPカンファレンス2010ではビジネスデイにリグレッションテストツールのPROVE for PHPを紹介させて頂きました。その講演の資料です。Keynoteで話しながら説明するように作っていたので、PDFで見ても大丈夫なように少し改変しています。 http://blog.ohgaki.net/media/users/yohgaki/PHPCON2010PROVE4PHP.pdf 商用ですがビジネスモデルは決まっていません。今のところパーソナルユースは無償で利用できるようにする方向性でビジネスモデルを考えています。 このプレゼンの中では解説していませんが、厄介なのがSESSIONモジュールのデータの取り扱いです。セッションモジュールのセッションセーブハンドラは直接I/Oを行っているのでラッパーを書けません。幸いセッションセーブハンドラ
何故かあたり前にならない文字エンコーディングバリデーション
(Last Updated On: 2018年8月8日)私が4年前（2005年）に「Webアプリセキュリティ対策入門」を執筆していた時には、既に壊れた文字エンコーディングなどの不正な文字エンコーディングを利用したJavaScriptインジェクションやSQLインジェクション攻撃は比較的広く知られていました。この問題は当時のスラッシュドットジャパンでも取り上げられていました。/.で取り上げられたので、そこら中のWebサイトとユーザが被害に合うのでは？とヒヤヒヤしたので良く覚えています。 不正な文字エンコーディングを利用した攻撃は、文字エンコーディングを厳格に取り扱い、文字エンコーディングをバリデーションすれば無くなります。これを怠ると、システムのどこで問題が発生するか予想できなくなります。つまり、いい加減に文字エンコーディングを取り扱うと安全なシステムは作れないのです。 参考：エンジニア向けに
PHP:既知のセキュリティ脆弱性 – Session Adoption
(Last Updated On: 2018年8月13日)追記：より新しい情報については間違いだらけのHTTPセッション管理とその対策をどうぞ。 PHPには広く知られているにも関わらず放置されている既知のセキュリティ脆弱性が幾つかあります。その一つがセッションモジュールのセッションアダプション(Session Adoption)脆弱性です。この脆弱性は現在広く利用されているWebアプリケーションの安全性に、非常に大きな影響を与える脆弱性です。 セッションアダプション脆弱性とはセッション固定化攻撃を可能とする脆弱性の一種です。セッションアダプションに脆弱なセッション管理システムは、ユーザ(ブラウザ)が送信してきた未初期化のセッションIDを受け入れ、セッションを初期化してしまいます。PHPに限らず、RailsやJavaのフレームワーク等、多くのWebフレームワークに発見されている脆弱性です。
現行版の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 5.3の名前空間仕様が変更されました
(Last Updated On: 2018年8月13日)名前空間に関する議論は5年以上も行われていたのですが、今度こそ結論が出たようです。 何故このようなエントリを書くかというと、Software Design（技術評論社）の11月号にPHPの最新情報としてα版PHP 5.3を紹介しているからです。入稿後に仕様変更があったので最新号の記事ですが既に内容が古くなってしまいました。 # とは言ってもまだ新しい仕様のPHPは無いですが α版なので仕様や機能が大きく変更される事もありますが大きな変更がありました。見本誌が刷り上がった頃に名前空間の区切り文字が”::”だと静的にメソッドを呼び出す場合やクラス定数を呼び出す場合に困る場合がある、とPHP開発者のMLで議論になり始めました。 ML上、IRC上、オフラインの打ち合わせが行われ、数週間におよぶ議論の結果が昨日MLに投稿されました。名前空間の
PHPのSessionモジュールの脆弱性
(Last Updated On: 2018年8月13日)たまたま目に止まったブログがあるので紹介します。 PHP:session_set_save_handlerリファレンスマニュアルのサンプルにパス・トラバーサル脆弱性 http://www.tokumaru.org/d/20080818.html#p01 [php]session_set_save_handlerのパストラバーサルで任意コマンドの実行が可能 http://www.tokumaru.org/d/20080819.html#p01 この危険性はStrict Sessionパッチが作られた頃にも議論されていました。このパッチを摘要するとセッションアダプション脆弱性も修正します。もし、互換性なので要件で厳格なSession管理ができない場合でもセッションIDに利用可能な文字は安全な文字のみに限定されるのでパストラバーサルなどの
PHP 5.2用のStrict Sessionパッチ
(Last Updated On: 2008年7月12日)随分前からバージョンアップしたパッチ公開しないと、と思いつつ遅れていました。PHP 5.2.6用の厳格なセッション管理を行うパッチを公開しました。詳しくはWikiをご覧下さい。 http://wiki.ohgaki.net/index.php?PHP%2Fpatch%2FStrictSession 他のネットワークからパッチをダウンロードしようとして、セキュリティ強化の為にPukiwikiのattachモジュールのカスタマイズで添付ファイルのダウンロードが出来なくなっていました。これも修正しました。 このパッチを摘要するとmake testのsession関連のテストがエラーになりますが、気にする必要はありません。テストの内容をみるとこれらのテストは本来失敗すべきであることが分かります。
中国でのソフト開発は大丈夫なのか?
(Last Updated On: 2008年6月12日)中国でのソフト開発が進められています。例えば、 「NEC、中国のソフト開発体制を強化−5000人にトレーニング開始」 http://enterprise.watch.impress.co.jp/cda/topic/2008/06/11/13158.html 人件費が圧倒的に安い中国ですがセキュリティの問題も考えなければなりません。中国政府の機関が直接関与していると考えられるセキュリティ上の問題は海外メディアやブログではかなり頻繁に報道されています。 A New Cold War? http://www.spinhunters.org/blog/a-new-cold-war/ にはアメリカの通商代表が中国訪問中にコンピュータから情報を盗まれた可能性があり、捜査中だとしています。 随分前になりますが国防相のメールが中国のサイバー攻撃によ
mod rewriteを使用した簡易WAF
(Last Updated On: 2018年8月8日)http://www.0x000000.com/?i=567 にmod rewriteを利用した簡易WAF(Web Application Firewall)の定義例が掲載されています。同じようなアイデアをお持ちの方、既に似たような設定を使われている方も多いとは思います。 簡単なWAFですが、実用性も高いです。例えば、ヌル文字やHTML特殊文字のインジェクションは様々な攻撃で利用されます。アプリケーションで対処が忘れられがちなCOOOKIEやREFER、USER_AGENT等に特殊文字が入っていた場合にアクセスを拒否する部分だけもで導入する価値は十分にあると思います。 元ネタのサイトは英語ですが、解説付きです。 これを入れると問題となる場合もあるので、内容を理解してから利用しなければなりません。 RewriteEngine On Op
PostgreSQL 8.3の全文検索機能（TSearch2）を日本語で利用する
(Last Updated On: 2018年8月13日)PostgreSQL 8.3.0から、ユーザから提供されている追加機能（contrib）として利用できた全文検索機能（TSearch2）が本体に取り込まれました。 本体に取り込まれたため、PostgreSQL 8.3.0以降ではソースから構築する場合に ./configure make make install と実行するだけで全文検索機能が利用できるようになりました。 TSearch2は単語単位で全文検索できます。しかし、日本語のように単語に区切りがない場合、単語に分解（形態素解析）してからインデックス化する必要があります。 # N-gramは使えません。 残念ながら日本語をそのまま扱える機能はPostgreSQL 8.3では実装されていません.しかし、TSearch2(textsearch)を日本語で利用するための追加機能がpg
誤解を招く記事 – LAMPセキュリティを強化する4つの方法
(Last Updated On: 2014年12月5日)LAMPセキュリティを強化する4つの方法 http://enterprisezine.jp/article/detail/311 書いてある情報は有用な事も記載されていますが、偏狭な視点からの記述により誤解を招く記事になっていると考えられます。著者はセキュリティの専門家ではないようなので仕方ないかも知れませんが、間違った認識は有害です。 # 原本は読んでいません。もしかすると日本語訳にも問題があるのかも知れません。 実行できる最も重要な対策は、PHPを使わないことです。腐った果物を導入する前に、以下に目を通してください。 後にPerl/Ruby/Pythonの方がかなり安全である旨の記述があります。メモリ管理が必要ない同じスクリプティング言語のレベルで「Perl/Ruby/Pythonを使えばセキュアなアプリケーションができる」と考
企業ユーザはPHP4からPHP5への移行は慎重にすべき
(Last Updated On: 2018年8月13日)2008年1月3日のPHP4.4.8のリリースを持ってPHP4サポートが終了しました。海外では「PHP5へ移行しよう」キャンペーンも始まりました。 私は従来から「PHP5へ早く移行すべきです」と繰り返し勧めて来ました。現在でも全てのオープンソースアプリケーションの開発者は、今すぐPHP5に移行すべき、と考えています。 しかし、新規開発を除き、企業ユーザには今すぐPHP5へ移行すべきだ、と一概にアドバイスできません。3つのお薦めしない理由があります。 PHP4からPHP5へのマイグレーションはそれほど簡単ではない PHP5に移行するとマイナーバージョンアップに追随しないとならない PHP5.3のリリースが準備されている PHP4からPHP5へのマイグレーションはそれほど簡単ではない PHP4からPHP5への移行でチェックしなければなら
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
