はじめに セキュリティエンジニアの齋藤ことazaraです。今回は、不可思議なContent-Typeの値と、クラウド時代でのセキュリティリスクについてお話しします。 本ブログは、2024 年 3 月 30 日に開催された BSides Tokyo で登壇した際の発表について、まとめたものです。 また、ブログ資料化にあたり、Content-Type の動作や仕様にフォーカスした形で再編を行い、登壇時に口頭で補足した内容の追記、必要に応じた補足を行なっています。 また、本ブログで解説をする BSides Tokyoでの発表のもう一つの題である、オブジェクトストレージについては、以下のブログから確認をすることが可能ですので、ご覧ください。 blog.flatt.tech なぜ今、この問題を取り上げるのか？ 従来のファイルアップロードにおいて、Content-Type の値を任意の値に設定すること

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

このエントリでは、Time-based SQLインジェクション、すなわち時間差を利用したSQLインジェクションが意外に実用的だったという報告をします。デモ映像ありです。 はじめに Time-based SQL Injectionという攻撃があります。これはブラインドSQLインジェクションの一種で、ある条件の場合に一定時間（例えば5秒）スリープし、そうでない時との応答時間の差で情報を盗もうというものです。1回のHTTPリクエストで1ビットの情報が得られるので、それを積み重ねることによって、いくらでも情報を盗めるはずです…理論的には。 しかし、「理屈はそうでも、時間が掛かりすぎるよね」ということで、深くは追っかけていませんでした。SQLインジェクションの検査には有効でも、悪用としての実用性はあまりないと考えていたのです。 きっかけ きっかけは、以下のYahoo!知恵袋に以下の質問です。 SQL

PHPerKaigi 2024 • Day 1での登壇資料です。 https://phperkaigi.jp/2024/ https://fortee.jp/phperkaigi-2024/proposal/0d0f8507-0a53-46f6-bca6-23386d78f17f ※ Authorizationヘッダーを利用したBearerトークン等の活用については言及していません。

Cross Origin の時の Cookie 送信 Cross Origin の場合は CORS 関連のヘッダを設定し、 fetch 関数であれば credentials オプションに include を設定しないと Cookie は送信されません Cross Site の場合はさらに SameSite 属性に None を設定する必要があります SameSiteに設定する値 Same Site に設定できる値は Strict, Lax(デフォルト), None の3種類あります。 Cross Site リクエスト時に Strict だと Cookie は送信されません。None であれば Cookie が送信されます デフォルトである Lax だとトップレベルナビゲーションの時のみ Cookie を送信します。トップレベルナビゲーションとは、WEBブラウザのURLバーのURLと、表示さ

はじめに Cookie の安全な設定について調べていると登場する SameSite 属性は、Google Chrome の仕様変更の話もあり、耳にしたことがある方も少なくないと思います。 Cookie には SameSite 属性と間違えやすい設定として Domain 属性もあり、片方だけ設定すればいいのか、どう使い分けるものなのかが一見分かりにくいのではないでしょうか。 結論 結論としては、Cookie の Domain 属性は送信「先」の制限、SameSite は送信「元」の制限という違いです。 Domain 属性は Cookie を送る先を設定するもので、誤って設定すると第三者のサイトに Cookie を送信することになり、セッションハイジャックが発生する可能性があります。 SameSite 属性は Cookie を送信するもとになるサイトを指定する属性で、CSRF 攻撃に対するいく

SPF レコードで許可されている IPアドレスの実態がクラウドやプロキシ等の共用サービスのものであるケースは多く、それらの IPアドレスが第三者によって利用できる可能性があることを悪用し、SPF 認証を pass、結果的に DMARC 認証まで pass して詐称メールを送信できてしまうことを指摘した論文が公開されています。 この論文では、上記のような SPF の脆弱な展開に対する攻撃手法を BreakSPF と呼び、関連するプロトコルや基盤の実装に対する分析と共に、その内容が体系的にまとめられています。 本記事では、その論文を参照しながら、簡単に概要をまとめておきます。 補足事項 (2024/3/5) 本記事につきまして、(当サイトとしては) 多くのアクセスいただいているようで (ちょっとビビってま) す。まことに大変ありがたいことに色々とシェアいただいたりしたようです。 そこで、記事の

