発生した事象は、サイトの一部ページを開いた際、ユーザー名とパスワードの入力を求める認証画面が出るというもの。象印マホービンは6月3日付の告知で、URL表示が「polyfill.io」となったログイン画面の例を示し、同じ画面が出た場合は何も入力せず「キャンセル」を選ぶよう求めている。 多くの企業は、polyfill.ioへの参照を削除対応中あるいは削除済みとしており、いずれも不正アクセスや情報漏えいは確認していないと報告している。各社は、画面にIDやパスワードを入力した場合、使い回している他サービスも含めてパスワードを変更するよう案内している。 公表したほとんどの企業が、不審なログイン画面はpolyfill.ioを経由して表示されたと説明しており、中でもFiNC Technologiesは「外部ライブラリ(polyfill.io)の改ざんに起因する」としている。 polyfill.ioはもと
オープンソースソフトウェア(OSS)の脆弱性に懸賞金をかけて発見を促し、対応を支援してきた米セキュリティ企業のHackerOneが、新規の報告受け付けを停止している。AIで生成された質の低い脆弱性報告の激増が原因といい、影響は主要OSSプロジェクトに及ぶ。同様の懸賞金プログラムを提供してきたGoogleも対応を強いられるなど、AIの影響が深刻化している現実が浮き彫りになった。 OSSの脆弱性を発見した人に懸賞金を支払うHackerOneのバグバウンティプログラムは2021年に開始され、これまでに支払われた賞金の総額は150万ドルを超える。重大な脆弱性の場合は1件あたり4000~2万5000ドルの賞金が支払われ、うち80%が発見者に、残る20%は対応に当たるOSSプロジェクト側に提供されていた。 しかしHackerOneは3月28日付けで、新規の報告受け付けを停止すると発表。理由については「
AIセーフティを標榜するAnthropicが、ビルド設定ミスで自社ツールのソースコードを丸ごと公開してしまった。未公開機能やロードマップが露出し、セキュリティ管理の教訓として記録に値する。 この記事ではClaude Codeに特化して解説します。Claude Code全般は Claude Code完全ガイド2026:インストールから本番運用まで をご覧ください。 Claude Codeソースコード流出の経緯 ── npmソースマップ混入事件 Anthropicが提供するAIコーディングツール「Claude Code」の中身が丸見えになった。 ハッキングされたわけではない。Anthropicが自分でnpm(JavaScriptのパッケージ管理システム)にコードを公開するとき、「ソースマップ」という本来含めてはいけないファイルを一緒に入れてしまった。いわば設計図を製品と一緒に箱に入れて出荷して
TL;DR 2026年3月31日、npm で最も利用されているHTTPクライアントライブラリの一つである axios がサプライチェーン攻撃を受けました。攻撃者はリードメンテナーのアカウントを乗っ取り、マルウェアを含む2つのバージョンを公開しています。 項目 内容
2019年から続けてきたPrettierのメンテナーをやめることにした。 実は直近一年では20コミットくらいしかしていなかったためもうすでに引退しているようなものだった。でもPrettierのメンテナーとして多くの人に僕のことを知ってもらって応援してもらっていたと思うので、あらためてやめることを明示的に宣言する。 やってたこと 僕がPrettierのメンテナーになったのは2019年で、筑波大学に入学した直後のことだった。それまで僕はWebアプリケーションのフロントエンドとバックエンドの開発が人並みにできるようになったという感じのスキルセットで、逆に言えば他のことは何もできなかった。 趣味か仕事かどっちかは忘れたけど、ふと見つけたPrettierのバグをなんとなく直してみて、それを繰り返しているうちにメンテナーになった。そして、今もそうだけど、当時のPrettierは人手不足だったから気づい
Sosuke is one of JavaScriptCore’s most prolific contributors, and will help us make JavaScript faster and Bun more compatible with Node https://t.co/G1BKUophlO — Jarred Sumner (@jarredsumner) August 18, 2025 8月15日にUbieを退職し、8月18日からJavaScriptランタイムを開発しているBunで働いている。住居は引き続き茨城県つくば市。 僕は直近1年半くらい余暇時間のほとんどをJavaScriptCoreの開発に費やしていて、それがBunの目に止まったらしい。いきなりBunのリクルーターからTwitterのDMで連絡をもらって、すぐにCEOのJarredと話すことになった。 J
はじめに こんにちは、GMO Flatt Security株式会社セキュリティエンジニアの石川(@ryusei_ishika)です。 近年、ChatGPT や Gemini などの大規模言語モデル(LLM)をはじめとする生成 AI の活用が急速に進んでいます。その一方で、これらの AI モデルに対する新たな攻撃手法である「プロンプトインジェクション」が注目を集めており、そのセキュリティリスクが問題視されています。 この記事では、プロンプトインジェクションが実際にどのような脅威となり得るのか、具体的な事例を交えながらそのリアルなセキュリティリスクを解説します。さらに、開発者や経営者が取るべき具体的な対策についても、分かりやすくご紹介します。 また、GMO Flatt Securityは日本初のセキュリティ診断AIエージェント「Takumi」や、LLMを活用したアプリケーションに対する脆弱性診
はじめに 本当に悔しいし許せないし、エンジニアとして不甲斐ないです。2025年2月26日深夜にハッキングにあいました。どのように相手と繋がり、どのような手口でハッカーに資産を抜かれたか、コードベースで全てお伝えします。今後同じ被害に遭う方が少しでも減ることがあればこんな嬉しいことはないです。 コード解説、さらに対策案も書いていきます。もし他に良い対策案などあればコメントでご教示ください。 ハッカーとのやりとりの流れ ハッカーとは Linkedin でブロックチェーンを使ったプロジェクトを手伝ってくれないかという連絡がりそこからやりとりが始まりました。そして移行の大まかな流れは下記のような感じです。 Linkedinでプロジェクトを手伝ってほしいと言う内容でDMがくる Githubリポを見て実装できそうか確認してほしいと言われる 自分のGithubアカウントを共有してプライベートリポジトリに
tech.iimon.co.jp TypeScript/JavaScriptでシングルトンオブジェクトが欲しいのであれば、 class Singleton { } export const singleton = new Singleton(); これをimportして使えば良いだけ。クラス自体をexportしなければ別のインスタンスを生成されることはないし、exportされたconstは常に同一のインスタンスであることが保証されている。 そもそも単一のインスタンスが欲しいだけならばclassを作る必要すらない。メソッドも直接オブジェクトに実装してしまえば良い。 class Singleton { name() { return 'singleton' } } export const singleton = new Singleton(); これは以下のようにも書ける export co
クイックサマリー:以前は、JavaScriptの正規表現は他の言語の正規表現に比べてパフォーマンスが劣っていたものの、近年改良が重ねられ、他の言語に見劣りしなくなっています。この記事では、Steven Levithan氏がJavaScriptの正規表現の歴史と現状を評価し、より読みやすく、保守性とレジリエンスに優れた正規表現の書き方をアドバイスします。 モダンJavaScriptの正規表現は、皆さんがよく知っている従来の正規表現と比べると随分進化しました。正規表現はテキストを検索して置き換えるツールとして非常に優れている一方で、書くのも理解するのも難しいという根強い評判があります(しかし今から説明するように、この認識は時代遅れかもしれません)。 正規表現に関するこの認識は、JavaScriptに特に当てはまります。PCREやPerl、.NET、Java、Ruby、C++、Pythonといっ
Deno Land Inc.は2024年10月9日、同社が開発するJavaScript/TypeScriptランタイム環境Denoの新バージョンDeno 2.0のリリースをアナウンスした。 Announcing Deno 2 4 years after Deno 1.0, the next generation of JavaScript is ready for production at scale. Deno 2 is out today: 🐢 Fully backwards compatible with Node and npm 📦 Package management and node_modules and package.json 📅 Long term supporthttps://t.co/LsV4D4Too8 pic.twitter.com/F6EI3whmX8
タリーズの件、CSPが設置されていたら防げていたという話がありますが、それは正しいでしょうか? CSPを設定していなかったとしても、想定していない外部へのリクエストが発生していないか、定期的にチェックすることも大事ですよね? タリーズのサイトからのクレジットカード情報漏えいについて、CSP(Content Security Policy)やintegrity属性(サブリソース完全性)の重要性がよくわかったという意見をX(Twitter)上で目にしましたが、これらでの緩和は難しいと思います。 まず、CSPの方ですが、今回の件では元々読み込んでいたスクリプトが改ざんされたと考えられるので、オリジンとしては正規のものです。evalが使われていたのでCSPで制限されると考えている人が多いですが、evalは難読化のために使われているので、evalを使わないことは可能です。個人的には、難読化しない方が
:has()疑似クラスは筆者が断トツで一番気に入っているCSSの新機能です。筆者と同じ意見の読者も多いでしょう。少なくとも、State of CSSのアンケートに回答した方の中には多くいるはずです。セレクタを逆向きに指定できることで、これまでできると思いもしなかったようなすごいことがもっと可能になります。 「もっと」と言うのは、すでに多くの人が極めてスマートなアイデアを色々と発表しているからです。以下に一部紹介します。 Using :has() as a CSS Parent Selector and much more(Jen Simmons) Quantity Queries for “islands of elements” with the same class, thanks to CSS :has()(Bramus) Style a parent element based o
2023年後半頃から、ブラウザの「戻る」ボタンを押すと、訪問したおぼえのないページが表示されることが増えた。そういうページは大抵、記事風の広告やサイト内の記事へのリンクが大量に並ぶという構成になっている。こんなレイアウトになってることが多い。 この手法はブラウザバック広告とかブラウザバックレコメンド (あるいはレコメンデーション) とか呼ばれており、国内外の複数のWeb広告会社がこれを提供しているようだ。 たとえば、こちらはGMOアドマーケティングの “TAXEL” が提供しているブラウザバックレコメンド。 【新たな収益・回遊源が誕生!】ブラウザバックレコメンド サイトから離れてしまうユーザーに対し、広告やレコメンド記事を表示させることで、収益化や内部回遊に繋げることを目的としているフォーマットになります。 ……というのがセールスポイントらしいのだが、サイトから離れる人は、サイトから離れた
海外のセキュリティ企業「Phylum」はトロイの木馬化された「jQuery」がnpmやGitHub、jsDelivr のCDNホストで拡散している事を指摘しました。 jQueryを悪用したサプライチェーン攻撃の概要 Phylumは 2024 年 5 月 26 日以来、トロイの木馬化された jQuery のバージョンを悪用する執拗なサプライ チェーン攻撃者を監視しており、最初に npm でこのjQuery を悪用する亜種を発見しました。 そこでは、1 か月にわたって数十のパッケージで侵害されたバージョンが公開されていました。 調査の結果、GitHubや、jsDelivr の CDN ホスト リソースでも、トロイの木馬化された jQuery のインスタンスを発見しました。 なお、今回解説されている内容は正規のjQueryへ、トロイの木馬が紛れ込んでいるのではなく、 悪意のあるユーザーがnpmや
This post details CVE-2024-4367, a vulnerability in PDF.js found by Codean Labs. PDF.js is a JavaScript-based PDF viewer maintained by Mozilla. This bug allows an attacker to execute arbitrary JavaScript code as soon as a malicious PDF file is opened. This affects all Firefox users (<126) because PDF.js is used by Firefox to show PDF files, but also seriously impacts many web- and Electron-based a
Intro CSRF という古の攻撃がある。この攻撃を「古(いにしえ)」のものにすることができたプラットフォームの進化の背景を、「Cookie が SameSite Lax by Default になったからだ」という解説を見ることがある。 確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の本質から言うと、解釈が少しずれていると言えるだろう。 今回は、「CSRF がどうして成立していたのか」を振り返ることで、本当にプラットフォームに足りていなかったものと、それを補っていった経緯、本当にすべき対策は何であるかを解説していく。 結果として見えてくるのは、今サービスを実装する上での「ベース」(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件 例えば、攻撃者が用意した attack.examp
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く