Security-testing-quick-guide

Burp Suiteの構成

Burp Suiteは、ブラウザとWebサーバーが送受信する情報の各パケットを傍受できるWebプロキシです。これにより、クライアントがWebサーバーに情報を送信する前にコンテンツを変更できます。

ステップ1 *-以下に示すように、アプリケーションはポート8080にインストールされ、Burpはポート8181にインストールされます。 Burpスイートを起動し、以下に示すようにポート8181で起動するために次の設定を行います。

ステップ2 *-Burpスイートがトラフィックを傍受できるように、Burpがアプリケーションがインストールされているポート＃8080をリッスンしていることを確認する必要があります。この設定は、次に示すようにBurp Suiteの[スコープ]タブで行う必要があります。

ステップ3 *-次に、ポート8181（Burp Suiteポート）をリッスンするようにブラウザのプロキシ設定を行います。したがって、以下に示すように、クライアント（ブラウザ）とサーバー（Webサーバー）間のトラフィックをインターセプトするようにWebプロキシを構成しました-

ステップ4 *-構成のスナップショットは、以下に示すような簡単なワークフロー図の助けを借りて以下に示されています

セキュリティテスト-インジェクション

インジェクション手法は、アプリケーションの入力フィールドを使用してSQLクエリまたはコマンドをインジェクトすることで構成されます。

Webアプリケーション-インジェクション

SQLインジェクションが成功すると、データベースから機密データを読み取って変更したり、データベースからデータを削除したりできます。また、ハッカーはDBMSのシャットダウンやデータベースの削除など、データベースで管理操作を実行できます。

単純な図を使用して、この欠陥の脅威エージェント、攻撃ベクトル、セキュリティの弱さ、技術的影響、ビジネスへの影響を理解しましょう。

例

アプリケーションは、以下の脆弱なSQLコールの構築に信頼できないデータを使用します-

String query = "SELECT * FROM EMP WHERE EMPID = '" &plus; request.getParameter("id") &plus; "'";

ハンズオン

ステップ1 *-以下に示すように、アプリケーションのSQLインジェクションエリアに移動します。

ステップ2 *-演習で示したように、文字列SQLインジェクションを使用して認証をバイパスします。 SQLインジェクションを使用して、正しいパスワードを使用せずにボス（「ネビル」）としてログインします。 Nevilleのプロファイルを表示できること、およびすべての機能（検索、作成、削除など）が使用可能であることを確認します。

ステップ3 *-パラメータを 'a' = 'a’または1 = 1として送信してパスワードをバイパスできるようにSQLを挿入します

ステップ4 *-悪用後、以下に示すように管理者であるネヴィルとしてログインできます。

SQLインジェクションの防止

SQLインジェクションを防ぐ方法はたくさんあります。開発者は、コードを記述するときに、それに応じて特殊文字を処理することを確認する必要があります。 OWASPから利用可能なチートシート/防止テクニックがあります。これは開発者向けのガイドです。

パラメータ化されたクエリの使用
すべてのユーザー指定入力のエスケープ
エンドユーザーに対してデータベースの最小特権を有効にする

壊れた認証のテスト

アプリケーションに関連する認証機能が正しく実装されていない場合、ハッカーはパスワードやセッションIDを侵害したり、他のユーザーの資格情報を使用して他の実装の欠陥を悪用したりできます。

単純な図を使用して、この欠陥の脅威エージェント、攻撃ベクトル、セキュリティの弱さ、技術的影響、ビジネスへの影響を理解しましょう。

例

An e-commerce application supports URL rewriting, putting session IDs in the URL −

http://example.com/sale/saleitems/jsessionid=2P0OC2JSNDLPSKHCJUN2JV/?item=laptop

サイトの認証されたユーザーは、URLを友人に転送して、割引販売について知らせます。彼は、ユーザーがセッションIDも提供していることを知らずに、上記のリンクを電子メールで送信します。彼の友人がリンクを使用するとき、彼らは彼のセッションとクレジットカードを使用します。

ハンズオン

ステップ1 *-Webgoatにログインし、「セッション管理の欠陥」セクションに移動します。 Cookieをスプーフィングして、認証をバイパスしましょう。以下は、シナリオのスナップショットです。

ステップ2 *-資格情報webgoat/webgoatを使用してログインすると、Burp SuiteからJSESSION IDがC8F3177CCAFF380441ABF71090748F2Eであり、認証が成功するとAuthCookie = 65432ubphcfxであることがわかります。

