タグ

ブックマーク / blog.jxck.io (5)

  • 令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io

    Intro CSRF という古の攻撃がある。この攻撃を「古(いにしえ)」のものにすることができたプラットフォームの進化の背景を、「Cookie が SameSite Lax by Default になったからだ」という解説を見ることがある。 確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の質から言うと、解釈が少しずれていると言えるだろう。 今回は、「CSRF がどうして成立していたのか」を振り返ることで、当にプラットフォームに足りていなかったものと、それを補っていった経緯、当にすべき対策は何であるかを解説していく。 結果として見えてくるのは、今サービスを実装する上での「ベース」(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件 例えば、攻撃者が用意した attack.examp

    令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io
    dorapon2000
    dorapon2000 2024/04/27
    “つまり、 SameSite Cookie が導入されるずっと以前から、「リクエストの出自を知る」ことはでき、それを用いて攻撃リクエストを弾くことはできたのだ。”
  • 3PCA 4 日目: 3rd Party Cookie の正体 | blog.jxck.io

    Intro このエントリは、 3rd Party Cookie Advent Calendar の 4 日目である。 3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiita https://qiita.com/advent-calendar/2023/3rd-party-cookie 前回は「サブリソースにまで Cookie が送られて何が嬉しいのか」という話だった。 今回はそのユースケースについて考えていく。 「さっき見てた商品が出る」のからくり 例えば、 EC サイトで色々な商品を探した後に、全然関係のないサイトで、なぜかさっきまで見ていた商品がそのサイト内でおすすめされている、という経験があるだろう。 今回はリアルワールドの例として、楽天の実装を引用する。 まず、楽天市場のサイトでミネラルウォーターを物色する。 その後、 Yaho

    3PCA 4 日目: 3rd Party Cookie の正体 | blog.jxck.io
    dorapon2000
    dorapon2000 2023/12/15
    “このリクエストを受け取った楽天は、「アカウントは不明だが、このユーザは、先ほどミネラルウォーターを見ていたユーザだ」とわかる。”
  • ブラウザでリロードしながらキャッシュの挙動を確認してる全ての開発者へ | blog.jxck.io

    Intro こういうタイトルを付けるのはあまり好きではないが、あえてこのようにした。 「ブラウザでキャッシュがヒットしない」 以下は、 Web における Caching の FAQ だ。 サーバで Cache-Control を付与したのにキャッシュがヒットしない サーバで ETag を付与したのに If-None-Match が送られない サーバで Last-Modified-Since を付与したのに If-Modified-Since が送られない 先日も、筆者が書いた MDN の Cache セクションで「記述が間違っているのでは?」と同様の質問を受けた。 Issue about the Age response header and the term "Reload" · Issue #29294 · mdn/content https://github.com/mdn/cont

    ブラウザでリロードしながらキャッシュの挙動を確認してる全ての開発者へ | blog.jxck.io
    dorapon2000
    dorapon2000 2023/11/06
    “では、「キャッシュの挙動」、正確には「ユーザが体験するキャッシュの挙動」はどのように検証すれば良いのだろうか? 答えは、最初に言ったように Navigation を用いることだ。”
  • XMLHttpRequest とはなんだったのか | blog.jxck.io

    Intro Fetch API の実装が広まり、 IE もリタイアを迎えたことで、今後忘れ去られていくことになるだろう XMLHttpRequest について。 どのように始まり、どのように広まり、どのように使われなくなっていくのか。その間に残した多大な功績を残す。 XMLHttpRequest の始まり この名前は非常に長いため、通常 XHR と略される。 この API は、現在の Web API のように W3C/WHATWG による標準化を経て策定された API ではない。 Microsoft によるいわゆる独自実装の API として始まり、後追いで標準化される。 したがって、 Web API の中でもかなり異質な命名である XHR が、 XmlHttpRequest でも XMLHTTPRequest でもなく XMLHttpRequest である理由も、 Microsoft の命

    XMLHttpRequest とはなんだったのか | blog.jxck.io
    dorapon2000
    dorapon2000 2022/10/20
    “Promise ベースでありながら Polyfill でもあり、痒いところにも手が届く Axios がちょうど良い落とし所になり、”
  • JavaScript のメディアタイプと RFC 9239 | blog.jxck.io

    Intro 長いこと作業が行われていた JavaScript の MIME タイプについての作業が完了し、 RFC 9239 として公開された。 これにより、推奨される MIME タイプが text/javascript に統一されることになった。 かつて推奨されていた application/javascript ではなくなった経緯などを踏まえ、解説する。 JavaScript MIME Types HTTP で Response する際に指定する Content-Type は、その内容がなんであるかを Client に Indicate し、適切な処理を促すために使用される。 例えば HTMLtext/html であったりするように、 JS も内容はテキストなので text/javascript が自然に思える。 しかし、例えば MS が実装していた JS 互換の JScript

    JavaScript のメディアタイプと RFC 9239 | blog.jxck.io
  • 1