文字コードとセキュリティ（クロスサイトスクリプティングなど）
では、このHTMLタグの無効化（サニタイジング）はどうすればいいかといいますと、皆さんご存知のように、左の表のように置換すれば良いことになります。これは、下記のような文字化け を悪用した攻撃にも効果的です。 例えば、「<」は16進文字コードで「0x3C」です。確かに、「<」で表示される文字（１バイト）なら、Shift_JISでもEUC-JPでもJISでも文字コードは一緒でしょう。しかし、もし「0x3C」を2バイト文字（漢字）の一部であると解釈すればどうでしょうか？ Shift_JISやEUC-JPには幸い「0x3C」は現れませんが、JISには現れます。 例えば、「紗」という漢字は、Shift_JISでは0x8ED1ですが、JISでは0x3C53です。0x3C53は、Shift_JISやEUC-JPでは、「1バイト文字が二つある」としか解釈できまず、この場合、「0x3C=<」「0x53=S」
htmlspecialchars()/htmlentities()の使用にはPHP 5.2.12以降/PHP 5.3.2以降を使う - zz log
携帯の絵文字について調べている際に、見つけたエントリーのまとめです。 htmlspecialchars()/htmlentities()を使用する際には、 PHP 5.2.12以降、PHP 5.3.2以降を使うこと。 以前のバージョンでは、 htmlspecialchars(ENT_QUOTES)を使用しても、XSSの可能性があります。 条件はかなり特殊(PHP側がShift_JISオンリー&特定のブラウザ)です。 (携帯はどうなのだろう。docomo買うしかないのかぁ。auとsoftbankの2個でもきついのに(非Wi-Fi搭載機種)。すべてがWi-Fi対応なら、パケット代が楽になるのに!) 参考 PHP 5.2.12 の文字エンコーディング関連の修正点 - t_komuraの日記 Shift_JISを利用することの是非 - ockeghem(徳丸浩)の日記 徳丸浩の日記 - [php]
サービス終了のお知らせ
平素より「PHPプロ！」をご愛顧いただき、誠にありがとうございます。 2006年より運営してまいりました「PHPプロ！」ですが、サービスの利用状況を鑑みまして、2018年9月25日（火曜日）をもちましてサービスを終了させていただくことになりました。 サービス終了に伴いまして、2018年8月28日（火曜日）を持ちまして、新規会員登録ならびにQ&A掲示板への新たな質問、回答の投稿を停止させていただきます。 なお、ご登録いただいた皆様の個人情報につきましては、サービス終了後、弊社が責任をもって消去いたします。 これまで多くの皆様にご利用をいただきまして、誠にありがとうございました。 サービス終了に伴い、皆様にはご不便をおかけいたしますこと、心よりお詫び申し上げます。 本件に関するお問い合わせはこちらよりお願いいたします。
htmlspecialcharsのShift_JISチェック漏れによるXSS回避策
補足 この記事は旧徳丸浩の日記からの転載です（元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2）。 備忘のため転載いたしますが、この記事は2009年10月9日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり このエントリでは、PHPのhtmlspecialchars関数の文字エンコーディングチェック不備をついたクロスサイト・スクリプティング(XSS)脆弱性について、PHP側のパッチが提供されない状況での回避策について説明します。 何が問題か PHPにおいて、XSS対策にはhtmlspecialcharsによって記号をエスケープすることが行われますしかし、htmlspecialcharsを利用していても、Shift_JISの先行バイトを利用して、XSSが発生する場合があります。 例えば、以下のようなINPUTがあ
Supplementation of Bug #49785
Written by Kousuke Ebihara <ebihara@tejimaya.com>. And thanks to Hiroshit Tokumaru and t_komura. 1. Hiroshi Tokumaru Reports About "How level does htmlspecialchars() check invalid encodings?" Original entry is http://www.tokumaru.org/d/20090930.html [ja] He inspected that the following enhancement is really fixed. 08 Nov 2007, PHP 5.2.5 (snip) - Fixed htmlentities/htmlspecialchars not to accept p
Shift_JIS では、htmlspecialchars() を使用しても XSS が可能な場合がある - t_komuraの日記
以下のページに関連して、htmlspecialchars() を使用している場合でも XSS が可能かどうか少し調べてみました。 http://www.tokumaru.org/d/20090930.html その結果、いくつかのブラウザで文字エンコーディングに Shift_JIS を使用していた場合、XSS が可能なことを確認しました。 テストコードは以下の通りです。リンクにマウスポインタを乗せると埋め込んだ Javascript が実行されます。 <?php $_GET['a1'] = "\xf0"; // \xf0 - \xfc で可能 $_GET['a2'] = " href=dummy onmouseover=alert(document.title) dummy=dummy"; header( "Content-Type:text/html; charset=Shift_JIS
プログラミング未経験から始めるPHP入門 (5) 入力フォームを使ってデータを送受信しよう！
はじめに 本連載では、PHPまたはプログラミング初心者の方を対象に、PHPを用いたWebアプリケーションの作成方法を説明していきます。今回はテキストボックスなどの入力フォームを使い、データを送受信する方法に関して説明をします。PHPの環境構築に関しては第2回をご参照ください。 対象読者 プログラミングが初めてでこれから学習する予定の方 プログラミングの経験はあるがPHPを初めて学習する方 これまでの連載 第1回「プログラムってなんだろう？ PHPってどういうもの？」 第2回「XAMPPをインストールして開発環境を整えよう！」 第3回「変数の扱い方を習得しよう！」 第4回「条件分岐と繰り返しを使いこなそう！」 動作確認環境 PHPが動作する環境が必要となります。以下に、今回のアプリケーション作成／動作確認に用いた環境を示します（インストールにあたっては最新安定版の使用を推奨します）。 Win
Shift_JISを利用することの是非 - ockeghem's blog
前回に引き続き、はじめてのPHPプログラミング 基本編5.3対応のゆるいところ第二段は、文字エンコーディングについてだ。 本書は、文字エンコーディングとしてShift_JISを採用している。しかし、本家から配布されているWindows用バイナリのPHP処理系は、「--enable-zend-multibyte」というオプションが設定されていないため、2バイト目が0x5Cで終わる文字が正しく扱えない。このため、以下のPHPスクリプトはエラーになる。いわゆる5C問題である。著者には、ブログのコメントとして確認した。 <?php $a = "表"; ?> 文字列リテラルを"表\"としてやればエラーは回避できるが、わずらわしいし、第一みっともない(前世紀のスクリプトみたいだ)。 やはり、ソースコードはEUC-JPかUTF-8で記述すべきだったと思う。前に取り上げたPHP×携帯サイト デベロッパーズ
「セキュアなPHPアプリケーションを作成するための7つの習慣」のサンプルがとんでもなく酷い - ockeghem's blog
はてブで250以上のブックマークを得ている以下のエントリ。 PHP アプリケーションを作成する際には、可能な限りセキュアなアプリケーションにするために、次の 7 つの習慣を守る必要があります。 入力を検証する ファイルシステムを保護する データベースを保護する セッション・データを保護する XSS (Cross-Site Scripting: クロスサイト・スクリプティング) の脆弱性から保護する フォームへの投稿を検証する CSRF (Cross-Site Request Forgeries: クロスサイト・リクエスト・フォージェリー) から保護する ほう。しかし、内容はどうだろうか。 読んでびっくりした。説明も微妙なところが多いが、サンプルが酷い。こんなサンプルでは悪い習慣が身についてしまう。全部は書ききれないと思うので、目についたところからピックアップして紹介する。 パストラバーサル
Webデザイナが知っておくべきPHPセキュリティ - builder by ZDNet Japan
MSセキュリティ担当者が紹介 マルチクラウド環境の保護を追求する Microsoft Defender for Cloud 本当のデータ活用できていますか？ データドリブンがあたりまえと言われる今あらためて考えたいデータ活用のありかた Kubernetes活用の最適解とは？ 今、注目のコンテナを活用した柔軟なIT基盤 運用、管理の課題を解決しメリットを最大化 DNSを守り、DNSで守る 高度・巧妙化し危険度を増すサイバーリスク いま考えるべきモダンセキュリティのあり方 50年の経験を持つアイネットが提供 ユーザー企業の使いやすさを第一に考えた ワンストップで使えるマネージドクラウド AWSとAzureを更に使いこなそう イマドキのマルチクラウドセキュリティを MS担当者が徹底解説 大事なのは”仕事の段取り” 幅広い業務を任されているからこそできる ひとり情シス流の業務改善術 いま求められる
WEBデザイナーの為のXSS(クロスサイトスクリプティング)入門
WEBデザイナーの為のXSS(クロスサイトスクリプティング)入門 情報処理推進機構のXSS（クロスサイトスクリプティング/Webアプリケーションに存在するセキュリティホール）が公開されて、ネット上では盛り上げっているようです。 まぁ、これを機会にXSS(クロスサイトスクリプティング)って言葉をはじめて聞いたデザイナー・プログラマーの方は、正しい知識・正しい対処法を勉強しましょう。 とくにプログラムなんてちょっと改造するだけというレベルの、WEBデザイナーさんに注意してもらいたいです。 XSSはwebページにスクリプトを埋め込む攻撃法方法 XSSは別のサイト(これはどこでも良い)から攻撃先のurlに対して特定の文字列を送ることにより攻撃先のurlでスクリプトを実行する攻撃方法です。 XSS脆弱性のあるスクリプトはこんなスクリプトである。 <input type="hidden" name="
諸君 私は脆弱性が好きだ
諸君 私は脆弱性が好きだ 諸君 私は脆弱性が大好きだ PHPが好きだ XSSが好きだ SQLインジェクションが好きだ CSRFが好きだ UTF-7が好きだ expressionが好きだ シェアウェアで Webで Googleで スペシャルねこまんまで LiveHTTPで Filemonで Regmonで OllyDbgで Perlで この地上に存在するありとあらゆる脆弱性が大好きだ セキュリティに関して口うるさく言っているサイトの脆弱性をいとも簡単に見つけるのが好きだ 大企業のサイトがGoogleによって脆弱性を発見された時など心が踊る Googleがあっけなく脆弱性を見つけてしまうのが好きだ Perlを馬鹿にしていた奴のアカウントを乗っ取った時など胸がすくような気持ちだった 粘り強い同業者がMS Officeのシリアル認証と格闘している様が好きだ PHP覚えたての野郎共が続々と脆弱性を作
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
第11回 スクリプトインジェクションを防ぐ10のTips | gihyo.jp
前回はスクリプトインジェクションがなくならない理由を紹介しました。それをふまえて今回はスクリプトインジェクションを防ぐ10のTipsを紹介します。 デフォルト文字エンコーディングを指定 php.iniには、PHPが生成した出力の文字エンコーディングをHTTPヘッダで指定するdefault_charsetオプションがあります。文字エンコーディングは必ずHTTPヘッダレベルで指定しなければなりません。しかし、デフォルト設定ではdefault_charsetが空の状態で、アプリケーションで設定しなければ、HTTPヘッダでは文字エンコーディングが指定されない状態になります。 HTTPヘッダで文字エンコーディングを指定しない場合、スクリプトインジェクションに脆弱になる場合あるので、default_charsetには“UTF-8”を指定することをお勧めします。サイトによってはSJIS、EUC-JP
第10回 スクリプトインジェクションが無くならない10の理由 | gihyo.jp
SQLインジェクション対策は非常に簡単です。しかしブラウザに対する「スクリプトインジェクション」はなかなか無くなりません。スクリプトインジェクションが無くならない10の理由をあげてみます。 複雑な攻撃経路と対策 前回紹介したように、ブラウザに対するスクリプトインジェクション攻撃の経路は3種類あります。エスケープ方法も数種類あります。すべての出力を完全にエスケープできればセキュリティ維持も容易になりますが、タグや属性を出力したい場合もあるため、必ずしもすべての出力をエスケープできるわけではありません。さらに攻撃手法にも、サイトをまたがった攻撃、直接攻撃、間接攻撃などパターンがあります。エスケープできないデータへの不正なスクリプトの挿入を防ぐには、データの起源までさかのぼり安全性を確保しなければなりません。ブラウザに対するスクリプトインジェクション対策はデータベースサーバへのSQLインジェクシ
第7回 いまさらながらクロスサイトスクリプティングの基礎の基礎 | gihyo.jp
今回はWebアプリケーションを作ったことがない方でも分かるようクロスサイトスクリプティング脆弱性を解説します。 クロスサイトスクリプティングとは？ 初めてクロスサイトスクリプティングと聞いて、どのような問題なのかすぐに理解できる人はいないと思います。サイトAに記述されたJavaScriptプログラムがサイトB上で実行されるために発生することが問題とされたので、「サイト間をまたがるスクリプトの実行」問題として、クロスサイトスクリプティング（XSS）と名前が付けられました。この命名では直感的に分かりづらい、サイト間にまたがらずHTMLメールなどにJavaScriptを挿入する攻撃でも同じ効果が得られることから、「JavaScriptインジェクション」とも呼ばれるようになっています。 図1 簡単なクロスサイトスクリプティング 例1 簡単な直接攻撃 掲示板サイトに投稿されたデータをエスケープ処
T.Teradaの日記 HTML Purifierを試した
Webメールでは、受信したHTMLメールのタグを残して、クライアントサイドスクリプト（JavaScriptなど）のみを除去するサニタイズ処理を行ないます。 このようなスクリプト除去処理は、Blog、掲示板などでも行なわれる、比較的ポピュラーなものであるため、それ用のライブラリがいくつか存在します*1。 HTML Purifierもその一つです。PHP4/5で動作します。バージョン1.0.0のリリースは2006年9月ですから、比較的新しいものです。私は昨年末に初めて触ってみました（バージョン1.3.2です）。 これまでのものと比べて、非常によく出来ているなと思いましたので、日記に書いてみます。 HTML Purifierの概要 特徴としては、以下が挙げられると思います。 ユニコード対応 UTF-8のHTMLに対応（既存のライブラリの多くはlatin1を暗黙の前提としていました）。EUC-JP
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
JVN#50327700 PHP におけるクロスサイトスクリプティングの脆弱性がよくわからない件について - 個々一番の.....
Download details: Windows Server 2003 Resource Kit Tools