WebサイトのログインにPasskeyを追加できる新サービス「Passwordless.dev」、Bitwardenが正式公開。月間1万ユーザーまで無料
オープンソースのパスワードマネージャ「Bitwarden」などを提供しているBitwarden,Inc.は、Webサイトのログイン機能にPasskeyを簡単に追加できる新サービス「Passwordless.dev」の正式公開を発表しました。 WebサイトをPasskey対応にすることで、ユーザーはパスワードを覚えておく必要がなくなると同時に、指紋認証などの手軽な手段でWebサイトにログイン可能になります。さらに、サーバ側でのパスワード流出や、ユーザー側での偽サイトに誘導されるフィッシングなどのリスクがほとんどなくなるというセキュリティ面での大きなメリットもあります。 一方で、WebサイトをPasskey対応にするには、ログインに関わる認証のロジックを従来のIDとパスワードの組み合わせに加えて、Passkey対応を追加しなければなりません。 今回正式公開されたPasswordless.dev
[書評] ハッキングAPI ―Web APIを攻撃から守るためのテスト技法
サマリ ハッキングAPI―Web APIを攻撃から守るためのテスト技法（2023年3月27日発売）を読んだ。本書は、Web APIに対するセキュリティテストの全体像と具体的なテスト方法を記載している。ペンテスターは、APIの検出、APIエンドポイントの分析、攻撃（テスト）を行う必要があり、そのために必要な情報がすべて記載されている。また、実習のためのツールと「やられサイト」を複数紹介し、具体的なトレーニング方法を解説している。単にツールやサイトの使い方の説明にとどまらず、本格的なペネトレーションテストの考え方を説明している。 本書の想定読者はAPIのペネトレーションテストを実施するペンテスター及びペンテスターを目指す人であるが、API開発者やウェブアプリケーション脆弱性診断員にとっても有益な内容を多く含む。 重要事項説明 本書の監修者の一人（洲崎俊氏）と評者は知人関係にある 評者が読んだ書
お知らせ：民間事業者向けの業界横断的なデジタル本人確認のガイドラインが公開されました
2022 年 5 月に KYC ワーキンググループ内に設置された「本人確認ガイドラインタスクフォース」が作成した「民間事業者向けデジタル本人確認ガイドライン」が公開されました。 「本人確認ガイドラインタスクフォース」は、会員企業 10 社とデジタル庁、有識者から構成され、官民が連携して議論・検討を重ね、本ガイドラインを策定したものです。 本人確認ガイドラインタスクフォースのメンバー リーダー 株式会社TRUSTDOCK サブリーダー 株式会社NTTドコモ 構成員（50音順） 伊藤忠テクノソリューションズ株式会社 KDDI株式会社 株式会社ジェーシービー セコム株式会社 ソフトバンク株式会社 デロイト トーマツ サイバー合同会社 トッパン・フォームズ株式会社 株式会社Liquid オブザーバー（50音順） 落合孝文弁護士 OpenIDファウンデーション・ジャパン デジタル庁（吉田泰己、林達也
webサーバのログの分析2022 8月分 | ITオムライス
公開している web サーバのログから通常のアクセスではない通信について分析しました。 多かったリクエスト ルータ等のログイン画面があるかの調査 login.cgi .envの調査 /.env Hikvision製ネットワークカメラの脆弱性（CVE-2021-36260） Hikvision製ネットワークカメラの脆弱性を利用するリクエスト Miraiベースのボットネットに利用されている脆弱性のようです。 Miraiベースのボットネット：MoobotがHikvisionの脆弱性を標的に /SDK/webLanguage PHPUnitのevalをリモート実行 PHPのユニットテストツールのPHPUnitの脆弱性を利用してのeval()を実行しようとする通信 Webサイト攻撃にあったログを見る。eval()を使うPHPファイルは狙われている。 | ただ屋ぁのブログ /vendor/phpuni
The OAuth 2.0 Authorization Framework: Bearer Token Usage（日本語）
The OAuth 2.0 Authorization Framework: Bearer Token Usage（日本語） Abstract この仕様書は, OAuth 2.0の保護リソースへアクセスするために, 署名無しトークンをHTTPリクエスト中でどのように利用するか記述したものである. 署名無しトークンを所有する任意のパーティ (持参人) は, 関連づけられたリソースへアクセスするために署名無しトークンを利用できる (暗号鍵の所有を示す必要はない). 誤った利用を避けるために, 署名無しトークンは保存場所や流通経路での値の露見から守られる必要がある. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Enginee
自作サービスがDDoS攻撃された話 - 週休７日で働きたい
攻撃に立ち向かうイヌさんThe English version is available here. タイトル訂正: 「自作サービス『に』→『が』DDoS攻撃された話」「それはDDoSではない」という指摘に関して末尾に追記 (6/18)SaaSを開発していると本当にいろんな事が起こります。それらは時に開発者に喜びや悲しみ、怒り、感謝、落胆や興奮をくれます。思い返してみれば結局はみんないい思い出になるものです。先週末に、拙作の小さなウェブサービスがDDoS攻撃を受けました。言わずもがな、悪い出来事です。本稿ではこの事故がどんなものだったのか、どうやって対処したのかについてお話します。 どうもTAKUYAです。僕はInkdropというクロスプラットフォームなMarkdownノートアプリを独りで3年以上開発・運用しています。ユーザ数2万人以下のとてもニッチなSaaSで、僕はこのサービスで生計を立
Chrome 80が密かに呼び寄せる地獄 ～ SameSite属性のデフォルト変更を調べてみた - Qiita
Chrome 79以下や他ブラウザのデフォルト値。 Chrome 80からこの値を設定する場合、Secure属性も必須となる。 Aサイトに対し、Bサイトからどのようなリクエストがあっても、発行したサイトでCookieヘッダーに含める (Cookieを使用する) 図にすると以下のようになります。 Strict 外部サイトからのアクセスではCookieを送らない。 Lax 外部サイトからのアクセスはGETリクエストのときだけCookieを送る。 None 従来通りの動き。 【追記】なおChrome 80以降でSecure属性を付けずSameSite=Noneを指定した場合、set-cookie自体が無効になります。 セキュリティ上の効果 CSRF対策になります。 CSRF (クロスサイト・リクエスト・フォージェリ) とは、 WEBサイトがユーザー本人の意図した動作であることを検証していないため
W3C、パスワードを不要にする「Web Authentication」（WebAuthn）を勧告として発表。Chrome、Firefox、Androidなど主要ブラウザですでに実装済み
W3C、パスワードを不要にする「Web Authentication」（WebAuthn）を勧告として発表。Chrome、Firefox、Androidなど主要ブラウザですでに実装済み W3Cは3月4日、FIDOアライアンスのFIDO2仕様の中心的な構成要素であるWeb認証技術の「Web Authentication」（WebAuthn）が勧告になったことを発表しました。 W3Cが策定する仕様はおもに、草稿（Working Draft）、勧告候補（Candidate Recommendation）、勧告案（Proposed Recommendation）を経て正式仕様となる「勧告」（Recommendation）に到達します。今回、WebAuthnが勧告となったのに合わせて、W3CとFIDOアライアンスはWebAuthnの仕様が正式版になったことも発表しました。 WebAuthnは2018
08 S2-054, S2-055 および jackson-databindの脆弱性 CVE-2017-7525, CVE-2017-15095 について
はじめに 2017年12月1日にStruts2のセキュリティアップデートが公開されました。 2.5.14.1 リリース : https://cwiki.apache.org/confluence/display/WW/Version+Notes+2.5.14.1 S2-054 : https://cwiki.apache.org/confluence/display/WW/S2-054 S2-055 : https://cwiki.apache.org/confluence/display/WW/S2-055 攻撃の可能性について先に結論だけ書くと、これらの脆弱性が実際の攻撃として悪用される可能性は低いと考えられます。 以下、本記事でS2-054, S2-055 および S2-055 に影響を与えた jackson-databind の脆弱性について解説します。 情報が公開される前からJa
Wildcard Certificates Coming January 2018 - Let's Encrypt
Update, March 13, 2018 Wildcard certificate support is live. Let’s Encrypt will begin issuing wildcard certificates in January of 2018. Wildcard certificates are a commonly requested feature and we understand that there are some use cases where they make HTTPS deployment easier. Our hope is that offering wildcards will help to accelerate the Web’s progress towards 100% HTTPS. Let’s Encrypt is curr
Let's Encrypt、ワイルドカード証明書を2018年1月から発行
管理者は1つの証明書と鍵の組み合わせを、1つのドメインとそのサブドメイン全てに使うことができ、HTTPSの導入がはるかに容易になるという。 インターネット上の通信を暗号化するTLSの普及を目指し、無料サーバ証明書を発行する非営利認証局（CA）のLet's Encryptは7月6日、1つの証明書で複数のサブドメインの暗号化を実現できる「ワイルドカード証明書」の発行を2018年1月から開始すると発表した。「HTTPSの100％普及に向けた進展を加速させたい」としている。 ワイルドカード証明書は、ベースドメインのサブドメイン（例えば*.example.com）で無制限に利用できる。管理者は1つの証明書と鍵の組み合わせを、1つのドメインとそのサブドメイン全てに使うことができ、「HTTPSの導入がはるかに容易になる」とLet's Encryptはいう。 ワイルドカード証明書は、ACME v2 API
Zaif のセッション情報が盗まれた原因のひとつについて。JavaScript からクッキー値を取得させない方法。 - clock-up-blog
HTTP Headers という 5万人が使っている Chrome 拡張のマルウェア疑惑。セッション盗まれて BTC も盗まれそうになった話。 の続き。 今回は Chrome 拡張とは関係ない、サイト設計側の話です。 ※本記事では Zaif のセキュリティ上の問題について指摘していますが、非難の意図はありません。 続報：11月4日 Facebookコメントより。 Ryosuke Hosoi · テックビューロ CTO ご指摘ありがとうございました！少し事情があってすぐに対応出来なかったのですが、先ほどZaifの認証情報にもhttp_only属性がつくようになりました。 しかしながら、jsが汚染されていると他にもいろいろ攻撃出来てしまいますので、今回の件はこれでもう安心、というわけではないと考えています。 15時間前 11月14日時点で httponly 属性が付くようになったようです。対応
HTTP Headers という 5万人が使っている Chrome 拡張のマルウェア疑惑。セッション盗まれて BTC も盗まれそうになった話。 - clock-up-blog
疑惑どころか 99.99% くらい黒な話。 （後記：セッション盗まれたと思ってたけど、よくよく考え直してみると生パスワードごと盗まれてる可能性もあるしやばい） 追記：続報 11月3日 今回指摘した HTTP Headers 以外にも、「Tab Manager」「Give Me CRX」「Live HTTP Headers」等で同様（？）の問題が報告されています。第三者が元の作者からソフトウェア権利を買い取って悪用する、というケースが割とある模様（？）。皆さま情報ありがとうございます。 11月4日 Zaif については、「不正な Chrome 拡張」と「スクリプトから保護されていなかったクッキー」のコンボによりセッションが盗まれていた可能性あり。 Zaif のセッション情報が盗まれた原因のひとつについて。JavaScript からクッキー値を取得させない方法。 - clock-up-blog
OWASPのSQLインジェクション対策方針を読んで「おまえは俺か」と思った
つい最近まで、グローバル・スタンダードのセキュリティ施策ではバリデーションが極めて重視されている、いささか過剰ではないかと思っていたのですが、OWASPの文書を読みなおしたところ、これは僕の思い過ごしだったかと思い始めました。あくまでOWASPに限った話ではありますが… OWASP Top 10 2004については、以下のようなプレゼンをしたことがあります（2012年3月27日）。 ここが変だよ、グローバルスタンダードの脆弱性対策～入力値の考え方～ OWASP Top 10 2004をはじめとして、バリデーションが過剰に重視されているのではないかという指摘でした。 しかし、最近OWASPの文書を読みなおしてみると、OWASP Top 10 2004当時にあった「バリデーション至上主義」のようなものはすっかり影を潜め、私が（そして日本の専門家の多くが）言っていることとほとんど変わらないことに
ハッシュ衝突でTLSを破るSLOTH攻撃(CVE-2015-7575)とは何か - ぼちぼち日記
0. 簡単なSLOTH攻撃のまとめ 最初に簡単なまとめを書いておきます。長文になりそうなので、読むのが大変な方はここだけ見ておいてください。 MD5ハッシュは既に安全ではなく、証明書の署名方式での利用は停止されていたが、後方互換のためハンドシェイクデータの署名方式にRSA-MD5が今でも利用できるTLS実装が幾つか存在していた(Firefox NSS, Java等)。 先週、INRIAグループからハッシュ衝突を利用して実際にTLSを破る攻撃(SLOTH)が公開された。それを受け、いくつかの実装でRSA-MD5を完全に利用不能にする修正が行われた(CVE-2015-7575)。 SLOTHでは、SHA1やTLS、IKE、SSHに対する攻撃についても評価を行い、幾つかは全く現実的に不可能なレベルではないことが示された。MD5とSHA-1でTLSハンドシェイクの完全性を担保しているTLS1.0/
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Railsエンジニアのためのウェブセキュリティ入門
GitHub - SecureSkyTechnology/study-struts2-s2-054_055-jackson-cve-2017-7525_cve-2017-15095: Struts2の脆弱性S2-045, S2-055 および Jackson の脆弱性 CVE-2017-7525, CVE-2017-15095 の調査報告
OAuth 2.0 をかみくだく
安全なPHPアプリケーションの作り方2016
安全なPHPアプリケーションの作り方2014
