背景 本プロジェクトは、ICSCoE7期生において、実業務で脆弱性対応を行う際に、日々公表される全ての脆弱性に対応しきれないという問題や、CVSS（Common Vulnerability Scoring System）基本値のスコアを脆弱性の対応優先度を決めるために利用するには不十分であると考え、これを解決すべく立ち上げられた。CVSS基本値が脆弱性そのものの深刻度を評価する点では有用であるものの、脆弱性の悪用状況やユーザの環境情報を考慮していないため、脆弱性対応の優先度を決定するために、単体で使用するのは適切ではないと考えた。また、CVSSやEPSS（Exploit Prediction Scoring System）などのリスク評価値を脆弱性対応の優先度付けに使用する場合、適切な閾値を設定する必要があると判断した。これらを踏まえて、評価値の妥当性や効率的な運用方法がないかという点につ

個人的に「Webサービスの公開前チェックリスト」を作っていたのですが、けっこう育ってきたので公開します。このリストは、過去に自分がミスしたときや、情報収集する中で「明日は我が身…」と思ったときなどに個人的にメモしてきたものをまとめた内容になります。 セキュリティ 認証に関わるCookieの属性 HttpOnly属性が設定されていること XSSの緩和策 SameSite属性がLaxもしくはStrictになっていること 主にCSRF対策のため。Laxの場合、GETリクエストで更新処理を行っているエンドポイントがないか合わせて確認 Secure属性が設定されていること HTTPS通信でのみCookieが送られるように Domain属性が適切に設定されていること サブドメインにもCookieが送られる設定の場合、他のサブドメインのサイトに脆弱性があるとそこからインシデントに繋がるリスクを理解してお

特に一番最後の暗号化サポートは非常に嬉しい進化です。dotenv単体で環境変数を運用すると、秘匿情報が含まれたdotenvファイル自体の管理に困ることや、デプロイする際にどうやって環境変数を提供するかが課題になることがありました。 現代ではクラウドプラットフォーム上にシークレットマネージャーのような仕組みが用意され、そこで中央管理するというのが一般的になっているかと思います。ただ、それだと変数のバージョン管理やレビューの仕組みを別途用意しないといけなかったりと完全ではありません（個人的主観です）。 dotenvファイル自体が暗号化され、Gitでバージョン管理でき、そのままデプロイして環境変数を適用できたら運用の手間が一気に減ります。

ハッカーが集うフォーラムで1511万5516件のTrelloユーザーのデータが売りに出されました。データを流出させた人物は電子メールやユーザー名が含まれていると主張。実際に自分のデータが流出したのかどうかが、「Have I been pwned?」でわかるようになっています。 Have I Been Pwned: Pwned websites https://haveibeenpwned.com/PwnedWebsites#Trello Trello Data Breach: 15 Mn User Records Allegedly On Sale https://thecyberexpress.com/alleged-trello-data-breach-raises-concerns/ Trello Allegedly Breached: Database of 15,115,516

元記事 元記事を読んで恐くなり、災害用公衆無線LANの00000JAPANを含むFree Wi-Fiの使用を躊躇してしまった一般利用者個人のためにこの記事を書きました。 本記事では大雑把に元記事がどのようなリスクを指摘しているのか、そしてなぜそれを考えなくて良いのかを説明した後、情報セキュリティについて持論を述べる前に理解しておくべき点に触れます。 結論 正しくスマホやPCを使う限りFree Wi-Fiは危険ではありません。00000JAPANをぜひ活用してください。 これに同意した方とネタが嫌いな人はセキュリティクラスタは口が悪いまで読み飛ばしてください。 まだ心配な人のために暗号化の重要性を知っている専門家の見解を紹介します。 災害時無料公衆無線LANの利用がNHKで紹介され、Wi-Fi暗号化がされていないことから「クレジットカード情報やパスワードなどの入力は極力、避けるよう」と呼び掛

ritou です。 少し前にパスキーとID連携の関係を考えるときにこういう観点があるよという話をしずかな方に書きました。 今回は、ログインに利用しようとした時のフローの中でここ似ているよね、こんな意図があるんだよっていう部分を取り上げます。 認証フローの似ている点 登場人物をUserAgent、RP、Authenticatorとして、あらゆるところを簡略化したシーケンスを用意しました。 ID連携、いわゆるソーシャルログインでは次のようになります。 登場人物をUserAgent、RP、IdPとするとこんな感じでしょう。 もちろん細かいところは違うわけですが、全体の流れは似ています。 WebAuthnのchallenge, OIDCのnonce, state 先ほどのシーケンス、たまたま似ていると言うよりも、これは認証フローにおける基本の流れであると意識しておきましょう。 パスキーやID連携の

