SPAセキュリティ超入門 | ドクセル
スライド概要 SPA(Single Page Application)の普及が一層進んでおり、従来型のMPAを知らないウェブ開発者も生まれつつあるようです。SPA対応のフレームワークでは基本的な脆弱性については対策機能が用意されていますが、それにも関わらず、脆弱性診断等で基本的な脆弱性が指摘されるケースはむしろ増えつつあります。 本セッションでは、LaravelとReactで開発したアプリケーションをモデルとして、SQLインジェクション、クロスサイトスクリプティング、認可制御不備等の脆弱性の実例を紹介しながら、現実的な対策について紹介します。LaravelやReact以外のフレームワーク利用者にも役立つ説明を心がけます。 PHPカンファレンス2022での講演資料です。 PHPカンファレンスでの動画URL https://www.youtube.com/watch?v=jZ6sWyGxcCs
【PoC編】XSSへの耐性においてブラウザのメモリ空間方式はLocal Storage方式より安全か？ - Flatt Security Blog
はじめに こんにちは。 セキュリティエンジニアの@okazu-dm です。 この記事は、Auth0のアクセストークンの保存方法について解説した前回の記事の補足となる記事です。前回の記事の要旨をざっくりまとめると以下のようなものでした。 Auth0はデフォルトではアクセストークンをブラウザのメモリ空間上にのみ保存するin-memory方式であり、XSSへの耐性のなさ等の理由でlocalStorageで保存することを推奨していない しかし、XSSでアクセストークンを奪取できるのはin-memory方式でも同じのはず(検証は行いませんでした)。localStorage方式を過度に忌避する必要はないのではないか なお、Flatt Securityの提供するセキュリティ診断はAuth0に限らずFirebase AuthenticationやAmazon CognitoなどのIDaaSのセキュアな利用
SPA認証トークンはlocalStorageでもCookieでもない、Auth0方式はいいねというお話 - @mizumotokのブログ
SPA認証トークンをどこに保存するかは論争が絶えません。localStorageやCookieがよく使われますが、Auth0は違う方法を採用しています。この記事では、Auth0のトークン管理の方式を理解でき、トークン管理上のセキュリティへの理解を深めることができます。 SPAの認証トークンをどこに保存するか ブラウザでトークンを保存できる場所 保存場所の比較 メリット・デメリット Auth0のアプローチ トークンはインメモリに保存 OpenID Connect準拠とトークン取得のUI/UXの悪化回避を両立 Auth0のjsライブラリ ログイン アクセストークンの（再）取得 図解 ログイン アクセストークンの（再）取得 自サービス内の認証だけのもっと簡易な構成 ログイン IDトークン取得 まとめ SPAの認証トークンをどこに保存するか React やVueで認証付きSPA（Single Pa
Yahoo! JAPAN はパスワードレス認証で問い合わせを 25% 削減、ログイン時間も 2.6 倍速に
Yahoo! JAPAN は日本にて検索やニュースといったメディアサービス、e コマース、メールサービスなど、100を超えるサービスを提供している企業です。これらのサービスで利用するためのユーザーアカウントも長年提供し続け、月間のログインユーザーは 5,000 万を超える規模となっています。しかし、このユーザーアカウントを提供する中で、ユーザーアカウントに対しての攻撃を継続的に受けており、また、アカウントを継続利用する上での課題についてユーザーから問い合わせも多く頂いていました。これらの課題の多くはパスワードという認証手段に依存するものでした。また、当時、技術的にもパスワード以外の認証手段を提供するための機能やデバイスの普及が始まりつつありました。こういった背景のもと、Yahoo! JAPAN はパスワードによる認証からパスワードレスな認証へ移行すると判断しました。 なぜパスワードレスか
Spectre の脅威とウェブサイトが設定すべきヘッダーについて
長い記事なので先に結論を書きます。 Spectre の登場で、ウェブサイトに必要とされるセキュリティ要件は増えました。具体的に必要な対策は下記の通りです。 すべてのリソースは Cross-Origin-Resource-Policy ヘッダーを使って cross-origin なドキュメントへの読み込みを制御する。 HTML ドキュメントには X-Frame-Options ヘッダーもしくは Content-Security-Policy (CSP) ヘッダーの frame-ancestors ディレクティブを追加して、cross-origin なページへの iframe による埋め込みを制御する。 HTML ドキュメントには Cross-Origin-Opener-Policy ヘッダーを追加して popup ウィンドウとして開かれた場合の cross-origin なページとのコミュニ
アンカー上の target=_blank が rel=noopener を暗示するようになりました | Firefox サイト互換性情報
リリース: Firefox 79 カテゴリー: DOM, HTML, プライバシー & セキュリティ 概要Firefox 79 以降、target="_blank" を伴った <a> や <area> 要素は、現行の HTML 仕様 に従い、rel 属性が設定されていない限り暗黙的に rel="noopener" を適用します。noopener リンクタイプは新たに開かれたウィンドウ内の window.opener を null とすることで、この DOM プロパティが信頼できない第三者のサイトによって悪用されるのを防ぎます。必要な場合は、rel="opener" を明示的に設定することで挙動を反転させられます。 Apple は 2019 年 3 月公開の Safari 12.1 で最初にこの変更を行いました。Firefox では、Firefox 65 以降の Nightly と早期 Be
Masato Kinugawa Security Blog: CVE-2020-11022/CVE-2020-11023: jQuery 3.5.0で修正されたSecurity Fixの詳細
English version is here: https://mksben.l0.cm/2020/05/jquery3.5.0-xss.html 先月、jQuery 3.5.0がリリースされました。 このバージョンでは、僕が報告した問題がSecurity Fixとして含まれています。 jQuery 3.5.0 Released! | Official jQuery Blog https://blog.jquery.com/2020/04/10/jquery-3-5-0-released/ 報告したバグは、CVE-2020-11022、 CVE-2020-11023 として採番されています。 https://github.com/advisories/GHSA-gxr4-xjj5-5px2 https://github.com/advisories/GHSA-jpcq-cgw6-v4j6
電子情報学特論：Chromiumのアーキテクチャを解き明かす
電子情報学特論： Chromium のアーキテクチャを解き明かす 〜 EEIC の授業が生きるプロダクトの世界〜 Kentaro Hara 2020 April (๑>ᴗ<๑) * * * *
Superfish/eDellRootが危険な理由 - めもおきば
Lenovo製のPCの一部にSuperfishというマルウェアが標準でインストールされていることが確認され、大きな問題となっています。 [2015-11-24追記] DELL製のPCにも、「eDellRoot」とされるSuperfishと同様の問題を持つルート証明書が導入されているようです。 DellのPCに不審なルート証明書、LenovoのSuperfishと同じ問題か - ITmedia エンタープライズ Dude, You Got Dell’d: Publishing Your Privates - Blog - Duo Security Joe Nord personal blog: New Dell computer comes with a eDellRoot trusted root certificate https://t.co/chURwV7eNE eDellRootで
そろそろ押さえておきたい AngularJSのセキュリティ
Rx初心者がいきなりRxJSのコードを見ると「RxJS意味がわからない、怖い」という印象を持ちがちです（実体験）。 そんなRxJSもマーブル図でゆるく理解すれば怖くありません。 初心者向けにマーブル図を紹介します。また実際にプロダクトで実装したRxJSの活用事例を紹介します。
mXSS - Mutation-based Cross-Site-Scripting のはなし - 葉っぱ日記
ここ数年、XSS業界の最先端で盛り上がっている話題として mXSS というものがあります。mXSS - Mutation-based XSS とは、例えば innerHTML などを経由してすでに構築されているDOMツリーを参照したときに、本来のDOM構造とは異なる結果を得てしまい、そのためにHTML構造の破壊を引き起こすという類のDOM based XSSの亜種とも言えます。 mXSSに関しては以下の資料などが参考になります。 The innerHTML Apocalypse mXSS Attacks: Attacking well-secured Web-Applications by using innerHTML Mutations どちらの資料にも掲載されていますが、mXSSのきっかけとなったのは 「教科書に載らないWebアプリケーションセキュリティ（1）：［これはひどい］IEの
バリデーション、エスケープ、フィルタリング、サニタイズのイメージ
バリデーション、エスケープ、フィルタリング、サニタイズの用語は分かりにくいので、イメージで説明します。 “><script>alert(‘xss’);</script> という入力文字列が、それぞれどうなるかを示します。 ※1 厳密な定義ではありません（要件や文脈により変化します） ※2 バリデーションという用語は非常に幅があります（ここの「名称補足」参照）。 ※3 サニタイズという用語は非常に幅があるで、使う場合は事前に語義を定義しましょう（参照）。
PHPのJSONのエスケープ
(Last Updated On: 2023年12月8日) 追記：最近のOWASPガイドの更新でJavaScript文字列はUnicodeエンコードで安全性を確保するよう変更されました。元々このブログでもUnicodeエスケープのまま利用するように書いています。他の言語のユーザーはUnicodeエスケープを利用しましょう。PHPもASCII領域の文字をUnicodeエスケープするようにした方が良いと思います。これは提案して実現するように努力します。 JSONはJavaScriptのオブジェクトや配列を表現する方式でRFC 4627で定義されています。メディアタイプはapplication/json、ファイル拡張子はjsonと定義されています。 PHPにJSON形式のデータに変換するjson_encode関数とjson_decode関数をサポートしています。 JSON関数がサポートされている
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
処理開始後の例外処理では「サニタイズ」が有効な場合もある
このエントリでは、脆弱性対処における例外処理について、奥一穂氏(@kazuho)との会話から私が学んだことを共有いたします。セキュアプログラミングの心得として、異常が起これば直ちにプログラムを終了することが推奨される場合がありますが、必ずしもそうではないというのが結論です。 はじめに Webアプリケーションの脆弱性対策では、脆弱性が発生するのはデータを使うところであるので、データを使う際の適切なエスケープ処理などで対処するのがよいと言われます。しかし、処理内容によってはエスケープができない場合もあり、その場合の対処についてはまだ定説がないと考えます。 エスケープができない場合の例としては、以下があります。 SQLの数値リテラルを構成する際に、入力に数値以外の文字が入っていた メール送信しようとしたが、メールアドレスに改行文字が入っていた 入力されたURLにリダイレクトしようとしたところ、U
妥当性とは仕様の所作 - SQLインジェクション対策とバリデーション - ＊「ふっかつのじゅもんがちがいます。」withぬこ
繰り返しになりますが、妥当性検証は仕様の問題であってセキュリティ対策ではありません。 バリデーションは仕様の問題であってセキュリティ対策ではないとはどういうことか説明します。SQLインジェクションの対策は、1. SQLを文字列結合で作らない 2. プレースホルダを使う です。バリデーションは関係ありません。 簡単な例 Webアプリケーションで郵便番号を指定するフォームを考えましょう。 日本の郵便番号を指定するフォームの設計でよく見るものは大きく分けて2通りあり、上3桁と下4桁を別々に入力させるものと、1つのフォームにまとめて入力させるものです。住所から補完させる設計もありえますがここではおいておきます。 <input type="text" name="postal_code_1"> - <input type="text" name="postal_code_2"> <input typ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
HTMLとCSSだけでWebブラウザにサイドチャネル攻撃を仕掛ける手法
ハッカソンでkintoneを使おう！ – cybozu developer network
徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2012
