正規表現によるバリデーションでは ^ と $ ではなく \A と \z を使おう
正規表現によるバリデーション等で、完全一致を示す目的で ^ と $ を用いる方法が一般的ですが、正しくは \A と \z を用いる必要があります。Rubyの場合 ^ と $ を使って完全一致のバリデーションを行うと脆弱性が入りやすいワナとなります。PerlやPHPの場合は、Ruby程ではありませんが不具合が生じるので \A と \z を使うようにしましょう。 はじめに 大垣さんのブログエントリ「PHPer向け、Ruby/Railsの落とし穴」には、Rubyの落とし穴として、完全一致検索の指定として、正規表現の ^ と $ を指定する例が、Ruby on Rails Security Guideからの引用として紹介されています。以下の正規表現は、XSS対策として、httpスキームあるいはhttpsスキームのURLのみを許可する正規表現のつもりです。 /^https?:\/\/[^\n]+$/
PHP で $_GET $_POST で Notice: Undefined index: が出る : Serendip – Webデザイン・プログラミング
以下のような記述が .php 内にあった場合、Notice: Undefined index: id in /Users/foo/public_html/hoge.php on line n と表示される。 $id = $_GET['id']; これは、外部からの汚染された引数が渡されたことが原因なので、htmlspecialchars を使ってサニタイズすると警告が表示されなくなる。 $id = htmlspecialchars(@$_GET['id']); 上の方法では、@を使ってエラー出力を抑制しているだけ。 $_GET['id'] の値が初期化されていないためにエラーとなっているので、isset で初期化チェックをおこなう。 $id = isset($_GET['id']) ? htmlspecialchars($_GET['id']) : null; 修正：2011/6/1
PHPのpreg_replace()で「The /e modifier is deprecated」となる場合の対処方法
PHPのpreg_replace()で「The /e modifier is deprecated」となる場合の対処方法について紹介します。 １．問題点 次のようなpreg_replace()で日付のフォーマットを変更するPHPを実行したところ、「The /e modifier is deprecated」というエラーが発生しました。 preg_replace()のe修飾子は、置換後パターンの文字列をPHP文法に従って評価することができるというものです。「e」はevalの意味のようです。 <?php $str = '2014-05-26'; $str = preg_replace("/(\d{4})-(\d{2})-(\d{2})/e","Date('n/j/Y',strtotime('$0'))",$str); echo $str; ?> 期待する結果 5/26/2014 エラー Dep
「Text run is not in Unicode Normalization Form C.」というHTML Validation Serviceの警告について
HTML Validation Serviceで発生した「Text run is not in Unicode Normalization Form C.」という警告の意味について紹介します。 この警告について日本語で書かれた記事はこれが第1号のようです（笑）。 １．問題点 昨日エントリーした「iPadなどのタブレット端末の画面操作に最適なスマートペン「パワーサポート スマートペン」」のページを「W3C Markup Validator」や「(X)HTML5 Validator」にかけたところ、「Text run is not in Unicode Normalization Form C.」という警告が表示されました。 （クリックで拡大） スクリーンショットでは「す」が警告の対象になっていますが、ひっかかったのはその部分ではなく、少し手前にある「で」が対象です。 ２．「Text run
PHP5.4のhtmlspecialcharsに非互換問題
第3引数を指定していない場合の影響前述のように、htmlspecialchars関数の第3引数を指定していない場合、PHP5.3までは、文字エンコーディングがISO-8859-1が指定されたとみなされます。この場合、入力内容にかかわらず不正な文字エンコーディングと判定されることはありません。したがって、文字エンコーディングのチェックが働かない代わりに、エラーになることもありませんでした。 これに対して、PHP5.4の仕様により文字エンコーディングがUTF-8とみなされた場合に、Shift_JISやEUC-JPの2バイト文字が入力されると、高い確率で「UTF-8として不正」というエラーになり、htmlspecialchars関数の出力は空になります。つまり、プログラムが正常に動作しません。 htmlspecialchars関数の第3引数を指定しておらず、内部文字エンコーディングがShift_
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PHPのtrueは1でfalseは''の話 - Qiita
PHP の str_replace でエスケープ文字に置換できない謎
JavaScriptã�®æ–‡å—列ã�«æ”¹è¡Œã‚³ãƒ¼ãƒ‰ã‚’入れる方法 | PbTimes 情報誌