ritouです。このしずかなインターネットにおける初投稿です。 おそらく、このしずかなインターネットのID連携では次のような設計になっていま「した」。問い合わせをさせていただき、対応いただきました。 これまでもQiitaなどで同様の実装例が紹介されていた際にはコメントさせていただいていたものですので、アンチパターンの紹介記事として読んでいただければと思います。 「Googleアカウントでログイン」ではじめると、ユーザーが作成され、Googleから受け取ったメールアドレス([email protected])が設定される 次回から「Googleアカウントでログイン」をすると、Googleから受け取ったメールアドレスでユーザーを参照 試しに、次のような流れで動作を確認してみます。 「Googleアカウントでログイン」でアカウント作成([email protected]) 「メールアドレス変更」

株式会社MIXI 開発本部 MIXI M事業部の ritou です。 DroidKaigi 2023にてお話しさせていただきました。 資料も公開しました。 今回も発表内容全部書き出してみたをやってみます。 同時通訳ありだったので台本はできていて、この通り話せたら良いだけだったのですが実際はそううまくいかずに普通に時間なくなりました。 それではどうぞ。 これからパスキーに関するユースケースと、それに伴うユーザーエクスペリエンスの課題について発表します。 株式会社MIXIでエンジニアとして働いています。 MIXI MというサービスでID基盤の開発に携わっており、8月にパスキー対応を行いました。 その経験も踏まえて、今日はお話をさせていただきます。 また、OpenIDファウンデーションジャパンでエバンジェリストをしています。 今日はID連携とパスキーの関係についてもお話します。 この発表を通して

SECCON Beginners Live 2023「JWTセキュリティ入門」の発表資料です。

Sansan株式会社が提供するキャリアプロフィール「Eight」、朝日インタラクティブ株式会社が運営する中小企業向けウェブメディア「ツギノジダイ」の共催イベント「日本を変える 中小企業リーダーズサミット2023」より、日本ハッカー協会の代表理事・杉浦隆幸氏の講演の模様をお届けします。本記事では、中小企業が取るべきセキュリティ戦略の基本や、中小企業で大企業並みの「ゼロトラスト」を実現する方法などが語られました。 中小企業のセキュリティ年間予算は「100万円以下」 司会者：「ハッカーが教える、妥協しない高コスパなセキュリティ対策」と題し、一般社団法人日本ハッカー協会代表理事・杉浦隆幸さんよりご講演いただきます。それでは杉浦さん、よろしくお願いいたします。みなさん盛大な拍手でお迎えください。 （会場拍手） 杉浦隆幸氏：今日は「ハッカーが教える、妥協しない高コスパなセキュリティ対策」ということで、

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

第4回未来科学大賞で多額の賞金が、数学者、王小雲に授与され、彼女の名前がにわかにメディアに注目をされた。王小雲は2004年に米国のハッシュ関数「MD5」の脆弱性を発見した研究者だったと資訊咖が報じた。 ネット社会に必須のハッシュ関数 デジタル時代、ハッシュ関数はさまざまなところで使われる。最もよく知られているのは、パスワードの保管や書類の改竄検知などだ。 ハッシュとは「混ぜこぜ」という意味で、元のデータを混ぜこぜにして、まったく別のデータに変換をしてしまうというものだ。例えば、「元の数値を2倍にして1を引く」という単純なアルゴリズムでもハッシュ関数に近いことができる。2であれば3になるし、7であれば13になる。元の数字とは異なったものになる。 しかし、これでは何かの役に立つことはできないため、暗号学者、数学者たちは、複雑なアルゴリズムを考案し、ハッシュ関数としてさまざまな応用をしてきた。こ

この記事は、Merpay Tech Openness Month 2023 の4日目の記事です。 こんにちは。メルコインのバックエンドエンジニアの@goroです。 はじめに このGitHub Actionsのセキュリティガイドラインは、社内でGithub Actionsの利用に先駆け、社内有志によって検討されました。「GitHub Actionsを使うにあたりどういった点に留意すれば最低限の安全性を確保できるか学習してもらいたい」「定期的に本ドキュメントを見返してもらい自分たちのリポジトリーが安全な状態になっているか点検する際に役立ててもらいたい」という思いに基づいて作成されています。 今回はそんなガイドラインの一部を、社外の方々にも役立つと思い公開することにしました。 ガイドラインにおける目標 このガイドラインは事前に2段階の目標を設定して作成されています。まず第1に「常に達成したいこと

