最小限で基礎的なセキュリティガイダンスである「AWS Startup Security Baseline (AWS SSB)」を紹介します いわさです。 SaaS on AWS では大きく 4 つのフェーズ（設計・構築・ローンチ・最適化）で役立てる事ができるコンテンツが提供されています。 設計フェーズでは技術面からコンプライアンスに準拠したりセキュリティベースラインを考える必要があります。 これらについてベストプラクティスが提案されている動画コンテンツがあります。 その中で初期段階で実施出来ることとして次のステップが紹介されていました。 セキュリティ周りは Well-Architected Framework や Security Hub の適用から始めることも多いと思いますが、様々な制約からすぐの導入が難しい場合もあります。 そんな方に本日は上記の中の AWS Startup Secur

AWSマネージドサービスGuardDutyによる待望のコンテナランタイム脅威検知。その検知内容と設定上の注意事項、検出の様子をまとめてお届けします。 「ECSのランタイム脅威検知って、商用製品必須だよね。どれにすっかなぁ。結構高いよね」 「1年前の予告を経て、よーーーやくAWSマネージドなやつがGAされましたよ」 去年のre:Invent2022においてKeynote中に予告だけされていたコンテナ環境のランタイム検知（【速報】GuardDutyによるコンテナランタイムの脅威検知サービスが発表されました！）。 先日のre:Invent 2023のアップデートにより、待望のECSにおけるランタイム検知が、GuardDutyで実現できるようになりました！！もともとEKSにおけるランタイム検知は提供されていましたが、それがECSにも拡張されたアップデートです。 これまでAWSのECSにおいてランタ

エンタープライズ企業が新しいクラウドサービスを導入する時には、自社のセキュリティ基準を満たせていることを確認するのが通例である。「セキュリティチェックシート」と呼ばれるエクセルシートを利用して一点一点チェックしていくことが多い。（この質問票で聞かれる内容が個社ごとにばらばらで、システム導入時に双方の負担になってしまっているのを標準化してなんとかできないかと思うことはあるが、この記事ではそこには触れない。） よくあるのが、「アンチウィルスソフトウェアをサーバーにインストールしていること」というチェック項目だ。明快な質問のように見えるが具体で実現するためには色々考えなければいけないことがある。標準的なサーバー構成、つまり、ハードウェアがあって、その中でOSが稼働していて、その上でアプリケーションが動いているというシンプルな構成であれば良いのだが、クラウドインフラを使い倒すようになった今ではマイ

SPAのアプリケーションで、外部のIdPを使ってOpenID Connect によるログイン機能を開発しようと考えています。IDトークンの保存先として、ブラウザのCookieかサーバーのDBに保存するかの2つの案があると思っています。調べた限り、サーバーサイドで持つべきという意見が多いように見えますが、以下のような背景がある中で開発しても、ブラウザのCookieでは持つべきなのではないのでしょうか？ - IDトークン自体にも、個人の属性（氏名等）情報は無いことを確認している - サーバーサイドでIDトークンの署名検証をして、IDトークンの改ざんが無いか確認する - Http Only属性：JSによるCookieへのアクセスを防ぐため - Secure属性：流出防止のため - SameSite=strict：CSRF対策のため 結論から言えば、「どちらでもよい」となります。しかし、恐らく話は

Googleと米Yahooが先日発表した、メール送信者向けのガイドラインをご存じでしょうか？Googleは2024年2月から、アカウントに対してメールを送信する際の条件（認証）を強化すると発表しました。また、米Yahooも同様にメール送信者向けに2024年第一四半期から条件の変更を発表しました。 GoogleやYahooと聞くと、個人利用やECサイトなどのメルマガなどをイメージすると思いますが、今回の対処にはGmailアカウント（@gmail、googlemail.com）だけでなく、企業や学校などが多く利用するGoogle Workspaceも対象に含まれています。この条件変更の流れは、日本国内のビジネスにも影響を与えていく可能性があります。その条件とは一体どんな内容なのかを解説します。 送信ドメイン認証に対応 メールセキュリティサービス ガイドブック ダウンロードする（無料） 目次 今

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

