タグ

関連タグで絞り込む (0)

  • 関連タグはありません

タグの絞り込みを解除

JavaScriptとHTTPとcookieに関するraimon49のブックマーク (5)

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

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

    令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io
  • はてなスターのひみつ - Hatena Developer Blog

    ハッピーホリデー!id:cockscombです。この記事ははてなエンジニアAdvent Calendarの8日目のエントリです。 今年1月、はてなスターのリニューアルを行いました。リニューアルの内容は告知をご参照ください。 はてなスターのリニューアルでは、クロスオリジンの問題を解決するために特別な実装をしています。今回は、ホリデーシーズンをお祝いして、そのひみつを詳 (つまび)らかにします。 はてなスターとクロスオリジン はてなスターは、はてなブログなどに埋め込んで利用されます。はてなブログは hatenablog.com や hatenadiary.jp などのサブドメインを利用しており、さらにはてなブログProでは独自のドメインを設定できます。 はてなスターは複数の異なるドメイン名のサイトから利用される、ということです。 要するにはてなスターはクロスオリジンで利用されます。一方ではてな

    はてなスターのひみつ - Hatena Developer Blog
  • CORSの仕様はなぜ複雑なのか

    Webアプリケーションを実装していると高確率で CORS の問題にぶつかります。CORSがどのようなものかはリンクしたMDNなど既存の解説を読むのが手っ取り早いと思いますが、「なぜそのように設計されたのか」という観点での説明はあまり見ないため、昔の資料の記述や現在の仕様からの推測をもとに整理してみました。 CORSとは 現代のWebはドメイン名をもとにした オリジン (Origin) という概念 (RFC 6454) をもとに権限管理とアクセス制御を行っています。その基となるのが以下のルールです。 Same-origin policy (同一生成元ポリシー): 同じオリジンに由来するリソースだけを制御できる。 上記Wikipedia記事によるとSOPの概念は1995年のNetscape 2.02に導入されたのが最初のようです。当時のドキュメンテーションを読む限り、これはウインドウ越しに別

    CORSの仕様はなぜ複雑なのか
  • CORS(Cross-Origin Resource Sharing)について整理してみた | DevelopersIO

    ブラウザからAmazon S3に直接ファイルをアップロードしたい 先日、Amazon S3にファイルをアップロードするWebアプリを作ろうとして色々調べていたところ、S3にCORSという仕様のクロスドメインアクセスの設定をすることによって、ブラウザから直接S3にアップロードをする方法にたどり着きました。ただ、この方法を使うにあたってはCORSというクロスドメインアクセスの仕様をきちんと理解しておいた方が良さそうでしたので、まずはCORSについて自分なりに整理してみました。 なお、弊社の横田がCORSとS3についての記事を以前書いていますので、S3のCORSサポートに関する概要を知りたい方はそちらをご覧下さい。 CORS(Cross-Origin Resource Sharing)によるクロスドメイン通信の傾向と対策 CORS ブラウザでAjax通信を行う際には、同一生成元ポリシー(Same

    raimon49
    raimon49 2014/05/28
    CORS対応サーバ側実装の例。Originフィールドのチェック、HTTPメソッドがOPTIONSでヘッダにAccess-Control-Request-Methodフィールドでpreflightか切り分け。クライアント側からpreflightリクエストの発生にはContent-Typeにapplication/jsonを付与。
  • 間違いだらけの「かんたんログイン」実装法

    今回は、そのかんたんログインの問題点について説明します。 「契約者固有ID」を用いるかんたんログイン かんたんログインとは、携帯電話の「契約者固有ID」を用いたログイン手法です。 第1回で説明したように、携帯電話のブラウザのリクエストヘッダには契約者固有IDと呼ばれるIDを付けることができます。契約者固有IDは、携帯電話事業者によって詳細は異なりますが、すべての携帯電話事業者が対応しています。 図1は、NTTドコモの携帯電話がサポートしている契約者固有IDである「iモードID」がサーバに送信される様子です。この情報は、ユーザーがそれと意識することなく送信されます。携帯電話のかんたんログインとは、契約者固有IDのみを用いて認証を行い、ログイン機能を実現することです。 かんたんログインは、ベーシック認証のようにIDとパスワードを管理する必要もなく、Cookieのように対応する端末を考慮する手間

    間違いだらけの「かんたんログイン」実装法
  • 1