タグ

Securityとsecurityに関するo_hiroyukiのブックマーク (510)

  • 徳丸浩氏に聞く クレカ情報の漏洩が非保持化でも起こるワケ 2つの攻撃手法と対応策

    徳丸浩氏に聞く、クレカ情報の非保持化に潜む漏洩リスクとEC事業者の対策 ECサイトやWebサービスからの情報漏洩が相次いでおり、クレジットカード番号やセキュリティコードなど、機微な情報が漏洩する事案も散見されます。特に、クレジットカード情報は、2018年に施行された改正割賦販売法にもとづき、ECサイトやWebサービスの運営事業者では事実上、保持しないこと(非保持化)が義務付けられているなか、なぜ漏洩被害が発生してしまうのでしょうか。 記事では、ECサイトからの漏洩事案を題材として、Webセキュリティの専門家である徳丸浩氏に「なぜクレジットカード情報の漏洩が起こってしまうのか」「ECサイト事業者はどのような対策をとるべきか」「漏洩が発生した場合、どんな流れで対応すべきか」などを伺いました。 この記事のポイント ECサイトでクレジットカード情報の漏洩事案が発生するのは、ECサイトの利用者がク

    徳丸浩氏に聞く クレカ情報の漏洩が非保持化でも起こるワケ 2つの攻撃手法と対応策
  • 「クレカを止めても不正利用が止まらない」のメカニズム【鈴木淳也のPay Attention】

    「クレカを止めても不正利用が止まらない」のメカニズム【鈴木淳也のPay Attention】
  • ブラウザ開発者ツールのネットワークタブに表示されない情報送信手法 - Qiita

    はじめに はじめまして、セキュリティエンジニアのSatoki (@satoki00) です。今回はブラウザの開発者ツールのネットワークタブから隠れて、Webサイト内の情報を送信する手法をまとめます。所謂Exfiltrationというやつです。中にはCSPの制限をBypassするために用いられるテクニックもあります。CTFなどで安全に使ってください。 前提 発端はWeb上でテキストの文字数をカウントできるサイトが閉鎖する際の話です。カウント対象のテキストデータがサイト運営 (やサイトを改竄した攻撃者) に盗み取られていないかという議論が巻き起こっていました。「盗み取られていない」側の主張は、ブラウザの開発者ツールのネットワークタブにリクエストを送信した形跡がないというものでした。ここで ブラウザの開発者ツールのネットワークタブに表示がなければ外部へデータを送信していないのか? といった疑問が

    ブラウザ開発者ツールのネットワークタブに表示されない情報送信手法 - Qiita
  • Webサービス公開前のチェックリスト

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

    Webサービス公開前のチェックリスト
  • ISPの送信ドメイン認証実装状況 | 送信ドメイン認証|迷惑メール相談センター

    2024/05/01 トピックス 特定電子メール法に違反しているSMSの情報提供のお願い 2024/09/02 注意喚起 労働金庫になりすました偽メール「件名:【労働金庫】振込(出金)、ATMのご利用(出金)利用停止のお知らせ」(偽メールは、実在の企業・団体と無関係に送信されたものです) 2024/09/02 注意喚起 アプラスカードになりすました偽メール「件名:NETstation*APLUSキャンペーン:3,000ポイントプレゼント!」(偽メールは、実在の企業・団体と無関係に送信されたものです) 2024/09/02 注意喚起 農業協同組合になりすました偽メール「件名:【農業協同組合】振込(出金)、ATMのご利用(出金)利用停止のお知らせ」(偽メールは、実在の企業・団体と無関係に送信されたものです) 2024/09/02 注意喚起 ドコモになりすました偽メール「件名:【重要】dо

  • 「パスキー」のユーザー体験を最適化させるデザインガイドライン、FIDOアライアンスが公開

    パスワードレスなユーザー認証を実現する業界標準である「パスキー」を策定するFIDOアライアンスは、パスキーのユーザー体験を最適化させるためのデザインガイドラインの公開を発表しました。 パスキーは、従来のパスワードによるユーザー認証よりも強力で安全な認証方式とされており、普及が期待されていますが、多くのユーザーが慣れ親しんできたパスワード方式と比べると、サインアップやサインインの方法が分かりにくいという課題が指摘されていました。 FIDOアライアンスによるデザインガイドラインの公開は、こうした状況を改善するものとして期待されます。 パスキーのデザインガイドラインの内容 デザインガイドラインは主に以下の要素から構成されています。 UXの原則(UX princeples) コンテンツの原則(Content principles) デザインパターン(スキーマ、サンプルビデオ、AndroidとiOS

    「パスキー」のユーザー体験を最適化させるデザインガイドライン、FIDOアライアンスが公開
  • テキスト生成AI利活用におけるリスクへの対策ガイドブック(α版)|デジタル庁

    デジタル庁では、デジタル社会の実現に向けた重点計画(令和4年6月7日閣議決定)を踏まえ、AIの実態と動向を把握し、リスクと必要な対応策を特定したうえで、官民における適切な活用の検討を進めています。 昨今の生成AIなどの技術革新により、さまざまな利点を得られるようになってきており、政府でも、このような技術の動向を見極めつつ、関係省庁における生成AIの業務利用について第10回デジタル社会推進会議幹事会・書面開催等の議論を重ねてきました。また、2023年12月より生成AIの適切な利活用に向けた技術検証を実施し、その結果※を公開しました。 ※技術検証結果の詳細は、2023年度 デジタル庁・行政における生成AIの適切な利活用に向けた技術検証を実施しましたをご覧ください。 これまでの議論の経緯や検証結果を踏まえ、「テキスト生成AI利活用におけるリスクへの対策ガイドブック(α版)」として公開します。実際

    テキスト生成AI利活用におけるリスクへの対策ガイドブック(α版)|デジタル庁
  • 総務省|報道資料|「クラウドの設定ミス対策ガイドブック」の公表

    総務省は、今般、令和4年10月に公表した「クラウドサービス利用・提供における適切な設定のためのガイドライン」の内容を、わかりやすく解説するために「クラウドの設定ミス対策ガイドブック」を策定いたしました。 総務省では、クラウドサービス利用・提供における適切な設定の促進を図り、安全安心なクラウドサービスの利活用を推進するため、クラウドサービスの提供者・利用者双方が設定ミスを起こさないために講ずべき対策や、対策を実施する上でのベストプラクティスについてとりまとめた「クラウドサービス利用・提供における適切な設定のためのガイドライン」を、令和4年10月に策定・公表しました。 今般、クラウドサービスを利用する事業者において、情報の流失のおそれに至る事案が引き続き発生している中で、ガイドラインの活用促進を図るため、ガイドラインの内容をわかりやすく解説した「クラウドの設定ミス対策ガイドブック」を策定しま

    総務省|報道資料|「クラウドの設定ミス対策ガイドブック」の公表
  • 令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io

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

    令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io
  • IPA、「情報セキュリティ10大脅威 2024」の解説および対策のための資料公開 

    IPA、「情報セキュリティ10大脅威 2024」の解説および対策のための資料公開 
  • GPT-4にWebサイトを“自律的に”ハッキングさせる方法 AI自身が脆弱性を検出、成功率70%以上【研究紹介】

    UIUC(イリノイ大学アーバナ・シャンペーン校)に所属する研究者らが発表した論文「LLM Agents can Autonomously Hack Websites」は、大規模言語モデル(LLM)を用いたAIエージェントに、自律的にWebサイトをハッキングさせる攻撃手法を提案した研究報告である。LLMエージェントがWebサイトに存在する脆弱性を事前に知らなくても、自動検知してのハッキングが可能となる。 ▲自律型LLMエージェントを使ったWebサイトのハッキングの模式図 keyboard_arrow_down 研究内容 keyboard_arrow_down 研究結果 Webサイトを自律的にハッキングするようLLMエージェントを活用するには、エージェントのセットアップと、目標に向けてのプロンプトによる指示という2つのステップが必要である。エージェントによるハッキングでは、関数呼び出し、文書

    GPT-4にWebサイトを“自律的に”ハッキングさせる方法 AI自身が脆弱性を検出、成功率70%以上【研究紹介】
  • AIセーフティ・インスティテュートを設立しました (METI/経済産業省)

    AIの安全性に対する国際的な関心の高まりを踏まえ、AIの安全性の評価手法の検討等を行う機関として、内閣府をはじめとする関係省庁、関係機関の協力の下、日独立行政法人情報処理推進機構(IPA)にAIセーフティ・インスティテュートを設置しました。 AIの安全性に対する国際的な関心の高まりを踏まえ、AIの安全性の評価手法の検討等を行う機関として、AIセーフティ・インスティテュート(所長:村上明子氏)を日設立しました。同機関は、内閣府をはじめ関係省庁、関係機関の協力の下、独立行政法人情報処理推進機構(IPA)に設置されます。 我が国として、AIの安全性評価に関する基準や手法の検討等を進めるにあたり、米国や英国のAIセーフティ・インスティテュートをはじめ、諸外国の同様の機関と連携を深めてまいります。 経済産業省としても、IPAに加え、国立研究開発法人産業技術総合研究所も通じて培ってきたAIの知見や

  • パスキーの基本とそれにまつわる誤解を解きほぐす

    2023 年は文句なく「パスキー元年」になりました。非常にたくさんのサービスがパスキーに対応し、2024 年はいよいよパスキー普及の年になりそうです。 記事では、パスキーの基を振り返ったうえで、パスキーでみなさんが勘違いしやすい点について解説します。 2023 年は当にたくさんのウェブサイトがパスキーに対応しました。例を挙げます: Adobe Amazon Apple eBay GitHub Google KDDI Mercari Mixi MoneyForward Nintendo NTT Docomo PayPal Shopify Toyota Uber Yahoo! JAPAN もちろんこのリストですべてではないですが、これらだけでも、世界人口のかなりをカバーできるはずで、まさに大躍進と言えます。もしまだパスキーを体験していないという方がいたら、ぜひこの機会にお試しください。

    パスキーの基本とそれにまつわる誤解を解きほぐす
  • 敵対的プロンプト技術まとめ - Qiita

    こんにちは@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サービスが敵対的なプロンプト手法に対応できるように公開をしたものであり,利用を

    敵対的プロンプト技術まとめ - Qiita
  • いろんなウェブサービスにパスキーでログインしてみる

    2023/12/12 記事公開 2023/12/14 調査サービスの差し替え & コメント返信 はじめまして。kinmemodokiです。 この記事はDigital Identity技術勉強会 #iddance Advent Calendar 2023の12日目の記事です。 2023年では様々なウェブサービスがパスキーに対応し様々なログインUXが生まれました。 記事はそのさまざまなウェブサービスのパスキーによるログインUXの挙動をまとめ、挙動の考察を行いました。 記事で扱うのは「ウェブサービスのパスキーでのログインUX」についてであり、「パスキー周りの実装や技術」については基的に扱いません。 なお、記事では「WEB+DB PRESS Vol.136「特集2 実戦投入パスキー ─いまこそ実現、パスワードレス認証!」」の「第2章 パスキー時代の認証UX」を参考にしており、最低限の部分は

    いろんなウェブサービスにパスキーでログインしてみる
  • スマホアプリの脆弱性診断って何するの?(iOS編) - STORES Product Blog

    *記事は STORES Advent Calendar 2023 6日目の記事です こんにちは。セキュリティ部のsohです。 現在、弊社ではスマホアプリ診断内製化の準備を進めています。 同じようにスマホアプリの脆弱性診断を内製化したい、というニーズがある会社は多く存在しますが、実際のところ、スマホアプリを対象とした脆弱性診断士の確保は困難であり、外部ベンダーの方にすべてお願いせざるを得ないケースも多いかと思います。 また、その情報の少なさから、スマホアプリ診断を実施したいと考えている開発者や脆弱性診断士にとっても、「何をやればいいのか」「何から始めればいいのか」がわからないものである場合は多いかと思います。 そこで、この記事では「スマホアプリ診断って実際何をしているのか」と疑問を持つ方をターゲットとして、一般的なスマホアプリ診断の検証要件や検証方法について解説します。 要件とガイドライ

    スマホアプリの脆弱性診断って何するの?(iOS編) - STORES Product Blog
  • メールアドレスをキーにしてID連携を行う設計の危うさ|ritou

    ritouです。このしずかなインターネットにおける初投稿です。 おそらく、このしずかなインターネットのID連携では次のような設計になっていま「した」。問い合わせをさせていただき、対応いただきました。 これまでもQiitaなどで同様の実装例が紹介されていた際にはコメントさせていただいていたものですので、アンチパターンの紹介記事として読んでいただければと思います。 「Googleアカウントでログイン」ではじめると、ユーザーが作成され、Googleから受け取ったメールアドレス([email protected])が設定される 次回から「Googleアカウントでログイン」をすると、Googleから受け取ったメールアドレスでユーザーを参照 試しに、次のような流れで動作を確認してみます。 「Googleアカウントでログイン」でアカウント作成([email protected]) 「メールアドレス変更」

    メールアドレスをキーにしてID連携を行う設計の危うさ|ritou
  • GPTs のプロンプトリーキング対策|ぬこぬこ

    ⚠️この記事を読んで得られる情報は、プロンプトリーキングに対する具体的な対策手法のみです。よく知られているプロンプトリーキング手法は既知の情報として一部掲載しますが、詳細な手法については言及しません。完全な対策は不可能という前提で「仮にすべてインターネットに流していいという情報」のみを Instruction プロンプトに記入&ファイルのアップロードをしてください。すぐ陳腐化する可能性があるので、適宜更新していきます。 ⚠️また、この記事の情報を知った上で、どなたかの GPTs の情報経由で取得した情報を公開したり、人の悲しむ目的に利用することを禁止します。いい人だけ読んでください。 ⚠️カッチカチに対策を施した GPTs でも簡単にリーキングできてしまうので、そもそもプロンプトで対策できるものと思わないようにしましょう。 プロンプトリーキングとは? Learn Prompting に準拠

    GPTs のプロンプトリーキング対策|ぬこぬこ
  • 警視庁に、家庭用ルーター不正利用の現状を聞く〜「“攻撃元”の家庭へ捜査員が話を聞きに行った事例も」 

    警視庁に、家庭用ルーター不正利用の現状を聞く〜「“攻撃元”の家庭へ捜査員が話を聞きに行った事例も」 
  • IPA情報セキュリティ10大脅威 知っておきたい用語や仕組み2023年5月.pdf

    情報セキュリティ 10 大脅威 知っておきたい用語や仕組み 2023 年 5 月 目次 はじめに......................................................................................................................................................... 3 1 章. 理解は必須! ...................................................................................................................................... 5 1.1. 脆弱性(ぜいじゃくせい) .............................