HTTPSを使ってもCookieの改変は防げないことを実験で試してみた
寺田さんのブログエントリ「他人のCookieを操作する」には、通信路上の攻撃者がいる場合は、SSLを使っても、Cookieの盗聴を防ぐことはできるが、Cookieの改変を防ぐことはできないと指摘されています。いかにも寺田さんらしい簡にして要を得たエントリで、これに付け加えることはあまりないのですが、残念ながらまだ読んでいない人が多そうだと言うことと、より広い読者に向けて具体的に説明した方がよいだろうと考えました。 そこで、通信路上に攻撃者がいる典型例として、公衆無線LANの偽AP（アクセスポイント）があるケースを題材として、「HTTPSを使ってもCookieの改変は防げない」ことを説明します（Secure属性使うと盗聴は防げますが、改変は防げません）。長いエントリなので結論を先に書いておきます。 Secure属性がないCookieはHTTPSでも盗聴できる Cookieの改変についてはSe
非技術者のためのOAuth認証(?)とOpenIDの違い入門【2023年版】
昔から、「OpenIDは認証でOAuthは認可だ」などということが言われます。しかし、その言語の意味を取り違えている方が結構多い気がしています。「もうOpenIDなんていらね。OAuthだけでいいじゃん」というような言説がよく流れてくるのがその証拠だと思います。OAuth認証というのもその類ですね。 そこで、今日はOAuthとOpenIDの違いを考えてみたいと思います。 Youtube版 OpenIDは紹介状、OAuthは合鍵 まずはOpenIDの概要の復習です。「OpenIDは認証」という言葉の内容をまずは復習してみましょう。 「認証」とは大変広い言葉でいろいろな場面で使われますが、「OpenIDは認証」という使い方の時は、「OpenIDは、いま来ている人の身元を認証」（ユーザ認証）という意味です。図にすると図1のような流れになります。 この例では、有栖さんがお客としてサービス提供をして
単なる OAuth 2.0 を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる
In some of the feedback I have gotten on the openID Connect spec, the statement is made that Connect is too complicated. That OAuth 2.0 is all you need to do authentication. Many point to Identity Pro… 英語読みたくないという人のために簡単に解説すると… OAuth 2.0 の implicit flow を使って「認証」をしようとすると、とっても大きな穴が開きます。 カット＆ペーストアタックが可能だからです。 OAuth 認証？は、図１のような流れになります。 図１ OAuth 認証？の流れ 一見、問題なさそうに見えます。しかし、それはすべてのサイトが「良いサイト」ならばです。 Site_A
ApacheのVirtualHostによる高集積Webホスティングでsymlink問題を根本解決する方法について考えた
人間とウェブの未来（旧） 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 最近、各所でApacheのVirtualHostを利用した高集積ホスティングのセキュリティに関するインシデントが起きています。僕自身、自分の専門の一つがWebサーバのセキュリティなので、他人事には思えず、毎日各所の経過情報を眺めています。また、数社からApacheのセキュリティに関してもいくつか質問を受けたりしており、公に話せるような内容はこのブログでも公開していきたいと思います。 ということで、ApacheのVirtualHostによる高集積Webホスティングにおけるsymlink問題を根本解決するにはどうしたら良いのかを考えました。まずは、静的コンテンツも動的コンテンツのようにファイルのユーザ権限で処理する方法から紹介します。その後、ホス
SQLインジェクション対策:偽プリペアドステートメントに注意 | beroの日記 | スラド
SQLインジェクションについて書くときに以下のメッセージを必ず含めて欲しいです。 -単にプリペアドステートメントを使え -絶対に文字列結合でSQLを構築しようとしてはいけない -IPAの「安全なSQLの呼び出し方」を読むこと とあるが、 - 本物のプリペアドステートメントであることを確かめる を付け加えたい。(まあ『IPAの「安全なSQLの呼び出し方」を読むこと』を守れば、そこに書いていることではあるが) IPA本では本物のプリペアドステートメントを「静的プレースホルダ」偽物（エミュレーション）を「動的プレースホルダ」と呼んでいるが、 後者はプリペアドステートメントぽい記述をライブラリ内で文字列結合してSQLを構築している。 偽プリペアドステートメントも無意味ではない。 少なくとも自前で文字列連結するのに比べ、単純なバグやエスケープ忘れは無くなる（ことが期待できる）。 しかし文字コードの違
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
