初めまして、Flatt Security社のブログに寄稿させていただくことになりました、西川と申します。 普段は、SaaS企業でプロダクトセキュリティをメインの仕事としていますが、一般社団法人鹿児島県サイバーセキュリティ協議会の代表理事として活動しております。 さて、今回はプロダクトセキュリティを生業としている私が、脆弱性診断を外注することと内製化すること、それからバグバウンティについてそれぞれの役割を記していきたいと思います。 本記事の目的 脆弱性診断を外注した方が良い、あるいは、内製化した方が良い、という話ではなく、それぞれ役割が異なると考えています。つまりそれは、それぞれが補い合う形で存在しているというものです。そして、これらをさらに補う要素としてバグバウンティがあるという話を通して、みなさまの組織で脆弱性診断をどのようにセキュリティ運用に組み込んでいくのかを検討したり、バグバウンテ

こんにちは、@hamayanhamayan です。 本稿ではWebセキュリティに対する有用な文書として広く参照されているOWASP Top 10の1つ「インジェクション」について考えていきます。色々なインジェクションを例に挙げながら、どのようにインジェクションが起こるのかという発生原理から、どのようにインジェクションを捉え、より広くインジェクションの考え方を自身のプロダクト開発に適用していくかについて扱っていきます。 SQLインジェクションやコマンドインジェクション、XSSのようなインジェクションに関わる有名な手法について横断的に解説をしながら、インジェクションの概念を説明していきます。初めてインジェクションに触れる方にとっては、インジェクションの実例や基本的な考え方に触れることができ、その全体像を把握する助けになるかと思います。 また、既にいくつかのインジェクション手法を知っている方にと

こんにちは、 @okazu_dm です。 この記事は、CookieのSameSite属性についての解説と、その中でも例外的な挙動についての解説記事です。 サードパーティCookieやCSRF対策の文脈でCookieのSameSite属性に関してはご存知の方も多いと思います。本記事でCookieの基礎から最近のブラウザ上でのSameSite属性の扱いについて触れつつ、最終的にHSTS(HTTP Strict Transport Security)のような注意点を含めて振り返るのに役立てていただければと思います。 前提条件 Cookieについて Cookieの属性について SameSite属性について SameSite属性に関する落とし穴 SameSite属性を指定しなかった場合の挙動 SameSite: Strictでも攻撃が成功するケース 例1: スキームだけ違うケース 例2: サブドメイ

はじめに こんにちは、株式会社Flatt SecurityでセキュリティエンジニアをやっているRyotaK (@ryotkak) です。 HackerOneのイベント (H1-512) に参加するためにテキサスに行った話で紹介したイベントにおいて報告したSSRF(サーバーサイドリクエストフォージェリ)に関して、脆弱性情報を公開する許可が得られたため、今回の記事ではその脆弱性に関して解説を行います。 なお、本記事で解説している脆弱性はGitHub Bug Bountyプログラムのセーフハーバーに則り行われた脆弱性調査の結果発見され、公開を行う許可を得たものであり、無許可の脆弱性診断行為を推奨することを意図したものではありません。 GitHubが開発するプロダクトやサービスに脆弱性を発見した場合は、GitHub Bug Bountyへ報告してください。 GitHub Enterprise Im

はじめに こんにちは。株式会社Flatt Securityセキュリティエンジニアの森(@ei01241)です。 最近は認証や認可に際してOpenID Connectを使うWebサービスが増えていると思います。「Googleアカウント/Twitter/Facebookでログイン」などのUIはあらゆるサービスで見かけると思います。しかし、OpenID Connectの仕様をよく理解せずに不適切な実装を行うと脆弱性を埋め込むことがあります。 そこで、突然ですがクイズです。以下のTweetをご覧ください。 ⚡️突然ですがクイズです！⚡️ 以下の画面はOAuth 2.0 Best Practice上は推奨されないような実装になっており、潜在的リスクがあります。https://t.co/bXGWktj5fx どのようなリスクが潜んでいるか、ぜひ考えてみてください。このリスクを用いた攻撃についての解説記

