タグ

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

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

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

    令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io
  • Cookie Store API による document.cookie の改善 | blog.jxck.io

    Intro JS から Cookie を操作する document.cookie の改善を目的とした Cookie Store API についてまとめる。 document.cookie document.cookie は、ブラウザの API における代表的な技術的負債の一つと言える。 HTML Standard https://html.spec.whatwg.org/multipage/dom.html#dom-document-cookie的な使い方は以下だ。 document.cookie = "a=b" console.log(document.cookie) // a=b まず、この API の問題を振り返る。 同期 API 最も深刻なのは、 I/O を伴いながら、同期 API として定義されているところだ。 この API は古くから実装されているため、I/O は非同期

    Cookie Store API による document.cookie の改善 | 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の仕様はなぜ複雑なのか
  • 実例に学ぶXSS脆弱性の発見と修正方法/line_dm 16 20160916 how to find and fix xss

    LINE Developer Meetup in Fukuoka #16 http://connpass.com/event/38413/

    実例に学ぶXSS脆弱性の発見と修正方法/line_dm 16 20160916 how to find and fix xss
    raimon49
    raimon49 2016/10/02
    安全とレビュー完了した箇所にsafeコメント入れて行くのか。なるほど。
  • Introduction to Service Worker: How to use Service Worker - HTML5 Rocks

    Stay organized with collections Save and categorize content based on your preferences. Explore our growing collection of courses on key web design and development subjects. An industry expert has written each course, helped by members of the Chrome team. Follow the modules sequentially, or dip into the topics you most want to learn about.

    Introduction to Service Worker: How to use Service Worker - HTML5 Rocks
    raimon49
    raimon49 2015/01/08
    Service Workerのスコープは登録されたorigin単位。
  • WKWebViewで躓いた10つのまとめ - Qiita

    WKWebViewについてわかったこと。iOS 8.1.0の時点での情報です。 StackOverflowやDeveloperForumsからの情報と、私がOhajiki Web Browserを開発する過程で得た知識を短めにまとめてみました。 これ以外にもまだまだ細かい部分があるかと思いますが、より良い方法や補足などがありましたらコメント欄で是非とも教えていただければ幸いです。 iOS 9での変更点はこちら: iOS 9 WKWebView 主な変更点をざっくり tmpフォルダ以外は file:/// を使ってアクセスできない iOS8.0.2からtmpディレクトリ以下のファイルに fileプロトコルでアクセスすることが可能になりましたが、それ以外のディレクトリからのアクセスは無効となっています。WKWebViewが普及しない一番の要因はこれではないでしょうか。 こちらで試すことが出来ま

    WKWebViewで躓いた10つのまとめ - Qiita
  • Canvas Fingerprintingはクッキーより怖いのか技術的に調べてみた|TechRacho by BPS株式会社

    morimorihogeです。最近忙しくて遠征すらおぼつかない状態です。夏イベント資源足りるのかこれ。 なんかはてブ界隈などでCanvas Fingerprintingの話題が出ていて、Cookieより怖い!とか、Adblockみたいに無効にする方法がないのにユーザトラッキングできて怖い!!といったアオリの記事がぽこぽこ出てきているようです。 でも、ざっと調べた限りの日語のどの記事を読んでも、具体的にどうやってユーザ個々のトラッキングができるようになるのか、技術的に解説されている記事が見つかりませんでした。 というわけで、エンジニアとしてはここは一つキッチリ理解しておきたいと思い、調べた結果をまとめます。 もし僕の読解がおかしくて変なことを言っている部分があれば、はてブやTwitter、コメント欄などで指摘して頂ければ更新していこうと思いますので、マサカリ上等です ;) Canvas F

    Canvas Fingerprintingはクッキーより怖いのか技術的に調べてみた|TechRacho by BPS株式会社
    raimon49
    raimon49 2014/08/07
    レンダリング結果でハードウェア構成の推定。
  • 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を付与。
  • はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知

    はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

    はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
    raimon49
    raimon49 2012/07/09
    クッキー無効の振る舞いを偽装 王道はhttponly属性の付与
  • text.ssig33.com - Facebook の JS SDK は使ってはいけない。

    Facebook の JS SDK は使ってはいけない。 非常に問題がある。どうせ単なる薄いラッパーなんだし、必要に応じて自分であんなの書けるでしょう。問題について書く。 ありがちなアプリケーションの例 FB.login(function(res){ FB.getLoginStatus(function(res){ if(res.status === 'connected'){ FB.api('/me', function(res){ console.log(res.email) } } }) },{scope: 'email'}) 自分 のemail を取得出来る。 ところで、こうしたらどうなるだろうか。 FB.login(function(res){ FB.getLoginStatus(function(res){ console.log(res.status) FB.api('/me

    raimon49
    raimon49 2012/05/20
    >サードパーティークッキーをオフにしていると、暗黙的フローで拾ってきた access token が FB.api を潜った瞬間に無効になってしまう
  • クライアントサイドの巨大なクッキーとサーバーサイドのヘッダーサイズ制限の組み合わせによるDoSについて - デー

    もう10年以上前のネタなのですが、いまだに有効だし、最近、セッションを扱っていないならXSSがあってもあまり問題ないという意見を見ることがあるので、サービス提供側として案外面倒なことになる場合がある、という話を書きました。 POCです。 http://www.udp.jp/misc/largecookiedos.html 内容としては、 JavaScriptから巨大なCookieをブラウザに設定できる HTTPサーバーは受け取れるHTTPヘッダーサイズの上限を持っていて、それを超えていた場合にBad Requestを返す 1によって2を超えるサイズのCookieが設定可能な場合がある(たぶんほとんどの場合可能) よってXSSなどによって巨大なCookieを設定されると以降サービスが利用できなくなる というものです。 Cookieの有効期限を何十年も設定されるとユーザー側で勝手に回復すること

    クライアントサイドの巨大なクッキーとサーバーサイドのヘッダーサイズ制限の組み合わせによるDoSについて - デー
    raimon49
    raimon49 2012/04/18
    巨大なサイズのcookieを送りつけてサービス不能に
  • はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知

    はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

    はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
    raimon49
    raimon49 2012/04/05
    location.hashそのまま使わない、$()関数が汎用的過ぎるので素直にパラメータ渡さない、XHRのリクエスト先には必ず 絶対パス + 動的部分、関数の粒度を細かく、パスワード入力させるドメインをサブドメイン化
  • ソフトバンクのゲートウェイ型SSLの脆弱性を振り返る

    WEB & NETWORK SSL/TLSより引用 わざわざSSLの場合にもゲートウェイを割り込ませている目的としては、ケータイID(UID)を付与することと、絵文字の変換があるようです。 ※注意:EZwebにもゲートウェイ型のSSLがあります(仕様)がProxyサーバーのホスト名が見えているわけではないので、今回報告するような問題はありません。 ゲートウェイ型SSLの問題点 ゲートウェイ型SSLが廃止されるきっかけは、高木浩光氏と、ソフトバンクモバイル取締役専務執行役員CTOの宮川潤一氏のtwitter上のやりとりであると言われています。この内容は、Togetterにまとめられています。これを読むと、ゲートウェイ方式のSSLでは、httpとhttpsでドメインが異なるため、Cookieを引き継ぐことができないことが問題として説明されています。現場のニーズとしてこの問題は大きいと思うのです

    raimon49
    raimon49 2011/07/02
    ソフトバンクの非公式JavaScript対応機に搭載されたブラウザがノーガード状態だった。
  • SoftBankガラケーの致命的な脆弱性がようやく解消 - 高木浩光@自宅の日記

    ■ SoftBankガラケーの致命的な脆弱性がようやく解消 ソフトバンクモバイルのガラケーWebブラウザで、https:接続する際の仕様に変更があった。昨年10月に予告が発表され、元々は2月に実施される予定だったのが、6月30日に延期されていたもの。これまで、https:サイトへのリンクのすべてが https://secure.softbank.ne.jp/ 経由に書き換えられる仕様だったが、この機能が廃止された。 ソフトバンクモバイル、携帯サイトの仕様変更で注意喚起, ITmedia, 2011年6月30日 Yahoo! ケータイ、2011年2月に仕様変更 ユーザーとサイト開発者に注意喚起, ITmedia, 2010年10月15日 MOBILE CREATION - WEB & NETWORK SSL/TLS, ソフトバンクモバイル これは、昨年6月に、ソフトバンクモバイル宮川CTOに

    raimon49
    raimon49 2011/07/02
    https://secure.softbank.ne.jp/ 経由でHTTPSアクセスを行う仕様によって、任意のサービスをiframe要素内に閉じ込めることで同一オリジンとなってcookieやDOMへのアクセスが可能となっていた。
  • EZwebの2011年秋冬モデル以降の変更内容とセキュリティ上の注意点 - ockeghem's blog

    au/KDDIの技術情報サイトEZfactoryには、2011年秋冬モデル以降にEZwebの仕様変更がある旨表示されています。セキュリティ上の問題の可能性もあるため以下に報告します。 EZfactoryトップページでの告知内容 EZfactoryトップページには、2011年秋冬モデルでの変更を以下のように要約しています。 ※お知らせ※ EZブラウザは、2011年秋冬モデルにて、EZサーバを含め、「機能」及び「ネットワーク環境」の見直しを行ないます。 これによる主な変更点は以下のとおりです。 <主な変更点> ・EZサーバの言語変換機能が削除され、HDMLが非サポートとなる。 ・EZブラウザ、PCサイトビューアーのIPアドレス帯域が統一される。 今後EZブラウザ向けコンテンツを作成する場合は、XHTML Basicを推奨します。 http://www.au.kddi.com/ezfactory

    EZwebの2011年秋冬モデル以降の変更内容とセキュリティ上の注意点 - ockeghem's blog
    raimon49
    raimon49 2011/06/27
    X-UP-SUBNOヘッダ(EZ番号)詐称可能だからIPアドレスとセットで本人確認を行って下さいとキャリア公式にお願いしているの図。
  • 間違いだらけの「かんたんログイン」実装法

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

    間違いだらけの「かんたんログイン」実装法
  • 「PCでは見えないはず」に頼ることの危険性

    “特殊だ”と形容されることの多い日の携帯電話向けWebサイト。そこには、さまざまな思い込みや性善説の上しか成り立たないセキュリティが横行しています。連載は、ケータイWebの特殊性をていねいに解説し、正しいケータイWebセキュリティのあるべき姿を考えます(編集部) 無視できない“ケータイWeb”セキュリティ はじめまして。今回からこの連載を担当することになりました徳丸浩といいます。この連載では、携帯電話向けWebアプリケーション(以後「ケータイWeb」と表記します)のセキュリティについて解説します。ここでいう携帯電話とは、iモードやEZweb、Yahoo!ケータイなど、日で従来、広く利用されているサービスを指します。一方、いわゆるフルブラウザやiPhoneAndroid端末などは含みません。 ケータイWebは、一般のPCなどから利用されるWebと比較して、使用技術の90%くらいは共通

    「PCでは見えないはず」に頼ることの危険性
    raimon49
    raimon49 2009/11/19
    閉鎖的でなくなりつつある日本のケータイWeb
  • Tender Surrender » Caja

    OpenSocial周りの調査をしていると、Cajaという言葉に遭遇します。セキュアなJavaScriptを実現するもの、ということだけ分かっていたのですが、詳細を調べてみました。 クロスサイトスクリプティングとブログパーツ gooやlivedoor、fc2などのホスティングを含めたブログサービスを使ったことのある方はご存知と思いますが、サービスによってブログパーツが貼れるもの、貼れないもの、一部だけ許可しているものがあります。なぜでしょうか? Cookieには同一ドメインから実行されたスクリプトしか参照できないという特徴があります。これを利用して、Cookieをセッション情報や閲覧履歴の保存場所として活用しているサービスは少なくありません。上記ブログサービスがブログパーツを許可しないのは、これらの情報を悪意のあるJavaScriptから守るためです。逆に言うと、同一ドメイン上でJavaS

  • iモードがJavaScriptやCookie対応、Flash動画も

    NTTドコモは、2009年夏モデルの発表にあわせ、「iモードブラウザの拡張(バージョンアップ)」として、iモード関連の仕様拡充を発表した。今夏モデル以降が対象となるが、今回発表された機種のうち、L-04A、L-06A、P-10A、T-01A、HT-03Aは非対応となる。 ■ 操作体系の変更 Flashゲームも方向決定キーで操作可能に 操作関連では、「i」ボタン(iモードボタン)を押した際の挙動が変更される。これまではiモードボタンを押すと、端末のiモード関連メニューが表示され、iメニューへのリンク、ブックマーク、ラストURL、iモード設定といった項目が表示された。しかし、今夏モデルからはiモードボタンを押すと、すぐiメニュー(iモード公式メニュー)へアクセスするようになる。 ブックマークや画面メモへは、サブメニューから利用する形となる。なお、iメニューのページにアクセスしている最中でも操作

    raimon49
    raimon49 2009/05/19
    アップデートされたのはiモードブラウザ