Web Platform Security PhD Summit @ Google MunichWeb Platform Security. The threats browser vendors are exploring at the moment, and some mitigations thereof.
静的ファイルのキャッシュコントロールについて ISUCON7 – そろそろちゃんとやります
@egapoolです。今回初めてISUCON7に参加させていただきました。（チーム名：元pyns） 当日やったこととこかはこちらにまとめています。 ISUCON7に参加して予選突破しませんでした。 – そろそろちゃんとやります 今回のお題の一つ目の壁は、いかに画像ファイル（アバターアイコン）をキャッシュさせてサーバーからデータを返さないようにするかでした。 8時間の大部分をこの対応に費やしましたが解決は出来ませんでした。 原因はきっちり304を返すための基礎知識が足りていなかったことです。 ですのでこれを機に勉強しなおしてみました。 304 (Not Modified) 大前提ですが、304ステータスコードは キャッシュの有効無効の確認付きリクエストに対して、有効である場合に返すステータスコード です。 この場合サーバーはリソースデータ(ペイロード)を送信しません。 すなわち，サーバは、［
補完、ハイライトが効くHTTP Prompt対話型クライアントを使ってみる - もた日記
http-prompt インストール 使い方 操作例1 操作例2 その他の操作例 http-prompt github.com HTTP Prompt - An interactive command-line HTTP client（公式ページ） HTTP Promptは自動補完、シンタックスハイライトが効くインタラクティブなコマンドラインHTTPクライアント。 説明に書いてあるようにHTTPie （HTTPクライアント）+ prompt_toolkit（インタラクティブコマンドラインライブラリ）のようなツール。 prompt_toolkitを使ったツールには下記ツールもある。 wonderwall.hatenablog.com wonderwall.hatenablog.com インストール pipでインストールできるので下記コードを実行。 $ pip install http-pro
Cookie関連の最新動向 (2016年) - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 去年ぐらいからCookieに関する議論が活発に行なわれているように感じます。そこでCookie関連の最新動向について仕様の観点から幾つか列挙します。 Deprecate modification of 'secure' cookies from non-secure origins Cookie Prefixes Same-site Cookies A Retention Priority Attribute for HTTP Cookies Content Security Policy: Cookie Controls G
HTTPステータスコードを適切に選ぶためのフローチャート : 難しく考えるのをやめよう | POSTD
HTTPステータスコードを返すというのはとても単純なことです。ページがレンダリングできた？よし、それなら 200 を返しましょう。ページが存在しない？それなら 404 です。他のページにユーザをリダイレクトしたい？ 302 、あるいは 301 かもしれません。 I like to imagine that HTTP status codes are like CB 10 codes. "Breaker breaker, this is White Chocolate Thunder. We've got a 200 OK here." — Aaron Patterson (@tenderlove) 2015, 10月 7 訳：HTTPのステータスコードのことは、市民ラジオの10コードみたいなものだと考えるのが好きです。「ブレーカー、ブレーカー、こちらホワイト・チョコレート・サンダー。200
CORSまとめ - Qiita
今更ですが、**CORS (Cross-Origin Resource Sharing)**を色々試していたら、思っていた以上に色々パターンがあることに気づいたので、改めてその扱い方についてまとめてみました。 そもそも 現在のWebブラウザでは、あるWebサイトが持つ情報が別の悪意あるWebサイトに悪用されるのを防ぐために、Same-Origin Policy(日本語では同一生成元ポリシー)が適用されます。 例えば、あるWebサイト https://guiltysite.com をブラウザで表示している時に、このWebページからXMLHttpRequest(以下、XHR)やFetch APIで別のWebサイト https://innocentsite.net からHTTP(S)でデータを読み込もうとすると、エラーになる、というわけです。 しかし、アクセス元が悪意あるWebサイトならともかく
非セキュアなオリジンから'secure'クッキーの変更を廃止する提案 - ASnoKaze blog
先日、HTTPSでsecure属性を付加した場合でも改変できると話が話題になりました。 クッキーの脆弱性が判明： HTTPS のセキュリティを突破する、攻撃が成り立ってしまう！ HTTPSを使ってもCookieの改変は防げないことを実験で試してみた(2013/9/30) Cookies Lack Integrity: Real-World Implications(PDF) そういったリスクを軽減するために、HTTPのオリジンからはsecure属性の付いたクッキーをセット, 上書きを廃止する仕様が提出されている。Googleの人がAuthorな点も興味深い。 提案 提案されている仕様は以下である。 「Deprecate modification of 'secure' cookies from non-secure origins」 とても短い仕様であり、既存の仕組みを先に述べたように変更
Cookieの属性を制限する Cookie Prefixesという仕様 - ASnoKaze blog
"$Origin-"プレフィックスは削除され、"$Host-"プレフィックスが追加されました。 (2015/10/13追記)(2015/10/17 記事更新) 背景の、domain属性の指定に誤りがあったため修正しました。「domain=my-example.com」-> 「domain=example.com」(2015/10/14追記) draft 05よりプレフィックスが$から__に変更されました(2015/12/1追記) Googleの方によって「Cookie Prefixes」という仕様が提案されています（draft-west-cookie-prefixes-01） 以下のCookieに関する仕様を提案しているMike West氏による提案である Origin Cookies Deprecate modification of ’secure’ cookies from non-
RFC的に、HTTPヘッダってどんな値を使えるんでしたっけ？のメモ - 小野マトペの納豆ペペロンチーノ日記
Web APIを開発していると、HTTPのヘッダについてRFCにおける規約を確認しなきゃいけない場面がたまにあるので、今回調べたことをまとめた。 HTTP/1.1のRFC HTTP/1.1のRFCといえば、長らくRFC2616であったが、2014年にRFC7230〜7239が発行され、2616は廃止された。 RFC2616 ハイパーテキスト転送プロトコル -- HTTP/1.1 RFC7230〜RFC2739 HTTP/1.1 — RFC 7230 〜 7235 — 日本語訳 両者の変更点については、RFC 723xの付録に記述されているので参照のこと。Content-MD5が廃止されたり、ちょいちょい面白い。文章としても723xの方が分かりやすくなっているので、一度目を通しておくことをお勧めする。 HTTP/1.1 が更新された | The Long Wait あたらしいHTTPの話をし
WebAPIリクエスト仕様書としてcurlコマンドのご提案 - Qiita
WebAPIの仕様を記述する方法はいくつかあると思う。 普通に日本語で記述する JSON Hyper-Schema、WADL、RAML、Swaggerなどを使う 仕様書の代わりにプログラムを書く HTTPメッセージそのものを記述しておく でも、文法にばらつきがあったり、読みにくかったり、ツールのセットアップが面倒だったり、どれもイマイチな所があって、手軽な方法が欲しいと思っていた。 何気なくcurlコマンドのオプションを調べていたら、「もうこれでAPIドキュメント扱いにしちゃえばいいんじゃね？」と思えてきたのでメモしておく。 curlコマンドのおさらい curlコマンドはlibcurlの付属コマンドで、最近のUnix系OSなら大抵最初から入っていると思う。コマンドの詳細はmanを読んでいただければ。 cURL - How To Use （マニュアルページ日本語訳） curlコマンドのオプシ
RFC7540 (HTTP/2) 日本語訳
May 17, 2015 先日の5月15日に、ようやく HTTP/2 の最終的な仕様が RFC7540 として発行されました。仕様がほぼ固まったところからなんだかんだで半年近くかかりましたが、やっと一安心というところです。いつものように今回も日本語訳を用意しましたので、RFC7540 日本語訳として公開します。「RFC になったし、HTTP/2 勉強するか」と思っている方のお役に立てれば幸いです。 仕様としては Draft 14 以降バイナリレベルの変更は入っていません。最後のドラフトとなった Draft 17 からも大きく変更はなく、h2c トークンの明記と編集上の細かい変更にとどまっていますので、今ある実装に手を加える必要もなさそうです。 さて、英語の勉強がてら始めた HTTP/2 の仕様の翻訳ですが、Draft 04 の時にスタートして気がつけば2年弱ほど続けてきたことになります。D
HTTP2 時代のサーバサイドアーキテクチャ考察 - Block Rockin’ Codes
update 色々と twitter で議論が起こったのでまとめて貼っておきます。 togetter.com みなさんありがとうございました。 intro HTTP2 の RFC 化も目前ということで、そろそろ実際に HTTP2 を導入していくにあたってサーバサイドの構成についても、具体的にどう変わっていくかという点を考え始めていく必要があります。 そんな話を @koichik さんとしていたら、色々と考えが膨らんだのでメモしておきます。 前提 今回は、中規模のサービスを想定し、特に HTTP2 のサーバプッシュを踏まえた上でのコンテンツ配信などに、どういう構成が考えられるかを考えていきます。 また、本エントリ内では独自に以下の表記を採用します。 HTTP/1.1 = HTTP/1.1 (平文) HTTP/2 = HTTP/2 (平文) HTTPS/1.1 = HTTP/1.1 over
Upgrade Insecure Resource Requests (A Collection of Interesting Ideas)
This document defines a mechanism which allows authors to instruct a user agent to upgrade a priori insecure resource requests to secure transport before fetching them. This is a public copy of the editors’ draft. It is provided for discussion only and may change at any moment. Its publication here does not imply endorsement of its contents by W3C. Don’t cite this document other than as work in pr
Network Error Loggingでブラウザのネットワークエラーを検知する - ASnoKaze blog
20180528 追記 Chrome devに来たので試した asnokaze.hatenablog.com 20180301 追記 結構代わりました NELヘッダは、json形式で表現するようになりました。また、report APIに準拠する形になりました NEL: {"report-to": "network-errors", "max-age": 2592000} report-to: { "url": "https://asnokaze.com/report", "group": "network-errors", "max-age": 10886400 }Webアプリケーションの特性を測定することは非常に大切だが、DNSによる名前解決・接続のタイムアウト・接続のリセットといったユーザ側による読み込み失敗などを知るすべはありません。 Network Error Loggingでは、
CookieのFirst-Party-Only属性 - ASnoKaze blog
draft 05より、「Same-site Cookies」という仕様に改称され、SameSite属性として属性が定義されました。 http://tools.ietf.org/html/draft-west-first-party-cookies-05 (2016/01/28) Googleの方による、CookieにFirst-Party-Only 属性を追加するという仕様が提案されていたので、簡単に目を通す。 大分理解が足りず間違い等あるかもしれません。 First-Party-Only Cookies(draft-west-first-party-cookies) First-Party-Only 属性 First-Party-Only 属性は他の属性と同様にset-cookieヘッダで指定される。 Set-Cookie: SID=31d4d96e407aad42; First-Par
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Request-URIのパスからのCRLFインジェクション
今さら聞けないSPAのCORS対策の話
[PDF] Crippling HTTPS with unholy PAC
[PDF] Two cross-protocol MitM attacks on browsers)
Event 1063 - MIME Restrictions - Authoritative Content Type Handling