概要 CookieにSameSite属性を付与することで、CSRF脆弱性1に対していくらかの防御ができる。 SameSite属性はStrict,Lax,Noneの3つの値を取り、設定値により効果の範囲は異なる Strictを設定することで、CSRFを防げる。ただし、Webサイトの使いやすさが損なわれる場合がある Laxを設定することで、POSTメソッドのリクエストのみを受け付ける処理でCSRFを防げる None は従来通りの動作であり、外部サイトからCookieを送信する Webサイトのセキュリティ要件により、設定すべき値が異なる SameSite属性は主要なブラウザすべてで対応されている SameSite属性の付与がCSRF脆弱性への防御とならないケース Windows 10 RS3（2017 Fall Creators Update）未満のIE 11など、SameSite属性をサポート

みなさんこんにちは。 FUJITSU その2 Advent Calendar 2018 17日目の記事担当は私 ゆきはらです。 前回14日目はkeiya-nobutaさんのSphinxの導入とLinux Kernelドキュメントのビルドで、 18日目はhasunumaさんの富士通サイバーセキュリティーワークショップ(FCSW)2018参戦記となっています。 はじめに なぜこのテーマにしたか Webアプリケーションに対する代表的な攻撃手法としてXSS（クロスサイトスクリプティング）とCSRF（クロスサイトリクエストフォージェリ）というものがあります。 しかしこの二つ、名前だけでなく攻撃手法も似ていて違いがとてもわかりづらいです。かつて私がセキュリティを勉強していたときもよく混同していました。 そこで、この記事ではXSSとCSRFの仕組みとそれらの違いについてまとめることにしました。 対象とす

について調べました。 same-site とは same-siteの説明は下記の記事がとってもわかりやすかった。 https://web.dev/same-site-same-origin/ ブラウザが開いているURLと、リクエストが飛ぶ先の eTLD+1が同じであれば same-site と判定される。 same-siteなリクエストについてはSameSite属性が何であろうとCookieは付与される。 SameSite属性によって挙動が変わるのはcross-siteなリクエストの時。 NoneとStrictの挙動 NoneとStrictは理解しやすい。 None: cross-siteなリクエストについて、どんな場合でもCookieは付与される。 Strict: cross-siteなリクエストについて、どんな場合でもCookieは付与されない。 Laxの挙動 Laxは少し複雑だ。 (

最近はMBSDでWebアプリケーションスキャナの開発をしている寺田です。 Webアプリケーションを開発していると、セキュリティの観点でURLをチェックしなければならないことがしばしばあります。本日の記事では、そのようなURLのチェックを如何に行うか、正規表現を使う場合の注意点や、バイパス方法などについて書きたいと思います。 本記事で想定するのは、ブラウザからパラメータとして来るURLをチェックしてリダイレクトやリンクのURL等として使ったり、ブラウザから来たOriginヘッダ等のURLをチェックしてアクセス制御をするケースです。その中でも、以下のようにサブドメイン部分（★の部分）を可変にする状況を主に想定します。 https://★.example.jp/… よく使われてそうなチェック用の正規表現と、そのバイパスは以下のとおりです。 正規表現: ^https://.+\.example\.

この記事はSPA + WEB_APIで構築するWEBサービスのセキュリティの脆弱性を考える時に必ず出てくる、CSRF対策やCORSの考察をした記録です。 SPAでWEBサイトを構築する方、または既に持っていて脆弱性がないか調べている時にお役に立てる内容となります。 CSRFについてはこちらのサイトがとてもわかりやすいです。 https://qiita.com/okamoai/items/044c03680766f0609d41 大前提 ブラウザで非同期通信を行う際には、同一生成元ポリシー(Same Origin Policy)によってWebページを生成したドメイン以外へのHTTPリクエストができません。 SPA + WEB_APIのパターンなど異なるドメインのリソースにアクセスしたいという需要があります → 昔はJSONP使ってたがセキュリティだめ → より手軽に、より安全にクロスドメイン