RFC9460が出ました 昨年、このエンジニアブログでHTTPSレコードについてとりあげました。これを書いたときはHTTPSレコードはまだインターネットドラフトだったのですが、2023年11月、ついにRFC9460として標準化されました。 RFCにはなったけど日本語の詳しい記事はまだ少ないし需要あるかなーと思って改めて解説を書きはじめたんですが、だらだらとクソ長くなって書いた本人が読んでも眠くて退屈な内容になってしまいました。ので、書いたものはばっさり捨てました。 そういえばいまから3年前、DNS Summer Day 2021で発表したプレゼン資料がありました。これをRFCになった現在の内容にあわせてアップデートしたほうがてっとりばやいしわかりやすそうです。 ということで、加筆修正した資料を置いておきます。DNS屋さんはとりあえず全部読んでおいてください。Web屋さんは前半だけ理解してお

しばたです。 昨年10月にGoogle(Gmail)および米国Yahoo!においてスパム対策の強化がアナウンスされました。 この件に関してつい先日まで他人事でいたのですが、実は全然他人事では済まないことが発覚し突貫で知識を仕入れています。 アナウンスに対する具体的な対応策についてはこちらのZennの記事を見れば全部わかる感じです。 最高ですね。 また、メール送信にAmazon SESを使っている場合はAWSのブログを確認すると良いでしょう。 「これらの記事を読み解けば万事解決！」という感じではあるのですが、私自身が学んだなかで予め知っておくと良さそうに思えた点がいくつかありました。 本記事ではその辺を共有するのと、実際にAmazon SESの環境を作って動作確認をしたのでその結果も合わせて共有します。 はじめに覚えておくと良い基礎知識 Zennの記事でも詳細な解説がありますが、個人的に「最

なぜセキュリティグループで0.0.0.0/0からのインバウンドトラフィックを許可することが危険なのか？ はじめに こんにちは！AWS事業本部コンサルティング部の和田響です。 この記事では「なぜセキュリティグループで0.0.0.0/0からのインバウンドトラフィックを許可することが危険なのか？」について説明し、具体的な対策と検知の方法について記載します。 0.0.0.0/0からのトラフィックとは？ 0.0.0.0/0は、IPアドレスの範囲を指定するCIDR（Classless Inter-Domain Routing）表記の一つで、IPv4アドレス空間におけるすべてのIPアドレスを意味します。 つまり「0.0.0.0/0からのトラフィック」とはすべてのIPからの通信であり、インターネットのあらゆる場所からの通信と言い換えることもできます。(IPv6の場合は::/0と表記します。) なぜ危険なの

100m先からQRコードに“肉眼で見えない”レーザーを当て偽物にする攻撃　読み込むと悪性サイトへ：Innovative Tech 東海大学に所属する研究者らは、最大100m離れた場所からQRコードに不可視光レーザーを照射し、偽装QRコードに変更する手法を提案する研究報告を発表した。ユーザーが攻撃中のQRコードをスキャンすると、悪性サイトへ誘導されるリスクがある。

2023年10月24日、東京大学は教員が使用していたPCがマルウエアに感染し、PC上に保管されていた情報が外部に流出した可能性があると公表しました。ここでは関連する情報をまとめます。 教員が在宅勤務で使用していたPCで被害 被害に遭ったのは東京大学大学院総合文化研究科・教養学部の教員（教授）で、在宅勤務で使用していたPCがマルウエアに感染していた。*1 大学が被害を覚知したのは、「標的型攻撃メールの事案を調査していた専門機関」からの指摘を受けたため。感染判明後に端末の調査を指摘をした機関と別の専門機関で調査をしたところ、PC内部の情報を盗み取った痕跡が確認された。 偽の講演の日程調整をやり取りする中でマルウエア感染 やり取り型の標的型攻撃のメールを通じて教員が使用してたPCがマルウエアに感染した。実在する組織の担当者を騙る人物から講演依頼のメールを受信し、日程調整のために教員がやり取りして

