個人的に「Webサービスの公開前チェックリスト」を作っていたのですが、けっこう育ってきたので公開します。このリストは、過去に自分がミスしたときや、情報収集する中で「明日は我が身…」と思ったときなどに個人的にメモしてきたものをまとめた内容になります。 セキュリティ 認証に関わるCookieの属性 HttpOnly属性が設定されていること XSSの緩和策 SameSite属性がLaxもしくはStrictになっていること 主にCSRF対策のため。Laxの場合、GETリクエストで更新処理を行っているエンドポイントがないか合わせて確認 Secure属性が設定されていること HTTPS通信でのみCookieが送られるように Domain属性が適切に設定されていること サブドメインにもCookieが送られる設定の場合、他のサブドメインのサイトに脆弱性があるとそこからインシデントに繋がるリスクを理解してお

angel (as ㌵㌤の猫) @angel_p_57 @AGAINST_sa9sa9 先にデジタル署名からおさらいです。 が、その前にまず「暗号化」「復号」という用語は忘れてください。 暗号技術の一部としてまとめられていますが、「暗号化」「復号」とは機能が全然異なる技術なので、混同すると誤解の元です。 2021-11-15 20:10:26 angel (as ㌵㌤の猫) @angel_p_57 @AGAINST_sa9sa9 デジタル署名は「特定の人だけが作れて、誰でも本物と確認できるデータ『署名』」を実現する技術です。 作る(署名する)時に必要なデータを署名鍵 or 秘密鍵、確認する(検証する)時に必要なデータを検証鍵 or 公開鍵と呼びます。 2021-11-15 20:10:51 angel (as ㌵㌤の猫) @angel_p_57 @AGAINST_sa9sa9 繰り返します

Intro Referrer-Policy は、送信される Referer の値を制御することが可能だ。 このヘッダの副次的な効果をよく理解していないと、「no-referrer にして送らないのが最も安全だ」という誤解を生むことになる。 では、複数あるポリシーの中でどのような観点で、どのディレクティブを採用するのが良いのだろうか? 前提として前回の記事の「リクエストの出自をチェックすることは現代の実装のベースプラクティスである」という点を踏まえて考えてみる。 令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io https://blog.jxck.io/entries/2024-04-26/csrf.html Referer とアナリティクス Referer は、リクエストに対してその前のページの URL を送るところから始まった。 GET / H

