もしWebセキュリティのエンジニアがRFC7540の「HTTP/2アプリ」をWeb診断したら[AWS EXpert Online for JAWS-UG 18] 見せてやるよ、Step Functions の本気ってやつをなAmazon Web Services Japan
X-Content-Type-Options: nosniff の効果
Heads up: nosniff header support coming to Chrome and Firefox https://github.com/blog/1482-heads-up-nosniff-header-support-coming-to-chrome-and-firefox ChromeとFirefoxでnosniffってどういうことなんだろうと思って少し調べた。 IE8から、X-Content-Type-Options: nosniff があった場合は、ファイルの中身を自動判別する機能が無効になる。htmlじゃないものが自動判別でhtmlだと誤判別されて表示されることで起こるXSSを防ぐことができる。 Internet Explorer 8 のセキュリティ Part VI: Beta 2 の更新項目 http://msdn.microsoft.com/ja-j
MIME Sniffing Standard
Participate: GitHub whatwg/mimesniff (new issue, open issues) Chat on Matrix Commits: GitHub whatwg/mimesniff/commits Snapshot as of this commit @mimesniff Tests: web-platform-tests mimesniff/ (ongoing work) Translations (non-normative): 日本語 1. Introduction The HTTP Content-Type header field is intended to indicate the MIME type of an HTTP response. However, many HTTP servers supply a Content-Type
情報セキュリティ技術動向調査（2011 年上期）：IPA 独立行政法人 情報処理推進機構
この何年かでWebアプリケーションは、サーバ上のみでプログラムが動作するものから、多くのJavaScriptコードがWebブラウザで動作し、背後でサーバと連携して、リッチかつスムーズな操作感を提供するものへと進化してきた。このことは、Webブラウザ上に悪意のスクリプトを送り込む「スクリプト注入（XSS）」攻撃を、より防止しづらく、悪用の懸念がより大きなものに変化させた。本稿は、WebアプリケーションにAjax等の進化をもたらした技術について振り返るとともに、スクリプト注入対策を考慮すべき新たな文脈について論じるものである。 Ajax（Asynchronous JavaScript and XML）[1]は、必要となるデータを非同期でWebサーバから取り寄せつつ、Webブラウザの画面上でなめらかな操作性を提供する形態のJavaScriptプログラムのことである。かつてのブラウザにおいてはこの
OWASP Secure Headers Project - OWASP
This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests. To view the new OWASP Foundation website, please visit https://owasp.org The OWASP Secure Headers Project describes HTTP response headers that your application can use to increase the security of your application. Once set, these HTTP response headers can restrict modern browsers from running into easily p
補足編：機密情報を含むJSONには X-Content-Type-Options: nosniff をつけるべき - 葉っぱ日記
「機密情報を含むJSONには X-Content-Type-Options: nosniff をつけるべき - 葉っぱ日記」の補足編です。 結局、よくわからないんだけど。 よくわからない場合は、とにかく全てのレスポンスに X-Content-Type-Options: nosniff をつけましょう。 機密情報を含むJSONにX-Content-Type-Options:nosniffをつける理由はわかったけど、「あらゆる」コンテンツにつける理由はなぜ？ 機密情報を含まなくても、<script>のような文字列を含むコンテンツをIEで直接開いた場合にはXSSにつながる可能性もあります。どのようなコンテンツにX-Content-Type-Options:nosniffが必要かを考えるくらいであれば、全てのコンテンツに付与したほうが間違いがなくていいでしょう、ということです。 IEのためだけの問
GitHub - github/secure_headers: Manages application of security headers with many safe defaults
SecureHeaders::Configuration.default do |config| config.cookies = { secure: true, # mark all cookies as "Secure" httponly: true, # mark all cookies as "HttpOnly" samesite: { lax: true # mark all cookies as SameSite=lax } } # Add "; preload" and submit the site to hstspreload.org for best protection. config.hsts = "max-age=#{1.week.to_i}" config.x_frame_options = "DENY" config.x_content_type_option
機密情報を含むJSONには X-Content-Type-Options: nosniff をつけるべき - 葉っぱ日記
WebアプリケーションにおいてJSONを用いてブラウザ - サーバ間でデータのやり取りを行うことはもはや普通のことですが、このときJSON内に第三者に漏れては困る機密情報が含まれる場合は、必ず X-Content-Type-Options: nosniff レスポンスヘッダをつけるようにしましょう(むしろ機密情報かどうかに関わらず、全てのコンテンツにつけるほうがよい。関連:X-Content-Type-Options: nosniff つかわないやつは死ねばいいのに! - 葉っぱ日記)。 例えば、機密情報を含む以下のようなJSON配列を返すリソース(http://example.jp/target.json)があったとします。 [ "secret", "data", "is", "here" ] 攻撃者は罠ページを作成し、以下のようにJSON配列をvbscriptとして読み込みます。もちろ
3 things I set on new servers
There are a number of things you can do to make a server more secure whilst protecting your hosted entities and their users. Here are just three of the many things I do on every new server I commission. I hasten to add that these are not necessarily the most effective or at the top of my list - they are just that: 3 things I set on new servers. Prevent framingOne method of attempting to fool users
ログアウト機能の目的と実現方法
このエントリでは、Webアプリケーションにおけるログアウト機能に関連して、その目的と実現方法について説明します。 議論の前提 このエントリでは、認証方式として、いわゆるフォーム認証を前提としています。フォーム認証は俗な言い方かもしれませんが、HTMLフォームでIDとパスワードの入力フォームを作成し、その入力値をアプリケーション側で検証する認証方式のことです。IDとパスワードの入力は最初の1回ですませたいため、通常はCookieを用いて認証状態を保持します。ログアウト機能とは、保持された認証状態を破棄して、認証していない状態に戻すことです。 Cookieを用いた認証状態保持 前述のように、認証状態の保持にはCookieを用いることが一般的ですが、Cookieに auth=1 とか、userid=tokumaru などのように、ログイン状態を「そのまま」Cookieに保持すると脆弱性になります
Content security policy 1.0 is officially awesome | Blog | Chrome for Developers
It's official! The W3C has advanced the Content Security Policy 1.0 specification from Working Draft to Candidate Recommendation, and issued a call for implementations. Cross-site scripting attacks are one step closer to being (mostly) a thing of the past. Chrome Canary and WebKit nightlies now support the unprefixed Content-Security-Policy header, and will be using the prefixed X-WebKit-CSP heade
HTTP Strict Transport Security - Wikipedia
HTTP Strict Transport Security (HSTS) is a policy mechanism that helps to protect websites against man-in-the-middle attacks such as protocol downgrade attacks[1] and cookie hijacking. It allows web servers to declare that web browsers (or other complying user agents) should automatically interact with it using only HTTPS connections, which provide Transport Layer Security (TLS/SSL), unlike the in
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - helmetjs/helmet: Help secure Express apps with various HTTP headers
Does X-Content-Type-Options really prevent content sniffing attacks?
fiesta.cc - このウェブサイトは販売用です！ - fiesta リソースおよび情報
Three Simple Ways to Improve the Security of Your Web App
HTML5 (WebSockets)の脆弱性?
HTTPデジタル署名プロトコルとAPIの提案