Chrome 113 で、 DevTools の Network ペインで HTTP ヘッダを好きなように編集して、いろんな状態をお試しできるようになっている。 What's New in DevTools (Chrome 113) - Chrome Developers で紹介されている。 GitHub から example.com を fetch してみる GitHub の CSP ヘッダを上書き example.com の CORS のヘッダを上書き 途中で指定したフォルダの中身は何？ 上書きをやめるには？ 感想 GitHub から example.com を fetch してみる 試しに、 CSP で外部への通信がそれなりに制限されている GitHub から、 example.com への fetch を成功させてみる (外部サイトへの通信は、認証情報や秘密の情報の漏洩などに気をつ
セキュリティ関連のHTTPヘッダを一括指定する Baseline ヘッダ - ASnoKaze blog
現在のWebでは、セキュリティ上レスポンスヘッダで色々なものを指定します。Webデベロッパーは個別に指定しなければなりません。 そこで、セキュリティ関連のヘッダを推奨デフォルト値に設定できるようにする「Baseline ヘッダ (Opt-into Better Defaults)」が、GoogleのMike West氏によって提案されています。 まだたたき台であり、これからW3CのWebAppSec WGで議論されている予定になっています。 Baseline ヘッダ 次のようにレスポンスヘッダを指定します。 Baseline: Security=2022これは、次のヘッダを送信するのと同様です。 Content-Security-Policy: script-src 'self'; object-src 'none'; base-uri 'none'; require-trusted-ty
普段**"HTTPヘッダ"**と呼んでるものについて、仕様上は "header fields" と呼ぶらしかったり、自分でも整理できていなかった。 今後もHTTP関連の仕様を読んでいく上でも理解しておきたかったので、この記事では、下記の用語について整理していく HTTP field header/trailer field field line HTTP セマンティクス まず、参照するドキュメントについて簡単に補足します。今回触れる用語は、HTTPセマンティクスの仕様である「HTTP Semantics(ドラフト版)」で定義されています。 HTTPセマンティクスとは、HTTPメッセージ(HTTPメソッドや、レスポンスコード、フィールド)の意味の定義です。 各HTTP/1.1~HTTP/3の仕様ではこのHTTPメッセージをどのように送るか(例えば、HTTP/2ではストリーム上のフレームで送信
この記事はRuby Advent Calendar 2022の第20日の記事です。前日の記事は@ydahさんによる「RuboCopのバージョンを最新に保つ技術」でした。 2022年11月22日に、Ruby cgi gemのHTTPヘッダインジェクション脆弱性CVE-2021-33621が発表がされました。 CVE-2021-33621: HTTP response splitting in CGI RubyのCGIライブラリにHTTPレスポンス分割脆弱性があり、秘密情報が漏洩する - HackerOne CGI::Cookieクラスにおけるセキュリティ上好ましくない仕様および実装 - HackerOne 私はHackerOneを通じてこの脆弱性を報告しました。この記事では、当該脆弱性の概要と発見の経緯などについて報告します。 概要 脆弱性発見の経緯 影響を受けるアプリケーション 影響 対策
AWS Lambdaで突如としてHTTPヘッダが消失し、それにより悩まされることとなった日の経験を共有します。この問題がどのように生じ解決に至ったのか、また、私たちが学んだ教訓について述べていきます。 対象のLambda関数 今回問題が起きたLambda関数では、ランタイムにNode.jsを利用していました。Lambda関数の中には、外部のAPIサーバに対するリクエスト処理が含まれます。 環境情報は以下の通りです。 ランタイム: Node.js 18 (18.18.2) リクエストライブラリ: ky v1.0.1 エラーの発生 ある時、APIサーバからのレスポンスが"415 Unsupported Media Type"というエラーで返ってくるようになりました。エラーメッセージは以下のようなものです。 問題が起きる前は一度も発生していないエラーでしたが、一度発生した後は、全てのリクエストが
HTTPヘッダーのX-は非推奨と言うけれど・・・
2012年にRFC-6648でHTTPのヘッダーフィルドも含めて、X-はやめようとなりました。 https://tools.ietf.org/html/rfc6648 X-の歴史 HTTPのヘッダーでは非標準ヘッダーにX-をつけるという慣習が長らく利用されていました。最初に導入されたのはRFC-822という電子メールのためのRFCで、この中では拡張フィールドという目的でした。 https://tools.ietf.org/html/rfc822: 1982年のRFCから20年たって、RFC-2822というRFC-822の後継RFCで拡張フィールドはなくなりました。 https://tools.ietf.org/html/rfc2822 X-廃止の範囲 ちなみにこれが対象としているのはHTTPヘッダーだけではありません。テキスト形式で名前をつけて何かを伝達させる「アプリケーションプロトコル」
ウェブアプリケーションのマイナーな脆弱性にHTTPヘッダインジェクションがあります。 Railsやそれ以外のモダンな開発ツールではほとんど問題にならない脆弱性ですが、わずかに脆弱性が発現する余地があります。 この発表では、HTTPヘッダインジェクションの基本的な説明の後、Railsや周辺の対策状況について説明します。 本日お伝えしたいこと ・HTTPヘッダインジェクション入門 ・Ruby on Railsはどうか? ・Pumaの状況 ・Puma以外の状況 あらすじ Ruby on Railsの脆弱性を発見した徳丸は、HackerOneで報告をした。すると、女装した謎の人物が現れ、これはRailsの脆弱性ではないと告げた。それはなぜか、この脆弱性の行方は? この動画は、銀座Rails#34@リンクアンドモチベーション での講演動画を主催者のご好意でいただいたものをそのまま投稿したもので
はじめに これは Qiita Advent Calendar 2021 の D言語カレンダー 11日目 の記事です。 マイクロサービスの監視で出てくる「分散トレーシング」(Distributed tracing)の概念を簡単に解説し、分散トレーシングに対応したアプリ実装に必要なことと実装例をご紹介します。 サービスの実装言語やフレームワークが様々ある昨今ですが、何をすればちゃんとトレースされるのか、単にライブラリやサービスの使い方ではなくその仕組みや目的を理解しておくことも大切だろう、といった主旨の記事になります。 こちら粗方理解できると、主に「ログは記録されるけど対応付けがされないなぁ」といった問題の解決ができるようになるはずです。 気軽に作った自作アプリで何度もやらかしているので皆さんもご注意ください！ なお今回は簡単のためにHTTP通信のみを対象とし、データの保存方法にはほとんど触れ
HTTPヘッダーCache-Control stale-while-revalidateを理解する｜Next.js｜開発ブログ｜株式会社Nextat（ネクスタット）
こんにちは。タカギです。 先日は弊社のアイドルけいちゃんがNext.js12のMiddlewareについての記事を書いてくれました。 その記事からもわかるように、弊社でもフロントエンドにReactやNext.jsを採用することが増えてきています。 Next.jsを採用した場合、同じくVercelで開発されている SWR というReact Hooksライブラリを併せて使用することが多いのではないかと思います。 SWRの公式ドキュメントのトップページには以下の文章があります。 “SWR” という名前は、 HTTP RFC 5861 で提唱された HTTP キャッシュ無効化戦略である stale-while-revalidate に由来しています。 SWR は、まずキャッシュからデータを返し（stale）、次にフェッチリクエストを送り（revalidate）、最後に最新のデータを持ってくるという
パフォーマンスメトリクスをクライアント側に返す HTTP ヘッダー "Server-Timing" - kakakakakku blog
HTTP ヘッダーを使ってアプリケーションのパフォーマンスメトリクスをクライアント側に返す仕様「Server Timing」を調べながら試してみた．詳細な仕様は以下の W3C ドキュメントに載っている．ドキュメントの Introduction に載っているけど，今まではクライアント側で "レスポンスタイム" は確認できても「どの段階でなぜ時間がかかったのか」という詳細までは確認できなかったという背景がある．そして Google Chrome 65 以上など，Server Timing をサポートしてるブラウザなら DevTools で可視化できる❗️ www.w3.org Server Timing 仕様 仕様としては HTTP ヘッダー Server-Timing にパフォーマンスメトリクスを設定してレスポンスを返す．フォーマットは以下の通り（W3C ドキュメントを引用）． Server
キャッシュされたくない場合のHTTPヘッダのベストプラクティス
キャッシュを防ぐHTTPヘッダの鉄板 他人のアカウント情報がキャッシュからレスポンスされてしまう（いわゆる別人問題）といった事故を防ぐために、HTTPヘッダでキャッシュを制御する、というものがセキュリティのお話では頻出します。 そして、その場合の鉄板的なベストプラクティスが、以下のHTTPヘッダを追加することです。 Cache-Control: private, no-store, no-cache, must-revalidate Pragma: no-cache 本記事では、キャッシュを防ぐためにはなぜ上記のHTTPヘッダが必要なのかについて解説します。 各ディレクティブについて 本文に入る前に、Cache-Controlのディレクティブについて簡単な説明を載せておきます。 private ローカルへのキャッシュの格納のみを許可する。また、通常キャッシュできないパターンもキャッシュされ
HTTP ヘッダを使ったキャッシュと Service Worker を使ったキャッシュの関係 - 30歳からのプログラミング
ブラウザは HTTP ヘッダを使ってキャッシュの制御を行うが、それ以外にも Service Worker と CacheStorage を使ったキャッシュも存在する。 Service Worker はリクエストを制御し書き換えることが可能なので、HTTP ヘッダの指定を無視した振る舞いをさせることができる。 例えば HTTP ヘッダを使ってキャッシュしないように設定したとしても、Service Worker でキャッシュしてそれを返してしまえば、サーバへの問い合わせは行われない。 この記事では、実際にコードを書いてどのような挙動になるのかを確認していく。 動作確認に使った環境は以下の通り。 ウェブサーバ Deno v1.10.3 ウェブクライアント Google Chrome 91.0.4472.77 環境構築 まずは検証用の環境を用意する。 index.html。 <!DOCTYPE h
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Chrome113でHTTPヘッダを上書きしていろんな状態をお試しできる - hogashi.*
"HTTPヘッダ"が指すものとは - Qiita
Ruby cgi gemのHTTPヘッダインジェクション脆弱性CVE-2021-33621の概要と発見の経緯
ポストモーテム: AWS Lambda内のリクエストからHTTPヘッダが消えた日
Rails周辺におけるHTTPヘッダインジェクション脆弱性の動向 - YouTube
分散トレーシングの仕組み 「ログの対応付け」と「受け渡すHTTPヘッダー」を大体5分で理解する