並び順

ブックマーク数

期間指定

  • から
  • まで

41 - 53 件 / 53件

新着順 人気順

xssの検索結果41 - 53 件 / 53件

  • ECサイトのクロスサイトスクリプティング脆弱性を悪用した攻撃 - JPCERT/CC Eyes

    攻撃者は、はじめに標的のECサイトの注文フォームに対し、不正なスクリプトを含んだ文字列を入力し、購入処理を行います(図1の①)。その結果、ECサイトの購入処理の部分にXSSの脆弱性が存在する場合、ECサイトの管理画面を閲覧した管理者は不正なスクリプトが実行され、クレデンシャル情報の窃取や、ECサイトへの簡素WebShellの設置などが行われます(図1の②~④)。その後、攻撃者によってECサイトにWebShellやユーザーの情報窃取を行うJavaScriptなどが設置されます。設置された“情報窃取JavaScript”によってECサイトを利用するユーザーのクレジットカード情報等を窃取され、“情報保存ファイル”としてECサイト内に保存されます(図1の⑤)。攻撃者は定期的なWebShellへのアクセスを行うことでこれらの情報を窃取していたと推測されます(図1の⑥)。 なお、攻撃者は、一連の攻撃の

      ECサイトのクロスサイトスクリプティング脆弱性を悪用した攻撃 - JPCERT/CC Eyes
    • XSSの脅威を考察する - セキュアスカイプラス

      はじめに こんにちは!CTOのはせがわです。 先日公開された、Flatt Securityさんのブログ「開発者が知っておきたい「XSSの発生原理以外」の話」、おもしろいですね。このXSSの記事に限らず、Flatt Securityさんのブログは役に立つ記事が多い*1ので、個人的には記事が公開されるのを毎回楽しみにしています!*2 たしかに、XSSの脅威についてはなかなか理解してもらうことが難しく、また一般的にはSQLインジェクション等と比べても脅威が低く見られることも多いため、XSSの脅威について少し掘り下げて考察したいと思います。 なお、この記事は「XSSの発生原因くらいは知ってるよ」という人を対象にしています。「XSSって何だっけ」という方は クロスサイトスクリプティング対策 ホンキのキホン (1/3):CodeZine(コードジン) などの記事を参照してください。 技術的な面からの解

      • おーい磯野ー,Local StorageにJWT保存しようぜ!

        ある日,HTML5のLocal Storageを使ってはいけない がバズっていた. この記事でテーマになっていることの1つに「Local StorageにJWTを保存してはいけない」というものがある. しかし,いろいろ考えた結果「そうでもないんじゃないか」という仮定に至ったのでここに残しておく. 先の記事では,「Local StorageにJWTを保存してはいけない」の根拠として「XSSが発生した時,攻撃者がLocal Storageに保存したJWTを盗むことが出来てしまう」といったセキュリティ上の懸念事項が挙げられていた. これに対し,クッキーを用いたセッションベースの認証では,セッションIDをクッキーに保存する.クッキーにHttpOnlyフラグをつけておけば,JavaScriptからはアクセスできず,XSSが発生しても攻撃者はセッションIDを読み取ることが出来ない. 一見すると,これは

          おーい磯野ー,Local StorageにJWT保存しようぜ!
        • New XSS vectors

          Published: 20 April 2022 at 14:00 UTC Updated: 20 April 2022 at 14:07 UTC Transition based events without style blocksSo, recently, I was updating our XSS cheat sheet to fix certain vectors that had been made obsolete by browser updates. Whilst looking at the vectors, the transition events stuck in my head. They needed a style block as well as the event: <style>:target {color:red;}</style> <xss id

            New XSS vectors
          • SPAセキュリティ入門~PHP Conference Japan 2021 | ドクセル

            スライド概要 シングルページアプリケーション(SPA)において、セッションIDやトークンの格納場所はCookieあるいはlocalStorageのいずれが良いのかなど、セキュリティ上の課題がネット上で議論されていますが、残念ながら間違った前提に基づくものが多いようです。このトークでは、SPAのセキュリティを構成する基礎技術を説明した後、著名なフレームワークな状況とエンジニアの技術理解の現状を踏まえ、SPAセキュリティの現実的な方法について説明します。 動画はこちら https://www.youtube.com/watch?v=pc57hw6haXk

              SPAセキュリティ入門~PHP Conference Japan 2021 | ドクセル
            • XSSがあってもlocalStorageに保存するのに比べてcookieのhttpOnlyはjsから読めないので強いと言うことですが、SPAのサイトであれば、XSSを使ってAPIを呼び出し放題なので、セッションのcookieがjsで読めなくても危険性には大差がないのでは?と思うのですが私の認識がおかしいでしょうか? - ockeghem page

              徳丸本の中の人 OWASP Japanアドバイザリーボード EGセキュアソリューションズ代表 IPA非常勤職員 脆弱性診断、WAFの販売・導入、セキュリティコンサルティングをやっています。 https://t.co/F0kveu1nJM

                XSSがあってもlocalStorageに保存するのに比べてcookieのhttpOnlyはjsから読めないので強いと言うことですが、SPAのサイトであれば、XSSを使ってAPIを呼び出し放題なので、セッションのcookieがjsで読めなくても危険性には大差がないのでは?と思うのですが私の認識がおかしいでしょうか? - ockeghem page
              • React における XSS|React と Vue に関する XSS アンチパターン

                  React における XSS|React と Vue に関する XSS アンチパターン
                • 発見した0dayについての技術的解説 - EC-Cube, SoyCMS, BaserCMS - Flatt Security Blog

                  ※このブログは、セキュリティエンジニアのstyprが英語で書いた文章を翻訳し、社内で監修したものになります。 こんにちは。株式会社Flatt Securityのstypr (@stereotype32)です。 以前公開した記事「Flatt Securityは“自分のやりたいことが実現できる”場所/セキュリティエンジニア stypr」でお話した通り、私は現在Flatt Securityで0day huntingとセキュリティの診断をしています。 私は 5月に入社してから 0day hunting の業務に取り組んでいます。他の面白い業務と並行して取り組んでいるので、一つの製品にかけている時間は、最低1日からせいぜい1週間程度です。 結果、これまでの間、私はかなり多くのOSS脆弱性を見つけてきました。そこで今回の記事では、現在までに修正された脆弱性のうち、技術的に面白い選りすぐりのものを解説し

                    発見した0dayについての技術的解説 - EC-Cube, SoyCMS, BaserCMS - Flatt Security Blog
                  • Security headers quick reference  |  Articles  |  web.dev

                    This article lists the most important security headers you can use to protect your website. Use it to understand web-based security features, learn how to implement them on your website, and as a reference for when you need a reminder. Security headers recommended for websites that handle sensitive user data: Content Security Policy (CSP) Trusted Types Security headers recommended for all websites

                    • Masato Kinugawa Security Blog: DiscordデスクトップアプリのRCE

                      数か月前、ゲームのコミュニティなどで人気のチャットアプリ「Discord」のデスクトップ用アプリケーションに任意のコードを実行可能な問題を発見し、Bug Bounty Programを通じて報告しました。発見したRCEは、複数のバグを組み合わせることによって達成される面白いものだったので、この記事では、その詳細を共有したいと思います。なお、現在脆弱性は修正されています。 調査のきっかけElectronアプリの脆弱性を探したい気分だったので、Electronアプリで報奨金が出るアプリを探していたところ、Discordが候補にあがりました。Discordは自分自身が利用者で、自分が使うアプリが安全かどうかをチェックしたいという思いもあったので、調査をすることにしました。 発見した脆弱性私は主に次の3つのバグを組み合わせることでRCEを達成しました。 contextIsolationオプションの

                      • ウェブ エコシステムの根本的なセキュリティ保護に向けて

                        .app 1 .dev 1 #11WeeksOfAndroid 13 #11WeeksOfAndroid Android TV 1 #Android11 3 #DevFest16 1 #DevFest17 1 #DevFest18 1 #DevFest19 1 #DevFest20 1 #DevFest21 1 #DevFest22 1 #DevFest23 1 #hack4jp 3 11 weeks of Android 2 A MESSAGE FROM OUR CEO 1 A/B Testing 1 A4A 4 Accelerator 6 Accessibility 1 accuracy 1 Actions on Google 16 Activation Atlas 1 address validation API 1 Addy Osmani 1 ADK 2 AdMob 32 Ads

                          ウェブ エコシステムの根本的なセキュリティ保護に向けて
                        • Auth TokenをlocalStorageに入れようが、cookieに入れようがどっちもXSS危険性には無防備(同ドメイン内なら ...) - Qiita

                          Auth TokenをlocalStorageに入れようが、cookieに入れようがどっちもXSS危険性には無防備(同ドメイン内なら ...)JavaScriptcookieJWTxsstoken tokenを保存する場所 localStorage cookie cookie (http only) メモリ内 (変数) よく言われるのが JWT tokenをlocalStorageに入れるべきではない ということ。 理由としてはJavascriptで簡単に読めてしまうので、XSSがあった場合意図しないスクリプトを動かされてしまい、結果としてtokenが盗まれるというもの。 対応策として cookie (http only) を色んな所で推奨してる。 https://techracho.bpsinc.jp/hachi8833/2019_10_09/80851 http://cryto.net

                            Auth TokenをlocalStorageに入れようが、cookieに入れようがどっちもXSS危険性には無防備(同ドメイン内なら ...) - Qiita
                          • JVN#97370614: マガジンガーZ におけるクロスサイトスクリプティングの脆弱性

                            CGI Script Market が提供するマガジンガーZ <http://cgiscriptmarket.com/magazinegerZ/> は、ウェブサイトにメールマガジン配信機能を提供する CGI スクリプトです。 マガジンガーZ には、管理画面にログインした管理者のウェブブラウザ上で、意図しないスクリプトが実行される格納型クロスサイトスクリプティング (CWE-79) の脆弱性が存在します。 この案件は、2021年1月22日に開催された公表判定委員会による判定にて、平成29年経済産業省告示第19号および、情報セキュリティ早期警戒パートナーシップガイドラインにおける、次のすべての条件を満たすことを確認したため、JVN で公表することが適当と判定されました。IPA は、その判定を踏まえ、脆弱性情報を公表すると判断しました。 当該案件が調整不能であること 製品開発者への連絡方法として