はじめに Next.jsのApp routerは、server components/server actionsによって、フロントエンドとバックエンドを型安全にやり取りでき、開発体験がとても良いですよね。 しかし、フロントエンドとバックエンドの境目がわかりづらくなったので、何も考えずに実装していると、フロントエンドにセキュアな情報が露出してしまうリスクが高まります。 そこで今回は、App routerを使う中で、セキュリティで気をつけることを紹介します。 先に言うと、フロントエンドとバックエンドの境目に気を遣えば基本良いかなと思います。 クライアントコンポーネントのpropsを本当に必要な情報だけにする App routerでは、 をする流れが多いです。 クライアントは、サーバーのデータをpropsで受け取れてしまうので、props経由で受け取るデータを気をつける必要があります。 例えば
APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface of Object Level Access Control issues. Object level authorization checks should be considered in every function that accesses a data source using an ID from the user. Authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementa
Intro CSRF という古の攻撃がある。この攻撃を「古(いにしえ)」のものにすることができたプラットフォームの進化の背景を、「Cookie が SameSite Lax by Default になったからだ」という解説を見ることがある。 確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の本質から言うと、解釈が少しずれていると言えるだろう。 今回は、「CSRF がどうして成立していたのか」を振り返ることで、本当にプラットフォームに足りていなかったものと、それを補っていった経緯、本当にすべき対策は何であるかを解説していく。 結果として見えてくるのは、今サービスを実装する上での「ベース」(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件 例えば、攻撃者が用意した attack.examp
先日、Kamal 2でNext.jsを安価なVPSにデプロイする勉強をしながら、Next.js App Router/Server ActionでCRUDのデモアプリを作成しました（コードはGitHub）。そのときにセキュリティについて気になって点がいくつかあり、勉強しながら対策をしましたので紹介したいと思います。 私自身は業務でNext.jsを書いた経験が限定的です。的外れな議論をしているかもしれません。あくまでもRuby on Railsアプリを書くときと同じ気持ちでNext.jsのアプリを書いたとき、セキュリティ上で気になった点を挙げているだけです。私が見落としている点や誤っている点等ありましたら、コメントやX等で教えていただけると大変ありがたいです。 その１：データ漏洩の危険性 この問題についてはムーザルちゃんねるが紹介しています。またNext.jsの公式ブログでも対策が紹介されて
こんにちは、ソフトウェアエンジニアの中村 ( id:kozy4324 ) です。 2024年10月25日 (金) から 26日 (土) に、東京の有明セントラルタワーホール & カンファレンスで開催予定の Kaigi on Rails 2024 にて、「ActiveRecord SQLインジェクションクイズ (Rails 7.1.3.4)」というタイトルで登壇させていただくことになりました。 今回は、このテーマを選んだ背景や、登壇を通じて達成したいことについて、事前にお伝えしようと思います。 Rails アプリケーション開発におけるセキュアコーディング、できていますか？ これは自戒の念を込めた問いかけでもあります。 昨年末、私は Ruby on Rails を使った新規サービス開発プロジェクトにジョインしました。それを機に、Rails におけるセキュアコーディングを再確認したいと思い、情報
高度診断部アプリケーションセキュリティ課の山崎です。 弊社エンジニアの名古屋と山崎がRuby on RailsのActive Storageの脆弱性CVE-2024-26144を報告しました。 本脆弱性はRailsの5.2.0から7.1.0のバージョンに影響するもので、お使いのRailsのバージョンが最新でない場合にはアップデートを推奨します。 本記事では本脆弱性の注意点と、関連してCookieのキャッシュに関する調査内容を紹介します。 TL;DR ・ Set-Cookieヘッダがキャッシュされると別人ログイン問題が発生する ・ RailsのActive StorageでSet-Cookieヘッダがキャッシュ可能な設定であった(CVE-2024-26144) ・ Nginx(+ Passenger), Apache(+ mod_cache)等のキャッシュ機構と合わせて利用すると実際に事故が
2024年7月1日、OpenSSHの開発チームは深刻な脆弱性 CVE-2024-6387 が確認されたとしてセキュリティ情報を発出し、脆弱性を修正したバージョンを公開しました。この脆弱性を発見したQualysによれば、既定設定で構成されたsshdが影響を受けるとされ、影響を受けるとみられるインターネット接続可能なホストが多数稼動している状況にあると報告しています。ここでは関連する情報をまとめます。 概要 深刻な脆弱性が確認されたのはOpenSSHサーバー（sshd）コンポーネント。脆弱性を悪用された場合、特権でリモートから認証なしの任意コード実行をされる恐れがある。 悪用にかかる報告などは公表時点でされていないが、glibcベースのLinuxにおいて攻撃が成功することが既に実証がされている。発見者のQualysはこの脆弱性の実証コードを公開しない方針としているが、インターネット上ではPoC
脆弱性検査をしていてしばしば出くわすのは、他人のCookieの値を操作できるとXSSやセッション固定等の攻撃が成功するようなWebアプリケーションです。 このようなアプリがあると、業界的には「Cookie Monsterという問題がありまして、、、でも、、、基本的に現状のブラウザではリスクは低いです」みたいな話がされることが多いのではないかと思います。 本日の日記では、それ（Cookie Monster）以外にも状況によっては考慮すべきことがある、という話をしたいと思います（過去の日記でも少し書いた話ですが、もう少しちゃんと書いておこうと思います）。 通信経路上に攻撃者がいる 被害者のブラウザとサーバの通信経路上に、アクティブな攻撃者がいると想定しましょう。 そのような状況では、攻撃者は正規のサーバになりかわってブラウザと通信をしたり、ブラウザと正規のサーバで交わされる通信に介入することが
ガイドラインへのリンクは、PDFではなく、本ページ（https://www.soumu.go.jp/main_sosiki/cybersecurity/wi-fi/）へのリンクとしていただけますようお願いします。 自宅Wi-Fi利用者向け 簡易マニュアル（令和6年3月版） 総務省では、自宅Wi-Fiの利用者に対し、安全な自宅Wi-Fiの利用のために必要なセキュリティ対策等に関する理解を深めていただくことを目的としたガイドラインとして、「自宅Wi-Fi利用者向け 簡易マニュアル」を作成しています。 セキュリティ対策の3つのポイントとして、 ポイント1 セキュリティ方式 は「WPA2またはWPA3」を選択しよう ポイント2 パスワードは第三者に推測されにくいものにしよう ポイント3 ファームウェアを最新の状態にしよう を示すとともに、わかりやすく解説を加えています。 なお本マニュアルは動画でも
概要 元サイトの許諾を得て翻訳・公開いたします。 英語記事: Beware of <%== in your erb files - Andy Croll 原文公開日: 2023/07/17 原著者: Andy Croll 日本語タイトルは内容に即したものにしました。 参考: §7.3 クロスサイトスクリプティング（XSS） -- Rails セキュリティガイド - Railsガイド Rails: ERBファイルで<%==を使うときはセキュリティに注意（翻訳） クロスサイトスクリプティング（XSS）は、他のユーザーが閲覧するWebページに対して悪意のあるスクリプトを注入可能になる一般的な脆弱性です。こうしたスクリプトは、個人情報の抜き取りやページコンテンツの操作といった悪意のある操作を攻撃者に代わって実行するのに使われる可能性があります。 Railsのようなフレームワークを使うメリットのひと
中小企業のセキュリティ年間予算は「100万円以下」司会者：「ハッカーが教える、妥協しない高コスパなセキュリティ対策」と題し、一般社団法人日本ハッカー協会代表理事・杉浦隆幸さんよりご講演いただきます。それでは杉浦さん、よろしくお願いいたします。みなさん盛大な拍手でお迎えください。 （会場拍手） 杉浦隆幸氏：今日は「ハッカーが教える、妥協しない高コスパなセキュリティ対策」ということで、私もいろんなセキュリティ製品やセキュリティの施策を見ていますが、その中で中小企業の人たちがどういうことをやると効果的なセキュリティ対策ができるかについて、簡単に説明したいと思います。 私は日本ハッカー協会の代表理事で、それまではセキュリティ企業を立ち上げて、バイアウトしてということをやっておりました。現在はいろんな会社さんや官公庁も含めて、セキュリティのコンサルティングやセキュリティの面倒をみたりということをして
不正アクセスによるIDとパスワードの漏洩を受けて、MD5によるハッシュ化について話題になっていました。システムを作る上で、パスワードの管理や認証はどう設計すべきかを考えるために、少し整理をしてみます。もし事実誤認があれば、どしどしご指摘ください。 == 2023/8/21追記 == この記事は、ハッシュの保存の仕方一つとっても、沢山の対策方法が必要であるということをお伝えするために記載しています。そして、これから紹介する手法を取れば安全とお勧めしている訳ではないので、その点をご留意いただければと思います。攻撃手法に応じての対応策の変遷を知っていただくことで、セキュリティ対策は一度行えば安全というものではないことを知って頂くキッカケになれば幸いです。 == 追記終わり == パスワードのハッシュ化 まず最初にパスワードの保存方法です。何も加工しないで平文で保存するのは駄目というのは、だいぶ認
ビジネス特化型SNSのLinkedInで、多数のアカウントがセキュリティ上の問題でロックされたり、攻撃者に乗っ取られたりしていると、セキュリティ企業・Cyberintが発表しました。LinkedInはこの件を公にしていませんが、ハッキング被害に関連したGoogle検索が過去数カ月間で50倍に急増していることから、その被害の甚大さがうかがえると指摘されています。 LinkedIn Accounts Under Attack https://cyberint.com/blog/research/linkedin-accounts-under-attack-how-to-protect-yourself/ LinkedIn accounts hacked in widespread hijacking campaign https://www.bleepingcomputer.com/news/
（結論はなく、ダラダラ昔話を書いただけ。） サービスやプロダクトの開発にあたって、自社外で開発されたオープンソースソフトウェア（OSS）を外部コンポーネントとして使うという場面は今や当たり前だと思うけど、そのOSSができるだけ長く保守開発を続けてくれるにはどうしたらよいか、ということまで考えることは少ないだろう。 OSSはそのライセンス遵守の上では金銭を支払うことなく自由にサービスやプロダクトに使えるし、うまく機能がハマれば開発の費用・時間コストを大幅に軽減できる。 ただ、そうしてできた素晴しいサービス、プロダクトのアーキテクチャを見返してみると、個人の手弁当のOSSが危ういバランスを支えてSPOF的に存在していることがある。ジェンガの絵がよく出てくるよね( File:dependency.png - explain xkcd )。 Someday ImageMagick will fin
7/14/20232023年7月14日よりTBS金曜ドラマ『トリリオンゲーム』の放送が始まりました。弊社エンジニアチームは、1話のハッキングシーン作成にIT・セキュリティ技術協力として携っています。本記事では、その背景と詳細を解説します。 『トリリオンゲーム』は起業家とエンジニアの成長物語で、原作からドラマに至るまで、Flatt Security様による的確な技術監修がなされています。このたび弊社は、原作と台本のシナリオに基づいて、 現実的に可能なハッキングシナリオの具体化 詳細が設定されていなかったプログラムの作成 実際のプログラム・コマンドに合わせたセリフ・演技指導 セキュリティチャンピオンシップのルール設定、画面作成支援 を行いました。 金曜ドラマ『トリリオンゲーム』｜TBSテレビ 以降、作成した資料や作成の舞台裏をピックアップして紹介します。 ■ 免責事項 本記事は、ドラマ中の技術
0_medium_vuln_en.md Disclosure of a vulnerability that allows the theft of visitors' email addresses using Medium's custom domain feature Author: mala Introduction This article describes a vulnerability in a web service called Medium that allows you to steal visitors' e-mail addresses by using custom domain plan of Medium. This is done as my personal activity and is not related to my organization.
2023.06.16 「リアルタイム応募状況」機能における個人情報の不適切利用に関するお詫びとご報告 当社が運営する転職・就職のための情報プラットフォーム「OpenWork」上で収集した個人情報について、一部、サービス上での不適切利用があったことが発覚いたしました。 4月10日にリリースした「リアルタイム応募状況」機能にて、ご本人の同意を得ずに「年齢、現年収、現職種、応募先求人、応募からの経過時間」を公開しておりました。本件発覚後、すみやかに機能の停止（6月16日完了）を行っております。 本件の対象となるユーザー様には順次、ご連絡させていただきます。 ユーザーの皆様および関係各位の皆様に多大なご迷惑とご心配をおかけしていることを、ここに深くお詫び申し上げます。 本件に関する概要と対応について、添付PDFファイルにてご報告いたします。 「リアルタイム応募状況」機能における個人情報の不適切利用
【 新機能「再指名リクエスト」のお知らせ 】 詳細は [リリースノート](https://job-draft.jp/release)をご確認ください。 【 年末年始営業のお知らせ 】 2024年12月28日(土)～2025年1月5日(日)を休業期間とさせていただきます。※年内最終営業日12月27日(金)は13時00分までの営業となります。 休業期間中にいただいたお問い合わせは2025年1月6日(月)10時30分より順次ご連絡を差し上げます。 この度、当社の運営する「転職ドラフト」上において、ご利用に関する一部のデータがHTMLソース上にて第三者による閲覧が可能な状態であったことが、2023年5月31日に判明いたしました。 判明した同日中に、閲覧が可能であった対象情報・HTMLソースの特定、及び閲覧ができない状態とする対応を完了しております。 また、本件を公表するにあたっての影響範囲の調査と
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
