6月9日（日） に放映された「ほこ×たて」の「たて」の裏側について
2013/06/11 コース：元祖こってり 「元祖こってり」記事はネットエージェント旧ブログ[netagent-blog.jp]に掲載されていた記事であり、現在ネットエージェントに在籍していないライターの記事も含みます。 6月9日（日） に放映された「ほこ×たて」の「たて」の裏側について 2013年6月9日に放映されました、フジテレビ「ほこ×たて」に関しまして、反響が大きいようですので撮影の裏側をご紹介いたします。 まず、番組コーナー内の冒頭にご紹介いただきました弊社製品「防人」については、弊社がどのような会社なのかを簡単に紹介するということでお見せしましたが、防人はメールによる標的型攻撃を防ぐための製品ですので、その後の対決には一切使用していません。 実際の対決に際して防御側に求められたのは、サービスパックや修正プログラムの全く当てられていないパソコン上で、脆弱性が確実に存在しているサー
はまちちゃんと脆弱性報告のあり方 - 世界線航跡蔵
はまちちゃん がいつものごとく、AmebaなうにCSRF脆弱性を発見して いたずらを仕掛けた 。そして、何故か今回だけ「それは迷惑行為だ」とかなんか騒がしい。 私はそもそも、はまちちゃんのいたずらを「隙があったからカンチョー」に喩えるのが程度がおかしいんじゃないかと思う。それで非技術者には話が通じていないのでは? CSRFやSQL Injectionを許していたら、何よりも守るべきユーザーの情報が危険だ。そしてAmebaがそういう脆弱性を持っていると言うことは、生越さんが指摘するように首相官邸からの公式情報を操作できるという意味だ。これは「隙があった」んじゃないだろう。「開腹したまま内臓が露出している」んだ。 ところが、どうも現実の医師とは違ってこの世界の、特にAmebaみたいな大きな会社の開発者はその辺の意識が甘い。「手術したけど、まー、内臓が見えててもすぐに死ぬ訳じゃないし、適当に皮被
携帯電話向けWebアプリのセッション管理はどうなっているか - ockeghem's blog
最近購入したPHP×携帯サイト 実践アプリケーション集を読んでいて妙な感じがしたので、この感覚はなんだろうと思っていたら、その理由に気づいた。本書に出てくるアプリケーションは、PHPのセッション管理機構を使っていないのだ。そんな馬鹿なと思ったが、目次にも索引にも「セッション」や「session」という語は出てこない。サンプルプログラムのCD-ROM上で session を検索しても出てこないので、セッションはどこでも使っていないのだろう。 そうは言っても、本書にはブログやSNSなど認証が必要なアプリケーションも登場する。本書で採用している認証方式はこうだ。 携帯電話の個体識別番号を用いた、いわゆる「かんたんログイン」のみを使う 認証状態をセッション管理機構で維持しない。全てのページで毎回認証する そのため、「iモードID」など、ユーザに確認せずに自動的に送信されるIDを用いる つまり、全て
高木浩光＠自宅の日記 - 児童ポルノ単純所持処罰化とタイムマシン
■ 児童ポルノ単純所持処罰化とタイムマシン 日曜が休日出勤だったので今日は代休をとった。 先週末、はてブ界隈で児童ポルノ法改正の国会審議の話題が上がってきていたので、所謂「まとめサイト」を見たところ、参考人のアグネスチャンがずいぶん酷く言われていた。いったいどんなだったんだと、衆議院TVで録画を観たところ、そんなにひどい話ではなく、やはりネットのこの手の「まとめ」は真に受けてはいけないなと思った。それはともかく、与党案と民主党案の2つの法案が出ていて、法案提出者との質疑がなかなかディベートとして面白いものになっていた。単純所持での冤罪の懸念に関する議論では、コンピュータ技術に関わる部分があり、興味深い。 まず、提出されている法案を確認しておくと、与党提出法案では、(1)目的によらず、「何人も、みだりに、児童ポルノを所持し、又は（略）記録した電磁的記録を保管してはならない」と、罰則なしで禁止
高木浩光＠自宅の日記 - 単純所持刑罰化ならウイルス罪を同時施行しないとセキュリティバランスが悪化する, 追記（15日）
■ 単純所持刑罰化ならウイルス罪を同時施行しないとセキュリティバランスが悪化する 私は、著作権のあり方に関心がないのにWinnyの問題について意見を述べてきた。これは、著作権が情報セキュリティに影響を及ぼしていたからだった。著作権法による規制の強化が、制御不能な流通システムを誕生させ、人々に維持し続けさせ、その結果、漏洩情報の拡散も抑制不能になるという情報セキュリティ上の深刻な問題を引き起した。（関連記事1、関連記事2） このところ、児童ポルノの単純所持の刑罰化や、青少年に対するコンテンツ規制の法制化の機運が高まっているようだ。私は、それらの是非については専門外であり、とくに意見を持ち合わせていない。しかし、それらが情報セキュリティに及ぼす影響について関心を持っている。 児童ポルノ、所持だけで懲役1年以下・与党ＰＴ , 日本経済新聞, 2008年5月2日 児童ポルノ：所持は１年以下の懲役ま
[セキュリティ]XMLをparseするアプリのセキュリティ|2009-06-21 - T.Teradaの日記
「XML」「セキュリティ」という単語でWeb検索すると、多くヒットするのはXMLデジタル署名やXML暗号などを説明したWebページです。 本日の日記では、それとはちょっと違うテーマ（XXEと呼ばれる攻撃）について書きます。 脆弱なコードと攻撃方法 さっそく脆弱性があるサンプルプログラムです。 import java.io.*; import javax.servlet.*; import javax.servlet.http.*; import org.w3c.dom.*; import org.apache.xerces.parsers.*; import org.xml.sax.*; public class Test1 extends HttpServlet { public void service(HttpServletRequest request, HttpServletRe
![[セキュリティ]XMLをparseするアプリのセキュリティ|2009-06-21 - T.Teradaの日記](https://cdn-ak-scissors.b.st-hatena.com/image/square/06a15c64ba0ceec233d86d71001ebb29a9dcbf5d/height=288;version=1;width=512/https%3A%2F%2Fcdn.blog.st-hatena.com%2Fimages%2Ftheme%2Fog-image-1500.png)
OpenID Provider のセキュリティ対策 (2) - return_to と realm のチェックを怠るな！ - 日向夏特殊応援部隊
OpenID Provider のセキュリティ対策 (1) - まずは SSL を導入！話はそれからだ - Yet Another Hackadelicの続編です。 はじめに RP が認証アサーションリクエストである checkid_setup/checkid_immediate を行う際には通常は return_to と realm を指定します。 return_to とは OP から認証アサーションレスポンスを間接通信で受け取る際に戻って来るURLの事。RP が指定しておく。 realm とは return_to のパターンをワイルドカードを使って表現する。 return_to と realm の検証 基本的に return_to の先は http://openid.art-code.org/handler であるという前提で。便宜上番号振りました。 (1) 期待通りの組合せ real
OpenID Provider のセキュリティ対策 (1) - まずは SSL を導入！話はそれからだ - 日向夏特殊応援部隊
やっと下準備終わったので書いてみる。 OpenID でのプトロコルメッセージで、認証アサーション要求*1及び応答*2でのメッセージは通常、RP-OP 間で associate 時に交換した MAC キーを持って署名を行う為、期待する相手と通信している限りは改ざんは起こりにくいと考えられます。 但し最近話題に出て来ている DNS Cache Poisoning のような攻撃を受けた場合、中間者攻撃 (man-in-the-middle attack) が成立する可能性があります。 攻撃手法の例 例えば、RP の DNS が汚染されていた場合を考えます。本来 OP であるはずのホストが悪意のある第三者のサーバーに割り当てられていた場合、その第三者のサーバーが中継を行えば、DH 鍵交換を行ってもまったく無意味で、認証データが盗まれる可能性があります。つまり、 RP から見ると OP に見えて O
Windows必携の無償セキュリティツール10選 - builder by ZDNet Japan
Windowsコンピュータの保護やウイルス除去、管理に用いることができる、Windowsユーザーにとって必携の無償セキュリティツールを10個紹介しよう。 ＃1：Secunia Personal Software Inspector トップを飾るのはSecunia Personal Software Inspectorだ。このツールはおそらく、Windowsマシン上で実行できる無償アプリケーションの中で最も役に立ち、かつ最も重要なものである。 このツールを用いることで、PC上にインストールされているすべてのアプリケーションをスキャンし、セキュリティパッチ／アップデートが必要なアプリケーションを特定することができる。 このツールはまず、あなたのコンピュータに格納されているファイルを検査し（検査するファイルは主に、拡張子が.exeと.dll、.ocxのいずれかのものである）、特定のソフトウェアビ
「ブログの引っ越し」を謳ったフィッシングサイトにご注意ください : ライブドアブログ スタッフブログ
いつもlivedoor Blogをご利用いただきありがとうございます。 ブログの引っ越しのため、などの理由でlivedoor ID/パスワードを入力させる悪質なフィッシングサイトが確認されております。 株式会社ライブドアが運営するサービス以外でlivedoor ID/パスワードを入力するのは大変危険です。登録されている個人情報、クレジットカード番号などが盗用される恐れがあります。livedoor ID/パスワードを第三者に提供してしまったことにより、お客さまに生じたいかなる損害について、当社は一切責任を負いませんので、あらためてlivedoor ID利用規約のご確認をお願いします。 livedoorIDサービス利用規約 第10条 (ユーザIDおよびパスワード) 3.livedoorIDユーザ」はユーザIDとパスワードの使用および管理について責任を負うと共に、使用上の過誤または第三者による不
クロスサイトスクリプティング(XSS)とCSRFの違い早分かり - ockeghem(徳丸浩)の日記
昨日の日記で、DK祭りで使われている脆弱性がXSSかCSRFかという問題になった。どうも、XSSとCSRFがごっちゃになっている人もいるように見受けるので、簡単な整理を試みたい。 XSSとCSRFには似た点がある。 どちらも「クロスサイト」という言葉が先頭につく なりすましのようなことが結果としてできる どちらも受動型攻撃である それに対して、もちろん違う点もある。専門家から見れば「似てるも何も、そもそも全然違うものですよ」となるのだろうが、現に混同している人がいるのだから紛らわしい点もあるのだろう。 私思うに、XSSとCSRFの決定的な違いは、以下の点ではないだろうか。 XSSは攻撃スクリプトがブラウザ上で動くが、CSRFはサーバー上で動く このため、XSSでできる悪いことは、すなわちJavaScriptでできることであって、攻撃対象のCookieを盗み出すことが典型例となる。一方、CS
ホワイトハッカー道場：ITpro
組織化された犯罪者たちは，日々，ソフトウエアやシステムのぜい弱性を探し， あの手この手でユーザーやシステムを狙ってくる。ユーザーは犯罪者の手口を見破 り，対策を打つ自己防衛の力を養わなければならない。コンピュータやネットワー クの奥を知り尽くした正義のハッカー「ホワイトハッカー」が，コンピュータ・セ キュリティの深層を解説する。 【ハッカー】 一般に，コンピュータやネットワークに対して深い技術知識 を持ち，技術的な探究心が旺盛な人を指す。 OSの挙動を調べるために，何時間 もかけてソース・コードを読破してプログラミング技術などを磨く。 ボット，スパイウエア，標的型攻撃－－。攻撃者の目的が自己顕示欲から金銭を得ることに変わる過程で，ユーザーやウイルス対策ソフトから発見されないようにするテクニックがマルウエアに追加されるようになった。それがルートキットだ。目に見えぬルートキットの恐怖を第一線で
高木浩光＠自宅の日記 - 対策にならないフィッシング対策がまたもや無批判に宣伝されている, 追記（26日）
■ 対策にならないフィッシング対策がまたもや無批判に宣伝されている 「PCからオンライン取引、ケータイで認証」−ソフトバンクBBの新発想・認証サービス, Enterprise Watch, 2007年9月20日 「同サービスはまったく新しい認証の手段だ。暗号化技術にも依存しないので、クラッカーとのいたちごっこにもならず、これまでの認証の問題を一挙に解決することが可能。本当の意味でIT革命が起こせると期待できるサービスだ」と意気込みをあらわにしながら説明を行った。（略） 「PCを標的にしたハッキングやDoS攻撃を受ける可能性がゼロになる」（中島氏）。また、偽サイトとはシンクロしないため、フィッシング詐欺を100％防止することも可能だ。 ソフトバンクBB、携帯活用認証システムでWebサイトログイン対応に, ケータイWatch, 2007年9月20日 今回の新機能は、安全・簡便・低コストで、そう
第12回 パスワードの決め方を考える
セキュリティ上重要なので、長く、複雑で、フレーズになっていないパスワードを作ってください。そして定期的に変更してください──。理屈では分かっても、実際に運用するのはたいへんなことだ。実際に使えるパスワードの作り方を考える。 PCでもWebサービスでも、使う際に必ずついて回るのがIDとパスワードだ。「あ、どんなパスワード入れたか忘れちゃった……」「これは！ と思うパスワードを全部入力したけどダメだった」「えーと、どんなパスワードにしよう。前と同じでいいかな？」 ほとんどの人はこんな経験をしたことがあるはずだ。その理由の1つは、守るべき要素と、運用上の使い勝手がほとんどの場合矛盾しているからである。 一般に、パスワードについては下記のようなことが“セキュリティ上重要”だと言われる。 同じパスワードを使わないこと → だからどのパスワードを使ったか分からなくなる パスワードは定期的に変更すること
Part6 危険5:なりすまし---電子署名をメールに追加
クラッカがメールの送信者をなりすますことは簡単にできてしまう。熟練したクラッカは，ニセのヘッダーをそれらしく作って送りつける。こうなると，受信者が見分けるのは，ほとんど不可能になる。重要な内容のメールは，内容を証明する手だてが必要になる。 クラッカがメールの送信者をなりすますことは，意外と簡単にできてしまう（図1）。受信メールには，送信元や返信先，中継してきたサーバー名などの情報がヘッダー部分に残る。しかし，熟練したクラッカは，ニセのヘッダーをそれらしく作って送りつける。こうなると，受信者が見分けるのは，ほとんど不可能になる。
Part5 危険4:盗聴---SSLでデータを暗号化
ホテルや無線LANアクセス・サービス，海外からの接続など，盗聴の可能性がある環境で問題なのは，パスワード漏えいだけでない。メール本文などが盗み見されてしまう可能性もある。他人が興味を持たないような内容のメールであれば，さほど神経質になる必要はない。しかし，仕事に関係する重要なメールなど，他人に見られては困る内容のメールをやりとりするときには，対策が必要になる。 メール・サーバーとの間を盗聴から守るのは意外と簡単だ。Webアクセスなどで広く利用されている暗号化技術であるSSLを使えばよい（図1）。POPによるメール受信をSSLで暗号化するPOP over SSLや，SMTPによるメール送信を暗号するSMTP over SSLというしくみを使うのである。
セキュリティ専門家、「iPhone」実証コード2件を発表--設計に深刻な問題と指摘
Independent Security Evaluators（ISE）の研究者らが、特別に作成されたウェブページを「Apple iPhone」が「Safari」を使って開くときの手法を悪用したエクスプロイトコードを少なくとも2件発表した。脆弱性の正確な詳細については、来週末ネバダ州ラスベガスで開催されるBlack Hatカンファレンスのプレゼンテーションで明らかになる。だが、概要の一部を以下に紹介する。 ISEの研究者Charlie Miller、Jake Honoroff、Joshua Masonの各氏は、Black Hatプレゼンテーションの素案で、「iPhoneには、セキュリティ関連の設計とインプリメンテーションに深刻な問題がある」と指摘し、大半のプロセスが管理者権限で実行される点を指摘した。さらに、iPhoneに搭載されるカスタムOSはアドレスのランダム化も非実行ヒープも採用して
葉っぱ日記 - レジストリの HKCR￥MIME￥Database￥charset 以下に定義されています。
UTF-7を利用したXSSは、charset が指定されていない場合に発生すると考えられていますが、少なくとも Internet Explorer においては、これは大きな間違いです。正しくは、Internet Explorer が認識できる charset が指定されていない場合であり、charsetが付加されていても、IEが認識できない文字エンコーディング名である場合にはXSSが発生します。 例えば、次のような HTML は(HTTPレスポンスヘッダで charset が明示されていない場合)IEが文字エンコーディング名を正しく認識できないため、その内容からUTF-7と解釈されるためにスクリプトが動作します。"utf8"という表記はUTF-8の慣用的な表現ではありますが、ハイフンが抜けており正しい表記ではありません。 <html> <head> <meta http-equiv="Co
たった2行でできるWebサーバ防御の「心理戦」 − ＠IT
高い壁を作るだけがセキュリティ対策ではない。攻撃者の心理を考え、彼らに選ばれないシステム作りも大きな効果が望めるのではないだろうか。本連載では視点を変え、攻撃者に選ばれないためにできる、ほんのちょっとした対策を取り上げる。（編集部） 対策をもう一歩進めるための新たな視点を持とう システムは動くだけではなく、セキュリティ対策がなされていなければいけないといわれ始めて久しい。セキュリティという言葉を聞くと、物理的なものだけではなく、ネットワークセキュリティを連想するほどの認知度も得ているのではないだろうか。 個人宅のネットワーク環境にもファイアウォール機能を搭載したルータがあり、PC1台1台にアンチウイルスソフトがインストールされている。いまとなっては珍しくなく、むしろ当たり前とも思えるようになった。 一方、ネットワークに存在する脅威というと、ウイルス、ワーム、ボット、サイトの改ざん、個人情報
見落としがちなぜい弱性---Webアプリケーション編
■問題■次の二つの画面を見て，このWebアプリケーションにどのような問題があるかをお答えください。 典型的な例であるためご存知の方も多いかもしれない。この例では，表示するエラー・メッセージに問題がある。エラー・メッセージの内容から，ユーザーが存在するか否かを判別できる。このため，認証の安全性が低下してしまう。対策の一つは，「ログインに失敗しました」のみを表示するなど，メッセージに含まれる情報を必要最小限にすることである。 当社はWebアプリケーションのぜい弱性診断サービスを提供しているが，その現場では，こうした問題点によく出くわす。今回は，そのぜい弱性診断の経験から，ユーザーが見落としがちなぜい弱性について取り上げてみたい。 Webアプリケーションに存在するぜい弱性と聞かれたら，ITproセキュリティの読者の多くは，まず，SQLインジェクションやクロスサイト・スクリプティング（XSS）を挙
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