「週刊新潮」の発売前日に速報が届く！ メールマガジン登録 デイリー新潮とは？ 広告掲載について お問い合わせ 著作権・リンクについて ご購入について 免責事項 プライバシーポリシー データポリシー 運営：株式会社新潮社 Copyright © SHINCHOSHA All Rights Reserved. すべての画像・データについて無断転用・無断転載を禁じます。

フリーランスのWebエンジニアの仕事を探す上で、いつも考えていたことをつらつらと書いてみます。 特に「単価」についての考え方について書きます。 前回（鬼のようにバズった。読んでくれた方感謝です…！） 単価に「正解」はない最初に触れておきたいのは、単価に正解はないということ。 時給1500円で凄腕エンジニアが雇われていようが、時給5万円で素人が雇われていようが、依頼主とエンジニアが満足しているのならそれで良い。 逆に「俺はXXができるから時給8000円であるべきだ！」とか「エンジニアに払う給料なんて年300万円でいいだろ」とか、そういう一方的な思い込みは「それってあなたの感想ですよね？」でしかなく、他人に強制するものではない。 「お互いが合意した単価が正解である」という考えをベースにお金の話を考えると上手くいくと思う。 関連して「こんな低単価で依頼してくるなんてふざけてる！！！」みたいな怒り

はじめに こんにちは。株式会社Flatt Securityセキュリティエンジニアの梅内(@Sz4rny)です。 本稿では、弊社がこれまでに実施してきたFirebase診断の事例や筆者独自の調査をもとに、Firebaseを活用して開発されたサービスにおいて発生しやすい脆弱性の概要やそれにより引き起こされるリスクおよびその対策を深刻度や発生頻度の評価を踏まえつつお伝えします。本稿を通じて、Firebaseを活用したサービスにおいて発生しやすい脆弱性にはどのようなものがあるのか、また、そのような脆弱性を埋め込むことなくセキュアなサービス実装を実現するためにはどのような観点に気をつければよいのかについて理解を深めていただけますと幸いです。 なお、本稿では「Firebase活用時に限って発生しうる脆弱性(例:Firestoreのセキュリティルールにおけるバリデーション不備)」と「Firebaseを活

フリーランスのWebエンジニアとして仕事をする上で、いつも気をつけていたことをつらつらと書いてみます。 フリーランスやっている人、興味ある人の参考になれば。 ※情報商材みたいなタイトルになったけど中身は真面目（多分） ※（一行だけ宣伝）今はSALESCOREでCTOやってます！積極採用中です！自分に興味もっていただけた方、お気軽にご連絡ください！ 自分についての情報フリーランスのWebエンジニアを2年半 当時はRails, Vue.js, Reactがメイン(2018-2020) 情報系の大学院 → メガベンチャー2年 → スタートアップ2年からの独立 今はSALESCOREのCTO 単価は相場の最高額くらい お金の話あんまりしたくないが、みんな興味あると思うので一応 一度お世話になったFindy Freelanceさんの募集を数年ウォッチして、自分がFindyさんで受けた案件が頭を抜けて

国内の主要なSaaS企業やSIerに脆弱性診断サービスなどを提供しているFlatt Security社は、Webエンジニアがセキュアコーディングを独習できるオンライン教材「KENRO」のトライアルとしてコンテンツの一部を無料で公開中です。 メールアドレスを登録するだけで利用を開始でき、期間も無制限。 KENROでは「SQLインジェクション」「XSS（クロスサイトスクリプティング）」「ディレクトリトラバーサル」などを始めとする10種類の一般的な脆弱性についてテキストで学び、その学びを基に攻撃者として脆弱性に対する攻撃を「ハッキング演習」で試し、その脆弱性があるコードを自分で修正する「堅牢化演習」まで、オンラインで実践できるユニークな教材です。 演習の結果もKENROが自動判定してくれるため、24時間365日、いつでも学習できます。 無料トライアルでは、一般的な10種類の脆弱性の学習コンテンツ

