You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
Broadcom Software Academy We are pleased to announce the launch of the redesigned and upgraded Broadcom Software Academy. Enterprise Software Industry analysts agree: a scalable, open and flexible digital business technology platform is mandatory for digital business success. Explore our capabilities NetOps Virtual Summit Discover how leading organizations are using DX NetOps and AppNeta to assure
CSRF 脆弱性対策には攻撃者の知り得ない秘密情報をリクエストに対して要求すればよく、そのような用途としてはセッション ID がお手軽でいいよねという時代があったかと思います。 いや、もちろん、 CSRF 対策の文脈だけで言えば今も昔も間違いというわけではありません。セッション ID が秘密情報であるのは Web アプリケーションにおいて当然の前提ですので、 CSRF 対策としてリクエストに求めるべきパラメータとしての条件はたしかに満たしています。 たとえば 『安全なウェブサイトの作り方』 改訂第6版では以下のように解説されています。 6-(i)-a. (中略) その「hidden パラメータ」に秘密情報が挿入されるよう、前のページを自動生成して、実行ページではその値が正しい場合のみ処理を実行する。 (中略) この秘密情報は、セッション管理に使用しているセッション ID を用いる方法の他、
まずは、Web Storageの簡単な説明から。 HTML5 Web Storageは、簡単なキー/バリューのデータ構造を持つ永続ストレージです。 現在、LocalStorageとSessionStorageの二種類が仕様に盛り込まれています。 LocalStorageは、サイト(オリジン)ごとに一意の永続領域で、同じサイト内の全てのWebページ/ウィンドウ間で共有され、永続化される期間は無制限です。 SessionStorageは、ブラウザウィンドウごとの永続領域で、ウィンドウを閉じると消えてしまいます。 で、SessionStorageが「ブラウザウィンドウごと」と言うのは具体的にどういう事なのか、仕様書と実際のブラウザによる実装をいろいろ試して調べてみました。 試すのに使用したのは以下のWebアプリ(僕が自分で試すために作っただけなので、超使いづらいですが)です。 http://ge
Webアプリケーションの開発・展開を行っている人々にとって、セキュリティ確保は大きな関心事の1つだといえます。そのためのベストプラクティスやフレームワーク、ガイドラインを提供しているのがOWASP(Open Web Application Security Project)です。OWASPのWikiサイト(OWASP.org)には、Webアプリケーションのセキュリティ確保のための様々な情報がありますが、それらの中でも即効性の高いのが「便利なHTTPヘッダのリスト(List of useful HTTP headers)」だといえるでしょう。 このページには、アプリケーションのHTTPレスポンスに追加することで、事実上無料でセキュリティを強化できるHTTPヘッダが7種類掲載されています。 これらの中でまず活用したいのが、以下の2つのHTTPヘッダです。 X-XSS-Protection 最近
Web技術者コミュニティ「html5j」が主催する最新技術トレンドや業界動向を学ぶ勉強会「HTML5とか勉強会」が六本木ヒルズのGoogleで開催された。第44回となる今回のテーマは「HTML5とセキュリティ」。 セキュリティのエキスパートたちが語る、HTML5および関連する周辺技術のセキュリティ対策に役立つ情報とヒントをレポートする。 by 馬場美由紀 (CodeIQ中の人) 今から始めるHTML5セキュリティ トップバッターで登壇したのは、一般社団法人JPCERTコーディネーションセンターの松本悦宜氏。JPCERT/CCが2013年10月に公開した「HTML5を利用したWebアプリケーションのセキュリティ問題に関する調査報告書」をもとに、Webアプリケーション開発者が 知っておきたいHTML5および関連する周辺技術のセキュリティ対策について解説した。 便利さの一方で、脆弱性も広がるHT
プロモーション・デザイン局 梅田悟司氏による朝日新聞WEBRONZAでの連載『「と思います」禁止令』を、ウェブ電通報特別バージョンでお送りします。 断定できる人は、強い 「人の心に響く言葉とは何ですか?」 そんな質問に対して、私は答えの一つとして「明確に未来を打ち出す言葉」と答えることがあります。学校の教科書では断定として登場する表現方法です。 断定は言い切ればいいので簡単なように思えます。しかし、実生活において言い切ることは非常に勇気がいることです。 通常の会話で考えれば、文末に何となく「と思います」や「のような気がします」といった言葉を入れることで、あえて断定を避け、内容をうやむやにしたり、言葉を濁すことがあります。人は無意識のうちに断定を避け、そうではない可能性を残しておくような言い方をしているのです。 これは一種のリスク分散と言えます。 「いやいや、断言はしていません」「その可能性
本稿はCodeZineに2015年12月28日に掲載された記事の再掲となります。 クロスサイトスクリプティング(XSS)は、古くから存在し開発者にもっともよく知られたセキュリティ上の問題のひとつでありながら、OWASP Top 10でも2010年に引き続き2013年でも3位と、未だに根絶できていない脆弱性です。 本記事では、Webアプリケーションの開発においてXSSを根絶するために必要な対策の基本を本気でお伝えします。 はじめに OWASPでは開発者に向けたセキュリティ対策のためのドキュメントやチートシートを多数用意しており、XSSへの対策としても「XSS (Cross Site Scripting) Prevention Cheat Sheet」というドキュメントが用意されています。 ただし、このXSS Prevention Cheat Sheetはシンプルなルールを定めたチートシートで
この文書は2016年以降更新されていません クロスサイトリクエストフォージェリ (CSRF) の防止策に関するチートシート クロスサイトリクエストフォージェリ (CSRF) は攻撃の一種であり、悪意のある Web サイト、電子メール、ブログ、インスタントメッセージ、またはプログラムを使用して、ユーザーが現在認証されている信頼されたサイト上で、ユーザーの Web ブラウザーに意図しないアクションを実行させます。クロスサイトリクエストフォージェリ攻撃が成功した場合、影響を受けるのは脆弱性のあるアプリケーションによって露出される機能に限られています。たとえば、この攻撃により、送金処理、パスワード変更、ユーザーコンテキストを使用した物品の購入などが行われることがあります。実際、攻撃者は CSRF 攻撃を使用して、ターゲットのシステムにターゲットのブラウザー経由で機能 (送金処理、フォーム送信など)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く