Expired:掲載期限切れです この記事は,産経デジタル との契約の掲載期限(6ヶ月間)を過ぎましたので本サーバから削除しました。 このページは20秒後にITmedia ニュース トップページに自動的に切り替わります。
昨日の日記の続きで、Ajaxに固有なセキュリティ問題について検討します。今回はJSON等の想定外読み出しによる攻撃です。これら攻撃手法は本来ブラウザ側で対応すべきもので、やむを得ずWebアプリケーション側で対応する上で、まだ定番となる対策がないように思えます。このため、複数の候補を示することで議論のきっかけにしたいと思います。 まず、作りながら基礎から学ぶPHPによるWebアプリケーション入門XAMPP/jQuery/HTML5で作るイマドキのWeから、Ajaxを利用したアプリケーションの概念図を引用します(同書P20の図1-23)。 前回、前々回は、(5)のHTTPレスポンスの前後で、JSON等のデータ作成(エンコード)に起因するevalインジェクションや、(5)のレスポンスを受け取った後のHTMLレンダリングの際のXSSについて説明しました。 しかし、問題はこれだけではありません。正常
Is there a way to allow multiple cross-domains using the Access-Control-Allow-Origin header? I'm aware of the *, but it is too open. I really want to allow just a couple domains. As an example, something like this: Access-Control-Allow-Origin: http://domain1.example, http://domain2.example I have tried the above code but it does not seem to work in Firefox. Is it possible to specify multiple domai
2012年10月12日 16時30分追記 読売オンラインに、新事実を入れ込んで、書きました。この記事と合わせてご覧ください 新情報盛り込みました。攻撃完了の報告を、したらば掲示板に自動書き込み!/遠隔操作ウイルスはオリジナル? 作者は腕の立つ人物か/読売オンライン ow.ly/eq2jx — 三上洋さん (@mikamiyoh) 2012年10月12日 http://www.yomiuri.co.jp/net/security/goshinjyutsu/20121012-OYT8T00959.htm 2012年10月11日 0時50分訂正追記 PC遠隔操作ウイルス(トロイの木馬)、なりすましの事件。今朝の記事「PC遠隔操作ウイルス、お茶の水女子大付属幼稚園で三件目の被害。単独犯の可能性も(ライター三上洋事務所)」でレポートしましたが、続報が入って、全体像が見えてきました。わかった情報をまと
Smarty は、PHP 用のテンプレートエンジンです。Smarty には、エラーメッセージを出力する際の処理に起因する、クロスサイトスクリプティングの脆弱性が存在します。
スマートフォン(高機能携帯電話、スマホ)にインストールすると、スマホに登録された電話番号などが外部に送信されるアプリケーション(応用ソフト)が出回り、約76万人分の個人情報が流出していることが6日、情報セキュリティー会社「ネットエージェント」(東京)への取材で分かった。警視庁は情報収集を始めた。 問題のアプリは、「全国電話帳」という名前で9月16日からさまざまなアプリがインストールできるインターネット上のサイトに掲載され、無料でインストールできるようになっている。 このアプリ自体は、ハローページとタウンページに掲載された情報を元に作成されているが、インストールした利用者のスマホに登録された電話番号や住所、メールアドレスなどが抜き取られ、利用者間で閲覧できる仕組みになっている。 アプリの作成元は、サイトで「過去のハローページとタウンページに掲載された約3800万件の情報をもとにデータベースを
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Internet Week 2010 S3 今日こそわかる、安全なWebアプリの作り方2010 http://www.nic.ad.jp/iw2010/program/s3/
Amazonクラウドで国内金融機関の安全基準は満たせる。SCSK、ISID、NRIの3社が調査結果を公開 しかしSCSK、電通国際情報サービス(ISID)、野村総合研究所(NRI)の3社は、金融庁の外郭団体である金融情報システムセンター(FISC)が策定したセキュリティに関する自主基準「金融機関等コンピュータシステムの安全対策基準」について、Amazonクラウドで対応するためのガイドライン「金融機関向け『Amazon Web Services』対応セキュリティリファレンス」(以下、セキュリティリファレンス)を公開しました。 セキュリティリファレンスは、全部で295305項目あるFISCの安全対策基準の項目それぞれについて、クラウド事業者であるAmazonクラウドの対応とSI事業者や利用者での対応を調査してまとめたもの。「ATM(自動現金預け払い機)のような、クラウドとは関係ないものは対象外
最近プライバシー、セキュリティ関連の話では、履歴やトラッキング関連の話題が持ち切りです。しかし僕はもっと危ない事例があると思うのでその話を書きます。 Google+ というアプリケーションがあります。 Google が運営している SNS です。この SNS では Picasa のインフラを使用してアルバムを作成できます。アルバムには公開非公開限定公開などのステータスを設定できます。 それはいい。それは他の SNS にも似たような機能がある。 このアルバムのやばいところは「写ってる人の顔認識をして、写ってる人に対して非公開アルバムを公開する」という機能があることです。 この機能は こういう UI でオン/オフが出来る。 これの何が問題か。例えを挙げて説明しましょう。 H さんという人がいたとする。 H さんでは分かりづらいので平田さんとする。平田さんという人は誰とでもすぐセックスをしていろ
技術者としての良心に従ってこの記事を書きます。俺はセキュリティとプライバシーの人ではなく、JavaScriptとUIの人である。法律の勉強だって自分の生活と業務に関わりのある範囲でしかしないだろう。しかし少なくともJavaScriptやブラウザが絡むような部分については、確実に自分のほうが理解していると思っている。高木浩光さんが、あからさまに間違ったことを書いたり、おかしなことを書いていたりしても、徐々に誰も指摘しなくなってきたと思う。おかしなこと書いていたとしても、非技術者から見たときに「多少過激な物言いだけど、あの人は専門家だから言っていることは正論なのだろう」とか、あるいは技術者から見た時でも、専門分野が違えば間違ったことが書かれていても気付けないということもあるだろう。 もう自分には分からなくなっている。誰にでも検証できるような事実関係の間違い、あるいは、技術的な間違いが含まれてい
これちょっとマズいんじゃないかなあ。 Kampa! の人である佐田さんが見つけて教えてくれたんだけど、 Facebook のメッセージは割と簡単に他人になりすまして送れるみたい。 以下、すべて送信者と受信者の自発的な協力を得て試してみた結果です。 起きること Facebook ではユーザーに @facebook.com のメールアドレスが与えられています。 個人ページが www.facebook.com/namaewo の人なら namaewo@facebook.com という具合に。 そのアドレス宛にメールを送ると、 アドレスの所有者に Facebook 上のメッセージとして届きますね。 この時、そのメールの送信元メールアドレスが 別の Facebook ユーザーによって登録されているアドレスであった場合 Facebook では、そのユーザーから送られたメッセージとして扱われます。 電子
どのページからでも,ログインフォームがオーバーレイで表示されてログイン出来る UI は本当に必要なのかという疑問. 専用ページの場合 そのページ(とフォームの送信先)を SSL にするだけですむ XSS の心配も限られた要素だけですむ そもそも JS 無しに出来てDOMXSS を気にしなくてすむ JS無し,CSS 無しの人でも使える どこでもログインの場合 フォームの送信先はもちろんのこと,ログインフォームを置くすべてのページで SSL 化すると面倒 ページ表示用のあらゆる要素もXSS の心配する必要 JS 使いまくりの場合DOMXSSの心配も必要 JS 無し,CSS 無しの人でも使えるようにするのが面倒 とデメリットのほうが先行してしまって,ログインのためのページ遷移の削減がそれほどメリットにならないなと. ところが,ユーザ側の視点からすると, そもそも別ページだろうとその場でだろうとフ
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
お客様各位 さくらインターネット株式会社 平素よりさくらインターネットに格別のご愛顧を賜り、誠にありがとうございます。 さくらインターネットでは、レンタルサーバサービスやVPSサービスなどのサービスと 併せて、DNSサーバ機能をレンタルするネームサーバサービスを提供しております。 ネームサーバサービスにおいては、当社で取得頂いたドメインのほか、他のレジスト ラで取得されたドメイン名を、当社の管理する広域分散されたネームサーバに登録する ことができます。 その登録において、当社ではドメインの所有者確認を行っておりませんでしたが、 その影響について外部からの指摘や、社内調査によって判明した問題を鑑み順次仕様 変更等を行っております。 その問題点と対処内容、当社方針等についてご報告いたします。なお、本件は当社 のみならず大半の事業者においても同様のケースが報告されております。従いまして、 啓蒙も
@tokuhiromから教えてもらったのですが、COOKPADのスマートフォン向けWebサイトのログインページには、パスワードを「伏せ字にせず入力」するボタンがついているのですね。 さっそく見てみましょう。まずはログイン画面です。パスワード欄の下側に、「伏せ字にせず入力」ボタンが見えます。 「元に戻す」ボタンを押すと、伏せ字に戻ります。 僕はこれを知って興奮しました。なぜなら、拙著「体系的に学ぶ 安全なWebアプリケーションの作り方」には以下のように書いたからです(P337~P338)。 パスワード入力欄のマスク表示は、現在の常識的なガイドラインですが、実は筆者自身は疑問を持っています。パスワード入力欄をマスク表示にすると、記号や大文字・小文字交じりの安全なパスワードを入力しにくくなるので、利用者は簡単な(危険な)パスワードを好むようになり、かえって安全性を阻害するリスクの方が大きいのでは
クラウドに預けていたデータが、「雲」が消えるかのごとく消失してしまった。20日17時頃、レンタルサーバー会社のファーストサーバ(大阪市)で起きた「データ消失」事故。その深刻な状況が日を追うごとに明らかになってきている。被害にあった顧客件数は5698件で、ほとんどが復旧不可能な状態。ウェブサイトやメールに加え、顧客情報やスケジュールなど多種多様なデータが失われ、業務が止まった企業からは悲痛な叫びが聞こえてくる。いったい何が起きているのか。
ZendFramework 流れ 表示時 : token生成→hiddenセット + セッションにセット 送信時 : 送られてきたtokenをセッションにあるものと同じかでチェック token生成方法 ランダム値 + salt + 固定値 + ランダム値 md5( mt_rand(1,1000000) . $this->getSalt() . $this->getName() . mt_rand(1,1000000) ); まとめ ランダム値をセッションにいれて、送られてきたものとチェック。 Symfony 流れ 表示時 : token生成→hiddenセット 送信時 : 送られてきたtokenを、再度生成したtokenと比較して同じかチェック token生成方法 salt + 固定値 + セッションID sha1($this->secret.$intention.$this->getSe
5. RFC RFC 4250 The Secure Shell (SSH) Protocol Assigned Numbers RFC 4251 The Secure Shell (SSH) Protocol Architecture RFC 4252 The Secure Shell (SSH) Authentication Protocol RFC 4253 The Secure Shell (SSH) Transport Layer Protocol RFC 4254 The Secure Shell (SSH) Connection Protocol RFC 4255 Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints RFC 4256 Generic Message Exchange Authent
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く