はじめに こんにちは。株式会社Flatt Securityセキュリティエンジニアの村上 @0x003f です。 弊社では本当にありがたいことに多くのお客様から様々なWebサービスの脆弱性診断をご依頼頂いています。本稿では、特にご依頼いただくことが多いBtoB SaaSという領域において実際にどのような種類の脆弱性が見つかっているのか(我々が発見できているのか)を集計し、上位10種類の脆弱性を紹介します。また、この上位10種類にどのような特徴があるのか、どのようにアクションを行うことでこれらの脆弱性がサービスに埋め込まれないようにできるのかについても解説しています。 データの概要 今回のデータは2022年1月から2023年2月までに診断を行ったBtoB SaaSに属するサービスで発見された脆弱性を元に集計と分類を行っています。集計を行った対象脆弱性の実数については、扱うデータの性質上公開でき

初めに こんにちは。株式会社Flatt Security セキュリティエンジニアの石川です。 近年、クロスプラットフォームなデスクトップアプリケーションを作成する上で、Electronを採用することが選択肢の1つになってきています。 Electronの開発では、ライブラリとしてのElectronの実装と、その上にユーザーが構築するデスクトップアプリケーションの2つのコードが存在します。デスクトップアプリケーションの実装においても、メインプロセスとレンダラープロセス、サブフレームなど、考慮すべき概念が多数存在します。 そこで本稿では、Electronのアーキテクチャを意識しながら、実際に発見された脆弱性の傾向について考察することで、 Electron開発者が開発時に気を付けるべき点とその緩和策について、セキュリティの観点から記述していきます。 その上で、一例として、2022年のBlack H

こんにちは。SALESCORE株式会社CTOの成澤です。 このシリーズでは、資金調達のリリースにあわせてSALESCOREにまつわる様々なトピックをお話ししています。 第二回となる今回の記事ではSALESCOREの「ドメイン特化型Full-Stack Data Platform」という開発コンセプトに焦点をあててお話しします！ ※第一回の記事はこちらから！ 「多機能」ではなく「複数のニーズに応える単機能」を開発する第一回では「セールスイネーブルメントのプロダクト開発は難しい」「その理由は多機能性とカスタマイズ性が求められるから」とお話ししました。SALESCOREはこの難しさに対して、いくつかのコンセプトで挑んでいます。ここではその一つについてお話します。 創業当初（旧社名は株式会社Buff）、初めて作ったサービス「Buff Sales」のコア機能は「Salesforceのレポートと同期し

はじめに こんにちは。セキュリティエンジニアの@okazu_dmです。 皆さんはブラウザにおいてLocal StorageやCookieに格納されている値が暗号化されているかどうかを考えたことはあるでしょうか。これらWebサービスの認証・認可において使われるデータが、XSSのようなアプリケーションの脆弱性への耐性に差があるかどうかは頻繁に議論されるところです。 しかし、ブラウザに保存されたデータが暗号化されているかどうかはまた別の攻撃経路への耐性の話であり、馴染みがないのではないでしょうか。 これは、基礎知識としてLocal StorageとCookieの仕組み/挙動の紹介と比較をしつつ、Google Chromeにおけるそれらの暗号化の実装上の違いを検証する記事です。 なお、保存先のストレージとAuth0のアクセストークンのXSS耐性との関連は過去に別の記事で検証しています。興味がある方

こんにちは、SREをやっている@okazu_dmです。 経歴としては、サーバサイドエンジニアからセキュリティエンジニアを経て、エス・エム・エスではサービス横断で技術的な課題を解決しています。 基本的には組織に必要なことと自分ができることや、やりたいことが交わるポイントで仕事をしており、現在はSREとして働いています。 今回は、過去の記事 とは違い、既存SREチームとは別に、介護事業者向け経営支援サービス「カイポケ」のリニューアルプロジェクトにスコープを絞って新しく立ち上げたSREチームとしての活動を紹介します。 リリース前のプロダクトのSREなので、一般的なSREの定義とは乖離する内容もある点ご留意ください。 リニューアルプロジェクトの概要 昨年末に出したフロントエンドの技術選定に関する記事 での説明と内容的な差分はありませんが、SREの業務の説明の前にこちらでも改めて触れておきます。 イ

