背景 近年、企業システムに対するサイバー攻撃は多様化・高度化しており、企業は日々新たな脅威への対応を迫られています。さらに、脆弱性の発見件数も年々増加傾向にあり、システムのリリース前後を問わず、潜在的な脆弱性をいかに早期に発見し適切に対策を講じるかが、事業継続や信頼性維持の観点からますます重要になっています。 一方で、脆弱性診断については多くの企業が外部ベンダーへ発注するケースが一般的ですが、脆弱性の増加やリリースサイクルの高速化により対応しきれないケースが増えつつあり、内製化への関心も高まっています。 こうした背景を踏まえ、当プロジェクトでは「脆弱性診断内製化ガイド」を作成しました。ガイドの作成にあたり、まず複数のツールを用いた技術検証で脆弱性診断の概要や概念、自動・手動診断の違いを整理し、それぞれの特性や有効性を明らかにしました。そのうえで、文献調査やアンケート、有識者・内製企業へのヒ
徳丸さんは好きな脆弱性はありますか？ 私はクリックジャッキングです。 初めて脆弱性を学習したとき、透明化したページを重ねてユーザーに意図しない処理を実行するメカニズムに感動した覚えがあります。 （こういうやり方があるのか、みたいな感じでした。）
こんにちは、富士榮です。 ちょっと前に某所でダメダメな認証系の技術実装ってなんだろうねぇ、、という話をしていたことをXで呟いたところ、色々とご意見を頂けましたのでまとめて書いておきます。
NTTドコモのサービスだったドコモ口座のドメイン名docomokouza.jpがドメイン名オークションにかけられて402万円という高値で落札されて話題になっています。 「ドコモ口座」のドメイン、落札される 402万円で - ITmedia NEWS まだ金融機関などから当該ドメインへのリンクなどが残っているので、フィッシングや詐欺サイトなどに悪用される懸念が表明されているところではありますが、この記事では、ドメイン名オークションの仕組みについて説明します。 ドメイン名のライフサイクルたまたま同時期に、EPARKの関連会社アイフラッグが運営していたsweetsguide.jpがオークションにかけられ、Srgr0さんがブログで時系列の説明をされているので引用します。時系列的には今回のdocomokouza.jpも同じだと思われます。 今回の流れ ・2023年05月08日 サイト閉鎖のリリース
2023年8月15日、GMWは同社が運営するサービスが不正アクセスを受けたことで、「pictBLand」及び「pictSQUARE」のデータベース情報が外部へ流出した可能性があると公表しました。また当該サービスのWebサイトを閲覧した際に別のサイトへ接続する状態になっていたことも明らかにしています。ここでは関連する情報をまとめます。 累計130万人登録のSNSに不正アクセス GMWが運営するサービスが不正アクセスを受け、pictBLandのサイトが一時改ざんされた他、データベース情報が外部に流出した可能性がある。サービスの累計登録者数は約130万人で、今回の不正アクセスによる影響を受けたアカウントの件数は約80万件。*1 不正アクセスとの関連があったとみられる事象が複数確認されており、それらは以下の通り。今後デジタルフォレンジックを行う企業へ調査を依頼することで影響範囲の特定を行うとしてお
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? pictBLandとpictSQUAREに対する不正アクセスがあり、パスワードがソルトなしのMD5ハッシュで保存されていたことが話題になっています。 2023年8月16日に外部のフォーラムにpictSQUAREより窃取した情報と主張するデータ販売の取引を持ち掛ける投稿が行われた（中略）パスワードはMD5によるハッシュ化は行われているもののソルト付与は行われていなかったため、単純なパスワードが使用されていた29万4512件は元の文字列が判明していると投稿。（それ以外の26万8172件はまだMD5ハッシュ化されたままと説明。） 不正アクセス
note_vuln.md noteの独自ドメインセッションの脆弱性について報告した件 文責: mala 前置き note.com (以下note) に2020年に報告した脆弱性(現在は修正済み)を解説する 個人の活動として行っており所属組織とは関係がない 自分がnote社に対して、問題があると指摘していたのは主に広報対応についてですが、この記事は技術的な知見を共有することを目的とするため、技術的な解説を中心にします。 公開にあたってはnote社に対して確認の上で行っています。note社による修正対応は2021年までに実施されていますが、その修正内容が適切であるかどうかについて保証するものではありません。(網羅的な確認や追加の検証をしていません) note社のサービスに他の脆弱性が無いことを保証するものではありません。 経緯 2020年9月30日に公開されたnote社の記事で https:/
はじめに こんにちは。株式会社Flatt Security セキュリティエンジニアの石川です。 本稿では、ログイン機能をもつWebアプリケーションにおける実装上の注意を、マイページ機能から派生する機能のセキュリティ観点から記載していきます。特に、XSS（Cross-Site Scripting）やSQLインジェクションのような典型的な脆弱性と比較して語られることの少ない「仕様の脆弱性」にフォーカスしていきます。 これから述べる実装上の注意点は、実際にはマイページ機能であるかどうかに関係なく注意するべきです。 しかし、開発者の視点に立つと「これこれの機能にはどのようなセキュリティ観点があるか」という形が読みやすく、また他の機能の仕様のセキュリティを考える上で想像力を働かせやすいものになるのではないでしょうか。 また、株式会社Flatt Securityではお客様のプロダクトに脆弱性がないか専
こんにちは。株式会社 Flatt Security セキュリティエンジニアの梅内(@Sz4rny)です。 本記事では、主にFirebaseの概要やセキュリティルールを用いた堅牢なCloud Firestore環境の構築について説明します。本記事を読むことで、Firebaseに関する基礎知識やデータベースにおけるセキュリティ上の懸念事項について理解するとともに、セキュリティルールを用いて堅牢なCloud Firestore環境を構築するための初歩を身につけることができるでしょう。 また、Flatt Securityでは開発/運用中のプロダクトにおいて、Firebaseをセキュアに活用できているか診断することも可能です。 Firebase を用いた開発におけるセキュリティ上の懸念事項が気になる場合や、実際に診断について相談したいという場合は、ぜひ下記バナーからお問い合わせください。 Fireb
画像出典: https://www.ipa.go.jp/files/000017316.pdf こんにちは。株式会社Flatt Security セキュリティエンジニアの奥山です。 本稿では、独立行政法人 情報処理推進機構(以下、IPA)が公開している資料「安全なウェブサイトの作り方」を紹介します。 「安全なウェブサイトの作り方」は、無料で公開されているにも関わらず、Webセキュリティを学ぶ上で非常に有用な資料です。これからWeb開発やセキュリティを勉強したいと考えている方はもちろん、まだ読んだことのない開発者の方々にも、ぜひ一度目を通していただけたらと思います。 一方、「安全なウェブサイトの作り方」では、一部にモダンなアプリケーションには最適化されていない情報や対象としていない範囲が存在します。それらについても本記事で一部、触れていきたいと考えていますので、資料を読む際の参考にしていただ
情報処理推進機構（IPA）は3月10日、2021年に起きた情報セキュリティ事案を基に、社会的影響の大きさをまとめたランキング「情報セキュリティ10大脅威2022」について、ランクインした脅威の動向や対策をまとめた資料を公開した。ランサムウェアや標的型攻撃、フィッシング詐欺といった脅威の特徴や手口を、約60ページに渡って解説している。 情報セキュリティ10大脅威2022はIPAが1月に策定。組織向けTOP10と個人向けTOP10で2つランキングを公開しており、組織向けでは「ランサムウェア」「標的型攻撃」「サプライチェーン攻撃」などが、個人向けでは「フィッシング詐欺」「ネット上での中傷やデマ」「メールやSMSを使った詐欺・脅迫」などが上位に入った。 今回公開したのは、2月に公開した個人向けTOP10の解説資料に、組織向けTOP10の解説を加えて編集し直したもの。追記部分では、組織向けTOP10
2022年2月28日、メタップスペイメントは決済情報などが格納されたデータベースへ不正アクセスが行われクレジットカードを含む情報流出が判明したと公表しました。ここでは関連する情報をまとめます。 複合的な攻撃を半年間受ける 不正利用懸念ありと連絡を受けたのはメタップスペイメントのイベントペイで2021年12月17日にクレジットカード決済を停止。さらに会費ペイを含む3サイトは2022年1月5日までにクレジットカードの新規決済を停止。その後2022年1月24日にバックドアの存在が確認されたことから、トークン方式のクレジット決済サービスを全て停止した。 攻撃を受けていたのは2021年8月2日から2022年1月25日の約6カ月。2021年12月14日にクレジットカード会社から連絡受領しその後調査するも自社での原因特定ができず外部機関でフォレンジック調査を実施。 不正アクセスはメタップスペイメントの決
先日、このようなツイートを書いたところ、かなりの反響がありました。 JavaScript の正規表現の脆弱性の例でいうと、例えば /\s+$/ は脆弱性があると言える console.time(); /\s+$/.test(" ".repeat(65536) + "a"); console.timeEnd(); 結構時間がかかるのがわかる。でも /\s+$/ を見て「これは危険だな」と理解出来る人はそんなにいない。JavaScript に限らないけれど。 — Takuo Kihira (@tkihira) February 17, 2022 これは一般に ReDoS (Regular expression Denial of Service) と呼ばれる脆弱性です。正確に理解するのが難しい脆弱性なので、少し解説してみたいと思います。 結論 長い記事になるので、最初に「とりあえずこれだけ知っ
※本記事は筆者styprが英語で執筆した記事を株式会社Flatt Security社内で日本語に翻訳したものになります。 TL;DR Node.jsのエコシステムで最も人気のあるMySQLパッケージの一つである mysqljs/mysql (https://github.com/mysqljs/mysql)において、クエリのエスケープ関数の予期せぬ動作がSQLインジェクションを引き起こす可能性があることが判明しました。 通常、クエリのエスケープ関数やプレースホルダはSQLインジェクションを防ぐことが知られています。しかし、mysqljs/mysql は、値の種類によってエスケープ方法が異なることが知られており、攻撃者が異なる値の種類でパラメータを渡すと、最終的に予期せぬ動作を引き起こす可能性があります。予期せぬ動作とは、バグのような動作やSQLインジェクションなどです。 ほぼすべてのオンラ
以下のツイートを読んで気持ちが昂ったので。 みんな、もうSNSでいがみ合うのはやめよう。 平和に好きなJWTの話でもしようよ。 JWTの格納場所はlocalStorageとCookieのどっちが好き？— 徳丸 浩 (@ockeghem) 2022年2月11日 というのも、JWTをセッションに使うときに保存先含めて一時期悩んでいたので、その時の自分の解。 ただ、考えるたびに変化しているので、変わるのかもしれない。 要約 タイトル。 あとは優秀な方々が既に色々考えておられるのでそちらを読むとよいでしょう。 SPAセキュリティ入門～PHP Conference Japan 2021 JWT カテゴリーの記事一覧 - r-weblife どうしてリスクアセスメントせずに JWT をセッションに使っちゃうわけ？ - co3k.org JWT形式を採用したChatWorkのアクセストークンについて -
はじめに こんにちは。事業推進部でOffensive Teamを担当する永井です。 先日のApple発表会では新型のiPhoneやApple Watchなど心躍る製品が色々と発表されましたね。筆者は特に新型iPad miniが心に刺さっています。 さて、今回はApple関連の話として「macOSの暗号化zipファイルはパスワード無しで解凍できる」というネタについて書いていきます。 解凍できる条件 何を言っているんだと思われるかもしれませんが、macOSで作られた暗号化zipファイルは以下の2つの条件を満たす場合にパスワード無しで容易に解凍が可能です。 zipの暗号化方式がzipcryptoである (通常の暗号化zipファイルは基本的にzipcryptoが利用されています) zip内のいずれかのディレクトリの中身が.DS_Storeファイルおよび何らかのファイル1つである このうち1.は基本
昨日、上野宣（@sen_u）さんがパスワードの総当りに要する時間の表をツイートされ、話題になっています。 総当たり攻撃時のパスワード最大解読時間の表を日本語化した。https://t.co/cVSNUZkAKv pic.twitter.com/rtS8ixwOqi — Sen UENO (@sen_u) August 17, 2021 1万件を超えるリツイートがありますね。大変よく読まれているようです。しかし、この表は何を計測したものでしょうか。上野さんにうかがってもわからないようでした。 何ですかね？パスワード空間が大きくなると解読に時間が掛かるということくらいがわかりますかね。 — Sen UENO (@sen_u) August 17, 2021 一般に、パスワードの総当たり攻撃（ブルートフォースアタック）というと、以下の二通りが考えられます。 ウェブサイト等でパスワードを順番に試す
Webアプリケーションを実装していると高確率で CORS の問題にぶつかります。CORSがどのようなものかはリンクしたMDNなど既存の解説を読むのが手っ取り早いと思いますが、「なぜそのように設計されたのか」という観点での説明はあまり見ないため、昔の資料の記述や現在の仕様からの推測をもとに整理してみました。 CORSとは 現代のWebはドメイン名をもとにした オリジン (Origin) という概念 (RFC 6454) をもとに権限管理とアクセス制御を行っています。その基本となるのが以下のルールです。 Same-origin policy (同一生成元ポリシー): 同じオリジンに由来するリソースだけを制御できる。 上記Wikipedia記事によるとSOPの概念は1995年のNetscape 2.02に導入されたのが最初のようです。当時のドキュメンテーションを読む限り、これはウインドウ越しに別
※この投稿は米国時間 2021 年 5 月 7 日に、Google Cloud blog に投稿されたものの抄訳です。 2021 年用に更新: この投稿には、Google のホワイトペーパー「パスワード管理のベスト プラクティス」のユーザー向けとシステム設計者向けの両方の最新情報を含む、更新されたベスト プラクティスが含まれています。 アカウント管理、認証、パスワード管理には十分な注意を払う必要があります。多くの場合、アカウント管理は開発者や製品マネージャーにとって最優先事項ではなく、盲点になりがちです。そのため、ユーザーが期待するデータ セキュリティやユーザー エクスペリエンスを提供できていないケースがよくあります。 幸い、Google Cloud には、ユーザー アカウント（ここでは、システムに対して認証を受けるすべてのユーザー、つまりお客様または内部ユーザー）の作成、安全な取り扱い、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く