ステップ3 *-クレデンシャルアスペクト/アスペクトを使用してログインすると、Burp SuiteからJSESSION IDがC8F3177CCAFF380441ABF71090748F2Eであり、認証が成功するとAuthCookie = 65432udfqtbであることがわかります。

ステップ4 *-次に、AuthCookieパターンを分析する必要があります。前半の「65432」は両方の認証に共通です。そのため、webgoatユーザーの場合はubphcfx、アスペクトユーザーの場合はudfqtbなど、authcookie値の最後の部分を分析することに興味があります。

ステップ5 *-AuthCookie値を詳しく見ると、最後の部分はユーザー名と同じ長さです。したがって、ユーザー名が何らかの暗号化方式で使用されていることは明らかです。試行錯誤/総当たりのメカニズムでは、ユーザー名webgoatを逆にした後、最終的にtaogbewになり、その前のアルファベット文字がAuthCookieとして使用されます。つまり、ubphcfx。

ステップ6 *-このCookie値を渡して、何が起こるか見てみましょう。ユーザーwebgoatとして認証したら、ステップ＃4とステップ＃5を実行して、AuthCookieの値を変更し、ユーザーAliceのモックを作成します。

防止メカニズム

OWASPのアプリケーションセキュリティ検証標準で定義されているすべての認証およびセッション管理要件を満たすように、強力な認証およびセッション管理コントロールを開発します。
開発者は、セッションIDを盗むために使用できるXSSの欠陥を回避する必要があります。

クロスサイトスクリプティングのテスト

クロスサイトスクリプティング（XSS）は、アプリケーションが信頼できないデータを取得し、検証せずにクライアント（ブラウザー）に送信するたびに発生します。これにより、攻撃者が被害者のブラウザで悪意のあるスクリプトを実行し、ユーザーセッションのハイジャック、Webサイトの改ざん、または悪意のあるサイトへのリダイレクトを引き起こす可能性があります。

単純な図を使用して、この欠陥の脅威エージェント、攻撃ベクトル、セキュリティの弱さ、技術的影響、ビジネスへの影響を理解しましょう。

3。クロスサイトスクリプティング

XSSの種類

Stored XSS -データベース/メッセージフォーラム/コメントフィールドなどのユーザー入力がターゲットサーバーに保存されると、永続XSSとも呼ばれる保存XSSが発生します。その後、被害者はWebアプリケーションから保存されたデータを取得できます。
Reflected XSS -非入力XSSとしても知られるReflected XSSは、ユーザー入力がエラーメッセージ/検索結果またはリクエストの一部としてユーザーによって提供された入力でWebアプリケーションによってすぐに返されたときに発生します。提供されたデータ。
DOMベースのXSS -DOMベースのXSSは、データのソースがDOMにあり、シンクもDOMにあり、データフローがブラウザを離れない場合のXSSの形式です。

例

アプリケーションは、検証中に信頼できないデータを構築に使用します。特殊文字はエスケープする必要があります。

http://www.webpage.org/task/Rule1?query=try

攻撃者は、ブラウザのクエリパラメータを次のように変更します-

http://www.webpage.org/task/Rule1?query=<h3>Hello from XSS"</h3>

ハンズオン

ステップ1 *-Webgoatにログインし、クロスサイトスクリプティング（XSS）セクションに移動します。 Stored Cross-site Scripting（XSS）攻撃を実行しましょう。以下は、シナリオのスナップショットです。

ステップ2 *-シナリオごとに、シナリオ自体に記載されているパスワード「tom」を使用してTomとしてログインします。 [プロファイルを表示]をクリックして、編集モードに入ります。 tomは攻撃者であるため、これらの編集ボックスにJavaスクリプトを挿入しましょう。

<script>
   alert("HACKED")
</script>

ステップ3 *-更新が終了するとすぐに、tomはメッセージが「ハッキングされた」という警告ボックスを受け取ります。これは、アプリが脆弱であることを意味します。

ステップ4 *-シナリオに従って、jerry（HR）としてログインし、jerryが注入されたスクリプトの影響を受けるかどうかを確認する必要があります。

ステップ5 *-Jerryとしてログインした後、以下に示すように、「Tom」を選択し、「view profile」をクリックします。

ジェリーのアカウントからトムのプロファイルを表示している間、彼は同じメッセージボックスを取得できます。