Cookie 概説 - 30歳からのプログラミング
Cookie とは、HTTP でステートフルなやり取りを実現するために、ブラウザとサーバ間で情報を送受信する仕組みである。 HTTP は本来ステートレスなプロトコルである。そのため、同一のユーザーが連続でリクエストを行っても、それぞれ独立したリクエストであり、「同じユーザーからのリクエストである」とサーバが認識することはできない。 これは例えば、ログイン状態の管理で問題となる。ID とパスワードで認証を行っている場合、リクエストの度に ID とパスワードを送信しなければならない。 Cookie を使うことで、このような事態を解決できる。 まず、サーバがブラウザに対して、Cookie としてどのような情報を保存するのか指示する。具体的には、レスポンスヘッダにSet-Cookieフィールドを含め、そこに Cookie として保存させたい情報を設定する。ログイン状態を管理したい場合は、セッション
フロントエンドの「想定外」に対応する考え方とTipsいくつか
とても個人的な話ですが、ここ最近で自分自身のプライバシー意識の高まりを感じて、ブラウザの設定を見直す機会がありました。見直したのはCookieの設定で、許可したドメインにしかCookieを記憶しないようにしました。設定変更によるある程度の不便は覚悟していました。とはいえ、ま〜せいぜい、初回アクセスの時のモーダルが何度も出るようになるとか、ログインできなくなるとか、そのくらいかなと思っていました。 しかし実際は、悪い意味で期待を裏切られることになりました。 Cookieが無効なだけで、“全く”動かなくなってしまうウェブサイトやウェブアプリが、本当にたくさんあることに気づいたのです。 全く動かなくなってしまう原因は単純（後述）だったのですが、ちょっとした対処で簡単に直せることなのに、サイト全体が一切使い物にならなくなってて、もったいない！！ と思いました。 フロントエンドの想定外 ウェブサイト
[iOS][Android] WebView の Cookie を削除する方法 | DevelopersIO
任意のタイミングでの Cookie 削除 iOS, Android でそれぞれ WebView の Cookie を削除する方法をご紹介します。 結構ハマりました。 WebView は罠が多いですね。 iOS iOS は WKWebView に関しての方法です。 UIWebView については調べていません。 サンプルコード - (void)removeAllCookies { NSString *libraryPath = NSSearchPathForDirectoriesInDomains(NSLibraryDirectory, NSUserDomainMask, YES).firstObject; NSString *cookiesPath = [libraryPath stringByAppendingPathComponent:@"Cookies"]; NSString *we
![[iOS][Android] WebView の Cookie を削除する方法 | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/59033efbc7e1ab5d824311649cd012ca1b753503/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2016%2F01%2Feye-catch-ios-and-android.png)
【PHP超入門】Cookieとセッションについて - Qiita
Udemy で講座の販売を開始しました！ Udemy で「プログラミング学習の心得＆HTTPの基礎」の動画講座を公開しました。 特別に 85% OFFのクーポンを発行します。 通常価格 10,800 円が 1,800 円で購入できます。 動画内でも説明していますが、初心者・初学者向けの内容です。 事前に自分の知りたい内容・興味のある内容か確認してからご購入ください。 挫折した人が教える PHP プログラミングシリーズ Vol.1『学習の歩き方』 はじめに PHPでメールフォームや掲示板などWebアプリケーションを作りたいと考えている方は、Cookieとセッションについて必ず理解しておく必要があります。 Cookieとセッションは、ユーザーを識別するために欠かせない技術で、非常に重要な役割をしております。 ここを理解すれば、作りたいWebアプリケーションに一歩前進しますので、Cookieとセ
Web Storage: セッショントークンのマシな手段 ― cookieとセキュリティ面を比較してみる | POSTD
最近、私は「セッショントークンを、cookieの代わりに Web Storage (sessionStorage/localStorage)に保存するのは安全ですか？」ということを尋ねられました。このことについてGoogleで検索したところ、検索結果の上位のほとんどが「Web storageはcookieに比べてかなりセキュリティが弱く、セッショントークンには不向きである」と断言していました。透明性のため、私はこの逆の結論に至った理論的根拠を公に書くことにしました。 Web Storageに関する議論の中核として言われるのは、「Web StorageはsecureフラグやHttpOnlyフラグといったcookie特有の機能をサポートしていないため、攻撃者が容易に盗み取ることが可能」というものです。path属性についても言及されます。私は、これらの機能それぞれについて調べてみました。そして、
Cookieとセッションをちゃんと理解する - Qiita
引用/参考書籍 「よくわかるPHPの教科書」 「初めてのPHP5」 「パーフェクトPHP」 「体系的に学ぶ安全なWebアプリケーションの作り方」 「PHPスーパーサンプル」 「プロになるためのWeb技術入門」 インターネット上で情報をやりとりするということは、大事な内容をはがきに書いて相手に送るようなもの。その情報が相手に届くまでに誰に見られるかわからない。 概要 HTTPはステートレスなプロトコル。「状態」を持てない。 例えば、「ログイン」ページの場合、「ログインしているかどうか」のチェックをする必要がある。 NG例) http://www.littleforest.jp/itemlist?login=ok loginパラメータを調べてokかどうかを調べる。 →→パラメータを容易に改変できてしまう。 解決策として、Cookieとセッションを使う。 Chromeで、Cookieを確認するに
ChromeCookiesView - Chrome Cookies Viewer
ChromeCookiesView v1.76 - View / delete cookies of Google Chrome Web browser Copyright (c) 2011 - 2024 Nir Sofer Description ChromeCookiesView is an alternative to the standard internal cookies viewer of Google Chrome Web browser. it displays the list of all cookies stored by Google Chrome Web browser, and allows you to easily delete unwanted cookies. It also allows you export the cookies into tex
Same-Origin Policy とは何なのか。 - 葉っぱ日記
ちょっと凝ったWebアプリケーションを作成していたり、あるいはWebのセキュリティに関わっている人ならば「Same-Origin Policy」(SOP)という言葉を一度は聞いたことがあると思います。日本語では「同一生成元ポリシー」あるいは「同一生成源ポリシー」などと訳されることもありますが、個人的には「オリジン」は固有の概念を表す語なので下手に訳さず「同一オリジンポリシー」と書いておくのが好きです。 さて、この「オリジン」とは何なのかという話ですが、これは「RFC 6454 - The Web Origin Concept」で定められており、端的に言うと「スキーム、ホスト、ポート」の組み合わせをオリジンと定め、それらが同じものは同一のオリジンとして同じ保護範囲のリソースとして取り扱うということです。 例えば、http://example.jp/fooとhttp://example.jp:
ログアウト機能の目的と実現方法
このエントリでは、Webアプリケーションにおけるログアウト機能に関連して、その目的と実現方法について説明します。 議論の前提 このエントリでは、認証方式として、いわゆるフォーム認証を前提としています。フォーム認証は俗な言い方かもしれませんが、HTMLフォームでIDとパスワードの入力フォームを作成し、その入力値をアプリケーション側で検証する認証方式のことです。IDとパスワードの入力は最初の1回ですませたいため、通常はCookieを用いて認証状態を保持します。ログアウト機能とは、保持された認証状態を破棄して、認証していない状態に戻すことです。 Cookieを用いた認証状態保持 前述のように、認証状態の保持にはCookieを用いることが一般的ですが、Cookieに auth=1 とか、userid=tokumaru などのように、ログイン状態を「そのまま」Cookieに保持すると脆弱性になります
スマホブラウザでのセッションクッキーの有効期限
サイトへJSでタブインターフェースや文字サイズ変更機能を実装したとします。 これらは他のページへ遷移する毎にリセットされるため、一時的にクッキーなど（※）に状態を保存するような対応をするかと思いますが、 PCブラウザと違い「ブラウザを終了する」機会の少ないスマホブラウザはどのタイミングでセッションクッキーが削除されるのでしょうか？ ※対象環境次第で（HTML5の）sessionStorageやlocalStorageの使用を検討 そこで、スマホブラウザのセッションクッキーの有効期限を把握すべく検証しました。 環境別の検証結果 iOS5.1.1 + Safari 削除されない動作 ホームボタンを押して終了。（実際にはバックグラウンドでブラウザが動作しており終了していない） 削除される動作 下記手順にてSafari終了。 ホームボタン2度押し→Safariアイコン長押し→アイコンが揺れだしたら
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
GoogleがSafariの設定を迂回してトラッキングしていたとされる件について - 最速転職研究会
※この記事の完成度は85%ぐらいなので後で追記します。 http://webpolicy.org/2012/02/17/safari-trackers/ http://online.wsj.com/article/SB10001424052970204880404577225380456599176.html http://blogs.wsj.com/digits/2012/02/16/how-google-tracked-safari-users/ 合わせて読みたい。 http://trac.webkit.org/changeset/92142 https://bugs.webkit.org/show_bug.cgi?id=35824 一番上のJonathan Mayer氏の記事については純粋に技術的なレポートなので、特におかしなことは書かれていない。元はといえばSafariのCooki
サードパーティCookieの歴史と現状 Part2 Webアプリケーションにおける利用とその問題 - 最速転職研究会
前回 http://d.hatena.ne.jp/mala/20111125/1322210819 の続きです。 前回のあらすじ ブラウザベンダーはサードパーティCookieをデフォルトでオフにしたかったんだけどお前らがサードパーティCookieに依存したサイト作るし使うからオフに出来なかったんだよ!!!!! といった事情を踏まえた上でWebアプリケーションにおけるサードパーティCookieの利用の歴史について書きます。前提知識の共有が済んだので、ここからはある程度個人的な意見も含まれます。実装面での技術的な内容も含みます。 サードパーティCookieが必要とされてきた歴史 広告のためのトラッキングCookie以外にも、サードパーティCookieに依存したサービスが数多く存在してきた。個人的に把握しているいくつかのサービスについて時系列で述べる。ついでに広告業界の流れについても重要なのを幾
サードパーティCookieの歴史と現状 Part1 前提知識の共有 - 最速転職研究会
Web開発者のためのサードパーティCookieやらトラッキングやらの問題点について三回ぐらいに分けて書きます。 この文章は個人的に書いていますので、おい、お前のところのサービスがサードパーティCookieに依存してるじゃねーかというツッコミがあるかもしれないが、そういうことを気にしているといつまで経っても公開できないという問題が出てしまうので、そんなことはお構いなしに書く。ちなみに例外なく自社サービスに対してもサードパーティCookieに依存するな死ねと言っている。これはWebプログラマー観点で、自分がサービス開発に関わる上で知っておかねばならないだろう知識として十数年間だらだらとWebを見ていて自然に知っていたものと、あるいは興味を持って率先して調べたものが含まれている。ググッて直ぐに分かる程度の用語の定義的なことは書かない。あくまでWebサイト制作者側からの観点なので、ブラウザ開発関係
都道府県型JPドメインがCookieに及ぼす影響の調査
JPRSからのプレスリリース『JPRSが、地域に根ざした新たなドメイン名空間「都道府県型JPドメイン名」の新設を決定』や報道などで「都道府県型JPドメイン」というものが新設されることを知りました。 都道府県型JPドメインとは、現在活発に使われていない地域型ドメインを活性化する目的で、地域型ドメインの制約（ドメイン名が長い、一人・一団体あたり1つまで）を簡略化しようというもののようです。 しかし、現在の地域型ドメインは、ブラウザにとって処理がややこしいもので、IEなどは昔からまともに対応していません。このため、Cookie Monster Bugという脆弱性になっているという経緯があります。このルールをさらに複雑にすることになるということから、ブラウザセキュリティに関心の高い人たちが騒ぎ始めています。 そこで、高木浩光氏の日記「JPRSに対する都道府県型JPドメイン名新設に係る公開質問」の以
大規模 Web サービスでログインを長期間保持するには SESSION は使わず Cookie とデータベースだけで実装する | ウェブル
先日ペコリンという Web サービスを公開したのですが、これが初めての WordPress との複合会員向けサービスだったためか、ログインが途中で切れたり、記事投稿時のリダイレクトがかかるタイミングなどで SESSION が切れてしまうことがありました。 しかし Twit Delay では長期的にログインが保持されていたり、mixi とかではログイン時間を指定できたりするので、なんとかできるものだろうと考えていたら Twitter で教えてもらいましたのでまとめておきます。 SESSION だけを使ったログインの保持では長期ログインは不可 私は今までログインの保持は以下のようにしていました。 1 2 3 4 5 <?php ini_set('session.gc_maxlifetime', 60*60*24); ini_set('session.gc_divisor', 10000); s
Set-Cookie 時にドメインを指定する/しないで挙動が変わる | tanablog
Firefox の Cookie の挙動でハマったのでメモしておきます。Set-Cookie 時にドメインを指定する/しないで、保存される Cookie が異なるようです。 ドメインを指定しない場合 レスポンスヘッダの Set-Cookie で、ドメインを省略した場合は、保存された Cookie のドメインは、そのサイトのドメイン (FQDN) となる。 ドメインを指定した場合 レスポンスヘッダの Set-Cookie で、ドメインを指定した場合は、保存された Cookie のドメインは、指定したドメインの先頭に "." (ドット) が付く。 ドットが付いている Cookie と付いていない Cookie ではアクセスレベルの意味が変わるので注意。ドットが付いている Cookie はサブドメインにアクセスした際にも送信される。この例だと foo.lab.kaihatsubu.com など。
XSS (Cross Site Scripting) Cheat Sheet
XSS (Cross Site Scripting) Cheat Sheet Esp: for filter evasion By RSnake Note from the author: XSS is Cross Site Scripting. If you don't know how XSS (Cross Site Scripting) works, this page probably won't help you. This page is for people who already understand the basics of XSS attacks but want a deep understanding of the nuances regarding filter evasion. This page will also not show you how to
しゃおの雑記帳 - 携帯サイト開発者のためのセキュリティ再入門
通勤電車で周囲を見渡せば大抵数台のスマートフォンを見つけられるようなご時世ですが、現実は日本の伝統的な携帯電話が多数派です。今もそんなガラケー向けWebサイトの開発案件は衰えることありません。 そんなガラケーサイトの開発者の間で話題になっている「セキュリティ対策」について、ガラケー界の現状をふまえた上でまとめてみます。 携帯電話のIPからのアクセスであることを前提としたセキュリティ対策はすでに無駄 ソフトバンク3Gのプロクシ情報は検索すればすぐに出てきます イー・モバイルのEMnetに至っては公開情報です サイトのソースもFlashのswfも画像もPCから丸見えだと思うべきです 危険な「かんたんログイン」 かんたんログインで使う契約者IDはあなたのサイトにも他のサイトにも同じものが送出されてます 悪意をもった人が他人の契約者IDをヘッダに乗せてかんたんログインのアクションを呼び出したらどう
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - carhartl/jquery-cookie: No longer maintained, superseded by JS Cookie:
