Intro CSRF という古の攻撃がある。この攻撃を「古(いにしえ)」のものにすることができたプラットフォームの進化の背景を、「Cookie が SameSite Lax by Default になったからだ」という解説を見ることがある。 確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の本質から言うと、解釈が少しずれていると言えるだろう。 今回は、「CSRF がどうして成立していたのか」を振り返ることで、本当にプラットフォームに足りていなかったものと、それを補っていった経緯、本当にすべき対策は何であるかを解説していく。 結果として見えてくるのは、今サービスを実装する上での「ベース」(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件 例えば、攻撃者が用意した attack.examp
2024年4月25日紙版発売 2024年4月25日電子版発売 市原創，板倉広明 著 A5判／456ページ 定価3,740円（本体3,400円＋税10%） ISBN 978-4-297-14178-3 Gihyo Direct Amazon 楽天ブックス ヨドバシ.com 電子版 Gihyo Digital Publishing Amazon Kindle 楽天kobo honto この本の概要 SSL/TLSは，通信の秘密を守るために利用されている通信プロトコルです。HTTPSやHTTP/3にも利用されており，今日のWebでは利用が一般的になっています。本書では，その最新バージョンであるTLS 1.3のしくみと，その使い方を解説します。SSL/TLSは公開されている実装例などを真似すれば基本的な動作はさせられますが，それを応用していくには技術に関する理論の理解が必須になります。しかしSSL
はじめに みなさん様々な言語でAPIサーバーを立てて負荷試験を実施したことはありますか。 私自身、業務でPythonのアプリケーションに対して負荷試験を実施した経験があります。 その際にPythonの速度観点の不安定さを目の当たりにしたと同時に、別の言語ではどのような違いが生まれるのだろうか、という疑問を持ちました。 そこで今回は、簡単ではありますがGoとRustとPythonでそれぞれAPIサーバーを立てて負荷試験をしてみます。 負荷試験対象のAPIサーバー 今回は(1) Hello, World!を返すAPI(2) ファイル読み込みAPI(3)1秒待ってから応答するAPIの3つを実装します。 (1)はAPIサーバー自体の応答速度の計測、(2)はメモリを消費する処理が生じた場合のAPIの応答速度の計測、(3)は待ち時間発生している時のAPIの応答速度の計測することが目的です。 (2)につ
これまで何度か HTTP Server の Graceful Shutdown について記事を書きました。 Go 言語で Graceful Restart をする Go 言語で Graceful Restart をするときに取りこぼしを少なくする Go1.8 の Graceful Shutdown と go-gracedown の対応 最終的に Go 1.8 で Server.Shutdown が導入され、この件は解決を見ました。 しかし、最近「あれ？本当に正しく Server.Shutdown 使えている？」と疑問に思い、少し考えてみました。 というか ↑ の記事もまだ考慮が足りない気がする。 ぼくのかんがえたさいきょうの Go HTTP サーバー起動方法 とりあえず完成形のコード。 package main import ( "context" "log" "net/http" "os
2.3k{icon} {views} 複数のLLM（GPT/Claude3）とArxivの検索APIをRAGで統合し、論文サーベイの自動生成を作りました。検索結果の前処理や、サーベイ特有のプロンプトエンジニアリングやソートが重要で、最適化手法として古くからある巡回セールスマン問題（TSP）が有効に機能しました。また、生成部分ではGPTよりClaude3の明確な有効性を確認できました。 できたもの Arxivの検索APIを使って検索拡張生成（RAG）したらサーベイを自動生成できた やっていること Arxivの検索ワードをGPT-4-Turboで生成 ArxivのAPIを叩いてヒューリスティックでフィルタリング OpenAIのEmbedding APIを叩く Embeddingに対して巡回セールスマン問題（TSP）を解いてソートをかける 論文の要旨をGPT-3.5-Turboで要約 ソートした
Intro IETF の httpbis で、 Reverse HTTP Transport という仕様が提案されている。 Reverse HTTP Transport https://www.ietf.org/archive/id/draft-bt-httpbis-reverse-http-01.html この仕様は、 Origin サーバの前に何かしら Intermediaries (Loadbalancer, Reverse Proxy, CDN etc)があるのが一般的な現代の Web サービス構成において、非常に革新的なアイデアを取り入れたプロトコルと言える。 まだ v01 という初期段階ではあるが、発想が非常に面白かったので、読書メモを残す。 登場人物 ベースとして HTTP の話にはなるが、登場人物が多いため Client/Server という「相対的な役割」で話をすると、紛
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
Webシステムにおける HTTPサーバ機能をどう用意するか？という問題に対して先人達の葛藤の歴史 | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]
こんにちは羽山です。 現代の Webシステム界隈は昔よりもはるかに洗練され、初心者からでも簡単に開発方法を学び作れる時代になっています。その反面で例えば Python なら WSGI や gunicorn、Waitress、uWSGI などが何のために存在しているのかが分かりにくいと思ったことはありませんか？Ruby の Rack、unicorn、puma だったり FastCGI など、いずれも Webシステムの構成要素として重要な一方で役割を理解しにくいのは事実です。 そこで今回は Webシステムが現代の形にたどり着くまでの先人達の葛藤の歴史を解説します。歴史を知ればこれらの仕様やプロダクトが何の役になっているかが分かるはずです。 前提 動的な Webサイト（＝Webシステム）を作りたいニーズはインターネット黎明期からありますが、ブラウザからのアクセスを適切に処理するには HTTPサー
![Webシステムにおける HTTPサーバ機能をどう用意するか？という問題に対して先人達の葛藤の歴史 | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/1de4f7647fc73bd264d932c4bca4a75a967a6b04/height=288;version=1;width=512/https%3A%2F%2Ftechblog.raccoon.ne.jp%2Fwp-content%2Fuploads%2F2024%2F05%2Fcloud-3406627_1280.jpg)
Real World HTTP 第3版 ミニ版
TOPICS 発行年月日 2024年05月 PRINT LENGTH 207 ISBN 978-4-8144-0083-6 FORMAT PDF EPUB 本書は、2017年に発行し、2024年に第3版を発行した『Real World HTTP 第3版』のエッセンスを凝縮した、無料の電子書籍です。 HTTP/1.0、HTTP/1.1、HTTP/2と、HTTPが進化する道筋をたどりながら、ブラウザが内部で行っていること、サーバーとのやりとりの内容などについて、プロトコルの実例や実際の使用例などを交えながら紹介しています。 ミニ版のため、一部の内容を割愛しています。詳しくは本書の「まえがき」をご覧ください。 ミニ版の使用について ミニ版の図版やテキストは、著作権法で認められている引用の範囲に加えて、有志での勉強会、自社の社員向けの研修に用いるプレゼンテーション資料のために、全体の10～20%程
恋愛で理解するHTTP通信 - Qiita
はじめに HTTP(ハイパーテキストトランスファープロトコル)について恋愛の告白で例えてみます。告白したことがある人もない人も青春に浸りながらHTTPを理解しましょう。 ※本記事はHTTP通信の流れがイメージできることを目的としています。詳細なニュアンスや意味が本来と異なる場合があります。 登場人物 告白する人 - クライアント 告白される人 - サーバー 太郎くんと花子さんです HTTP通信とは HTTPとは告白する人(クライアント)と告白される人(サーバー)の間でデータの送受信を行うために用いられるプロトコルです。プロトコルとは簡単に言えば約束事、決まりのことです。 告白で例えるとプロトコルは言葉と言えます。日本語や英語などです。通信プロトコルは世界強共通(言語)なので世界中あらゆる場所で通信できるのです。 愛があれば言語(プロトコル)の壁を越えることもあるかもしれませんが通信の場合、
Cookieの改訂版仕様 rfc6265bis について、その変更点をざっと眺めていく はじめに SameSite属性 Cookie名プレフィックス (Cookie Name Prefixes) __Secureプレフィックス __Hostプレフィックス 非セキュアなオリジンからの Secure属性の上書きを禁止 nameless cookieの許容 Cookie名、Cookie値の上限長の指定 Expires属性の年が2桁の場合の処理の指定 Max-Age/Expires の上限 その他 今回入らなかった機能 はじめに Cookieの仕様は『RFC 6265: HTTP State Management Mechanism』として標準化されています。 そのCookieの仕様の改訂版が『rfc6265bis』と呼ばれているもので、現在標準化作業が進められいています。"SameSite属性"
今回はRustを使って、簡単なHTTPサーバを実装してみましょう。HTTPは単純ですが生活インフラとしても必須となっているWebの根幹となる技術です。Rustに対する理解を深めると同時にWebの根幹となるHTTPについても学びましょう。 RustでHTTPを実装してみよう HTTPプロトコルとは？ 「HTTP(Hypertext Transfer Protocol)」とは、WebサーバーとWebブラウザの間でデータをやりとりするための通信規則（プロトコル）です。 1990年末にイギリスの物理学者ティム・バーナーズ＝リー氏と、ロバート・カイリュー氏によって設計されました。 HTTPプロトコルは、RFCとして公に発表されています。RFCとは、IETFが発行しているインターネットに関連する技術仕様などを共有するために公開される文書であり誰でも読むことができます。1996年にHTTP/1.0に関す
AWS Lambdaで突如としてHTTPヘッダが消失し、それにより悩まされることとなった日の経験を共有します。この問題がどのように生じ解決に至ったのか、また、私たちが学んだ教訓について述べていきます。 対象のLambda関数 今回問題が起きたLambda関数では、ランタイムにNode.jsを利用していました。Lambda関数の中には、外部のAPIサーバに対するリクエスト処理が含まれます。 環境情報は以下の通りです。 ランタイム: Node.js 18 (18.18.2) リクエストライブラリ: ky v1.0.1 エラーの発生 ある時、APIサーバからのレスポンスが"415 Unsupported Media Type"というエラーで返ってくるようになりました。エラーメッセージは以下のようなものです。 問題が起きる前は一度も発生していないエラーでしたが、一度発生した後は、全てのリクエストが
Intro Referrer-Policy は、送信される Referer の値を制御することが可能だ。 このヘッダの副次的な効果をよく理解していないと、「no-referrer にして送らないのが最も安全だ」という誤解を生むことになる。 では、複数あるポリシーの中でどのような観点で、どのディレクティブを採用するのが良いのだろうか? 前提として前回の記事の「リクエストの出自をチェックすることは現代の実装のベースプラクティスである」という点を踏まえて考えてみる。 令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io https://blog.jxck.io/entries/2024-04-26/csrf.html Referer とアナリティクス Referer は、リクエストに対してその前のページの URL を送るところから始まった。 GET / H
Is Secure Cookie secure? - CookieのSecure属性・__Host-プレフィックス・HSTSを正しく理解しよう - Flatt Security Blog
こんにちは、 @okazu_dm です。 前回の記事 に引き続きCookie関連のセキュリティに関する記事となります。 今回は、Cookieの仕様を定めたRFC6265(https://datatracker.ietf.org/doc/html/rfc6265)自体に含まれるSecure属性の問題点と、その対策について紹介していきます。 CookieのSecure属性自体は前回紹介したSameSite属性と比較してわかりやすいのもあり、かなり知名度が高いと思われますが、Secure属性単体で守れる範囲というのは実は限定的である、という点を本記事では実験も交えて示していきます。 なお、本記事はセキュリティ以外の分野を主業務とするソフトウェアエンジニアを主な想定読者として書いています。 記事内の検証につかったブラウザのバージョン Cookieについて 中間者攻撃の仕組み 実際に中間者攻撃をして
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io
SSL/TLS実践入門 ──Webの安全性を支える暗号化技術の設計思想
Go、Rust、Pythonで実装したAPIサーバーの負荷試験比較 - Qiita
ぼくのかんがえたさいきょうのGo HTTPサーバー起動方法
Arxiv RAGによる論文サーベイの自動生成 | Shikoan's ML Blog
Reverse HTTP Transport が描く新しい Web サービスデプロイ構成 | blog.jxck.io
GitHub - 1buran/rHttp: REPL for HTTP
Cookieの改訂版仕様 rfc6265bis の変更点 - ASnoKaze blog
Rustで有名アルゴリズムに挑戦(17) RustでHTTPサーバを実装してみよう
ポストモーテム: AWS Lambda内のリクエストからHTTPヘッダが消えた日
Referrer-Policy の制限を強めると安全になるという誤解 | blog.jxck.io
「Edge 124」でHTTPコンテンツがダウンロードできないトラブル ～Microsoftが変更を撤回／「Edge 127」で改めてセキュリティ強化を実施、事前の準備を【やじうまの杜】
