S3経由でXSS!?不可思議なContent-Typeの値を利用する攻撃手法の新観点 - Flatt Security Blog
はじめに セキュリティエンジニアの齋藤ことazaraです。今回は、不可思議なContent-Typeの値と、クラウド時代でのセキュリティリスクについてお話しします。 本ブログは、2024 年 3 月 30 日に開催された BSides Tokyo で登壇した際の発表について、まとめたものです。 また、ブログ資料化にあたり、Content-Type の動作や仕様にフォーカスした形で再編を行い、登壇時に口頭で補足した内容の追記、必要に応じた補足を行なっています。 また、本ブログで解説をする BSides Tokyoでの発表のもう一つの題である、オブジェクトストレージについては、以下のブログから確認をすることが可能ですので、ご覧ください。 blog.flatt.tech なぜ今、この問題を取り上げるのか？ 従来のファイルアップロードにおいて、Content-Type の値を任意の値に設定すること
令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io
Intro CSRF という古の攻撃がある。この攻撃を「古(いにしえ)」のものにすることができたプラットフォームの進化の背景を、「Cookie が SameSite Lax by Default になったからだ」という解説を見ることがある。 確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の本質から言うと、解釈が少しずれていると言えるだろう。 今回は、「CSRF がどうして成立していたのか」を振り返ることで、本当にプラットフォームに足りていなかったものと、それを補っていった経緯、本当にすべき対策は何であるかを解説していく。 結果として見えてくるのは、今サービスを実装する上での「ベース」(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件 例えば、攻撃者が用意した attack.examp
SPAセキュリティ入門～PHP Conference Japan 2021
こちらのスライドは以下のサイトにて閲覧いただけます。 https://www.docswell.com/s/ockeghem/ZM6VNK-phpconf2021-spa-security シングルページアプリケーション(SPA)において、セッションIDやトークンの格納場所はCookieあるいはlocalStorageのいずれが良いのかなど、セキュリティ上の課題がネット上で議論されていますが、残念ながら間違った前提に基づくものが多いようです。このトークでは、SPAのセキュリティを構成する基礎技術を説明した後、著名なフレームワークな状況とエンジニアの技術理解の現状を踏まえ、SPAセキュリティの現実的な方法について説明します。 動画はこちら https://www.youtube.com/watch?v=pc57hw6haXkRead less
SameSite属性とCSRFとHSTS - Cookieの基礎知識からブラウザごとのエッジケースまでおさらいする - Flatt Security Blog
こんにちは、 @okazu_dm です。 この記事は、CookieのSameSite属性についての解説と、その中でも例外的な挙動についての解説記事です。 サードパーティCookieやCSRF対策の文脈でCookieのSameSite属性に関してはご存知の方も多いと思います。本記事でCookieの基礎から最近のブラウザ上でのSameSite属性の扱いについて触れつつ、最終的にHSTS(HTTP Strict Transport Security)のような注意点を含めて振り返るのに役立てていただければと思います。 前提条件 Cookieについて Cookieの属性について SameSite属性について SameSite属性に関する落とし穴 SameSite属性を指定しなかった場合の挙動 SameSite: Strictでも攻撃が成功するケース 例1: スキームだけ違うケース 例2: サブドメイ
失効が不要なShort-lived証明書に関するmemo - ASnoKaze blog
IETFやCAB Forumで有効期限の短い証明書(Short-lived Certificate)について議論があるようなので軽く眺めておく 詳しい人は補足いただけると嬉しいです 背景 Googleでは、Webをより安全にするためにWeb PKIのポリシーについて様々な取り組みを行っています。 www.chromium.org その取り組みのなかにはCAが証明書の発行ポリシーに関するものもあります。 有効期間の短い Short-lived証明書 の利用を促し、より自動化を促進するために、CA/Browser ForumのBaseline Requirementsに対して提案を行っています。 具体的なProposalでは、OCSPをOptinalにすることと、Short-lived Certificateで失効(Revocation)が不要であるとすることを提案しています。 github.
国内で発生したSIMスワップによる不正送金事案についてまとめてみた - piyolog
2023年1月26日、愛知県警は第三者のSIMカードを不正に取得したとして男2人を逮捕したと公表しました。また2月22日には、取得した他人名義のSIMカードを用いて不正送金を行っていたとして再逮捕されました。ここでは関連する情報をまとめます。 SIMスワップで4千万円超の不正送金か 摘発されたのは神奈川県の男と東京都の男の2名で、神奈川県の男が闇バイトとして勧誘を行っていた。男2名が行っていたのは不正に取得した他人名義のSIMカードを使用しSIMスワップと呼ばれる手口で、詐取した他人名義のSIMカードを使用して不正送金を行っていた。国内で同手口の逮捕者が出るのは珍しい(詐取した他人名義のSIMカードによる不正送金事案では全国で初めて)と報じられている。*1 愛知県警は男2名に対して、2023年1月25日に詐欺と偽造有印市公文書行使、その後2月22日には不正アクセス禁止法違反、電子計算機使用
bcryptの72文字制限をSHA-512ハッシュで回避する方式の注意点
宅ふぁいる便から平文パスワードが漏洩した件を受けて、あらためてパスワードの安全な保存方法が関心を集めています。現在のパスワード保存のベストプラクティスは、パスワード保存に特化したハッシュ関数（ソルトやストレッチングも用いる）であるbcryptやArgon2などを用いることです。PHPの場合は、PHP5.5以降で使用できるpassword_hash関数が非常に便利ですし、他の言語やアプリケーションフレームワークでも、それぞれ用意されているパスワード保護の機能を使うことはパスワード保護の第一選択肢となります。 なかでもbcryptは、PHPのpassword_hash関数のデフォルトアルゴリズムである他、他の言語でも安全なハッシュ保存機能として広く利用されていますが、パスワードが最大72文字で切り詰められるという実装上の特性があり、その点が気になる人もいるようです（この制限はDoS脆弱性回避が
Why would I ever use AES-256-CBC if AES-256-GCM is more secure?
I guess the gist of my question is: Are there cases in which CBC is better than GCM? The reason I'm asking is that from reading this post by Matthew Green, and this question on cryptography stack exchange, and this explanation of an attack on XML (since I'm encrypting json in my work, although it's not streamed anywhere, but apparently a chosen cipertext attack is possible), then I should never, e
セキュリティ関連のHTTPヘッダを一括指定する Baseline ヘッダ - ASnoKaze blog
現在のWebでは、セキュリティ上レスポンスヘッダで色々なものを指定します。Webデベロッパーは個別に指定しなければなりません。 そこで、セキュリティ関連のヘッダを推奨デフォルト値に設定できるようにする「Baseline ヘッダ (Opt-into Better Defaults)」が、GoogleのMike West氏によって提案されています。 まだたたき台であり、これからW3CのWebAppSec WGで議論されている予定になっています。 Baseline ヘッダ 次のようにレスポンスヘッダを指定します。 Baseline: Security=2022これは、次のヘッダを送信するのと同様です。 Content-Security-Policy: script-src 'self'; object-src 'none'; base-uri 'none'; require-trusted-ty
パスワードレス技術の現状と未来について | フューチャー技術ブログ
はじめにこんにちは。TIG の吉岡です。秋のブログ週間 10 本目の投稿です。 2022年の 5 月に Apple, Google, Microsoft そして FIDO Alliance が マルチデバイス対応FIDO認証資格情報 を発表してから、パスワードレス技術に対する注目が高まっています。1 パスワードレスの概要について調査してまとめてみました。 目次 私たちとパスワード パスワードの抱える問題 パスワードマネージャ 公開鍵暗号の活用 パスワードレスと FIDO Alliance FIDO v1.0 FIDO2 FIDO の認証フロー Passkeys パスワードレスな未来 私たちとパスワード今日、私たちのデジタルアイデンティティはパスワードに支えられています。私たちは日々 Google で検索し、Netflix を観て、Twitter でつぶやき、Amazon で買い物をしますが
パスキーのセキュリティについて - Apple サポート (日本)
パスキーのセキュリティについて これからは、パスワードに代わってパスキーをお使いください。すばやくサインインできて使い方も簡単。そして何より、セキュリティが一段と強化されます。 パスキーはパスワードに代わるものとして設計されました。Web サイトや App にパスワードなしでサインインできるようになり、便利なだけでなく安全面も強化されます。パスキーは標準に即したテクノロジです。パスワードとは違い、フィッシング詐欺対策に優れ、常に強力で、シークレット (秘密) を共有しない設計になっています。App や Web サイトに簡単にアカウント登録できるようになる上、簡単に使えて、すべての Apple 製デバイスで横断的に機能します。実際に近くにあれば、Apple 製以外のデバイスでも使えます。 資格情報のセキュリティ パスキーは、公開鍵暗号化を用いる WebAuthentication ("Web
TrivyでAWSアカウントのセキュリティスキャンができるようになりました | DevelopersIO
中山です trivyのv0.31.0でAWSアカウントのセキュリティスキャンができるようになりました。 feat: Add AWS Cloud scanning (#2493) Releases / v0.31.0 なお、v0.31.0でスキャンを実行するとクラッシュするバグがあり、すぐにv0.31.2がリリースされました。 Releases / v0.31.2 どんな感じか気になったので、軽く触っておこうと思います。 ドキュメントを確認 まずはドキュメントを確認します。 Amazon Web Services ポイントになると思った点をまとめます。 CIS AWS Foundations Benchmark standardに準拠したチェックが可能 認証方法はAWS CLIと同じ すべてのAWSリソースに対する参照権限が必要 (ReadOnlyAccess) サービス・リージョン・リソー
正規表現の脆弱性 (ReDoS) を JavaScript で学ぶ
先日、このようなツイートを書いたところ、かなりの反響がありました。 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) と呼ばれる脆弱性です。正確に理解するのが難しい脆弱性なので、少し解説してみたいと思います。 結論 長い記事になるので、最初に「とりあえずこれだけ知っ
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利用部
DNSリバインディング(DNS Rebinding)対策総まとめ
サマリ DNSリバインディングが最近注目されている。Google Chromeは最近になってローカルネットワークへのアクセス制限機能を追加しており、その目的の一つがDNSリバインディング対策になっている。Googleが提供するWiFiルータGoogle Nest WiFiはデフォルトでDNSリバインディング対策機能が有効になっている。 DNSリバインディング対策は、攻撃対象アプリケーションで行うべきものであるが、ブラウザ、PROXYサーバー、リゾルバ等でも保護機能が組み込まれている。本稿ではそれら対策機能の状況と対策の考え方について説明する。 DNSリバインディング（DNS Rebinding）とは DNSリバインディングはDNS問い合わせの時間差を利用した攻撃です。DNSのTTL（キャッシュ有効期間）を極めて短くした上で、1回目と2回目の問い合わせ結果を変えることにより、IPアドレスのチ
【マジで】サイバー演習シナリオの作り方【怖い】 - freee Developers Hub
「CEOに身代金を要求したい」 こんにちは、PSIRTマネージャのただただし（tdtds）です。この記事はfreee Developers Advent Calendar 2021 18日目です。 freeeにjoinしてから早くも14ヶ月がすぎました。freeeでは毎年10月に全社障害訓練をしていて、昨年は入社したてで右も左もわからないままAWS上の本番環境（のレプリカ）に侵入してDBをぶっ壊す役目をさせられたのも良い思い出です*1。 で、上の「CEOに身代金を要求したい」という物騒な相談は、今年の訓練計画の話です。話を持ち掛けてきたのはCIOの土佐。昨年は主要サービスが落ちて、開発チームが対応にあたる中、ビジネスサイドも顧客対応などで訓練参加しましたが、今年はさらに、経営サイドまで巻き込もうというゴール設定がされたわけですね。腕が鳴ります。 ゴールは「CEOに4BTCを要求する」 ゴー
Web Security
The goal of this document is to help operational teams with creating secure web applications. All Mozilla sites and deployments are expected to follow the recommendations below. Use of these recommendations by the public is strongly encouraged. The Security Assurance team maintains this document as a reference guide. Table of Contents Cheat Sheet Transport Layer Security (TLS/SSL) HTTPS HTTP Stric
OWASP Secure Headers Project | OWASP Foundation
This website uses cookies to analyze our traffic and only share that information with our analytics partners. Accept Introduction 🎯 The OWASP Secure Headers Project (also called OSHP) describes HTTP response headers that your application can use to increase the security of your application. Once set, these HTTP response headers can restrict modern browsers from running into easily preventable vul
Content Security Policy でユーザーを守ろう
はじめに こんにちは、ビットバンクのチーフ・ビットコイン・オフィサーのジョナサンです。 最近仮想通貨以外のセキュリティー面を色々と調査しておりましたが、その中でも一番注目している Content Security Policy (CSP) についてお話できればと思っています。 仮想通貨を扱うことのありそうなウェブサービスを運営される皆さんにも是非検討していただきたいものです。 Content Security Policy (CSP)は誰を守る？ CSPの仕組みから説明すると分かりやすいと思います。CSPが活用される時、以下のような流れになります。 ウェブサービスはHTTPレスポンスのヘッダ(若しくはタグ)にて Content-Security-Policy のヘッダを返す 利用者のブラウザがそのヘッダを見ると、ヘッダに記載されたルールに従いCSPを有効化する 例： default-src
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
クラウドサービスセキュリティチェックDB | マネーフォワード Admina