はじめに この記事は Scala Advent Calendar(Adventar) の13日目です。パスワード保存に使うBCryptの話をします。 安全にパスワードを保存する 皆様、パスワードをセキュアに保存しているでしょうか？まさかとは思いますが、パスワードを生で保存するとかおぞましいことをしてないでしょうか？ パスワードは攻撃者によってソースコード・DBすべて取得されたとしても、元のパスワードを類推することを不可能とするように保存することにより、パスワード漏洩最後の砦として機能させることが望ましいです。 この条件を満たす方法として、パスワードをHash化して保存する方法があります。ただし単純なHash化では駄目です。まず、類推されにくくて衝突しずらい、暗号学的に良いHash関数アルゴリズムが必要です。また、よくあるHash関数アルゴリズムは(元々高速に計算することを意図していたのもあ

開発部のにゃんです。主にバックエンドを弄っております。 Webアプリケーションではセキュリティ対策のためにランダムな文字列を使用する場面が多々あります。例えば CSRF対策のトークン OAuthやOpenID Connectで使用するnonce, state, code_verifier メールの到達確認用URLのトークン パスワードをhashする際に使用するsalt セッションID これらの値は単に衝突しなければOKというものではありません。十分なセキュリティ強度を確保するためには推測不可能なランダム値を使う必要があります。 以下は推測不可能なランダム値ではありません。セキュリティが求められる場面では使ってはいけません。 Math.randomなどの疑似乱数 日付やユーザ情報のハッシュ ではどのような値が適切なのでしょうか？ /dev/randomと/dev/urandom Linuxに

ストレッチングは必要なのか 皆さんは「ストレッチング」という手法をご存知でしょうか。 以前からたびたびTwitter上で「ストレッチングは行う必要があるのか」という議論が交わされています。 最近では太田さんが自身の開発体験を踏まえ、ストレッチングのエントリをされています。 ストレッチング採用の理由−水無月ばけらのえび日記 徳丸本のあれこれを実践してみて気付いたこと−水無月ばけらのえび日記 また、北河さんや徳丸さんはストレッチングの必要性に関して次のようなつぶやきをされています。(これだけでは断片的なのでできれば前後の内容も参照してください。) http://twitter.com/kitagawa_takuji/status/61258646180470784:twitter:detail:left http://twitter.com/ockeghem/status/7510281023

はじめに 背景 これを知っていたからと言って何かの役に立つかというと、そうでない人の方が多いとは思うのですが、いい加減、SSHの公開鍵認証の説明がデマばかりなので、少しはちゃんとした説明もあった方が良いかもな、ということで記事にしました。 SSHについて 皆さんご存知の通り、SSHはSecureSHellの略であり、暗号によって保護された通信を通じて遠隔操作を行う1アプリケーション、またはプロトコル2を指します。 Linux等のUNIX系OSの遠隔操作3、またはネットワーク機器の管理に広く使われており、その実装としてはOpenSSHが有名です。 ところでSSHには、接続してきたユーザが誰なのかを識別する認証機能があり、その方式としてパスワード認証と並んで最もメジャーなのが公開鍵暗号を用いる公開鍵認証です。4 しかし…。残念なことに、公開鍵認証の設定や使い方はともかくとして、その仕組みに対す

JAWS DAYS 2019に登壇した時の資料です。 セッション中の攻撃デモの動画は以下となります。 https://youtu.be/AyzrYEM601wRead less

みなさん正規表現は好きですか？ 私は好きです。簡単に脆弱性を作り込めて、とても便利ですからね。 この記事ではPCRE関数(preg_match(), preg_replace()など)を利用して、みなさまにPHP正規表現のバッドノウハウを教示いたします。 先に結論を書きます 単独の文字列のマッチに $ を用いるのは予期しないパターンになるのでやめましょう。^は特に危険ではありませんが、^と$の組み合せではなく\Aと\zの組み合せを覚えましょう。ただし、m修飾子で複数行(マルチラインモード)で、行頭と行末にマッチさせたい場合を除きます。 文字列のマッチに ^ と $ のペアを利用する そうですね、例としてQiitaのようなユーザー登録サイトの表示名 @tadsan のような文字列を登録する前の検査をするとします。 要件としては、使用可能な文字は abcdefghijklmnopqrstuvw

はじめに 筆者は10年以上ウェブアプリケーション開発を主な業務とするJavaプログラマであったにも関わらず、Strutsについてはこれまでずっと食わず嫌いでした。初期のStrutsは「XMLだらけで効率が悪そう」というイメージが強かったためです。最近はRuby on Rails等の影響を受けCoC(convention over configuration)を採り入れ、XML地獄もだいぶ解消したようです。 StrutsはJavaアプリケーションらしくない種類（任意のコード実行等）の脆弱性を連発することでも知られており、最近は我々の提供するSaaS型WAFサービス、Scutum(スキュータム)のお客様からも頻繁にStrutsについての問い合わせを受けるようになりました。また、去年見つかった任意のコード実行の脆弱性では、脆弱性の公表後すぐにPoCが出回り実際に攻撃が発生するなど、悪い意味で注目