#PHP でもutf8_decodeは使ってはならない
(Last Updated On: 2009年9月22日)Twitterで書いた方が良いようなエントリですが、たまには良いでしょう。 #perl – utf8::decode()ではなくEncode::decode_utf8()を使うべき理由 という記事がありました。PHPにも似た関数、utf8_decodeがあります。PHPでも使ってはなりません。日本人というよりマルチバイト圏で使っている人はほとんどいないはずです。理由はコードを見れば一目瞭然です。 /* All the encoding functions are set to NULL right now, since all * the encoding is currently done internally by expat/xmltok. */ xml_encoding xml_encodings[] = { { "ISO-
W2Cマークアップエンジニア・ワーキンググループ 「マークアップエンジニアが知っておきたい3つの脆弱性」 | 作者プロフィール
2009年9月16日、W2Cマークアップエンジニア・ワーキンググループでお話しした「マークアップエンジニアが知っておきたい3つの脆弱性」に関するサポートページです。とりあえず資料がダウンロードできます。 資料ダウンロードプレゼンテーション資料の PDF 版がダウンロードできます。 bakera_w2cWG.pdf (PDFファイル 487KB) 無断での再配布はご遠慮ください。また、資料内に含まれる画面キャプチャは全て削除されていますので、一部不自然な空白があります。 以下に若干の補足があります。 マークアップエンジニアが知っておきたい3つの脆弱性:補足 参考サイト話の中で触れたり、参考にしたりしたサイトです。 情報処理推進機構 (www.ipa.go.jp)経済産業省告示「ソフトウエア製品等脆弱性関連情報取扱基準」(PDF) (www.meti.go.jp)ソフトウェア等の脆弱性関連情報
論点の整理: 文字エンコーディングバリデーションは自動化が望ましい - 徳丸浩の日記(2009-09-18)
_文字エンコーディングバリデーションは自動化が望ましい 私が9月14日に書いたブログエントリPHP以外では - 既にあたり前になりつつある文字エンコーディングバリデーションに対して、大垣靖男さんから名指しで「セキュリティ専門家でも間違える！文字エンコーディング問題は難しいのか?」というエントリを頂戴しましたので、それに回答する内容を書きたいと思います。 まずは論点の整理から始めます。 合意していると思われる内容 まずは合意できていると思われる内容から書き始めたいと思います。以下の内容は、大垣さんと私で合意事項だと考えています。 論点1.文字エンコーディングの問題によるセキュリティ上の脅威がある 論点2.文字エンコーディングに起因するセキュリティ上の問題に対して、文字エンコーディングのバリデーションが有効である 論点3.Webアプリケーションによっては文字エンコーディングのバリデーションが不
XPath に文字列を埋め込むときの注意 - IT戦記
よく、以下のように XPath に文字列を埋め込む事があります document.evaluate('//*[@class="' + text + '"]', document, null, 7, null); まあ、僕もよくこんなコード書くんですけど。 でも、これって text が外部から来るものだったら、意図通りの動作をしないんですよね たとえば、以下のような例です。 var text = '"] | /hoge/fuga/piyo | .["'; document.evaluate('//*[@class="' + text + '"]', document, null, 7, null); というわけで 任意の文字列を XPath の式に変換する JavaScript を書いてみた 以下で試せます http://amachang.sakura.ne.jp/misc/xpath_es
セキュリティ対策を行うべき部分 – 自分が作っている部分
(Last Updated On: 2018年8月8日)アプリケーション開発者がセキュリティ対策を行うべき部分とはどこか?当たり前ですがアプリケーションです。アプリケーションとは広い意味でのアプリケーションです。Webアプリの場合もあれば、ライブラリやモジュールであったり、フレームワークであったり、言語やサーバの場合もあります。 すべてのアプリケーション開発者が同じような意識を持ち、アプリケーションが安全に動作するようの作る責任はアプリケーションにあると責任感を持って開発すべき、と言いたいところですが実際には難しいです。 例えば、開発を始めたばかりの初心者であれば無理があります。どう作れば安全か、危険か、判断する基準がないからです。経験を積んだ開発者でも自分が作った事もない様なプラットフォーム上でどのように作れば安全か判断できません。 何故、セキュリティが分かり辛いのか?その一つ理由が「セ
狙われるphpMyAdmin、攻撃のきっかけは？
狙われるphpMyAdmin、攻撃のきっかけは？：川口洋のセキュリティ・プライベート・アイズ（19） 川口、全国を飛び回ってます。 皆さんこんにちは、川口です。先日、私は島根に出張をしていました。せっかく島根という地に行くのですから各地の方と交流したいと思い、山陰ITPro勉強会（通称 SITW：しちゅー）での勉強会に参加してきました。 実は8月27日の夕方に、“勉強会エバンジェリスト”のまっちゃさんと話をしていてSITWの担当者の方に連絡を取ってもらえることになりました。そして28日に勉強会内容の調整、告知を一気に行い、週明けの9月2日に無事開催することができました。急な開催告知にもかかわらず、13人も参加してくれました。 勉強会の内容は参加した人だけのお楽しみということで割愛しますが、楽しんでいただけたのではないかと思っています。意外だったのは島根でIPS製品を開発している企業の方が参
第24回 無くならないSQLインジェクション脆弱性 | gihyo.jp
SQLMapを使ってみる 比較的メンテナンス状態が良いSQLMapを使ってみます。SQLMapはPythonで記述されたプログラムです。Pythonが利用可能なコンピュータであれば利用できます。 SQLMapを利用するために以下の、まったく無防備なコードを用意しました。これをローカルホストのApache／PHPで実行しアクセスできるようにしました。 PHPコード <?php $conn = mysql_connect('localhost','root'); mysql_select_db('test', $conn); $sql = "SELECT * FROM user WHERE name = '".$_GET['name']."' AND pass = '".$_GET['pass']."'"; $result = mysql_query($sql, $conn); if (!$r
セキュリティ専門家でも間違える！文字エンコーディング問題は難しいのか?
(Last Updated On: 2018年8月13日)一見徳丸さんのブログは分かりやすいように思えますが、それは単純な実験により分かりやすいように見えるだけで複数の間違いがあります。 その間違いとは 意図の取り違い – 誤読 言語の仕様と実装の理解不足 HTTPやPHP仕様の理解不足 セキュリティ対策をすべき場所の理解不足 です。(※0) 徳丸さんは非常勤とは言え、国の出先機関の研究員であるし、その出先機関は職務放棄とも言える文書（「例えば、PHPを使用しない」と勧める文書）を公開している(いた?)のでしっかり反論しておく必用がありますね。IPAのあの文書は職務放棄と言える文書だと思っています。これについても後で意見を述べます。 意図の取り違い – 誤読 最初の間違いは私のブログのエントリ「何故かあたり前にならない文字エンコーディングバリデーション」に対する理解です。特にPHPユーザに
PHP以外では: 既にあたり前になりつつある文字エンコーディングバリデーション - 徳丸浩の日記(2009-09-14)
_既にあたり前になりつつある文字エンコーディングバリデーション 大垣靖男さんの日記「何故かあたり前にならない文字エンコーディングバリデーション」に端を発して、入力データなどの文字エンコーディングの妥当性チェックをどう行うかが議論になっています。チェック自体が必要であることは皆さん同意のようですが、 チェック担当はアプリケーションか、基盤ソフト（言語、フレームワークなど）か 入力・処理・出力のどこでチェックするのか という点で、さまざまな意見が寄せられています。大垣さん自身は、アプリケーションが入力時点でチェックすべきと主張されています。これに対して、いや基盤ソフトでチェックすべきだとか、文字列を「使うとき」にチェックすべきだという意見が出ています。 たとえば、id:ikepyonの日記「[セキュリティ]何故かあたり前にならない文字エンコーディングバリデーション」では、このチェックは基盤ソフ
こんな簡単に他人がパスワードリセットできたのか – WordPress 2.8.4 リリース – Nire.Com
WordPress 2.8.4 がリリースされました。WordPress 2.8.2 → 2.8.3 に続くセキュリティリリースというわけですが、PHP の変数型のフレキシブルさを逆手にとった脆弱性のようです。実際 2.8.3 でやってみると、簡単にパスワードのリセットができてしまいました。 乗っ取られはしないが、イタズラでパスワードがリセットされる 日本語版公式サイトによると、 特別に作成された URL がリクエストされると、ユーザーがリクエストしたパスワードのリセットを確認するためのセキュリティチェックを攻撃者が回避できる可能性があります。その結果、データベースにキーを持たない最初のアカウント (通常は管理者アカウント) のパスワードがリセットされ、新しいパスワードがそのアカウントのメールアドレスに送られます。 ということで、パスワードが乗っ取られるわけではないですが、ピンポンダッシュ
ハッキング・クラックキング・ツール
目次 ハッカーに狙われるポイントは３つあります 最近注目度アップのツール（L0phtCrack と Nmap) ポートスキャン・ツール 大規模システム解析用商用ツール Web spoofing 付録 全体のテーマの性格上リンク切れのページが多くなっています。 出来るだけ修復をしていますが、リンク切れの場合はご容赦ください。 またここに掲載した情報はたまたま私が入手できたもので体系的に収集したものではありません。 いろんなクラック・ハッキング・ツールがインターネットで入手できます。 これらのツールはハッキングの防止やシステムのセキュリティホールを見つけるのに役に立ちますが、当然ハッキングのツールとしても使えます。 要は使い方の問題なのです。 最近の傾向としてはPCの性能向上で後で述べるようなポートスキャンやLinuxベースのツールが増加しています。 アメリカで最近またもや話題になった銃器によ
何故かあたり前にならない文字エンコーディングバリデーション
(Last Updated On: 2018年8月8日)私が4年前（2005年）に「Webアプリセキュリティ対策入門」を執筆していた時には、既に壊れた文字エンコーディングなどの不正な文字エンコーディングを利用したJavaScriptインジェクションやSQLインジェクション攻撃は比較的広く知られていました。この問題は当時のスラッシュドットジャパンでも取り上げられていました。/.で取り上げられたので、そこら中のWebサイトとユーザが被害に合うのでは？とヒヤヒヤしたので良く覚えています。 不正な文字エンコーディングを利用した攻撃は、文字エンコーディングを厳格に取り扱い、文字エンコーディングをバリデーションすれば無くなります。これを怠ると、システムのどこで問題が発生するか予想できなくなります。つまり、いい加減に文字エンコーディングを取り扱うと安全なシステムは作れないのです。 参考：エンジニア向けに
UTF-8の冗長なエンコードとは何で、なんでそれがセキュリティ的に危ないのか？を文字コード知識レヴェル3くらいの凡プログラマが考えてみる - tohokuaikiのチラシの裏
何故かあたり前にならない文字エンコーディングバリデーション | yohgaki's blog ってあるように、いまいち文字コードの不正な判定による危険性ってのが分かってない。 SJISの問題は、（2/3）SQLインジェクションを根絶！セキュア開発の極意 - 第5回■注目される文字コードのセキュリティ問題：ITproの記事がわかりやすかった。 というか、やっぱりPHP使ってると誰でも一度は「なんじゃこの『￥』は？」って思うもんなんで。 なるほど、確かに↓の図のように「あるバイト」が2つの意味を持つっていう文字コード形態はやばいんだなと。 EUC-JPはそんなことはしないで、1つのバイトには1つの意味しか取らせない。 だけど、これでも文字化けが起こることがある。経験的には、「マルチバイトをXX文字で切り落としたい」とかやった場合。ちゃんと文字コードを判定してくれるPHPでいえばmb_subst
第5回■注目される文字コードのセキュリティ問題
今回から5回にわたって，アプリケーション全体に関する文字コードの問題と対策について説明する。文字コードがセキュリティとどう関わるのか，疑問に思うかもしれないが，Webアプリケーションで文字コードを指定可能な個所は非常に多く，しかも文字コードの選定や処理方法次第ではぜい弱性の原因になることが分かってきている（図1）。実は文字コードはWebアプリケーションのセキュリティ問題の最新の話題と言ってよい。 2008年10月に開催されたセキュリティ・イベントBlack Hat Japan 2008では，ネットエージェントの長谷川陽介氏が「趣味と実益の文字コード攻撃」と題して，文字コード問題の広範なプレゼンテーションを発表した 。そのプレゼンテーション資料が発表されている のでこの問題の詳細に関心のある方は参照されたい。ここでは，セキュアなWebアプリケーションを開発するために文字コードの問題をどのよう
HASHコンサルティング徳丸浩の日記 - 9月4日 PHPカンファレンス2009 ビジネスデイで発表しました - 発注者のためのセキュリティ
■発注者のためのセキュリティ こちらの日記はずいぶん後沙汰しておりますが、標記のように、PHPカンファレンス2009 ビジネスデイにて発表する機会をいただきました。関係者のみなさまありがとうございました。 主催者からのリクエストが、「発注側として気をつけるべきセキュリティ」ということでしたので、今さらXSSやSQLインジェクションの話をしてもしょうがないと思い、発注者視点での話をこの機会にまとめてみようと思いました。そのため、タイトルは「45分で分かる、安全なWebアプリケーション開発のための、発注・要件・検収」といたしました。 発表の中でも述べましたが、発注者がセキュリティに関与できる場面は、発注と検収の場面しかなく、検収は発注仕様に沿っているかどうかを確認するものですので、発注と要件（発注仕様）が極めて重要ということになります。しかし、従来、このセキュリティ要件をどのように書けばよい
Webアプリにおける11の脆弱性の常識と対策
Webアプリにおける11の脆弱性の常識と対策：Webアプリの常識をJSPとStrutsで身につける（11）（1/4 ページ） 本連載は、JSP／サーブレット＋StrutsのWebアプリケーション開発を通じて、Java言語以外（PHPやASP.NET、Ruby on Railsなど）の開発にも通用するWebアプリケーション全般の広い知識・常識を身に付けるための連載です 【2013年2月25日】編集部より、おわびと訂正のお知らせ 本稿において読者の皆さまより多数のご指摘をいただきまして、誠にありがとうございます。編集部であらためて調べた結果、間違いを把握し、あらためて修正版を掲載させていただきます。この度は、長期にわたり誤った内容を掲載したので、読者の皆さまに多大なご迷惑をお掛けしたした点をおわび申し上げます。 通常、記事に間違いがあった場合には、筆者確認後に修正版を掲載するのですが、今回の場
高木浩光＠自宅の日記 - EV SSLを緑色だというだけで信用してはいけない実例
■ EV SSLを緑色だというだけで信用してはいけない実例 EV SSLに関して以前から懸念されていたことが既に現実になっていた。一時期、EV証明書を発行する一部のCA事業者が、EV SSLの宣伝で「緑色になったら安全」などといいかげんな広告を打っていて、誤った理解が広まりかねないと心配されていたわけだが、「緑色になったら安全」という理解がなぜ駄目なのか、その理由の一つは、いわゆる「共用SSL」サービスにEV SSLが使われかねないという懸念だった。 そして、その実例が既に存在していたことに気付いた。図1は私が作ったWebページである。 アドレスバーは緑色になっているが、ここに入力されたデータは私宛にメールで送信*1されてくる。（このページは既に閉鎖している。） 悪意ある者がこうしたページを作成*2し、何らかの方法でこのページに人々を誘導*3すれば、フィッシングの被害が出るおそれがある。
PHPの設定をセキュリティの観点から改善·PHP Security Consortium MOONGIFT
PHPは広く数多のWebサーバでインストールされ、使われている。設定ファイルは殆どそのままで使われていることが多いのではないだろうか。だが4.2より前のバージョンではregister_globalsのデフォルトがOnになっていたなど、利便性とセキュアであることとの関係で潜在的な問題はあるかも知れない。 php.iniのセキュリティチェックに 見直すのはPHPの設定ファイルであるphp.iniだが、多数の設定があるのでぱっと見では設定の善し悪しが分かりづらいかも知れない。そこで使うのがPHP Security Consortiumだ。 今回紹介するオープンソース・ソフトウェアはPHP Security Consortium、PHPのセキュリティ設定を見直すソフトウェアだ。 PHP Security ConsortiumはPHPで作られたソフトウェアで、phpinfo()から得られる情報を使っ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「UnicodeによるXSSとSQLインジェクションの可能性」プレゼン資料 - ockeghem's blog
ウイルス、セキュリティ対策｜OCNセキュリティポータル