「GitHub Copilot 導入時に考えたセキュリティのあれこれ」というタイトルで登壇したのは、freee株式会社のただただし氏。タイミー社主催の「GitHub Copilotで拓く開発生産性」で、「GitHub Copilot 」を全社一斉導入する際に考えるべきセキュリティリスクについて発表しました。 freee株式会社 PSIRT マネージャーのただただし氏 ただただし氏：freee株式会社のただただしと申します。 今日は、「GitHub Copilot 導入時に考えたセキュリティのあれこれ」ということで、Copilotのセキュリティリスクについて語るわけですが、考えてみたら、GitHubの中の人を前にこんなことをしゃべるのは相当大胆な話だと思います。最後にいいことで締めるのでちょっと我慢してください。 自己紹介をいたします。ただただしと申します。PSIRTという組織でマネージャー

3Dセキュアとは不正利用を防止する本人認証サービスで、お客様がオンラインでも安心して買い物を楽しめるよう、全ネットショップ事業者に対して導入が求められています。この記事では3Dセキュアの導入を検討している事業者に向けて、3Dセキュアの仕組みや、「3Dセキュア2.0」と「3Dセキュア1.0」との違い、導入のメリット、注意点などを解説します。 目次 3Dセキュアとは 「3Dセキュア1.0」と「3Dセキュア2.0」の違い 事業者が3Dセキュアを導入するメリット 3Dセキュアの注意点 事業者がクレジットカードの不正利用を防ぐ方法 3Dセキュアとは 3Dセキュアとは、オンライン上でクレジットカード決済をする際に用いられる本人認証サービスで、不正利用（※）の防止を目的としたものです。 ※不正利用とは第三者が何かしらの方法でクレジットカード情報を盗み取り、悪用する犯罪行為で、「フィッシング詐欺」や「スキ

画像：警察庁より引用 警察庁はこのほど、企業や団体の潜在的脅威となっているランサムウェア問題について、新たな手口「ノーウェアランサム」の広がりを発表しました。 ランサムウェアは主に法人をターゲットにしたマルウェアの一種で、感染したサーバーデータを暗号化（≒利用できなくなる）したり、流出情報の公開や、情報を人質に金銭の要求することで知られています。ところが、警察庁が新たに「ノーウェアランサム」と名付けた攻撃は暗号化をしないまま情報を盗み出し、金銭を要求する手口とのことです。 ノーウェアランサム攻撃は、暗号化が生じず通常より脅威度の低い攻撃に見えます。しかし、攻撃者の視点では余分な処理が生じず手軽であるうえ、情報を人質にした脅迫は可能であり、個人情報や機密情報を人質にした要求行為は可能です。依然として脅威度は高いと見られます。 警察庁によるとノーウェアランサムの被害は本年度中に6件ほど確認され

Amazon の 2段階認証(2SV)が突破された？ Amazon の 2段階認証(2SV) が突破されたのではないかという件が話題になっています。 私もこれについてはとても気になっており、できるだけ早く真相が解明されることを願っています。 そこで、ふと疑問に感じたことが、2SV は何をどの程度防いでくれるのかということです。 ここでは、Amazon を例に、いろんなことを考えていきたいと思います。 フィッシングの前には無力 まず、2SVの突破と言っても様々な手口があります。 徳丸先生の動画が示す通り、中継型フィッシングであれば、自ら正しい認証情報を入力することになるので、2SVを設定していようがいまいが突破されてしまいます。 フィッシングではなく、かつ、TOTPでも突破されたケースも 今回の被害者には、中間者攻撃やフィッシングを受ける状態になかったと仰っている方がいました。 なので、何か

pictBLandとpictSQUAREに対する不正アクセスがあり、パスワードがソルトなしのMD5ハッシュで保存されていたことが話題になっています。 2023年8月16日に外部のフォーラムにpictSQUAREより窃取した情報と主張するデータ販売の取引を持ち掛ける投稿が行われた（中略）パスワードはMD5によるハッシュ化は行われているもののソルト付与は行われていなかったため、単純なパスワードが使用されていた29万4512件は元の文字列が判明していると投稿。（それ以外の26万8172件はまだMD5ハッシュ化されたままと説明。） 不正アクセスによるpictBLand、pictSQUAREの情報流出の可能性についてまとめてみた - piyolog より引用 これに関連してMD5ハッシュやソルトに関するツイート(post)を観察したところ、どうもソルトの理解が間違っている方が多いような気がしました。