興味のある言語にPHPと書いておいたら面接で爆笑された - moriyoshiの日記
Inspired by http://anond.hatelabo.jp/20100125020240 Perlエンジニアを募集してる会社の採用面接を受けた時の話。 転職エージェントに作れと言われて作ったシートに、「興味のある技術/言語」という欄があったんです。 PSGI/Plackとか色々書いたけど、プログラミング言語の中で興味があるのはPHPだったので、 PHPと書いておいたのですが、それを見た髭面サスペンダーの面接官のリアクションが酷かった。 面接官「PHP・・・ふははっ！PHP！」 面接官「PHPやってるんですか？ｗｗｗｗｗ」 俺「(唖然)は、はい・・まだ参照を理解したぐらいですが。。」 面接官「PHP・・・ﾆﾔﾆﾔ」 その人はCPANコミッタで、当然Perlのコードを書いている人だったので、 Perlが「Improved PHP」と呼ばれている事を知らないワケが無いだろうと思って
PHPでのデバッグ方法
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog おひさしぶりです。オークション担当の山崎 賢です。 前回はPHP Serialize についてでしたが、 今回はPHPでのデバッグに関してお話します。 基本PHPはインタプリタ(厳密にはPHPは内部で一度コンパイルしていますのでインタプリタとは言い切れませんが) のデバッグではログ埋め込みが手軽です。 しかし、まれにSIGSEGVやSIGBUSなどでPHPスクリプトが落ちることがあり、途方にくれます。 地道にログを埋め込んでいき、箇所を特定するのも手法の1つですが、今回はgdbを用いたデバッグ方法を記載したいと思います。 ■STEP1 まずは、プログラムが落ちることを目的として以下のようなPHP Moduleを作成します。 ・ ・
PHPのSession Adoptionは重大な脅威ではない - ockeghem's blog
なぜPHPアプリにセキュリティホールが多いのか?：第25回 PHPのアキレス腱にて、大垣靖男氏がPHPのSession Adoption問題について取り上げている。大垣氏は度々この問題を取り上げているが、今のところ氏の主張に同調する人を見かけない。それもそのはずで、大垣氏の主張は間違っていると私は思う。 以下、大垣氏の主張を実際に試してみる形で、順に説明しよう。 大垣氏の主張 大垣氏の主張は、PHPにはSession Adoption脆弱性があるために、標準的なSession Fixation対策であるsession_regenerate_id()を施しても、その対策は有効ではないというものだ。 しかし，実際には現在に至るまでPHPのセッションモジュールのセッションアダプション脆弱性は修正されないままになっています。このために，本来はsession_regenerate_id関数をログイン
preg_replaceによるコード実行 - T.Teradaの日記
最近少し調べていたのが、PHPの任意コード実行系の脆弱性です。中でも、preg_replace関数（Perl互換の正規表現による置換を行なうための関数）を不適切な方法で使った場合に発生する脆弱性について調べていました。 せっかくなので、日記にまとめてみます。 3種類の脆弱性 preg_replace関数を使ったPHPコード実行系の脆弱性には、大きく分けて3つの種類があります。 第一引数への挿入を許す e修飾子付き・第二引数への挿入を許す e修飾子付き・第三引数への挿入を許す 以下でそれぞれについて見ていきます。 タイプ１：第一引数への挿入 以下のコードに、任意のPHPコードが実行可能な脆弱性があります。 $m = preg_replace("/([^<]*)$kw([^>]*)/i", "\\1<font color=red>$kw</font>\\2", $m); $kwと$mは外部から
WEBデザイナーの為のXSS(クロスサイトスクリプティング)入門
WEBデザイナーの為のXSS(クロスサイトスクリプティング)入門 情報処理推進機構のXSS（クロスサイトスクリプティング/Webアプリケーションに存在するセキュリティホール）が公開されて、ネット上では盛り上げっているようです。 まぁ、これを機会にXSS(クロスサイトスクリプティング)って言葉をはじめて聞いたデザイナー・プログラマーの方は、正しい知識・正しい対処法を勉強しましょう。 とくにプログラムなんてちょっと改造するだけというレベルの、WEBデザイナーさんに注意してもらいたいです。 XSSはwebページにスクリプトを埋め込む攻撃法方法 XSSは別のサイト(これはどこでも良い)から攻撃先のurlに対して特定の文字列を送ることにより攻撃先のurlでスクリプトを実行する攻撃方法です。 XSS脆弱性のあるスクリプトはこんなスクリプトである。 <input type="hidden" name="
Ruby on Rials – Session Fixation脆弱性の攻撃方法
(Last Updated On: 2008年2月3日)前回に引き続きWeb関係のセキュリティ脆弱性がどのように攻撃されるのか解説した記事がThinkITに掲載されています。 今回はRuby on Railsの脆弱性が対象です。Ruby on Railsにもいくつかのセキュリティ脆弱性が報告されていますが、URLベースのセッションがいかに脆弱であるか解説しています。 解説対象の脆弱性 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5380 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6077 Railsのセッション管理機構にはSession Adoption脆弱性は無いのに何故攻撃できるのか?と思った方は読んでみてください。記事を読んで頂くと脆弱性を実際の攻撃に
企業ユーザは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への移行でチェックしなければなら
PHP4 セキュリティ保守サービス - SRA OSS, Inc. 日本支社
本サービスは Web サーバ用途にオープンソースのスクリプト言語 PHP を利用されている Web サイト向けに、PHP バージョン 4 に対する保守サービスを提供するものです。 » 本サービスで提供しているパッチ情報（例）は こちら » PHP 5.1、5.2 に対するサービスも提供しております。 本サービスの定形メニューとしての販売は 2014年4月をもちまして終了いたしました。 「PHP旧バージョンに対する最新セキュリティパッチのバックポート」は、ご相談に 応じまして個別に提供させていただきます。お問い合わせいただけましたらと思います。 PHP4 のメンテナンスが終了 PHP コミュニティより、PHP 4.x の開発停止とメンテナンス終了が発表されています。 2007 年 12 月 31 日にて、PHP 4.x のすべての開発を終了し、その後は、大きなセキュリティホールがあればケース
PHPのhtmlspecialcharsにはENT_QUOTESを付ける:phpspot開発日誌
htmlspecialchars ( ) でセキュリティ対策（ ENT_QUOTES もね！） PHPのhtmlspecialcharsにはENT_QUOTESを付ける。 htmlspecialchars でXSS対策をしていたと思ったら、デフォルトでは シングルクオートをエスケープしてくれない(マニュアル参照) htmlspecialchars($str, ENT_QUOTES); ENT_QUOTES を指定することで、シングルクオートも ' にエスケープ出来ます。 ZAPAブロ〜グのZAPAさんの指摘するh関数を定義してフレームワークなどに組み込んでおくのがスマートなのかもしれませんね→htmlspecialchars関数を簡単にする 意外に知られていないかもしれないので、念をのため紹介しておきます。(知っている人はごめんなさい) その危険な例をしめしてみます。 例えば、h
htmlspecialchars関数を簡単に扱えるようにする
特殊文字を HTML エンティティに変換してくれるhtmlspecialchars関数。 PHPでは基本中の基本である関数でありながら、名前の長さやオプションの設定などが面倒で困ったものです。「htmlspecialchars」は覚えられても、オプションの「ENT_QUOTES」まで覚えるのはなかなか大変だったりします。でも、ここで手を抜くと簡単に脆弱なアプリケーションができあがってしまう危険性があります。特にユーザーからの入力には、手軽にがっちり入力保険をかけておくべきです。 そんなわけで、htmlspecialcharsを簡単に扱えるようにする方法を考えてみました。 お知らせ：PHP5.4にて、htmlspecialchars()関数に互換性の問題が出てきましたので、当ページでも第三引数に文字コードを指定するコードに変更しました。以下、第三引数の"UTF-8"の部分は、利用中の文字コー
"諸君、私はPHPが大好きだ" - ぐらめぬ・ぜぷつぇんのはてダ(2007 to 2011)
ついカッとなってやってしまった。後悔はしないことはないだろう。 諸君 私はPHPが好きだ 諸君 私はPHPが大好きだ PHP/FI2が好きだ PHP3が好きだ PHP4が好きだ PHP5が好きだ PHP6が好きだ PEARが好きだ PECLが好きだ Smartyが好きだ PHPマニュアルが好きだ PHP-CLIが好きだ Windowsで Linuxで UNIXで BSDで Macで りなざうで Blogで Wikiで サーバ上で クライアントPC上で この地上で行われるありとあらゆるPHPプログラミングが大好きだ file_{get|put}_contents()/file()でファイルの読み書きを一瞬で実装するのが好きだ xdebugで武装したベテランの連中がプロファイリングでボトルネックを検出した時など心がおどる PHP4でnewした結果を&つけ忘れたためオブジェクトがコピーされてしま
PHPにおける数値と文字列のヘンな比較結果: dara-j
0 == 'str' // true PHPSPOTでこんなエントリがあった。 PHPで、文字列と数値0の比較は等価になるようです:phpspot開発日誌 タイトルだけみたときは「0 == '0'のことか？そりゃ当然じゃん」とか思って記事を見たところ、 $a = 0; $b = 'str'; if( $a == $b ) { echo 'equal'; } else { echo 'not equal'; } なんてコードが掲載されてた。試してみると確かに「equal」と出力される。どういうこっちゃ？ 仕様を調べてみる ちょっとこの現象は、どういう理屈に基づいてこうなるのかさっぱりわからないので、仕様上どうなっているのか調べてみた。 違う型同士を比較するので、暗黙の型変換が発生するだろうと思い、マニュアルの「型の相互変換」を見てみたがそれっぽいことは記述されていなかった。 このページの最後
PHPで画像XSSの一味変わった対策。 - cybertのセキュリティ日記
IE仕様？をついた画像ファイルを使用したXSSというのがあります。なかなか決定的な対策がなく、私も困っています。画像の再コンバートとか、画像のファイルヘッダを確認するのも。コメントとかカラーパレットとかで、決定的なものがありません。 が、ちょっと作ってみたのが、 1．空の画像を作って 2．ユーザのアップロードしてきた画像を空の画像にコピーする これだといけそうな気がしたので作っていました。 PHPのimagecopyを使って画像XSSをやっつける。どうぞHACKしてください。 http://tepppei.com/hackme/img.php 画像XSSの詳しくは有名な方々のブログの方にお任せ。 <html> 画像XSSの対策をしました。<br> 任意の画像ファイルをアップロードしてください。<br> 完了したら対策した画像のリンクが出ます。<br> XSSが動いたらおめでとうですね。連絡
今も新規開発され続けるPHP 4アプリケーション - ockeghem's blog
この日記をご覧の方には先刻ご承知のことだろうが、去る7月13日に、PHP 4のEOL(End Of Life)アナウンスが公式に宣言された*1。 これによると、PHP 4のメンテナンスは2007年12月31日まで、重大なセキュリティホールへの対応も2008年8月8日までとなっている。このため、既存の膨大なPHP 4アプリケーションのマイグレーションをどうするかは大きな課題である。 ここまでは皆さんご存知の情報であろう。 しかし、PHP 4アプリケーションは今も開発され続けている。私がそれを知ったのは、Webアプリケーションの脆弱性診断をしているからである。診断にてPHPなどの脆弱性を発見した場合はこれまでも都度報告していたが、2007年7月13日以降は、PHP 4を使っているだけでも、(脆弱性ではないが)上記情報を報告し、PHP 5への移行を推奨してきた。そういうレポートを書く際には、「き
フォームの2重送信の防止…
(Last Updated On: 2013年12月3日)ちょっと気になったので… 記事はコラム形式だったので書いていないだけだと思いますが2つ問題があります。 1. 識別可能なフォームの数に限りがある セッション変数を利用しているため変数名でフォームを識別する必要があり、ユーザが複数のフォームを利用した場合、正しく動作しない。この制限をなくす事もできますが、その場合セッション変数が大きくなりすぎた状態に対処するようにしないとならくなります。（ガーベッジコレクションの実装が必要） 2. レースコンディションによる2重投稿の可能性がある コードを見て分かる通り if (isset($_POST['submit_button'], $_SESSION['ticket'], $_POST['ticket']) && $_SESSION['ticket'] === $_POST['ticket']
58. すごいリロード対策
まず、日本のサイトにある一般的な登録フォームの画面遷移は 入力画面→入力確認画面→完了画面 となっている場合が多いようです。ここでリロード問題となるのは完了画面でのDBへのINSERT処理やCSV書き出し処理、メール送信処理など「一度しか行わない処理」です。例えば完了画面へ遷移した際にブラウザのリロードボタンが押された場合、確認画面よりsubmitした情報が再度submitされて上記の一度しか行わない処理が二度行われてしまいます。そうならないよう、リロード対策はスクリプトで制御します。 まずは確認画面のスクリプト 確認画面でチケットを発行し、セッションに保存しておきます。同時に完了画面へチケットがPOSTされるよう、hiddenにセット。こうして完了画面へ遷移させます。それでは完了画面のスクリプトを見てみましょう。 このように、確認画面で発行されたチケットは一度使い切ってしまえば2度処理さ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
not found
http://www.revulo.com/blog/20080715.html
http://htmlpurifier.org/
連載：なぜPHPアプリにセキュリティホールが多いのか?｜gihyo.jp