こんにちは。Cyber Security Innovation Group（CSIG）の井上です。 部門名の通り、サイバーセキュリティに関する部署で、セキュリティコンサルティングやFutureVuls（ https://vuls.biz）という脆弱性対策サービスのコンサルティングやサポートをしています。 初めに春の入門祭り2023 という事で、初めて脆弱性対応をする方に向けた記事を書いてみようと思います。 この時期になると、部門移動等で情報システム部に移動し「何をやっていいのか分からない…」という話も時々聞きます。 今回は、IPAの「mjcheck4」（ https://jvndb.jvn.jp/apis/myjvn/mjcheck4.html）というツールを使った、**セキュリティ情報の収集**についてお話しようと思います。 セキュリティ情報収集とは世の中にはセキュリティ情報はいろいろあ

Developers Summit 2023 10-A-4 「フロントエンド開発のためのセキュリティ入門」の発表資料です。 https://event.shoeisha.jp/devsumi/20230209/session/4176/ 「HTTPS化」「CORS」「XSS」「脆弱なライブラリの…

前振り 全国の暗号を使うエンジニアの皆さんこんにちは。今日は暗号移行とRSA暗号の話をしたいと思います。まず暗号を利用している皆さんであればCRYPTRECの「電子政府推奨暗号リスト」のことはご存じですよね！（言い切るw） CRYPTRECから2022年7月（昨年夏）に暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準（PDF直リンク）が公開されました。この中では暗号のセキュリティ強度で各種暗号と鍵長が整理されています。セキュリティ強度はビットセキュリティと呼ばれるビットサイズ（共通鍵暗号の場合のビット長）で区分されます。暗号アルゴリズムが違ってもセキュリティ強度で比較ができるということですね。例えば現在一般的に良く使われているセキュリティ強度は112ビットセキュリティが多く、これにはデジタル署名であればRSA暗号の2048ビットやECDSAのP-224等が含まれます。今日は公開鍵暗

攻撃に対して強固なソフトウェアを開発するためのセキュリティの基本を学び、脆弱性を突かれた際の被害の軽減と迅速な対応を理解することができます。OpenSSF（リーダーを結集し、広範なコミュニティ、ターゲットを絞った取り組み、およびベストプラクティスを構築することでオープンソース ソフトウェアのセキュリティを強化する異業種コラボレーション）の関与により、オープンソースやその他のソフトウェアを安全に使用、開発するための具体的なヒントを提供します。 このコースの内容は日本語です。 このコースは、ソフトウェア開発者、DevOpsプロフェッショナル、ソフトウェアエンジニア、Webアプリケーション開発者、および安全なソフトウェアの開発方法の学習に関心のあるその他の人々を対象としており、限られたリソースでも情報セキュリティを向上させるための実践的な手順に焦点を当てています。 最新のソフトウェアは絶えず攻撃

といった感じです。（この例、下で問題例として取り上げるため、実はおかしなチェック内容にしています。） "No.～基準"までがシートに記載されていてます。回答する発注先企業は"Yes,No,N/A"を3択で✅をつけ、備考欄にNoやN/Aの理由のほか、注記を記載できます。こういう項目が20～500項目あるExcelのシートに、発注先企業の回答担当は自社の状況、対応を確認しながら、ひたすら記載してゆくわけです。 知ってる人は知っているが、知らない人はぜんぜん知らない 最近参加したエンジニアがぞろぞろいらしたカンファレンスで、私が 「……あの セキュリティーチェックシート ってあるじゃないですが、あの 面倒なアレ です。アレにこの規格を採用するよう書いてあったら、各企業に規格の採用が広がるかもですね。あはは。」 と話したことがありました。その瞬間、 嫌なことを思い出したのか顔を曇らせたり苦笑いをす

こんにちは、SSTでWeb脆弱性診断用のツール(スキャンツール)開発をしている坂本(Twitter, GitHub)です。 最近 Fetch API*1 や XMLHttpRequest*2 を使ってクロスサイトのCookieを送る・送らないの実験をする機会がありました。 そこで自分の勘違いが複数発見され、改めて「今のクロスサイト Cookie って難しいな」と感じました。 セキュリティエンジニアのみならず、開発者の方にも参考になるかと思いましたので、自分の勘違いを紹介していきたいと思います。 なお本記事では「サイト」という単語を Cookie における Same-Site の定義に沿って扱います。 Understanding “same-site” and “same-origin” 使用したWebブラウザ: Chrome(burp 同梱のChromium) 106.0.5249.62