HTTPSを使ってもCookieの改変は防げないことを実験で試してみた
寺田さんのブログエントリ「他人のCookieを操作する」には、通信路上の攻撃者がいる場合は、SSLを使っても、Cookieの盗聴を防ぐことはできるが、Cookieの改変を防ぐことはできないと指摘されています。いかにも寺田さんらしい簡にして要を得たエントリで、これに付け加えることはあまりないのですが、残念ながらまだ読んでいない人が多そうだと言うことと、より広い読者に向けて具体的に説明した方がよいだろうと考えました。 そこで、通信路上に攻撃者がいる典型例として、公衆無線LANの偽AP（アクセスポイント）があるケースを題材として、「HTTPSを使ってもCookieの改変は防げない」ことを説明します（Secure属性使うと盗聴は防げますが、改変は防げません）。長いエントリなので結論を先に書いておきます。 Secure属性がないCookieはHTTPSでも盗聴できる Cookieの改変についてはSe
SSRF対策としてAmazonから発表されたIMDSv2の効果と限界
サマリ Capital OneからのSSRF攻撃による大規模な情報漏えい等をうけて、Amazonはインスタンスメタデータに対する保護策としてInstance Metadata Service (IMDSv2) を発表した。本稿では、IMDSv2が生まれた背景、使い方、効果、限界を説明した上で、SSRF対策におけるIMDSv2の位置づけについて説明する。 SSRFとは SSRFは、下図のように「外部から直接アクセスできないエンドポイント」に対して、公開サーバーなどを踏み台としてアクセスする攻撃方法です。SSRF(Server Side Request Forgery)の詳細については過去記事「SSRF(Server Side Request Forgery)徹底入門」を参照ください。 最終的な攻撃目標は多様ですが、近年問題になっているのが、クラウドサービスのインスタンス・メタデータを取得する
徳丸浩の日記: ECサイトからクレジットカード情報を盗み出す新たな手口
エグゼクティブサマリ 聖教新聞社が運営する通販サイト「SOKAオンラインストア」から2,481件のクレジットカード情報が漏洩した。リリースによると、漏洩に使われた手口は従来とは異なるもので、改正割賦販売法の実務上のガイドラインである「クレジットカード情報非保持化」では対策できないものであった。 はじめに 今年の9月4日に聖教新聞社の通販サイトSOKAオンラインストアからクレジットカード情報漏洩の可能性がリリースされました。以下は聖教新聞社から運営委託されているトランスコスモス株式会社のリリースです。 「ＳＯＫＡオンラインストア」の件 このたび、弊社が聖教新聞社様より運営を委託されている「ＳＯＫＡオンラインストア」において、クレジットカード情報を入力して商品をご注文いただいた一部のお客さまのクレジットカード情報が、第三者によって不正に取得された可能性があることが発覚い たしました。 http
GodaddyのSSL証明書にドメイン認証の脆弱性があり8850件の証明書が失効された
エグゼクティブサマリ GoDaddy社の発行するドメイン認証SSL証明書に認証不備の脆弱性があり、予防的な処置として8850件の発行済証明書が失効された。これは同期間に発行された証明書の2%未満である。現在は脆弱性は解消されている。 概要 GoDaddy社は米国のホスティング（レンタルサーバー）やレジストラの大手で、認証局（CA）の事業も手がけています。 GoDaddyが発行するドメイン認証証明書の認証手続きに不備があったとして報告されています。 In a typical process, when a certificate authority, like GoDaddy, validates a domain name for an SSL certificate, they provide a random code to the customer and ask them to p
JALの不正ログイン事件について徳丸さんに聞いてみた
高橋: こんにちは、高橋です。今日は徳丸さんをお招きして、JALの不正ログイン事件についてお話を伺います。徳丸さん、よろしくお願いします。 徳丸: 徳丸です。よろしくお願いします。 高橋: まず、事件の概要を説明します。日本航空のホームページに不正アクセスがあり、JALマイレージバンク（JMB）のマイルが、Amazonのギフト券に勝手に交換される被害がありました。日本航空の発表では、1月31日から2月2日にかけて、身に覚えがないマイル交換がされているという問い合わせが複数ありました。調査の結果、40人の利用者のマイルがアマゾンのギフト券、数百万円相当と交換されていたというものです。 徳丸: ここで問題となるのは、パスワードは数字6桁ということなんですよね。 高橋: やはりそこですか。パスワードが数字6桁だとどのような攻撃ができるのでしょうか? ブルートフォース攻撃 徳丸: まず、ブルートフ
パスワード攻撃に対抗するWebサイト側セキュリティ強化策
Webサイトのパスワード認証を狙った攻撃が大きな脅威になっています。 Tサイト（プレスリリース） goo（プレスリリース） フレッツ光メンバーズクラブ（プレスリリース） eBook Japan（プレスリリース） My JR-EAST（プレスリリース） これらの事例のうちいくつか（あるいは全て）は、別のサイトで漏洩したIDとパスワードの一覧表を用いた「パスワードリスト攻撃（後述）」であると考えられています。パスワードリスト攻撃を含めて、パスワードを狙った攻撃が成立してしまう原因は、利用者のパスワード管理に問題がある場合が多く、攻撃を受けたWebサイト側には、直接の責任はないケースが多いと考えられます。 しかしながら、 大半の利用者はパスワード管理に興味がない パスワード認証を採用している理由は、コスト上の理由、すなわちサイト側の経済的な事情 インターネットが「とても危険なもの」となるとネット
Time-based SQL Injectionは意外に実用的だった
このエントリでは、Time-based SQLインジェクション、すなわち時間差を利用したSQLインジェクションが意外に実用的だったという報告をします。デモ映像ありです。 はじめに Time-based SQL Injectionという攻撃があります。これはブラインドSQLインジェクションの一種で、ある条件の場合に一定時間（例えば5秒）スリープし、そうでない時との応答時間の差で情報を盗もうというものです。1回のHTTPリクエストで1ビットの情報が得られるので、それを積み重ねることによって、いくらでも情報を盗めるはずです…理論的には。 しかし、「理屈はそうでも、時間が掛かりすぎるよね」ということで、深くは追っかけていませんでした。SQLインジェクションの検査には有効でも、悪用としての実用性はあまりないと考えていたのです。 きっかけ きっかけは、以下のYahoo!知恵袋に以下の質問です。 SQL
正規表現によるバリデーションでは ^ と $ ではなく \A と \z を使おう
正規表現によるバリデーション等で、完全一致を示す目的で ^ と $ を用いる方法が一般的ですが、正しくは \A と \z を用いる必要があります。Rubyの場合 ^ と $ を使って完全一致のバリデーションを行うと脆弱性が入りやすいワナとなります。PerlやPHPの場合は、Ruby程ではありませんが不具合が生じるので \A と \z を使うようにしましょう。 はじめに 大垣さんのブログエントリ「PHPer向け、Ruby/Railsの落とし穴」には、Rubyの落とし穴として、完全一致検索の指定として、正規表現の ^ と $ を指定する例が、Ruby on Rails Security Guideからの引用として紹介されています。以下の正規表現は、XSS対策として、httpスキームあるいはhttpsスキームのURLのみを許可する正規表現のつもりです。 /^https?:\/\/[^\n]+$/
難読化していないAndroidアプリケーションは脆弱性か
このエントリでは、Androidアプリケーションにおいて、難読化が施されていない場合、脆弱性にあたるかについて議論します。 はじめに Androidアプリケーションは主にJava言語で記述され、DEX形式のファイルにコンパイルされたコードを、DalvikというJava互換VM上で実行します。DEXおよびAPKファイルの仕様は公開されており、DEXにはクラスやメソッド等のシンボル名も含まれているため、リバースエンジニアリングが容易であると言われています。このため、Android SDKには標準でProGuardという難読化ツールが添付されています。 それでは、難読化の目的はそもそも何で、難読化でその目的は達成されるのでしょうか。 難読化の目的 Webアプリケーションの場合は、重要なロジックは主にサーバー側に存在するため、ソースコードを外部から取得することはできません。これに対して、スマートフ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