9社のSaaS・OSS開発の現場で活躍する開発エンジニア・セキュリティエンジニアの方々に、2022年のセキュリティ分野での取り組みや2023年に取り組みたいことなどを聞いた2週連続企画の後編です。後編では、5社からのコメントをご紹介します。 今回コメントをいただいた方々（社名五十音順・順不同） 後編（本記事） サイボウズ 開発本部 PSIRT SmartHR セキュリティグループ　岩田季之さん メルカリ Security Engineering Team Manager 　Simon Girouxさん Ubie　水谷正慶さん LayerX　鈴木研吾さん 前編 Aqua Security Open Source Team　福田鉄平さん カンム　金澤康道さん グラファー　森田浩平さん Finatextホールディングス 取締役CTO/CISO　田島悟史さん ▼前編記事 flatt.tech 今回

はじめに 本記事の流れ 最初にして最大の難関「ネタ出し」 「1. ネタ出しのコミュニケーション・体制作りを構築していない」の解決 「2. 本来ネタになるはずのものを見逃している / 諦めている」の深掘り 「切り口を考える」とは？ ☔️ 切り口を考えていない例 🌞 切り口を考えられている例 切り口のまとめ 切り口を考えるために必要な要素 情報の希少性 課題の鏡面性 (構造の頑強性) 「情報の希少性」「課題の鏡面性」を意識して切り口を考える 企画は難しいからこそ、ガチガチの運用はしない どのように難しいのか？ 2つに共通する難しさ 「情報の希少性」をジャッジする難しさ 「課題の鏡面性」をジャッジする難しさ 難しさを受け入れる まとめ はじめに はじめまして。開発者のためのセキュリティサービスを提供したい、Flatt Security 執行役員の豊田恵二郎 @toyojuniです。 Flatt

昨今、ITベンダーだけでなくユーザー企業にもシステム内製化の動きが広がりつつあり、「セキュアな開発をいかに実現するか」は多くの開発組織における悩みの1つとなっています。 「セキュアな開発組織」をどう作っていくべきか。また、セキュアな開発を組織に浸透させるにはどうすれば良いのかーー。株式会社Flatt Securityでセキュアな開発のための学習プラットフォーム「KENRO(ケンロー)」の開発・コンテンツ監修を務めたCTO・米内貴志が、これまで様々な開発組織を牽引してきた株式会社LayerX 執行役員の名村卓さん、Ms.Engineer株式会社 Mother of Engineerの齋藤匠さんのお二人にお話を伺いました。 ▼後編はこちら flatt.tech プロフィール 「開発にかける時間とセキュリティにかける時間」のバランスに葛藤 セキュリティに対するモチベーションが高いチームをどう作っ

こんにちは。株式会社Flatt Security セキュリティエンジニアの梅内 (@Sz4rny) です。 本稿では、2022年9月に Cloud Storage for Firebase に新たに導入された Cross-service Rules という機能について、前提知識をおさらいしつつ、実例を交えながらその概要や利用方法、メリットなどを紹介します。 また、Flatt Securityのセキュリティ診断(脆弱性診断)ではFirebaseを用いたサーバーレスなアプリケーションも診断可能です。 「料金を自分で計算できる資料」を無料公開中ですので、ご興味のある方は是非ダウンロードしてみてください。 前提知識のおさらい Firebase とは Firestore の概要 Cloud Stroage の概要 Cross-service Rules が解決する課題 課題 事例1. ロールに基づく

はじめに こんにちは。ソフトウェアエンジニアの@kenchan0130です。 AWS Lambdaは関数URLやAPI Gatewayのバックエンド、AWSサービスのイベントをトリガーとしたスクリプト実行など様々な用途で使用されます。 そのため、ユースケースによっては秘密情報を扱いたい場合があります。 この記事では、AWS LambdaでAPIキーなどの秘密情報を安全に扱う方法を解説します。 なお、Flatt SecurityではAWS・GCP・Azureのようなクラウドも対象に含めたセキュリティ診断サービスを提供しています。 是非下記のSmartHR様の事例をご覧ください。 推奨されない方法 秘密情報を安全に取り扱う方法を解説する前に、まずはワークロードによっては推奨されない方法があるため、その方法を2つ紹介します。 AWS Lambdaのソースコードに秘密情報をハードコード ソースコー