サプライチェーン攻撃への防御策 | blog.jxck.io
Intro 前回は、Nx の事例をベースに「パッケージを公開する側」の対策について解説した。 今回は、「パッケージを使う側」、もっと言えば「OSS を使う上で開発者が考えるべきこと」について考察する。 OSS の危険性 npm 起因のサプライチェーン攻撃が確認されたことで「npm は危険だ」という話になると、「npm を禁止すべき」といった極端な話になったりする。 前回のブログで紹介したような対策を行うなら、多少は良くなるかもしれない。しかし、それらは全てパッケージ公開者に委ねられる。自分が公開者として実施するなら、自分が原因で攻撃が発生することは防げるだろう。 一方、攻撃に必要な突破口は 1 つあれば良い。npm にある全てのパッケージが対策されない限り、npm を主語とした安全が担保される日は来ない。 この広大な依存関係の中には、闇落ちした開発者が、それまでの善良なコードを、自分の意志
エコシステム全体でのソースコード漏洩への対処の振り返り
自分の2025年は、Viteの脆弱性の対応をし、エコシステム内の他のツールにそれを報告することから始まりました。このブログ記事は、その経験についての振り返りです。この記事は主に非技術的な側面に焦点を当てています。技術的な側面に興味がある場合は、次に書く予定の記事を参照してください。 Viteへの報告 新年の休みが開けてすぐの1月9日、ある脆弱性レポートがViteに報告されました（GHSA-vg6x-rcgg-rjx6 / CVE-2025-24010）。 その内容はViteのWebSocketサーバーがCross Site WebSocket Hijacking (CSWSH) attackに対して脆弱（CWE-1385）であり、ソースコードを外部から取得できてしまうというものでした（注: レポートの内容は報告時のものから変更されています）。 ViteのWebSocketサーバーがCSWS
Cookieの安全性を高める "__HttpOnly-"プレフィックスの提案仕様 - ASnoKaze blog
新しくCookieに"__HttpOnly-"プレフィックスを追加する『HttpOnly cookie prefix』という提案仕様が出されています。 前提: Cookie Name Prefixes について Cookieには『Cookie Name Prefixes』という仕様があります(もうそろそろRFCになります)。なお、すでにブラウザに実装されています。 Cookie名にプレフィックスをつけることで、特定の属性が付与されている事が保証されます。 例えばCookie名に "__Secure-" をつけることで、secure属性が付与されている事が保証されます。javascriptや共有先のサイトにより勝手に属性値が外されることはありません。 現在は次の２つのプレフィックスが定義されています __Secure- __Host- googleのサイトもすでに、これらがついたCookie
ISO-2022-JPの自動判定によるクロスサイト・スクリプティング(XSS)
サマリ ISO-2022-JPという文字エンコーディングの自動判定を悪用したクロスサイト・スクリプティング(XSS)攻撃について説明する。これは、文字エンコーディングを適切に指定していないウェブコンテンツに対して、文字エンコーディングをISO-2022-JPと誤認させることでバックスラッシュが円記号と解釈されることによりエスケープ処理を回避する攻撃である。本稿で紹介する攻撃は、従来からのセキュリティベストプラクティスである「文字エンコーディングの明示」に従っていれば影響を受けることはない。 はじめに クロスサイト・スクリプティング対策として、記号文字のエスケープ処理に加えて、コンテンツの文字エンコーディングをレスポンスヘッダやmetaタグで明示しましょうと言われてきました（参照）。その背景として、UTF-7という文字エンコーディングを悪用したXSSの存在がありました。この攻撃については以下
Node.jsの色々
2020-07-15 OWASP Sendai Node.js の色々 OWASP Kansai board member はせがわようすけ 長谷川陽介 (はせがわようすけ) (株)セキュアスカイ・テクノロジー 取締役CTO [email protected] https://utf-8/jp/ 千葉大学 非常勤講師 OWASP Kansai ボードメンバー OWASP Japan ボードメンバー CODE BLUEカンファレンス レビューボードメンバー OWASP Kansai Chapter 自分たちの直面するWebセキュリティの問題を 自分たちの手で解決したい！ 日本で2番目の OWASP Local Chapter Webセキュリティの悩み事を気楽に相談し情報共有できる場 スキル、役職、業種、国籍、性別、年齢に関係なし vol.16 OWASP Kansai 森田 智彦
注目したいクライアントサイドの脆弱性2選/ Security.Tokyo #3
Security.Tokyo #3の発表資料です。 クライアントサイドのパストラバーサルと、postMessage経由の脆弱性を取り上げました。
バグバウンティにおける JavaScript の静的解析と動的解析まとめ - blog of morioka12
1. 始めに こんにちは、morioka12 です。 本稿では、バグバウンティなどの脆弱性調査で行う、JavaScript の静的解析と動的解析についてまとめて紹介します。 1. 始めに 免責事項 想定読者 検証環境 静的解析と動的解析 2. 静的解析 (Static Analysis) 2.1 JavaScript File の URL を収集する getJS hakrawler getallurls (gau) 2.2 エンドポイントを列挙する LinkFinder xnLinkFinder katana jsluice endext 2.3 シークレット情報を検出する SecretFinder jsluice Mantra trufflehog 2.4 潜在的な脆弱性情報を検出する Retire.js ESLint 3. 動的解析 (Dynamic Analysis) DevTool
Exploiting XSS in hidden inputs and meta tags
Published: 11 July 2023 at 13:00 UTC Updated: 11 July 2023 at 13:00 UTC In this post we are going to show how you can (ab)use the new HTML popup functionality in Chrome to exploit XSS in meta tags and hidden inputs. It all started when I noticed the new popover behaviour with Chrome on Twitter. We all know about annoying modal dialogs that nag you to subscribe to a newsletter - now you can create
フォーム入力支援やサイト最適化サービスの改ざんについてまとめてみた - piyolog
2022年10月25日、ショーケースは同社が提供する複数のサービスが不正アクセスを受けたため、サービスを利用する企業のWebサイトを通じて入力された情報が外部へ流出した可能性があると公表しました。ここでは関連する情報をまとめます。 フォーム入力支援やサイト最適化サービス改ざんで複数社に影響波及 www.showcase-tv.com 不正アクセスによりショーケースが提供するサービスのソースコードの改ざんが行われた。対象サービスが稼働するシステムの一部で脆弱性を悪用されたことが原因。 被害に遭ったのは「フォームアシスト」「サイト・パーソナライザ」「スマートフォン・コンバータ」の3つ。フォームの入力支援やサイト表示最適化を行うサービスで利用企業は同社が公開するJavaScript (formassist.jp、navicast.jp上で公開)を自社サイトより読み込むことで利用する。 改ざん被害
SPAセキュリティ超入門 | ドクセル
スライド概要 SPA(Single Page Application)の普及が一層進んでおり、従来型のMPAを知らないウェブ開発者も生まれつつあるようです。SPA対応のフレームワークでは基本的な脆弱性については対策機能が用意されていますが、それにも関わらず、脆弱性診断等で基本的な脆弱性が指摘されるケースはむしろ増えつつあります。 本セッションでは、LaravelとReactで開発したアプリケーションをモデルとして、SQLインジェクション、クロスサイトスクリプティング、認可制御不備等の脆弱性の実例を紹介しながら、現実的な対策について紹介します。LaravelやReact以外のフレームワーク利用者にも役立つ説明を心がけます。 PHPカンファレンス2022での講演資料です。 PHPカンファレンスでの動画URL https://www.youtube.com/watch?v=jZ6sWyGxcCs
フロントエンドのコードからの情報漏洩を防ぐための工夫 - BASEプロダクトチームブログ
基盤チームの右京です。 昨今はフロントエンドのアプリケーションもリッチになり、ブラウザ上で実行されるコードが行うことの範囲も増えてきました。一方で多くのことを実装できてしまうのはリスクでもあり、BASE でも問題となることがあります。 その中でも「開発環境の URL」や「デバッグ機能の存在」ような環境毎に異なる情報は、特に意図せずに漏れやすいものだと考えています。これらはコードを記述する際に、実装方法を知識として知っていればその多くが回避可能です。この記事ではその実装例を解説しています。 コードから漏れる情報 例えば、次のようなコードがあるとします。 function debug() { // 開発環境の host であればデバッグ機能を有効にする return location.host === 'dev.example.com'; } なんの変哲もないようなコードに見えますが、ブラウザ
SPA認証トークンはlocalStorageでもCookieでもない、Auth0方式はいいねというお話 - @mizumotokのブログ
SPA認証トークンをどこに保存するかは論争が絶えません。localStorageやCookieがよく使われますが、Auth0は違う方法を採用しています。この記事では、Auth0のトークン管理の方式を理解でき、トークン管理上のセキュリティへの理解を深めることができます。 SPAの認証トークンをどこに保存するか ブラウザでトークンを保存できる場所 保存場所の比較 メリット・デメリット Auth0のアプローチ トークンはインメモリに保存 OpenID Connect準拠とトークン取得のUI/UXの悪化回避を両立 Auth0のjsライブラリ ログイン アクセストークンの（再）取得 図解 ログイン アクセストークンの（再）取得 自サービス内の認証だけのもっと簡易な構成 ログイン IDトークン取得 まとめ SPAの認証トークンをどこに保存するか React やVueで認証付きSPA（Single Pa
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フレームワークは便利な一方で
Asynchronous RegExp for node.js with termination
async_rex.js `bw �� @�� �� const { Worker, isMainThread, workerData, parentPort } = require('worker_threads') if (isMainThread) { class AsyncRex { constructor (pattern, flags) { if (pattern instanceof RegExp) { this.source = pattern.source this.flags = pattern.flags } else if (typeof pattern === 'string') { this.source = pattern this.flags = flags } else { throw new TypeError('The "pattern" argume
正規表現の脆弱性 (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) と呼ばれる脆弱性です。正確に理解するのが難しい脆弱性なので、少し解説してみたいと思います。 結論 長い記事になるので、最初に「とりあえずこれだけ知っ
Node.jsのMySQLパッケージにおけるエスケープ処理だけでは防げない「隠れた」SQLインジェクション - GMO Flatt Security Blog
※本記事は筆者styprが英語で執筆した記事を株式会社Flatt Security社内で日本語に翻訳したものになります。 TL;DR Node.jsのエコシステムで最も人気のあるMySQLパッケージの一つである mysqljs/mysql (https://github.com/mysqljs/mysql)において、クエリのエスケープ関数の予期せぬ動作がSQLインジェクションを引き起こす可能性があることが判明しました。 通常、クエリのエスケープ関数やプレースホルダはSQLインジェクションを防ぐことが知られています。しかし、mysqljs/mysql は、値の種類によってエスケープ方法が異なることが知られており、攻撃者が異なる値の種類でパラメータを渡すと、最終的に予期せぬ動作を引き起こす可能性があります。予期せぬ動作とは、バグのような動作やSQLインジェクションなどです。 ほぼすべてのオンラ
Firebase CLIとかの出力が2022-01-10の一時期に乱れてた件 - Qiita
依存の依存の場合 基本的には対象パッケージの更新待ちです。動く状態の package-lock.json が残っている場合、そのままにしておきましょう。 更新が来たら npm update で新しいバージョンがインストールされます。 ちなみに対象パッケージ自体のバージョンを下げてもたぶん改善しません。 更新が必要だったり新規プロジェクトとかでロックファイルがない場合は、直接書き換えれば差し当たりは動きます。package-lock.json から "colors" で検索してね。（このやり方で大丈夫なのか不安。） "dependencies": { "colors": { - "version": "1.4.2", - "resolved": "https://registry.npmjs.org/colors/-/colors-1.4.2.tgz", + "version": "1.4.
プログラミング言語のパッケージ管理ツールに潜む危険性
NECサイバーセキュリティ戦略本部 セキュリティ技術センター インテリジェンスチームの郡司です。今週のセキュリティブログでは、プログラミング言語のパッケージ管理ツールに潜む危険性に関する話題をお届けします。 最近のプログラミング言語にはたいてい「パッケージ管理ツール（およびパッケージリポジトリサービス）」があります。自分が作成したライブラリをパッケージという形にまとめてリポジトリに公開したり、逆に他人が作成したライブラリをリポジトリからパッケージとして追加したりといったことが簡単にできるプラットフォームが提供されています。たとえばプログラミング言語PythonではPyPI[1] 、Node.jsではnpm [2]、RubyではRubyGems [3]などです。自分が欲しいと思っている機能を誰かがすでに実装してパッケージとして公開しているのであれば、機能を一から開発しなくても、誰かが作ったパ
Frida • A world-class dynamic instrumentation toolkit
Dynamic instrumentation toolkit for developers, reverse-engineers, and security researchers. Scriptable Inject your own scripts into black box processes. Hook any function, spy on crypto APIs or trace private application code, no source code needed. Edit, hit save, and instantly see the results. All without compilation steps or program restarts. Portable Works on Windows, macOS, GNU/Linux, iOS, wa
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ReDoS 検出の最先端 recheck の紹介 / State of the Art of ReDoS Detection
