XSS対策:JavaScriptのエスケープ(その3) - ockeghem's blog
5/14の日記XSS対策:JavaScriptのエスケープ(その2) - ockeghem(徳丸浩)の日記に対して、id:hasegawayosukeさんからコメントを頂戴した。その内容は、JavaScriptに対応していないブラウザの場合に対する考慮が抜けているという趣旨だと理解した。 元の日記にも書いたように、私自身はJavaScriptの動的生成は(特殊な場合を除いて)好ましくないと考えているが、始めた以上は最後まで検討しようと思う。 解決すべき課題の整理 まず、解決すべき課題を整理しよう。元の日記では、JavaScriptを動的生成する(ただし、文字列リテラル内のデータに限る)場合のXSS対策として二段階のエスケープが必要であることを説明した。具体的には、(1)JavaScript文字列リテラルのエスケープとして、「"」、「'」、「\」のエスケープの実施、(2)HTMLとしてのエス
PHPのイタい入門書を読んでAjaxのXSSについて検討した(3)～JSON等の想定外読み出しによる攻撃～ - ockeghem(徳丸浩)の日記
昨日の日記の続きで、Ajaxに固有なセキュリティ問題について検討します。今回はJSON等の想定外読み出しによる攻撃です。これら攻撃手法は本来ブラウザ側で対応すべきもので、やむを得ずWebアプリケーション側で対応する上で、まだ定番となる対策がないように思えます。このため、複数の候補を示することで議論のきっかけにしたいと思います。 まず、作りながら基礎から学ぶPHPによるWebアプリケーション入門XAMPP/jQuery/HTML5で作るイマドキのWeから、Ajaxを利用したアプリケーションの概念図を引用します（同書P20の図1-23）。 前回、前々回は、(5)のHTTPレスポンスの前後で、JSON等のデータ作成（エンコード）に起因するevalインジェクションや、(5)のレスポンスを受け取った後のHTMLレンダリングの際のXSSについて説明しました。 しかし、問題はこれだけではありません。正常
PHPのイタい入門書を読んでAjaxのXSSについて検討した(2)～evalインジェクション～ - ockeghem(徳丸浩)の日記
昨日の日記の続きで、Ajaxに固有なセキュリティ問題について検討します。タイトルはXSSとなっていますが、今回紹介する脆弱性はXSSではありません。 作りながら基礎から学ぶPHPによるWebアプリケーション入門XAMPP/jQuery/HTML5で作るイマドキのWeから、Ajaxを利用したアプリケーションの概念図を引用します（本書P20の図1-23）。 Ajaxのアプリケーションでは、XMLHttpRequestメソッド等でデータを要求し、サーバーはXML、JSON、タブ区切り文字列など適当な形式で返します。ブラウザ側JavaScriptでは、データ形式をデコードして、さまざまな処理の後、HTMLとして表示します。以下に、Ajaxのリクエストがサーバーに届いた後の処理の流れを説明します。 サーバー側でデータを作成、取得 データ伝送用の形式（XML、JSON、タブ区切り文字列等）にエンコード
徳丸本の台湾版が発売開始されました - ockeghem's blog
拙著「体系的に学ぶ 安全なWebアプリケーションの作り方（以下、徳丸本）」が中国語繁体字に翻訳され、台湾で販売開始されましたので報告します。出版社の紹介ページ。 @kuroneko_stacyさんが、早くも台湾で購入されたそうで、書店での平積みの様子を写真にとって下さいました。画像をクリックすると拡大します。 昨日見本が届きましたので、いくつか写真を紹介します。まずは表紙。 謝辞のところ。 人気の(?)3章、悪人と銀行員の会話。 台湾の本屋さんのコメント（@kuroneko_stacyさんと現地本屋さんの会話） 徳丸本、台湾でも人気だそうです。本屋のおじちゃんが良さを熱く語ってくれました。「この本は凄く良くできている！日本人が書いているんだ。知ってたか？」って聞かれたので、おこがましくも著者は友人ですよって言わせていただきました（笑） https://twitter.com/kuronek
書籍「Android Security」の暗号鍵生成方法には課題がある - ockeghem's blog
書籍「Android Security 安全なアプリケーションを作成するために」は既に各方面で絶賛されているように、Androidアプリケーションの開発者には必携の書籍だと思いますが、新しい分野だけに、首をひねらざるを得ない箇所もありました。このエントリでは、同書第10章「暗号化手法」から共通鍵の生成方法について議論します。 はじめに 書籍「Android Security」（業界では「タオ本」と呼ばれているので、以下タオ本と記述）の10章では、端末内のファイルを暗号化して保存する手法について説明されています。その際に問題となるのが、鍵の生成と保管の方法です。スマートフォン端末、とくにAndroid端末は、アプリケーションのリバースエンジニアリングとルート化の可能性は常にあるため、あらゆる場合にも破られない暗号化というものはありません。このため、守るべき情報資産と、想定する脅威（言い換え
「管理者パスワードは何日ごとに変更すればよいか」に関する質疑応答 - ockeghem's blog
昨日Webサイトを守るためのセキュリティ講習会の講師を担当しました。講習会の終了後、受講生から「管理者パスワードの定期的変更」に関する質問がありました。備忘の為、質疑内容を以下に記録します。 Q1:上位ポリシーにて、管理者パスワードは定期的に変更するように義務づけられているが、何日毎に変更するのが正しいのか。最近の専門家の見解をお伺いしたい A1:専門家の見解は分かれているとお答えしました 現在の主流はパスワードを定期的に変更するべしという考え方ですが、それに異論を持つ人もいて、私もその一人です。 一般ユーザのパスワードとは異なり、管理者パスワードは、業務の必要上複数の人が知っている状況があります。その状況では、「定期的に変更」するのではなく、管理者パスワードを知っている人が、他業務に異動、あるいは退職するタイミングで遅滞なく変更するべきです。そうしないと、「管理者でなくなった人が管理者パ
「SQLインジェクション対策」でGoogle検索して上位15記事を検証した - ockeghem's blog
このエントリでは、ネット上で「SQLインジェクション対策」でGoogle検索した結果の上位15エントリを検証した結果を報告します。 SQLインジェクション脆弱性の対策は、既に「安全なSQLの呼び出し方」にファイナルアンサー（後述）を示していますが、まだこの文書を知らない人が多いだろうことと、やや上級者向けの文書であることから、まだ十分に実践されてはいないと思います。 この状況で、セキュリティのことをよく知らない人がSQLインジェクション対策しようとした場合の行動を予測してみると、かなりの割合の人がGoogle等で検索して対処方法を調べると思われます。そこで、以下のURLでSQLインジェクション対策方法を検索した結果の上位のエントリを検証してみようと思い立ちました。 http://www.google.co.jp/search?q=SQLインジェクション対策 どこまで調べるかですが、以前NH
YAPC::Asia Tokyo 2011でパスワードについてトークしました - ockeghem(徳丸浩)の日記
既にこのブログでも報告しましたが、10月14日、YAPC::Asia Tokyo 2011でパスワードについてトークしてきました。スライドとビデオは以下のサイトにあります。 オフィシャルサイト HASHコンサルティング・オフィシャルブログ 私はWebアプリケーションのセキュリティを専門にしていますが、開発系のカンファレンスでしゃべる機会を増やしたいと思っています。Webアプリケーションの脆弱性は、つまるところWebアプリケーションのバグなので、開発者の方々にセキュリティのことを知ってもらわないと、脆弱性をなくすことはできないからです。 ということで、今年はYAPCの他に、PHPカンファレンスでもトークさせていただきました。PHPカンファレンスもYAPCも、トークを公募していて、誰でも応募できます。PHPカンファレンスの方は、昨年もトークに応募していて、文字コードの話をしました。このテーマは
勝手に補足：レガシーPHPのセキュリティ対策，大丈夫ですか？未修正の脆弱性（2） - ockeghem's blog
第4回 未修正の脆弱性（2）：レガシーPHPのセキュリティ対策，大丈夫ですか？｜gihyo.jp … 技術評論社という記事を読みました。とても重要なことが記載されている一方で、記述の間違い及び記述もれがあるため、読者の便宜のため勝手に補足したいと思います。具体的に、PHP4系の最終版PHP4.4.9にてパッチの提供されない4つのぜい弱性についての話題です。一部のぜい弱性はPHP5.2系でもパッチが出る見込みがないものです。 CGIのDoS 元記事ではCVE-2009-3660として紹介されていますが、CVEおよびNVDのサイトを見ると、Efront 3.5.4以前の脆弱性とあります。明らかに該当しないので調べてみると、CVE-2008-3660の間違いのようですね。2008を2009とTYPOしたのでしょう。 脆弱性の中味ですが、元記事に以下のように書かれています。 この脆弱性は不正なパス
みずほダイレクトの謎 - ockeghem's blog
ソフトバンク携帯電話のSSL方式変更に伴い、みずほ銀行のモバイルバンキングが一部使えなくなっていましたが、昨日復旧したようです。 7月3日時点では、みずほダイレクトのトップに以下のように表示されていました。URLは魚拓のものです。 現在、ソフトバンクの携帯電話からアクセスいただいた、みずほダイレクト（モバイルバンキング）の［ネット決済振込サービス］および［Pay-easy（ペイジー）税金・料金払込みサービス］において、一部のお取引がご利用いただけません。「ご利用の端末のユーザーIDを「ON」に設定し、再度アクセスしてください。」と表示された場合には、パソコンなどでご利用ください。 お客さまには大変ご迷惑をおかけしておりますことをお詫び申しあげます。 （原因につきましては現在調査中です。） http://megalodon.jp/2011-0703-0032-51/www.mizuhoban
EZwebの2011年秋冬モデル以降の変更内容とセキュリティ上の注意点 - ockeghem's blog
au/KDDIの技術情報サイトEZfactoryには、2011年秋冬モデル以降にEZwebの仕様変更がある旨表示されています。セキュリティ上の問題の可能性もあるため以下に報告します。 EZfactoryトップページでの告知内容 EZfactoryトップページには、2011年秋冬モデルでの変更を以下のように要約しています。 ※お知らせ※ EZブラウザは、2011年秋冬モデルにて、EZサーバを含め、「機能」及び「ネットワーク環境」の見直しを行ないます。 これによる主な変更点は以下のとおりです。 ＜主な変更点＞ ・EZサーバの言語変換機能が削除され、HDMLが非サポートとなる。 ・EZブラウザ、PCサイトビューアーのIPアドレス帯域が統一される。 今後EZブラウザ向けコンテンツを作成する場合は、XHTML Basicを推奨します。 http://www.au.kddi.com/ezfactory
モテるセキュ女子力を磨くための4つの心得「SQLインジェクションができない女をアピールせよ」等 - ockeghem's blog
こんにちは、セキュリティ勉強会などで講師を担当しているockeghem夫です。私は学歴も知識もありませんが、セキュリティに関してはプロフェッショナル。今回は、モテるセキュ女子力を磨くための4つの心得を皆さんにお教えしたいと思います。 1. あえて2〜3世代前の書籍の知識で対策する あえて2〜3世代前の書籍の知識で脆弱性対策するようにしましょう。そして勉強会の打ち上げで好みの男がいたら話しかけみましょう。「あ〜ん！ addslashes本当にマジでチョームカつくんですけどぉぉお〜！」と言って、男に「どうしたの？」と言わせましょう。言わせたらもう大成功。「SQLインジェクションとか詳しくなくてぇ〜！ サテ技本に載ってたからずっとaddslashes使ってるんですけどぉ〜！ 日本語が化けるんですぅ〜！ ぷんぷくり〜ん（怒）」と言いましょう。だいたいの男は新しい書籍を持ちたがる習性があるので、古か
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
