10年間は生き続ける考え方が凝縮された良書「AWSではじめるクラウドセキュリティ」 | DevelopersIO
まずはお詫び タイトルパクりました。ゴメンナサイm(__)m はじめに 立て続けに神本が発売されて、2023年はいい年になりそうと思っているAWS認定トレーニング講師の平野@おんせん県おおいたです。 ところでみなさん、「セキュリティ」と聞いてどんな印象お持ちですか？ たとえばこんな感じじゃないですか なんか大事なのは分かる なんか難しそうなので、できれば関わりたくない セキュリティ担当者がいい感じにやってくれるはず 時々セキュリティ事故のニュースを見るが、うちは関係ない まあ、僕も以前はそうでした。 AWSをはじめて、セキュリティには興味を持ったのですが、専門用語をググってもよく分からずに、心折れながら勉強してきました。 そんな中で、先日発売されたのが今回ご紹介する本です。全人類に読んでもらいたいと思ってます。 誰に読んでもらいたいか 全人類といいたいところですが、実際にはこんな方々になり
Low-Level Software Security for Compiler Developers
1 Introduction Compilers, assemblers and similar tools generate all the binary code that processors execute. It is no surprise then that these tools play a major role in security analysis and hardening of relevant binary code. Often the only practical way to protect all binaries with a particular security hardening method is to have the compiler do it. And, with software security becoming more and
セキュリティ対応組織の教科書 第3版
© 2023 ISOG-J セキュリティ対応組織（SOC/CSIRT） の教科書 ～ X.1060 フレームワークの活用 ～ 第 3.0 版 2023 年 2 月 13 日 NPO 日本ネットワークセキュリティ協会 （JNSA） 日本セキュリティオペレーション事業者協議会 （ISOG-J） © 2023 ISOG-J 改版履歴 2016/11/25 初版作成 2017/10/03 第２．０版作成 ・７章、８章の追加 ・別紙に「セキュリティ対応組織成熟度セルフチェックシート」を追加 ・これらに伴う、１章の修正 ・その他、軽微な修正 2018/03/30 第２．１版作成 ・ 「8.3. 各役割の実行レベル」における、成熟度指標（アウトソース）の 改善 ・これに伴う、別紙「セキュリティ対応組織成熟度セルフチェックシー ト」の修正 2023/2/13 第３．０版作成 ・ITU-T 勧告 X.106
HTTPS 証明書の Common Name の検証がしれっと禁止されていた件について | IIJ Engineers Blog
開発・運用の現場から、IIJのエンジニアが技術的な情報や取り組みについて執筆する公式ブログを運営しています。 こんにちは。IIJ Engineers Blog編集部です。 IIJの社内掲示板では、エンジニアのちょっとした技術ネタが好評となって多くのコメントが付いたり、お役立ち情報が掲載されています。 今回は、すでにお気づきの方もいるかもしれませんが、いつの間にか HTTPS 証明書の Common Name の検証が禁止 になっていた件について紹介します。 HTTPS 証明書の検証手続きは、RFC2818 で「Subject Alternative Name があればそれで、なければ Common Name を見よ」となっていました。 If a subjectAltName extension of type dNSName is present, that MUST be used as
セキュリティ・バイ・デザイン導入指南書 ：IPA 独立行政法人 情報処理推進機構
ソフトウェア開発者でなくとも、セキュリティ・バイ・デザインという言葉は聞いたことがあると思います。しかし、セキュリティ・バイ・デザインが十分に実施できていると言える組織は多くないのではないでしょうか。 いざセキュリティ・バイ・デザインを実施しようとしても「何をすればよいのだろう？」「どうやれば良いのだろう？」となかなか手が動かない。そんな状況の一助となるよう、我々がセキュリティ・バイ・デザインを学び、実践した内容を文書化し公開する運びとしました。 セキュリティ初心者でも読みやすいように、以下の特徴を念頭において本書を執筆しました。 軽快な文章 図表を多用したグラフィカルな見た目 キャラクターのセリフに共感しながら理解ができる 1章 セキュリティ・バイ・デザイン －セキュリティ・バイ・デザインの概要や必要性の説明 2章 脅威分析 －組織やシステムに対する脅威分析の実施方法 3章 セキュリティ
【PoC編】XSSへの耐性においてブラウザのメモリ空間方式はLocal Storage方式より安全か？ - Flatt Security Blog
はじめに こんにちは。 セキュリティエンジニアの@okazu-dm です。 この記事は、Auth0のアクセストークンの保存方法について解説した前回の記事の補足となる記事です。前回の記事の要旨をざっくりまとめると以下のようなものでした。 Auth0はデフォルトではアクセストークンをブラウザのメモリ空間上にのみ保存するin-memory方式であり、XSSへの耐性のなさ等の理由でlocalStorageで保存することを推奨していない しかし、XSSでアクセストークンを奪取できるのはin-memory方式でも同じのはず(検証は行いませんでした)。localStorage方式を過度に忌避する必要はないのではないか なお、Flatt Securityの提供するセキュリティ診断はAuth0に限らずFirebase AuthenticationやAmazon CognitoなどのIDaaSのセキュアな利用
Auth0のアクセストークンをLocal Storageに保存するのは安全？メリット・デメリットをin-memory方式と比較して検討する - Flatt Security Blog
※追記: 本記事の続編としてin-memory方式からアクセストークンを奪取するPoCを下記記事で公開しました。ぜひあわせてご覧ください。 はじめに こんにちは。 セキュリティエンジニアの@okazu-dm です。 この記事では、Auth0のSPA SDKでアクセストークンのキャッシュを有効化する際の考慮ポイントについて紹介し、それを切り口にアクセストークンの保存場所に関してin-memory方式とlocalStorage方式の2つについて解説します。 Auth0のようなIDaaSは昨今かなり普及が進んでいると思いますが、Flatt Securityの提供するセキュリティ診断はAuth0に限らずFirebase AuthenticationやAmazon CognitoなどのIDaaSのセキュアな利用まで観点に含めて専門家がチェックすることが可能です。 ご興味のある方は是非IDaaS利用部
「情報セキュリティ白書2022」、IPAが公開 国内外の政策や被害実態など240ページに渡り解説
情報処理推進機構（IPA）は7月15日、情報セキュリティに関する書籍「情報セキュリティ白書2022」を公開した。国内外の官民の各種データや資料を引用し、情報セキュリティ分野のトピックを240ページ以上に渡り解説している。IPA会員ならばアンケートに回答することで、PDFファイルを閲覧可能。印刷書籍版もあり、2200円で購入できる。 情報セキュリティ白書はIPAが2008年から毎年発行している書籍。情報セキュリティに関する国内外の政策や脅威の動向、インシデントの発生状況、被害実態などをまとめている。22年版では「内部不正防止対策の動向」「個人情報保護法改正」「クラウドの情報セキュリティ」「中小企業に向けた情報セキュリティ支援策」「米国や欧州の政策」などのトピックも取り上げた。 読書アンケートによると情報セキュリティ白書は、「学習・自己研さん」「対策強化・予算策定などの上位者への説明資料」「新
ゼロトラスト移行のすゝめ：IPA 独立行政法人 情報処理推進機構
ゼロトラストの概念は近年のテレワークやクラウド利用の普及により注目を集めていますが、いざ自組織に実装しようとしたときにはさまざまな課題に直面することが予想されます。また、ゼロトラスト移行の効果を最大限発揮するためには、ゼロトラストに対する担当者の理解が不可欠になっています。 そこで本書ではゼロトラストの概念を自組織に実装する際に必要となる検討の流れや、得られるメリット、ソリューションの導入順序とその際のポイントについてまとめました。これからゼロトラスト移行を検討している組織の担当者に参考にしていただけると幸いです。
Webサービスにおけるマイページの仕様とセキュリティ観点 - Flatt Security Blog
はじめに こんにちは。株式会社Flatt Security セキュリティエンジニアの石川です。 本稿では、ログイン機能をもつWebアプリケーションにおける実装上の注意を、マイページ機能から派生する機能のセキュリティ観点から記載していきます。特に、XSS（Cross-Site Scripting）やSQLインジェクションのような典型的な脆弱性と比較して語られることの少ない「仕様の脆弱性」にフォーカスしていきます。 これから述べる実装上の注意点は、実際にはマイページ機能であるかどうかに関係なく注意するべきです。 しかし、開発者の視点に立つと「これこれの機能にはどのようなセキュリティ観点があるか」という形が読みやすく、また他の機能の仕様のセキュリティを考える上で想像力を働かせやすいものになるのではないでしょうか。 また、株式会社Flatt Securityではお客様のプロダクトに脆弱性がないか専
あなたのWebサービスの脆弱性を発見者から教えてもらう方法 - RFC9116が発表されました
先日、RFC9116が発表されました🚀 あなたのWebサービスに潜在する未知の脆弱性を誰かが見つけた時、それをあなたに連絡する方法を提示するsecurity.txtを標準化するものです。 この記事では何故これが必要だったのか、そして私たちがこれを実装する方法を簡潔に説明します。 なぜこれが必要だったのか https://securitytxt.org/のSummary(概要)にはこのように書かれています。 Webサービスのセキュリティリスクが、リスクの重大性を理解している独立したセキュリティ研究者によって発見された場合、それらを適切に開示するためのチャンネルが不足していることがよくあります。 その結果、セキュリティの問題が報告されないままになる可能性があります。 security.txtは、組織がセキュリティ研究者がセキュリティの脆弱性を安全に開示するためのプロセスを定義するのに役立つ標
サブドメインをユーザーホスティングサイトに使うときのパターン(Same Origin/Cookie/Public Suffix List)
README.md サブドメインをユーザーホスティングサイトに使うときのパターン hoge.example.com でユーザが作成したサイトをホスティングして、任意のJavaScriptを実行できる状態にしたいケース。 サブドメインを分けることで、Fetch APIなどはSame Origin Policyを基本にするため、別のサブドメインや example.com に対するリクエストなどはできなくなる。 一方で、CookieはSame Origin Policyではない。 デフォルトでは、hoge.example.com から example.com に対するCookieが設定できる。 これを利用したDoS(Cookie Bomb)やこの挙動を組み合わせた別の脆弱性に利用できる場合がある。 The Cookie Monster in Your Browsers - Speaker Dec
Firebase Authentication 7つの落とし穴 - 脆弱性を生むIDaaSの不適切な利用 - Flatt Security Blog
はじめに こんにちは、株式会社 Flatt Security セキュリティエンジニアのぴざきゃっと (@pizzacat83) です。 認証機構を自作せずに導入できる Firebase Authentication は様々なアプリケーションにて利用されていますが、その特性を十分に理解せずに導入すると、実は不具合や脆弱性が生じることがあります。そこで本稿では Firebase Authentication を利用するうえで、注意しなければ不具合や脆弱性に繋がりうる 7 個の「落とし穴」について解説します。 はじめに IDaaS の利点と欠点 落とし穴 1. 自己サインアップ リスク 対策 不十分な対策 落とし穴 2. ユーザーが自身を削除できる 対策 落とし穴 3. 他人のメールアドレスを用いたユーザー登録 リスク リスク 3-1. メールアドレス誤入力によるユーザー乗っ取り リスク 3-2
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
iOS・Androidも対応「パスキー」とはなにか? パスワード時代の終焉
マイナンバーカード | SPY×FAMILY | デジタル庁
無料で「開発におけるセキュリティの基本」を学べる18時間のオンライン講座、Linux Foundationが開講
Reactコンポーネントにおけるテスト手法の選択肢
TLS, HTTP/2演習
SSH implementation comparision
https://twitter.com/matsuu/status/1522751803242455043
