HTML5 を利用したWeb アプリケーションのセキュリティ問題に関する調査報告書
HTML5 は、WHATWG および W3C が HTML4 に代わる次世代の HTML として策定を進めている仕様であり、HTML5 およびその周辺技術の利用により、Web サイト閲覧者 (以下、ユーザ) のブラウザ内でのデータ格納、クライアントとサーバ間での双方向通信、位置情報の取得など、従来の HTML4 よりも柔軟かつ利便性の高い Web サイトの構築が可能となっています。利便性が向上する一方で、それらの新技術が攻撃者に悪用された際にユーザが受ける影響に関して、十分に検証や周知がされているとは言えず、セキュリティ対策がされないまま普及が進むことが危惧されています。 JPCERT/CCでは、HTML5 を利用した安全な Web アプリケーション開発のための技術書やガイドラインのベースとなる体系的な資料の提供を目的として、懸念されるセキュリティ問題を抽出した上で検討を加え、それらの問題
銀行から個人まで駆け込む ネット風評“掃除業”が急拡大
inside 産業界・企業を取り巻くニュースの深層を掘り下げて独自取材。『週刊ダイヤモンド』の機動力を活かした的確でホットな情報が満載。 バックナンバー一覧 今月、新たな業界団体が正式に発足する運びだ。その名称は「風評被害対策事業者連絡会」。 インターネット上の風評被害や誹謗中傷対策を引き受ける大手“イレイサー”（消しゴム≒削除者の意）専門会社で構成する初の業界団体だ。 今夏から国の関係省庁との協議や情報交換を重ねており、急拡大を続ける一方で悪質業者もはびこる業界の健全化を図ることが、設立目的という。 団体設立の音頭を取った業界大手、シエンプレは、過去3年で売り上げを2倍以上に伸ばし、今期は15億円の売り上げを見込む。
子供を取り巻くインターネットとその問題点
兵庫県の小学校で2013/02/20発表するための資料。 話す際のノートを含め公開しているので、再利用される場合は参考にどうぞ。 セッションを受けた人の感想とか↓に書いてます http://d.hatena.ne.jp/hanazukin/20130312/1363069453
サービス終了のお知らせ - NAVER まとめ
サービス終了のお知らせ NAVERまとめは2020年9月30日をもちましてサービス終了いたしました。 約11年間、NAVERまとめをご利用・ご愛顧いただき誠にありがとうございました。
｜探偵事務所・興信所－東京探偵調査士会
Strict Standards: Non-static method DB::connect() should not be called statically, assuming $this from incompatible context in /home/www/tantei-tjc.jp/memo.north-tjc.jp/htdocs/app_files/user/util/ArticleAccessor.php on line 8 Strict Standards: Non-static method DB::parseDSN() should not be called statically, assuming $this from incompatible context in /home/www/tantei-tjc.jp/memo.north-tjc.jp/htdo
暗証番号はなぜ4桁なのか? セキュリティを本質から理解するための考え方 | ブクペ
概要セキュリティに関する身近な疑問を専門用語をなるべく使わずに教えてくれる1冊 ATMの大きな役割「識別と認証」◆ATMでお金をおろすときの銀行側の2つステップ ①識別：ATMにやってきた人が銀行に口座を持っている ・持っていないのにおろせたら、銀行は成り立たない ②認証：口座を持っている人と、引き出す人が同じか確認する ・誰でもおろせてしまったら、盗難と同じ ◆なければ利用者の手間もなくなるのに暗証番号はなぜ必要？ ・「お金をおろしたい」という人が本人であるかどうか銀行側はチェックをしたい ・認証（本人であるということを確認するステップ）が必要である ・この認証の役割を果たすのが、暗証番号 ◆認証ではなぜ暗証番号を入力するのか？ ・認証するだけなら、カードキーを使う(車だって盗難防止は鍵)でも問題はない ・カードキーを使った場合、識別と認証を1つで同時に行なえる ・つまりカードキーを盗ま
単なる OAuth 2.0 を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる
In some of the feedback I have gotten on the openID Connect spec, the statement is made that Connect is too complicated. That OAuth 2.0 is all you need to do authentication. Many point to Identity Pro… 英語読みたくないという人のために簡単に解説すると… OAuth 2.0 の implicit flow を使って「認証」をしようとすると、とっても大きな穴が開きます。 カット＆ペーストアタックが可能だからです。 OAuth 認証？は、図１のような流れになります。 図１ OAuth 認証？の流れ 一見、問題なさそうに見えます。しかし、それはすべてのサイトが「良いサイト」ならばです。 Site_A
OAuth.jp
いままで Mix-up Attack は Client が AS 毎に redirect_uri を使い分けていれば防げると信じられてきましたが、それじゃ防げないケースもあるよってのが OAuth ML に投稿されました。 細かい解説は英語読んでもらうとして、シーケンスにするとこういうことです。 Attacker AS が (Display Name やロゴ等を通じて) 一見 Honest Client に見えるような Client (Attacker Client) を Honest AS に登録しておく必要があります。 User が Attacker AS 選んでるのに Honest AS に飛んで Approve してしまってる部分も、Attacker Proxy が利用可能な状況 (e.g., Client が HTTP なエンドポイントで Honest AS のログインボタン等を
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
地獄のJavaScriptセキュリティ