サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
デスク環境を整える
ockeghem.hatenablog.jp
昨日のソフトバンクの非公式JavaScript対応の調査結果 | 徳丸浩の日記で報告したように、昨年5月に、ソフトバンク60機種の検証を行い、JavaScript対応の状況などを調査しました。当時はまだ公式なJavaScript対応機種はない状態でしたが、既にほとんどの端末が *非公式に* JavaScriptに対応していました。 このエントリでは、検証の様子を報告します。 なぜJavaScript対応状況を調査したか http://www.hash-c.co.jp/info/20091124.htmlを公表した前後に、とある方(この方)から、ソフトバンクのケータイでもJavaScriptが動作すると伺いました(参考のやりとり)。XMLHttpRequestも含めてJavaScrptが動くと教えていただいた932SHを私も購入して調べたところ、以下が判明しました。 確かにJavaScrip
PHPの現行バーション(PHP5.3.6以前)には、ファイルアップロード時のファイル名がルート直下の場合、先頭のスラッシュを除去しないでファイル名が渡される問題があります。CVE-2011-2202として報告されています。 後述するように影響を受けるアプリケーションは少ないと思われますが、念のためアプリケーションの確認を推奨します。また、次バージョンPHP5.3.7のRC1で修正されていることを確認しましたので、PHP5.3.7正式版が公開され次第、できるだけ早期に導入することを推奨します。 ※このエントリは、http://blog.tokumaru.org/2011/06/PHP-file-upload-bug-CVE-2011-2202.html に移転しました。恐れ入りますが、続きは、そちらをご覧ください。
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
Scan Tech Report(無償版)を読んでいたら、PHP には、socket_connect() 関数の脆弱性(CVE-2011-1938)があると紹介されていました。調査の結果、この脆弱性の影響を受けるPHPのバージョンとして公開されている情報は間違っているようなので報告します。 概要 Scan Tech Reportには以下のように説明されています。 PHP には、socket_connect() 関数の処理に起因してバッファオーバーフローを引き起こしてしまう脆弱性が報告されました。 http://scan.netsecurity.ne.jp/archives/51983960.html バッファオーバーフローというと影響が大きそうでびっくりしますが、この脆弱性はあまり話題になっていません。その理由は、この脆弱性が悪用されるシナリオがほとんどあり得ないからです。 もう少し、詳し
こんにちは、セキュリティ勉強会などで講師を担当しているockeghem夫です。私は学歴も知識もありませんが、セキュリティに関してはプロフェッショナル。今回は、モテるセキュ女子力を磨くための4つの心得を皆さんにお教えしたいと思います。 1. あえて2〜3世代前の書籍の知識で対策する あえて2〜3世代前の書籍の知識で脆弱性対策するようにしましょう。そして勉強会の打ち上げで好みの男がいたら話しかけみましょう。「あ〜ん! addslashes本当にマジでチョームカつくんですけどぉぉお〜!」と言って、男に「どうしたの?」と言わせましょう。言わせたらもう大成功。「SQLインジェクションとか詳しくなくてぇ〜! サテ技本に載ってたからずっとaddslashes使ってるんですけどぉ〜! 日本語が化けるんですぅ〜! ぷんぷくり〜ん(怒)」と言いましょう。だいたいの男は新しい書籍を持ちたがる習性があるので、古か
ヨミウリ・オンラインを閲覧していて、ふと、ソーシャルブックマークのボタンが設置されていることに気がつきました。以下に引用します。 ご覧のように、twitterやfacebookの他、はてなブックマークにワンタッチで登録できるようになっています。ソーシャルブックマークのボタンにはヘルプボタン(右端の?)があり、ヘルプページにリンクしています。 ヨミウリ・オンラインにソーシャルボタン導入 ヨミウリ・オンライン(YOL)の記事に「ソーシャルボタン」、および「携帯に送るボタン」を設置しました。ソーシャルボタンはソーシャルサービス上で記事をブックマークしたり、関心を持った記事を手軽に友人・知人と共有したりすることができます。ぜひご利用ください。 【中略】 (2010年11月15日 読売新聞) http://www.yomiuri.co.jp/info/socialbutton/ 引用部分にあるように
ホワイトリストという用語はセキュリティの分野では非常に基本的な用語ですが、セキュアプログラミングという文脈では意外に曖昧な使われ方がされているように見受けます。本エントリでは、ホワイトリストという用語の意味を三種類に分類し、この用語の実態に迫ります。拙著体系的に学ぶ 安全なWebアプリケーションの作り方(以下、徳丸本)では、ホワイトリストという用語を一度も使っていませんが、その理由に対する説明でもあります。 ホワイトリストの分類 私の調査によると、ホワイトリストは以下の3種類に分類されます。 許可されたものの一覧表(第一種ホワイトリスト) セキュリティ上安全と考えられる書式(第二種ホワイトリスト) アプリケーション仕様として許可された書式(第三種ホワイトリスト) 以下順に説明します。 許可されたものの一覧表(第一種ホワイトリスト) ホワイトリストというくらいですから、本来のホワイトリストは
このエントリでは、evernoteクライアントを使って、evernote社にも復号できない状態でテキストを暗号化する方法について紹介します。 昨日、EvernoteのXSS問題に関連して、「Evernoteの開発者も徳丸本読んでいたらよかったのにね」などとつぶやいていたら、「EvernoteのCEOが徳丸さんに会いたがっている」という連絡をもらいました。こういうのは異例のことでちょっと悩みましたが、行くっきゃないだろうということで、Evernote社の日本法人でmalaさんと一緒にCEOにお会いしました。 XSSやポリシーについては非常に誠実な対応をお約束いただいたのでよいミーティングだったと思います。僕が指摘した脆弱性についても、当日の夜のうちに直っていたようです。米国時間では深夜から早朝という時間帯で、迅速な対応だったと思いますが、本題はこれからです。 その場で、malaさんが「Eve
ライザムーン攻撃に対する行き届いた解説を読みました。 大規模インジェクション 「LizaMoon」攻撃について調べてみた。 - piyolog ここで紹介されている内容は素晴らしいと思うのですが、一点、WAFに関する以下の記述が引っかかりました。 SQLインジェクションであれば既知の攻撃手法でありWAFで防ぐことは出来るのではという考え方もありますが、例えばブラックリストタイプのWAFでこの数値リテラル型をつくSQLインジェクションを防ぐことが出来ません。HTTPリクエストとして受けた文字列だけで、最終的にデータベースに対して発行されるSQLでその文字列がどのような扱いになるか(数値リテラルになるのかどうか)判断することが出来ないためです。 本当にブラックリストタイプのWAFで防ぐことができないのでしょうか。IBMのレポートに紹介されている以下の攻撃で考えてみます。 /target.asp
拙著「体系的に学ぶ 安全なWebアプリケーションの作り方*1」はおかげさまで多くの読者の支持をいただき、まことにありがとうございます。その結果として、本書はAmazonをはじめとするネット書店にてお求めにくい状況が生じております。AmazonマーケットプレイスやYahoo!オークション等では、一部においてプレミア価格で販売されているようです。未来の読者の皆様に不利益が生じるといけませんので、在庫状況と今後の見通しについて報告致します。 在庫の状況について 3月1日の発売開始以降本書は、Amazonでは常にお求めにくい状況が続いており、3月12以降は在庫なし(「出品者からお求めいただけます。」という表記)になっております。実は、3月8日には出版元の在庫がなくなっており、即日増刷が決定されています。 Amazonだけでなく、多くのネット書店にて在庫がない状況ですが、以下のネット書店には在庫があ
去年の5月末に「本を書く」という宣言をしてから8ヶ月以上掛かってしまいましたが、ようやく体系的に学ぶ 安全なWebアプリケーションの作り方が脱稿し、3月1日に発売される運びとなりました。 現時点で一番詳しい本の目次は、出版元のオフィシャルページにありますが、このブログでもおいおい詳しい内容を紹介したいと思います。また別途サポートページを立ち上げる予定です。 本書の目次は以下の通りです。 1章 Webアプリケーションの脆弱性とは 2章 実習環境のセットアップ 3章 Webセキュリティの基礎 〜HTTP、セッション管理、同一生成元ポリシー 4章 Webアプリケーションの機能別に見るセキュリティバグ 5章 代表的なセキュリティ機能 6章 文字コードとセキュリティ 7章 携帯電話向けWebアプリケーションの脆弱性対策 8章 Webサイトの安全性を高めるために 9章 安全なWebアプリケーションのた
本を書いています。昨日ようやく全ての章の初稿を書き上げ、レビューアの皆様に最後の初稿を送付しています。現在は、レビューの結果を反映した第2稿に着手しています。最初の方に書いた章・節は、かなり手直しが必要で、まだ時間が掛かりそうです。 というわけで、当初計画では、今頃は書店に並んでなければならないのですが、今は、今期中になんとか出さないと、というところです。 当初は、こういうことを書いていたわけですが、 入門的な内容になる予定ですので、私のブログの読者が期待するような、マニアックな内容にはならないと思います http://d.hatena.ne.jp/ockeghem/20100528/p1 できあがった初稿を見るに、「入門的な内容」というよりは、むしろ「基礎的な内容」をみっちり書いたという感じかなと、思っております。入門的と基礎的のニュアンスの違いは、まぁ本が出てからのお楽しみということで
2008年2月にパスワードの定期変更は「神話」なのか? - ockeghem(徳丸浩)の日記を書いた時の反応は、賛否両論という感じだったが、その後、twitterでのつぶやきなどを見るに、「パスワードは定期変更しなくてもいいんじゃない?」という意見は、セキュリティの専門家にも多くなっているような印象を受けている。 そのよう状況の中、以下の記事を読んだ。 辞書攻撃がうまくいかない場合、クラッカーは総攻撃(ブルートフォース攻撃とも言います)を仕掛けます。【中略】仮に1秒間に1000万回の計算ができるとすれば、パスワードのクラックに要する時間は1年にもなりません。どんなに強固なパスワードであっても、1年ももたないということになります。だからこそ、3カ月に1回とか半年に1回はパスワードを変更する必要があるのです。(2ページ目より引用) http://www.itmedia.co.jp/enterp
iモードブラウザ2.0では、同一ドメインであっても、iframe内のコンテンツがJavaScriptにより読み出せないよう制限が掛かっていることを確認しましたので報告します。 【追記】元の内容には、重大な事実誤認がありました。正確には、同一ドメイン・同一ディレクトリであれば読み出せます。詳しくは追記2をご覧ください。 きっかけ ケータイtwitter(twtr.jp)においてDNS Rebinding攻撃に対する脆弱性を発見・通報し、即座に修正された - 徳丸浩の日記(2010-02-22)にて既に紹介したように、twitter.comの日本のケータイ向けフロントエンドであるtwtr.jpにDNSリバインディング脆弱性があったことを確認・報告し、直ちに修正されました。このエントリの中に、以下のように書いています。 すぐに確認作業が終わるだろうと思っていたが、意外なところで失敗した。ログイン
Loading...での発表に用いた資料です。 お役に立つかどうかは心許ないのですが、ドキュメントの一部を希望されていた方もおられましたので、slideshareで公開します。 ガラケーで楽しむオレJSの勧めView more presentations from Hiroshi Tokumaru.
NTTドコモとソフトバンクモバイルは、フィーチャーフォン(いわゆるガラケー)にてJavaScriptの対応を始めています。JavaScriptに対応すると、クロスサイト・スクリプティング(XSS)脆弱性の懸念が高まりますが、両社は独自の手法によりXSS対策をしている(しようとしている)挙動が観測されましたので報告します。この内容は、オレ標準JavaScript勉強会でネタとして使ったものです。 NTTドコモに学ぶ「XSS対策」まず、サンプルとして以下のようなXSS脆弱なスクリプトを用意します。 <?php session_start(); ?> <body> こんにちは<?php echo $_GET['p']; ?>さん </body>これを以下のURLで起動すると、IE7では下図のような表示になります。 []http://example.com/xss01.php?p=山田<scrip
ソフトバンククリエイティブさんからお話をいただき、Webアプリケーションセキュリティの本を書くことになりました。6月から書き始めて、年内に出版できればいいなという感じのスケジュール感です。 今度書く本は、入門的な内容になる予定ですので、私のブログの読者が期待するような、マニアックな内容にはならないと思いますが、入門的な本こそ今必要なのではないかなと思っています。言語としてはPHPを基本として、適宜他の言語(Perl、Java等)を補足する予定です。 脱サラしたときの目標の1つが単著を出すことだったのですが、いつもながらそのような機会は向こうからやってきます。私は「はい、やります」と言えばよいだけなので、ありがたいなーと思っています。 今忙しいので書き始めるのは来月からですが、結城さんみたいに、ブログに「本を書いています」と書き始めるのがささやかな夢です:-) あと、レビュアーを募集しようと
セキュリティExpert 2010に大河内智秀氏が「現状の課題と“完璧なWAF”」と題して寄稿されている。大変興味深い内容であるので、この寄稿をなぞりながら、WAFの防御戦略について検討してみたい。 クロスサイト・スクリプティング(XSS)に対する防御 大河内氏の寄稿の前半は、現状のWAFの課題として、Webアプリケーションに対する攻撃の多く(大半)がWAFのデフォルト設定では防御できないと指摘する。例えばクロスサイト・スクリプティング(XSS)に関しては、以下のような指摘がある。 仮にscriptをブラックリストに指定したとしましょう。それでもまだ不十分です。<IMG>タグでXSSが発動することをご存じでしょうか?プログラムなどでは<IMG>タグは画像添付に必須であり、WAFで禁止することは難しいのが実情で、ブラックリスト方式の課題となっています。 「現状の課題と“完璧なWAF”」より引
日経新聞電子版のリンクポリシーが話題になっていたところで、ソーシャルブックマークなどサイト側の対応はどうなのだろうかと気になりました。そこで、はてなブックーのユーザとして、以下のように、はてなに問い合わせしてみました。 日本経済新聞の電子版のリンクポリシーによると、『フロントページや専門サイトのトップページへのリンクは原則として自由』だが、個別記事へのリンクは禁止となっています。しかし、はてなブックマークでは以下から参照できるように、個別記事へのブックマークがなされていて、これは個別記事へのリンクに該当すると考えられます。 http://b.hatena.ne.jp/entrylist?url=http://www.nikkei.com/ これは、以下のどれに該当するのでしょうか。 (1)日本経済新聞社との契約にもとづき、特別に個別記事へのリンクを許可されている (2)Webにおけるリンク
新政党「たちあがれ日本」のホームページが話題になっていたので私も見てみた。そして、メーリングリストの受付フォーム中に記述されたメールアドレスのチェック用のJavaScriptが気になった。以下に引用する。 if (!node.match(/^[A-Za-z0-9]+[\w-]+@[\w\.-]+\.\w{2,}$/)){ alert("e-mailアドレスをご確認ください。"); return false; } https://www.tachiagare.jp/mail.php メールアドレスをチェックするための正規表現は、ネット上でたびたび問題視される定番ネタだか、その論点は、RFC(RFC2822やRFC5322)に対して準拠しているかどうかだと思う。例えばこれ(404 Blog Not Found:「PHP使いはもう正規表現をblogに書くな」と言わせないでくれ)。 しかし、現実に
computerworld.jpは3月17日に『2010年に最も警戒すべきセキュリティ脅威は「DNSリバインディング」』と題した記事を公開したが、一部誤報があるので訂正する。 米国White Hat Securityの研究者らがまとめた2010年版の深刻なセキュリティ脅威トップ10では、DNSリバインディングが1位となった。同社では、2006年から毎年、脅威トップ10を発表している。 http://www.computerworld.jp/news/sec/177029.html 当初、この記事を読んで違和感を覚えた。DNSリバインディングという攻撃手法そのものは以前から知られているものであるし、この記事で説明されている脅威の内容についても、以前から知られているものと違わない。このタイミングでなぜ、DNSリバインディングがもっとも警戒すべきなのか。このため、この記事の裏を取ってみようと思っ
NSFOCUSという中国のセキュリティ会社が日本に進出してインテカーセキュアソリューションズという会社を設立することになり、セミナーで講演することになりました。NSFOCUS社の日本での主力製品は、DoS攻撃防御システム(Anti-DoS)やWAF(Web Application Firewall)ですが、セミナーでは、脆弱性診断とWAFの話がメインになります。時節柄アンチDoS製品に興味を持たれる方も多いと思いますが、WAFにもアンチDoS機能が入っているように伺っています(オプションかもしれません)。 日時 2010年3月15日(月) 14:00〜17:00(13:30受付開始) 場所 新宿パークタワー S側 30階 桔梗(KIKYO)ルーム 基調講演 誤解だらけのWebアプリケーションセキュリティ対策〜発注から事後対策まで〜 講演1 最先端の診断サービスとは?〜セキュリティ先進国、中
間際の案内で恐縮ですが、今週の木曜と金曜に、ほぼ同じテーマで講演します。いずれも無料です。 2009年12月4日(金) 「これからのWebアプリケーションセキュリティ」セミナー 日本アイ・ビー・エム株式会社 本社事業所(箱崎) 2009年12月3日(木)セキュア開発プロセス対策セミナー KCCS東京支社(泉岳寺) 同じ内容で、2010年1月21日、2月18日にも開催されます 箱崎の方は80名、泉岳寺の方は10名ですし、開催時間なども異なります。ご都合の良い方、あるいは会場の大きさに対する好みなどで選択されればよいと思います。 敢えて内容の差を説明するならば、テクマトリックスさんのセミナーでは、発注・契約・要件などの最上流と開発プロセスの話に絞ること、KCCSさんのセミナーでは上記に加えセキュリティ検査の中身の話もします。上流やプロセスの話に興味の中心がある方およびAppScanによる検査に
以下のようになります。CGIでHTTP_で始まる環境変数を列挙したものです。 HTTP_USER_AGENT=DoCoMo/2.0 P07A3(c500;TB;W24H15) HTTP_COOKIE=≪Cookie値≫ HTTP_X_UE_VERSION=1 HTTP_HOST=≪ホスト名≫これは、通常のリクエストと全く同じで、XMLHttpRequestを区別するためのリクエストヘッダはありません。 追記(2009/11/18) PCのブラウザの場合、もう少しヘッダが多くつくことと、際だった違いとして、Refererが付与されることがあります。なぜ付与しないのですかね。ちなみに、SCRIPT要素のSRC属性で呼び出した場合はRefererが付与されます…なんて書いたらSCRIPT要素からのRefererも削除されかねませんな。
i-mode2.0は前途多難 - ockeghem(徳丸浩)の日記にて報告したように、ドコモのiモードブラウザ2.0のJavaScript機能が5/28に停止されていたが、本日ケータイアップデートが準備されたので、深夜3時まで待たずに即座にアップデートを実行した。そして、JavaScriptが復活していることを確認した。 iモードブラウザ2.0のJavaScript « mpw.jp管理人のBlogで報告されているように、alert関数や、setRequestHeaderメソッドが無効化されていることを確認した。関数自体は削除されていないのだが、実行しても何もおこらない状態になっている。alertを無効化した理由は理解に苦しむが、setRequestHeaderを無効化したのは、携帯JavaScriptとXSSの組み合わせによる「かんたんログイン」なりすましの可能性で指摘したような危険性を
SQLインジェクションの進化形として、ブラインドSQLインジェクションという手法があります。通常のSQLインジェクションは、検索結果表示やエラー表示のところに、アプリケーションの想定とは別のテーブル・列の値を表示するものですが、ブラインドSQLインジェクションは、SQLの結果がエラーになる・ならないを1ビットの情報として悪用し、これを積み重ねることで、データベース内の任意情報を得ることができるというものです。 1ビットの情報が得る手段としては、SQLのエラー表示に限らないわけで、現実問題として、SQLのエラーが外部からは判別しにくい場合もあります。そのような場合の究極形として、時間差を利用するという手法があります。 MS SQL Serverには、waitfor delayという命令があって、時・分・秒指定でスリープさせることができます。金床本には、MySQLやPostgreSQLの場合の
だいぶ間があいてしまいましたが、本年1月31日に開催された、第04回まっちゃ445勉強会目覚まし勉強会におけるライトニングトークの資料を公開します。 UnicodeによるXSSとSQLインジェクションの可能性View more presentations from ockeghem.
最近購入したPHP×携帯サイト 実践アプリケーション集を読んでいて妙な感じがしたので、この感覚はなんだろうと思っていたら、その理由に気づいた。本書に出てくるアプリケーションは、PHPのセッション管理機構を使っていないのだ。そんな馬鹿なと思ったが、目次にも索引にも「セッション」や「session」という語は出てこない。サンプルプログラムのCD-ROM上で session を検索しても出てこないので、セッションはどこでも使っていないのだろう。 そうは言っても、本書にはブログやSNSなど認証が必要なアプリケーションも登場する。本書で採用している認証方式はこうだ。 携帯電話の個体識別番号を用いた、いわゆる「かんたんログイン」のみを使う 認証状態をセッション管理機構で維持しない。全てのページで毎回認証する そのため、「iモードID」など、ユーザに確認せずに自動的に送信されるIDを用いる つまり、全て
404方面でも絶賛されていたPHP逆引きレシピを購入した。本書はとても丁寧な仕事で素晴らしいと思ったが、セキュリティに関しては若干残念な思いをしたので、それを書こうと思う。 目次は以下のようになっている。 第1章 準備 第2章 PHPの基本構文 第3章 PHPの基本テクニック 第4章 ファイルとディレクトリ 第5章 PEARとSmarty 第6章 Webプログラミング 第7章 クラスとオブジェクト 第8章 セキュリティ 8.1 セキュリティ対策の基本 8.2 PHPの設定 8.3 セキュリティ対策 第9章 トラブルシューティング 第10章 アプリケーション編 PHP逆引きレシピ オフィシャルサポート 本書は、タイトルの示すように、コレコレしたいという目的ごとにPHPでの書き方が書かれている。よくある逆引き辞典タイプの本だが、類書に比べて丁寧に書かれている印象を受けた。私が感心したのは、PH
次のページ
このページを最初にブックマークしてみませんか?
『ockeghem's blog』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く