タグ

cookieとsecurityに関するMakotsのブックマーク (12)

  • 2023年4月においてクリックジャッキング未対策のサイトはどの条件で被害を受けるか

    サマリ CookieやlocalStorage等でセッション管理しているウェブサイトがクリックジャッキング対策していない場合、どの条件で被害を受けるかを説明する。SameSite属性のないCookieでセッション管理しているウェブサイトは、主要ブラウザのデフォルト設定ではクリックジャッキングの影響を受けない。一方、loaclStorageにトークン類を格納するウェブサイトでは、Google Chrome等のブラウザでクリックジャッキングの影響がある。また、ブラウザの設定を変更した場合の影響についても説明する。 クリックジャッキングとは クリックジャッキングとは、一言で説明すると「ウェブサイト利用者に意図しないクリック(タップ)をさせる」攻撃です。ウェブサイト上で意図しないクリックを勝手にさせられると、重大な結果になる場合があります。例えば、このURLを閲覧すると、以下のようにTwitter

    2023年4月においてクリックジャッキング未対策のサイトはどの条件で被害を受けるか
  • 2022年1月においてCSRF未対策のサイトはどの条件で被害を受けるか

    サマリ2020年2月にGoogle ChromeCookieのデフォルトの挙動をsamesite=laxに変更しましたが、2022年1月11日にFirefoxも同様の仕様が導入されました。この変更はブラウザ側でCSRF脆弱性を緩和するためのもので、特定の条件下では、ウェブサイト側でCSRF対策をしていなくてもCSRF攻撃を受けなくなります。この記事では、デフォルトsamesite=laxについての基礎的な説明に加え、最近のブラウザの挙動の違いについて説明します。 (2022年1月29日追記) 日確認したところ、Firefoxにおけるデフォルトsamesite=laxはキャンセルされ、従来の挙動に戻ったようです(Firefox 96.0.3にて確認)。デフォルトsamesite=lax自体は先行してGoogle Chromeにて実装されていましたが、細かい挙動の差異で既存サイトに不具合が

    2022年1月においてCSRF未対策のサイトはどの条件で被害を受けるか
  • mozaic bootcampに参加して気づいた、自分に欠けていたWeb技術の知識メモ - ninjinkun's diary

    mozaic bootcampというhttps://t.co/OfP8vuZTkfリスナーのための4日間通し勉強会に参加中。2日目の今日はkeep-aliveからのちょっとHTTP2、これからCookieの話— にんじんくん (@ninjinkun) 2019年4月29日 mozaic bootcampとは? mozaic.fmリスナー向けの勉強会。mozaic.fmはJxck氏が主催するPodcastで、Web標準やブラウザ、プロトコルなどWeb技術をターゲットにしており、自分も愛聴している。 今回行われたbootcampはゴールデンウィークの4日間を使い、「Webを正しく理解し、正しく使う」ことを目的として行われた。 参加者はざっくり言うとそこそこ経験のあるWebエンジニアが6名、主催のJxck氏、mozaic.fmでお馴染みの矢倉氏の計8名。参加にあたってはビデオ通話による選考もあっ

    mozaic bootcampに参加して気づいた、自分に欠けていたWeb技術の知識メモ - ninjinkun's diary
  • どうして JWT をセッションに使っちゃうわけ? - co3k.org

    備考 2018/09/21 22:15 追記 2018/09/20 12:10 に公開した「どうして JWT をセッションに使っちゃうわけ?」というタイトルが不適切だとご指摘をいただいています。 その意見はもっともだと思いますので、現在、適切となるようにタイトルを調整しています。 ご迷惑およびお騒がせをして大変申し訳ございません。 文の表現についても改善の余地は大いにありそうですが、こちらは (すでにご意見を頂戴している関係で、) 主張が変わってしまわないように配慮しつつ慎重に調整させていただくかもしれません。 はあああ〜〜〜〜頼むからこちらも忙しいのでこんなエントリを書かせないでほしい (挨拶)。もしくは僕を暇にしてこういうエントリを書かせるためのプログラマーを募集しています (挨拶)。 JWT (JSON Web Token; RFC 7519) を充分なリスクの見積もりをせずセッシ

  • 「世界最悪のログイン処理コード」を解説してみた

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 概要 ところでこのツイートを見てほしい。このソースコードをどう思う? 世界最悪のログイン処理コード。 実際のサービスで可動していたものだとか……https://t.co/C2bG93ZCkj pic.twitter.com/EfVNAEslrn — はっしー@海外プログラマ🇳🇿元社畜 (@hassy_nz) 2018年8月10日 すごく……セキュリティーホールです…… 一応は動いていますが、あまりに問題がありすぎるため、Twitterでも話題になっていました。 問題点は片手に入り切らないぐらいある気がしますが、一つづつ解説していきま

    「世界最悪のログイン処理コード」を解説してみた
    Makots
    Makots 2018/08/13
    やばくて笑けてくる
  • HTTPSを使ってもCookieの改変は防げないことを実験で試してみた

    寺田さんのブログエントリ「他人のCookieを操作する」には、通信路上の攻撃者がいる場合は、SSLを使っても、Cookieの盗聴を防ぐことはできるが、Cookieの改変を防ぐことはできないと指摘されています。いかにも寺田さんらしい簡にして要を得たエントリで、これに付け加えることはあまりないのですが、残念ながらまだ読んでいない人が多そうだと言うことと、より広い読者に向けて具体的に説明した方がよいだろうと考えました。 そこで、通信路上に攻撃者がいる典型例として、公衆無線LANの偽AP(アクセスポイント)があるケースを題材として、「HTTPSを使ってもCookieの改変は防げない」ことを説明します(Secure属性使うと盗聴は防げますが、改変は防げません)。長いエントリなので結論を先に書いておきます。 Secure属性がないCookieはHTTPSでも盗聴できる Cookieの改変についてはSe

    HTTPSを使ってもCookieの改変は防げないことを実験で試してみた
  • Outbound Port 80 blocking のご提案

    Outbound Port 80 blocking ⽵竹 <takesako@shibuya.pm.org> http://www.janog.gr.jp/meeting/janog31/program/OP80B.html [ ] � MacBook Air ⾏行行 � [ ] � ⾏行行 ⼈人 � [ ] � ⼊入 � [ ] � ⼈人 � [ ] � ⽤用 Google Wireshark ⾯面⼈人 Firesheep � 2010 10⽉月 �Firefox � �Eric Butler⽒氏 � LAN facebook Twitter ⽂文 HTTP Cookie � �PoC⽰示 Firesheep ⾯面 Eric  Butler⽒氏⽤用 Firesheep � Web �Amazon.com CNET dropbox Evernote Facebook Flickr Gith

    Makots
    Makots 2013/01/26
    セッションハイジャックを気にしないhttpだけで良いサイトもあるだろうしISPで遮断するのはやり過ぎな気がするなあ
  • サードパーティCookieの歴史と現状 Part1 前提知識の共有 - 最速転職研究会

    Web開発者のためのサードパーティCookieやらトラッキングやらの問題点について三回ぐらいに分けて書きます。 この文章は個人的に書いていますので、おい、お前のところのサービスがサードパーティCookieに依存してるじゃねーかというツッコミがあるかもしれないが、そういうことを気にしているといつまで経っても公開できないという問題が出てしまうので、そんなことはお構いなしに書く。ちなみに例外なく自社サービスに対してもサードパーティCookieに依存するな死ねと言っている。これはWebプログラマー観点で、自分がサービス開発に関わる上で知っておかねばならないだろう知識として十数年間だらだらとWebを見ていて自然に知っていたものと、あるいは興味を持って率先して調べたものが含まれている。ググッて直ぐに分かる程度の用語の定義的なことは書かない。あくまでWebサイト制作者側からの観点なので、ブラウザ開発関係

    サードパーティCookieの歴史と現状 Part1 前提知識の共有 - 最速転職研究会
  • 「欠陥ドメイン名」が世界的に増えそうな件について:Geekなぺーじ

    JPRSが「JPRSが、地域に根ざした新たなドメイン名空間「都道府県型JPドメイン名」の新設を決定」というプレスリリースを出しましたが、それに対して高木浩光氏から問題提起及び公開質問状のが行われました。 さらに、徳丸浩氏が、実際にcookieで問題が発生することを検証されていました。 高木浩光@自宅の日記: JPRSに対する都道府県型JPドメイン名新設に係る公開質問 徳丸浩の日記: 都道府県型JPドメインがCookieに及ぼす影響の調査 高木浩光氏が以下のように述べられています。 何もしなければ、「都道府県型JPドメイン名」の登録が始まっても、cookieを利用できないなどの欠陥ドメイン名となることが予想される。 「都道府県型JPドメイン名」が開始されるにあたって、指摘されているような問題は実際に発生すると思われるので、JPRSが公開質問状に答えることを期待したいところです。 で、今回のこ

  • 「安全なWebアプリケーションの作り方」を読んでセッションを復習してみた - As a Futurist...

    タイトルが長くて略称があれば知りたい感じの「安全な Web アプリケーションの作り方」を暇を見つけて読んでいます。今まであいまいなままだった部分を順を追って説明してくれるので、当に助かります。Web アプリ作りの初心者は卒業したかなーという人は必ず目を通しておくと良いと思います。 Cookie を用いたセッションについて復習 「HTTP はステートレスで」とかいう話はよく聞きますが、じゃあどうやってセッション管理するのがいいの?って話をよく考えると体系的に聞いたことがなかった!というわけで、こので文字通り体系的に学び直すことができました。 その中でも、「セッション ID の固定化」という話題はちゃんと分かってなかった部分があったので、こちらのサイトを参考に PSGI なアプリケーションを作ってみました(僕の書いたアプリ自体はその他の脆弱性に溢れていますがw)。コードはエントリの最後に。

    「安全なWebアプリケーションの作り方」を読んでセッションを復習してみた - As a Futurist...
  • ユーザーが制御できない「秘密cookie」、半数強のサイトが利用

    米研究チームの発表によると、Adobe Flashを使ってネット上のユーザーの行動をひそかに追跡し続けるサイトが増えているという。 Adobe Flashを使ってネット上のユーザーの行動を追跡し続ける「秘密cookie」を利用するサイトが増えているという。米カリフォルニア大学バークリー校などの研究チームがこのほど論文を発表した。 「Flash cookie」は通常のcookieとは異なり、ブラウザのセキュリティ設定ではコントロールできないという。研究チームが大手サイトによる同cookieの利用実態について調べたところ、調査対象としたサイトの半数以上がFlash cookieを使ってユーザー情報を保存していることが判明した。 中にはユーザーが削除したHTTP cookieを、Flash cookieを使って復活させているケースもあった。しかしその存在についてはサイトのプライバシーポリシーでも

    ユーザーが制御できない「秘密cookie」、半数強のサイトが利用
  • 第1回 まずは「クッキー」を理解すべし

    この記事は会員登録で続きをご覧いただけます申込は簡単3分! 今すぐ会員登録(無料) 会員の方はこちら 有料会員(月額プラン)は初月無料! 詳しくはこちら ▼日経クロステック有料会員になると… オリジナル記事がすべて読める 専門雑誌7誌の記事も読み放題 雑誌PDFを月100ページダウンロードできる

    第1回 まずは「クッキー」を理解すべし
  • 1