Intro CSRF という古の攻撃がある。この攻撃を「古(いにしえ)」のものにすることができたプラットフォームの進化の背景を、「Cookie が SameSite Lax by Default になったからだ」という解説を見ることがある。 確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の本質から言うと、解釈が少しずれていると言えるだろう。 今回は、「CSRF がどうして成立していたのか」を振り返ることで、本当にプラットフォームに足りていなかったものと、それを補っていった経緯、本当にすべき対策は何であるかを解説していく。 結果として見えてくるのは、今サービスを実装する上での「ベース」(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件 例えば、攻撃者が用意した attack.examp

［注意喚起］ブラウザ互換ライブラリ「Polyfill.io」がドメイン名ごと中国企業に売却、CloudflareとFastlyが代替となる配信を開始 開発者がブラウザの互換性を気にすることなくWebアプリケーションを開発するためのJavaScriptライブラリ「Polyfill.io」が、ドメイン名ごと中国企業に売却されたことを受けて、CloudflareとFastlyが急きょライブラリをフォークし、安全が確認されているコードの配信を開始しました（Cloudflareの発表、Fastlyの発表）。 Polyfill.ioをドメインごと中国企業に売却 Polyfill.ioはAndrew Betts氏が開発したオープンソースのJavaScriptライブラリです。Polyfill.ioを組み込むことで、ブラウザのバージョンを気にすることなくWebアプリケーションの開発を行うことができる便利なラ

【以下 掲載文】 関係者様へ 敵意はありません。 お世話になっております、ITを少しかじってるブタ野郎です。 この度は、関係者様向けページを閲覧いただきありがとうございます。 さて、このページを訪れたということは、こちらのツイート(画像)より来られたかと思います。 はい、本来の「tenji.ao-buta.com」ではなく「tenji-ao-buta.com」と別のURLを入力してしまったため、このように第三者が作成したWebページに移動できてしまうのです。 セキュリティ的観点より、上記のツイートを速やかに削除し、再度告知することを提案いたします。 なお、このような事態をわかりやすく説明しているサイトがありますので共有します。 サイト上ではメールアドレスの事例ですが、今回のWebサイトでも一緒です。 上記ツイートのインプレッション数は10万件を超え、正しいリンクを貼った私のリプライでさえ、

CSRF 対策は One Time Token を form なりに付与して、サーバ側でチェックすれば良い。 それをデフォルトでサポートしてるフレームワークなどもあるし、なくてもライブラリでいくらでも対応できる。 どうせ完全にステートレスなサービスはなかなかないので、サーバ側に redis や memcache を用意するのも別に大変じゃない。 なので、 CSRF 対策として Token を付与するのは、最も安全で推奨できる方式ではある。 っていうのを踏まえた上で、もう SameSite=Lax デフォルトだけど、今でも Token 必須なの？みたいなのがたびたび話に出るので、いい加減まとめる。 前提 この話は、スコープがどこなのかによって話が多少変わるので、そこを絞る。 今回は Passive ではなく Active に対策していく場合を考えるので、前提をこうする。 SameSite=l

こんにちは@fuyu_quantです。 この記事はLLM Advent Calender 2023 17日目の記事です。 よかったらプライベートで作成したData Science wikiのGPTsも見て下さい！ はじめに 今回は敵対的なプロンプト技術についてまとめました．まとめ方は主に，Ignore This Title and HackAPrompt: Exposing Systemic Vulnerabilities of LLMs through a Global Scale Prompt Hacking Competition というLLMに対する敵対的なプロンプト技術に関してまとめた論文を参考にしています．本記事の内容が世の中のLLMを使ったサービスの機能向上の役に立てれば幸いです． ※世の中のLLMサービスが敵対的なプロンプト手法に対応できるように公開をしたものであり，利用を

最近見つけた現象で既に論じられているかと思ったがちょっと解説が見つからなかったのでまとめておく。 手短に X(旧Twitter)クライアントで表示されるTwitterカードについてカードに表示されるドメインとは違うページにリンクさせる手法が存在する この手法は第三者のTwitterカードを利用することができる つまり悪用者は第三者のTwitterカードを表示させながら自身の意図するページに閲覧者を誘導することができる これはフィッシングの手法になりうる 見つけたツイート 以下のツイートはGoogle、Bloomberg、日経ビジネスのTwitterカードが添付されているがクリックするとそれらとは異なる情報商材サイトにジャンプする。リンク先に危険な仕組みはないと思われるがクリックは自己責任で。念を入れたい人は curl -L　で。 PCブラウザでカーソルを合わせてもXの短縮URLサービスであ

こんにちは、ソーシャル経済メディア「NewsPicks」のむとうです。 先日から『Ghost of Tsushima』の開発者が書いた『ルールズ・オブ・プログラミング』という本をちょっとずつ読み進めていて、プログラミング熱が高まっています。この本は大きな指針を示すだけで具体の話をするものではないのですが、読み物として面白いので私も似たようなことをやってみたくなりました。 何年もこういう仕事をしているとバグが入るパターンというのが見えてきます。そしてだいたいどこに行っても何の仕事でも似たようなことをすることになるのですが、今回の話もその一つです。 構造化テキストを文字列結合で作らない、置換でいじらないというのはこれだけみると何のことか分かりづらいかも知れませんがSaaS Product Team セキュアコーディングの啓蒙 第2回 （SQL インジェクション編）の内容とある面では同じ話です。

2023年11月9日、いなげやは同社一部店舗で掲示していたポスターなどに記載されたQRコードへアクセスした際、予期せぬ不正サイトに誘導する広告が表示され、クレジットカード情報が盗まれる被害が発生したと公表し注意を呼びかけました。ここでは関連する情報をまとめます。 短縮URLサービス中の広告表示を起因とした事案か いなげやはネットスーパーの入会案内として、入会用サイトへアクセスさせるため店頭展示していたポスターや配布していたチラシにQRコードを掲載していた。このQRコードを読み込んだ際に、予期せぬ不正なサイトに誘導する広告が表示される場合があり、今回この不正なサイトを通じてクレジットカード情報を盗まれる事案が発生したとして顧客に対して注意を呼び掛けた。また万一クレジットカード情報を誤って入力するなどしてしまった際はカード会社に連絡を取るようあわせて案内を行っている。*1 同社が公表した資料中

doda、個人ユーザー約10万人の情報が元勤務先から丸見えだった可能性　ブロック機能が「全角半角・大文字小文字が完全一致」でないと動かず 転職サイト「doda」に不具合があり、個人ユーザー9万6338人の個人情報などが、本来権限がないはずの法人ユーザーでも確認可能になっていた可能性があると、パーソルキャリアが発表した。過去の勤務先から情報を見られないようにするブロック機能の設計に不備があったという。 パーソルキャリアは11月7日、転職サイト「doda」に不具合があり、個人ユーザー9万6338人の個人情報などが、本来権限がないはずの法人ユーザーでも確認可能になっていた可能性があると発表した。過去の勤務先から情報を見られないようにするブロック機能の設計に不備があったという。 不具合があったのは法人向けサービス「doda Request」の機能。2018年8月7日から23年10月31日にかけて、

ritouです。 サービス、ブラウザ、OSそれぞれのパスキー対応が日々進んでいます。 その中で、パスキーを利用してみて認証要素についてふと考えてしまう人がいるでしょう。 パスキー簡単！けどこれ指紋認証だけ？弱くなってない？ SMS OTPを2FAに設定し、パスワードマネージャーも使ってたから使い勝手はあまり変わらない。むしろSMS OTPがないぶんだけ弱くなった？ この辺りについて整理します。 認証要素というと、次の3つです。 SYK: Something You Know. パスワード、PIN SYH: Something You Have. 認証アプリ、TOTP生成アプリ、バックアップコード、 SYA: Something You Are. 生体認証 前にこんな記事を書きました。 この内容を説明すると、「うん、わかってる」って人は多いです。 でも、実際に使ってみると心許なく感じたりする

pictBLandとpictSQUAREに対する不正アクセスがあり、パスワードがソルトなしのMD5ハッシュで保存されていたことが話題になっています。 2023年8月16日に外部のフォーラムにpictSQUAREより窃取した情報と主張するデータ販売の取引を持ち掛ける投稿が行われた（中略）パスワードはMD5によるハッシュ化は行われているもののソルト付与は行われていなかったため、単純なパスワードが使用されていた29万4512件は元の文字列が判明していると投稿。（それ以外の26万8172件はまだMD5ハッシュ化されたままと説明。） 不正アクセスによるpictBLand、pictSQUAREの情報流出の可能性についてまとめてみた - piyolog より引用 これに関連してMD5ハッシュやソルトに関するツイート(post)を観察したところ、どうもソルトの理解が間違っている方が多いような気がしました。

作成日 2023-05-31 更新日 2023-06-02 author @bokken_ tag well-known, appsec はじめに パスワード変更のためのURLを示すための、A Well-Known URL for Changing Passwords という仕様が存在する。¶ この仕様は主にクライアントサイドのパスワード管理ツールで使われる想定の仕様だ。¶ 本記事ではこの仕様がどういうものか、どういった利点があるのかについてまとめる。¶ パスワード管理ソフトとその課題 パスワード管理ツールはクロスサイトでのパスワードの再利用を防いだり、オートフィルをしてユーザビリティを高めてくれる良いツールだ。 ブラウザにもパスワード管理ツールが搭載されていたり、有名どころでは1PasswordやBitwardenのようなツールがある。¶ これらのツールの中にはパスワードの強度を教えてく

ゴールデンウィークのはじめ（4月29日）に投稿された以下のツイートですが、5月7日20時において、1,938.8万件の表示ということで、非常に注目されていることが分かります。 我が名はアシタカ！スタバのFreeWi-Fiを使いながら会社の機密情報を扱う仕事をしてたら全部抜かれた。どうすればよい！ pic.twitter.com/e26L1Bj32Z — スタバでMacを開くエンジニア (@MacopeninSUTABA) April 29, 2023 これに対して、私は以下のようにツイートしましたが、 これ入社試験の問題にしようかな。『スタバのFreeWi-Fiを使いながら会社の機密情報を扱う仕事をしてたら全部抜かれた』と言う事象に至る現実的にありえる脅威を説明せよ。結構難しいと思いますよ。 https://t.co/LH21zphCTV — 徳丸 浩 (@ockeghem) April

初めに こんにちは。株式会社Flatt Security セキュリティエンジニアの石川です。 近年、クロスプラットフォームなデスクトップアプリケーションを作成する上で、Electronを採用することが選択肢の1つになってきています。 Electronの開発では、ライブラリとしてのElectronの実装と、その上にユーザーが構築するデスクトップアプリケーションの2つのコードが存在します。デスクトップアプリケーションの実装においても、メインプロセスとレンダラープロセス、サブフレームなど、考慮すべき概念が多数存在します。 そこで本稿では、Electronのアーキテクチャを意識しながら、実際に発見された脆弱性の傾向について考察することで、 Electron開発者が開発時に気を付けるべき点とその緩和策について、セキュリティの観点から記述していきます。 その上で、一例として、2022年のBlack H

» 今、インスタの「いいね」をめぐって起きている地獄 / いいねを付ける闇バイトに潜入し目撃した虚像だらけの世界 特集 何から話せばよいだろう。とんでもなく真っ黒で、とんでもなく複雑で、もしかしたら大事（おおごと）なんじゃないか？　ってくらい、気持ちの悪い世界を私は見ていた。 まだすべての答えは出ていないが、先に伝えておいた方が良いこともあるので、今わかっていることを書き残しておきたい。 ・「いいね」を付ける闇バイトに潜入 私が潜り込んでいたのは、インスタ（Instagram）の裏側とも言える世界である。単刀直入に言うと「闇バイト」。 「いいね」を付ける代わりに「報酬（カネ）」を得る、「いいねの労働者」になりすましていた。 極秘の潜入調査につき、身バレの危険性もあるため画像等はお見せできない。なので文章だけの記事になるが、どうか、最後まで読んでほしい。 ・闇の入り口 どのようにこの世界に入

「全く身に覚えのない家宅捜索に入られた」ここ数年、そんな話をよく聞くようになりました。その多くがサイバー犯罪で疑われるケースです。 ネットで世界中が繋がった結果、遠く離れた赤の他人と、何らかの情報が紐付くことが起こり得るようになりました。 その中には当然犯罪者も含まれており、運悪く紐付いたために警察に疑われてしまう人がいるようです。 ネットの普及により、一般市民がとばっちりで警察に目を付けられるリスクは以前にも増して高まっています。 なぜ家宅捜索に入られたのかサイバー警察に誤って家宅捜索された人たちの記事をいくつかご紹介します。 在宅エンジニアが疑われた フリーランスのエンジニアが仕事で不正サイトを調査したところ、アクセス履歴から犯人と間違われた事件です。 真犯人がVPNで身元を隠していたためか、生IPでアクセスした彼が警察に疑われてしまったようです。おそらく警察は、真犯人がヘマして生IP

リンク Yahoo!ニュース 他人の寿司にわさび乗せイタズラ...はま寿司が被害届提出へ 投稿動画が炎上→加害者謝罪も厳正対応（J-CASTニュース） - Yahoo!ニュース 他の客が注文した寿司にレーン上でわさびを乗せる、といったいたずら行為の動画がSNS上に投稿され、大手回転寿司チェーン「はま寿司」は、警察に近く被害届を出すことを2023年1月23日の取材に明らかに 285 users 1013