セキュリティテスト-クイックガイド
Web上の悪意のあるアクティビティからシステムを保護するには、セキュリティテストが非常に重要です。
セキュリティテストとは何ですか？
セキュリティテストは、情報システムがデータを保護し、意図したとおりに機能を維持しているかどうかを判断するためのテスト手法です。セキュリティテストはシステムの完全なセキュリティを保証するものではありませんが、テストプロセスの一部としてセキュリティテストを含めることが重要です。
セキュリティテストでは、セキュリティで保護された環境を提供するために、次の6つの対策を講じています。
Confidentiality −意図しない受信者への情報の開示から保護します。
Integrity −送信者から目的の受信者に正確で正しい必要な情報を転送できます。
Authentication −ユーザーの身元を確認します。
Authorization −ユーザーとリソースへのアクセス権を指定します。
Availability −要件に関する情報の準備ができていることを確認します。
Non-repudiation −メッセージを送信または受信したことに対する送信者または受信者からの拒否がないことを保証します。
例
Webベースのアプリケーションのセキュリティ上の欠陥を見つけるには、複雑な手順と創造的な思考が必要です。場合によっては、簡単なテストで最も深刻なセキュリティリスクが明らかになることがあります。この非常に基本的なテストは、どのWebアプリケーションでも試すことができます-
有効な資格情報を使用してWebアプリケーションにログインします。
Webアプリケーションからログアウトします。
ブラウザの[戻る]ボタンをクリックします。
再度ログインするように求められるかどうか、またはログインしたページに再度戻ることができるかどうかを確認します。
セキュリティテストは、システムに対する制御された攻撃と見なすことができ、現実的な方法でセキュリティの欠陥を明らかにします。その目標は、ITシステムの現在のステータスを評価することです。としても知られていますpenetration test またはより一般的に ethical hacking。
侵入テストは段階的に行われ、この章では、完全なプロセスについて説明します。攻撃を再現するために必要なすべての手順をすぐに利用できるように、各フェーズで適切な文書化を行う必要があります。ドキュメントは、侵入テストの最後に顧客が受け取る詳細なレポートの基礎としても機能します。
ペネトレーションテスト–ワークフロー
ペネトレーションテストには、4つの主要なフェーズが含まれます-
- フットプリント
- Scanning
- Enumeration
- Exploitation
これらの4つのステップは、通常のSDLCと連携して複数回繰り返されます。
悪意のあるソフトウェア（マルウェア）は、攻撃者/マルウェアの作成者にシステムの部分的または完全な制御を与えるソフトウェアです。
マルウェア
マルウェアのさまざまな形態を以下に示します-
Virus−ウイルスは、それ自体のコピーを作成し、これらのコピーを他のコンピュータプログラム、データファイル、またはハードディスクのブートセクタに挿入するプログラムです。複製が成功すると、ウイルスは、ハードディスク領域やCPU時間を盗むなど、感染したホストに有害な活動を引き起こします。
Worm −ワームはマルウェアの一種であり、パス内の各コンピュータのメモリに自身のコピーを残します。
Trojan −トロイの木馬は、悪意のあるコードを含む非自己複製型のマルウェアであり、実行時にデータの損失や盗難、またはシステムへの危害をもたらす可能性があります。
Adware−アドウェアは、フリーウェアまたはピッチウェアとも呼ばれ、ゲーム、デスクトップツールバー、およびユーティリティの商用広告を含む無料のコンピュータソフトウェアです。これはWebベースのアプリケーションであり、Webブラウザーのデータを収集して、広告、特にポップアップをターゲットにします。
Spyware−スパイウェアは、ユーザーを匿名で監視する侵入ソフトウェアであり、ハッカーがユーザーのコンピューターから機密情報を取得できるようにします。スパイウェアは、無料のオンラインソフトウェアダウンロードまたはユーザーがクリックしたリンクに頻繁に付随するユーザーとアプリケーションの脆弱性を悪用します。
Rootkit −ルートキットは、ハッカーが盗んだパスワードを介して、または被害者の知らないうちにシステムの脆弱性を悪用してインストールされたコンピュータ/ネットワークへの管理者レベルのアクセスを取得するために使用するソフトウェアです。
予防措置
システム内にマルウェアが存在しないようにするには、次の対策を講じることができます。
オペレーティングシステムとアプリケーションがパッチ/アップデートで最新であることを確認してください。
奇妙な電子メール、特に添付ファイルのある電子メールは絶対に開かないでください。
インターネットからダウンロードするときは、インストールするものを常に確認してください。ポップアップウィンドウを閉じるために単に[OK]をクリックしないでください。アプリケーションをインストールする前に、発行元を確認してください。
ウイルス対策ソフトウェアをインストールします。
ウイルス対策プログラムを定期的にスキャンして更新するようにしてください。
ファイアウォールをインストールします。
ブラウザとアプリケーションが提供するセキュリティ機能を常に有効にして使用してください。
マルウェア対策ソフトウェア
次のソフトウェアは、システムからマルウェアを削除するのに役立ちます-
- マイクロソフト・セキュリティ・エッセンシャルズ
- Microsoft Windows Defender
- AVGインターネットセキュリティ
- Spybot-検索と破棄
- アバスト！個人使用のホームエディション
- パンダインターネットセキュリティ
- MacOSおよびMacOSX用のMacScan
プロトコルを理解することは、セキュリティテストをよく理解するために非常に重要です。Webサーバーとクライアントの間でパケットデータを傍受するときに、プロトコルの重要性を理解することができます。
HTTPプロトコル
ハイパーテキスト転送プロトコル（HTTP）は、分散型の協調型ハイパーメディア情報システム向けのアプリケーションレベルのプロトコルです。これは、1990年以来のワールドワイドウェブのデータ通信の基盤です。HTTPは、要求メソッド、エラーコード、およびヘッダーの拡張を使用して、他の目的にも使用できる汎用のステートレスプロトコルです。
基本的に、HTTPはTCP / IPベースの通信プロトコルであり、HTMLファイル、画像ファイル、クエリ結果などのデータをWeb経由で配信するために使用されます。これは、コンピューターが相互に通信するための標準化された方法を提供します。HTTP仕様は、クライアントの要求されたデータがサーバーに送信される方法、およびサーバーがこれらの要求に応答する方法を指定します。
基本的な機能
HTTPをシンプルで強力なプロトコルにする次の3つの基本機能があります-
HTTP is connectionless− HTTPクライアント、つまりブラウザがHTTPリクエストを開始します。要求を行った後、クライアントはサーバーから切断し、応答を待ちます。サーバーは要求を処理し、クライアントとの接続を再確立して応答を送り返します。
HTTP is media independent−クライアントとサーバーの両方がデータコンテンツの処理方法を知っている限り、任意のタイプのデータをHTTPで送信できます。これは、クライアントとサーバーが適切なMIMEタイプを使用してコンテンツタイプを指定するために必要です。
HTTP is stateless− HTTPはコネクションレス型であり、これはHTTPがステートレスプロトコルであるという直接的な結果です。サーバーとクライアントは、現在の要求の間のみお互いを認識します。その後、二人はお互いを忘れます。プロトコルのこの性質により、クライアントもブラウザも、Webページ全体の異なる要求間で情報を保持できません。
HTTP / 1.0は、要求/応答交換ごとに新しい接続を使用しますが、HTTP / 1.1接続は、1つ以上の要求/応答交換に使用できます。
建築
次の図は、Webアプリケーションの非常に基本的なアーキテクチャを示し、HTTPが存在する場所を示しています。
HTTPプロトコルは、Webブラウザ、ロボット、検索エンジンなどがHTTPクライアントとして機能し、Webサーバーがサーバーとして機能するクライアント/サーバーアーキテクチャに基づく要求/応答プロトコルです。
Client − HTTPクライアントは、要求メソッド、URI、およびプロトコルバージョンの形式でサーバーに要求を送信し、その後にTCP / IP接続を介して要求修飾子、クライアント情報、および可能な本文コンテンツを含むMIMEのようなメッセージを送信します。
Server − HTTPサーバーは、メッセージのプロトコルバージョンと成功またはエラーコードを含むステータス行で応答し、その後にサーバー情報、エンティティメタ情報、および可能なエンティティ本体コンテンツを含むMIMEのようなメッセージが続きます。
HTTP –デメリット
HTTPは完全に保護されたプロトコルではありません。
HTTPは、通信のデフォルトポートとしてポート80を使用します。
HTTPはアプリケーション層で動作します。データ転送のために複数の接続を作成する必要があるため、管理のオーバーヘッドが増加します。
HTTPを使用するために暗号化/デジタル証明書は必要ありません。
Httpプロトコルの詳細
HTTPプロトコルを詳細に理解するには、以下のリンクのそれぞれをクリックしてください。
HTTP Parameters
HTTP Messages
HTTP Requests
HTTP Responses
HTTP Methods
HTTP Status Codes
HTTP Header Fields
HTTP Security
HTTPS（Secure Socket Layerを介したハイパーテキスト転送プロトコル）またはHTTP over SSLは、Netscapeによって開発されたWebプロトコルです。これはプロトコルではありませんが、SSL / TLS（Secure Socket Layer / Transport Layer Security）の上にHTTPを階層化した結果です。
つまり、HTTPS = HTTP + SSL
HTTPSはいつ必要ですか？
私たちが閲覧するとき、私たちは通常、HTTPプロトコルを使用して情報を送受信します。したがって、これにより、誰もが私たちのコンピュータとWebサーバー間の会話を盗聴することになります。多くの場合、セキュリティで保護し、不正アクセスを防ぐ必要がある機密情報を交換する必要があります。
次のシナリオで使用されるHttpsプロトコル-
- 銀行のウェブサイト
- ペイメントゲートウェイ
- ショッピングサイト
- すべてのログインページ
- メールアプリ
HTTPSの基本的な動作
HTTPSプロトコルのサーバーには、公開鍵と署名付き証明書が必要です。
https：//ページに対するクライアントの要求
https接続を使用する場合、サーバーは、Webサーバーがサポートする暗号化方式のリストを提供することにより、最初の接続に応答します。
それに応じて、クライアントは接続方法を選択し、クライアントとサーバーは証明書を交換してIDを認証します。
これが行われた後、Webサーバーとクライアントの両方が同じキーを使用していることを確認した後、暗号化された情報を交換し、接続が閉じられます。
https接続をホストするには、サーバーに公開鍵証明書が必要です。公開鍵証明書には、鍵の所有者のIDを確認して鍵情報が埋め込まれています。
ほとんどすべての証明書はサードパーティによって検証されるため、クライアントはキーが常に安全であることが保証されます。
エンコードとデコードとは何ですか？
エンコードとは、文字、数字、その他の特殊文字などの一連の文字を、効率的に送信するための特殊な形式に変換するプロセスです。
デコードは、エンコードされた形式を元の文字シーケンスに変換するプロセスです。これは、私たちが通常誤解している暗号化とは完全に異なります。
エンコードとデコードは、データ通信とストレージで使用されます。機密情報の転送にはエンコードを使用しないでください。
URLエンコード
URLは、ASCII文字セットを使用してインターネット経由でのみ送信できます。URLにASCII文字以外の特殊文字が含まれている場合は、エンコードする必要があります。URLにはスペースが含まれておらず、プラス（+）記号または％20に置き換えられています。
ASCIIエンコーディング
ブラウザ（クライアント側）は、Webページで使用されている文字セットに従って入力をエンコードし、HTML5のデフォルトの文字セットはUTF-8です。
次の表は、文字のASCII記号とそれに等しい記号、そして最後にサーバーに渡す前にURLで使用できるその置換を示しています。
| ASCII | シンボル | 置換 |
|---|---|---|
| <32 | ％xxでエンコードします。xxは文字の16進表現です。 | |
| 32 | スペース | +または％20 |
| 33 | ！ | ％21 |
| 34 | 「」 | ％22 |
| 35 | ＃ | ％23 |
| 36 | $ | ％24 |
| 37 | ％ | ％25 |
| 38 | ＆ | ％26 |
| 39 | ' | ％27 |
| 40 | （（ | ％28 |
| 41 | ） | ％29 |
| 42 | * | * |
| 43 | + | ％2B |
| 44 | 、 | ％2C |
| 45 | - | - |
| 46 | 。 | 。 |
| 47 | / | ％2F |
| 48 | 0 | 0 |
| 49 | 1 | 1 |
| 50 | 2 | 2 |
| 51 | 3 | 3 |
| 52 | 4 | 4 |
| 53 | 5 | 5 |
| 54 | 6 | 6 |
| 55 | 7 | 7 |
| 56 | 8 | 8 |
| 57 | 9 | 9 |
| 58 | ： | ％3A |
| 59 | ; | ％3B |
| 60 | >> | ％3C |
| 61 | = | ％3D |
| 62 | >> | ％3E |
| 63 | ？ | ％3F |
| 64 | @ | ％40 |
| 65 | A | A |
| 66 | B | B |
| 67 | C | C |
| 68 | D | D |
| 69 | E | E |
| 70 | F | F |
| 71 | G | G |
| 72 | H | H |
| 73 | 私 | 私 |
| 74 | J | J |
| 75 | K | K |
| 76 | L | L |
| 77 | M | M |
| 78 | N | N |
| 79 | O | O |
| 80 | P | P |
| 81 | Q | Q |
| 82 | R | R |
| 83 | S | S |
| 84 | T | T |
| 85 | U | U |
| 86 | V | V |
| 87 | W | W |
| 88 | バツ | バツ |
| 89 | Y | Y |
| 90 | Z | Z |
| 91 | [ | ％5B |
| 92 | \ | ％5C |
| 93 | ] | ％5D |
| 94 | ^ | ％5E |
| 95 | _ | _ |
| 96 | ` | ％60 |
| 97 | a | a |
| 98 | b | b |
| 99 | c | c |
| 100 | d | d |
| 101 | e | e |
| 102 | f | f |
| 103 | g | g |
| 104 | h | h |
| 105 | 私 | 私 |
| 106 | j | j |
| 107 | k | k |
| 108 | l | l |
| 109 | m | m |
| 110 | n | n |
| 111 | o | o |
| 112 | p | p |
| 113 | q | q |
| 114 | r | r |
| 115 | s | s |
| 116 | t | t |
| 117 | u | u |
| 118 | v | v |
| 119 | w | w |
| 120 | バツ | バツ |
| 121 | y | y |
| 122 | z | z |
| 123 | {{ | ％7B |
| 124 | | | ％7C |
| 125 | } | ％7D |
| 126 | 〜 | ％7E |
| 127 | ％7F | |
| > 127 | ％xxでエンコードします。xxは文字の16進表現です。 |
暗号化とは何ですか？
暗号化は、データを暗号化および復号化する科学であり、ユーザーが機密情報を保存したり、安全でないネットワークを介して送信したりして、目的の受信者だけが読み取ることができるようにします。
特別な対策を講じることなく読み取って理解できるデータを plaintext、その実体を隠すために平文を偽装する方法が呼び出されている間 encryption。
暗号化されたプレーンテキストは暗号文と呼ばれ、暗号化されたデータをプレーンテキストに戻すプロセスは次のように知られています。 decryption。
安全な通信を分析および遮断する科学は、暗号解読として知られています。同じことを実行する人々は、攻撃者としても知られています。
暗号化は強い場合も弱い場合もあり、強度は実際の平文を復元するために必要な時間とリソースによって測定されます。
したがって、強力な暗号化メッセージを解読するには、適切なデコードツールが必要です。
1秒間に10億回のチェックを行う10億台のコンピューターでさえ、テキストを解読できない暗号化技術がいくつかあります。
計算能力は日々向上しているため、攻撃者からデータや重要な情報を保護するために、暗号化アルゴリズムを非常に強力にする必要があります。
暗号化はどのように機能しますか？
暗号化アルゴリズムは、キー（単語、数字、またはフレーズ）と組み合わせて機能し、プレーンテキストを暗号化します。同じプレーンテキストは、異なるキーを使用して異なる暗号文に暗号化します。
したがって、暗号化されたデータは、暗号化アルゴリズムの強度やキーの機密性など、完全に依存するいくつかのパラメーターに依存します。
暗号化技術
Symmetric Encryption−従来の暗号化とも呼ばれる従来の暗号化は、暗号化と復号化の両方に1つのキーのみを使用する手法です。たとえば、DES、トリプルDESアルゴリズム、IBMによるMARS、RC2、RC4、RC5、RC6。
Asymmetric Encryption−暗号化に一対の鍵を使用するのは公開鍵暗号です。データを暗号化するための公開鍵と復号化のための秘密鍵です。公開鍵は、秘密鍵を秘密にしながら人々に公開されます。たとえば、RSA、デジタル署名アルゴリズム（DSA）、Elgamal。
Hashing−ハッシュは一方向の暗号化であり、元に戻すことができない、または少なくとも簡単に元に戻すことができないスクランブルされた出力を作成します。たとえば、MD5アルゴリズム。これは、デジタル証明書、デジタル署名、パスワードの保存、通信の検証などを作成するために使用されます。
同一生成元ポリシー（SOP）は、Webアプリケーションのセキュリティモデルにおける重要な概念です。
同一生成元ポリシーとは何ですか？
このポリシーに従って、同じサイトから発信されたページで実行されるスクリプトを許可します。これは、次の組み合わせにすることができます。
- Domain
- Protocol
- Port
例
この動作の背後にある理由はセキュリティです。あなたが持っている場合はtry.comを1つのウィンドウでとgmail.com別のウィンドウで、あなたはtry.comからのアクセスにスクリプトをしたいか、あなたに代わってのGmailのコンテキストでgmail.comの内容や実行のアクションを変更しないでください。
以下は同じ起源のウェブページです。前に説明したように、同一生成元はドメイン/プロトコル/ポートを考慮に入れます。
- http://website.com
- http://website.com/
- http://website.com/my/contact.html
以下は、異なる起源のWebページです。
- http://www.site.co.uk（別のドメイン）
- http://site.org（別のドメイン）
- https://site.com（別のプロトコル）
- http://site.com:8080（別のポート）
IEの同一生成元ポリシーの例外
Internet Explorerには、SOPに対する2つの大きな例外があります。
1つ目は、「信頼できるゾーン」に関連しています。両方のドメインが信頼性の高いゾーンにある場合、同一生成元ポリシーは完全には適用されません。
IEの2番目の例外は、ポートに関連しています。IEは同一生成元ポリシーにポートを含めないため、http：//website.comとhttp://wesite.com：4444は同じ生成元からのものと見なされ、制限は適用されません。
クッキーとは何ですか？
Cookieは、後でブラウザで読み取れるようにWebブラウザに保存するためにWebサーバーから送信される小さな情報です。このようにして、ブラウザは特定の個人情報を記憶します。ハッカーがCookie情報を入手すると、セキュリティの問題が発生する可能性があります。
クッキーのプロパティ
ここにクッキーのいくつかの重要な特性があります-
これらは通常、コンピュータのブラウザディレクトリに保存されているIDタグが付けられた小さなテキストファイルです。
これらは、ユーザーがWebサイトを効率的にナビゲートし、特定の機能を実行するのを支援するためにWeb開発者によって使用されます。
ユーザーが同じWebサイトを再度閲覧すると、Cookieに保存されているデータがWebサーバーに返送され、ユーザーの以前のアクティビティがWebサイトに通知されます。
巨大なデータベースがあり、ログインが必要で、カスタマイズ可能なテーマがあるWebサイトでは、Cookieは避けられません。
クッキーの内容
クッキーには以下の情報が含まれています-
- Cookieの送信元のサーバーの名前。
- クッキーの存続期間。
- 値-通常はランダムに生成された一意の番号。
クッキーの種類
Session Cookies−これらのCookieは一時的なものであり、ユーザーがブラウザを閉じると消去されます。ユーザーが再度ログインした場合でも、そのセッションの新しいCookieが作成されます。
Persistent cookies−これらのCookieは、ユーザーがCookieを消去するか、有効期限が切れない限り、ハードディスクドライブに残ります。Cookieの有効期限は、Cookieの有効期間によって異なります。
クッキーのテスト
クッキーをテストする方法は次のとおりです-
Disabling Cookies−テスターとして、Cookieを無効にした後、Webサイトへのアクセスを確認し、ページが正しく機能しているかどうかを確認する必要があります。ウェブサイトのすべてのページに移動し、アプリのクラッシュを監視します。また、サイトを使用するにはCookieが必要であることをユーザーに通知する必要があります。
Corrupting Cookies−実行するもう1つのテストは、Cookieを破損することです。同じことを行うには、サイトのCookieの場所を見つけて、偽の/無効なデータで手動で編集する必要があります。このデータを使用して、ドメインの内部情報にアクセスし、サイトをハッキングすることができます。
Removing Cookies − WebサイトのすべてのCookieを削除し、Webサイトがそれにどのように反応するかを確認します。
Cross-Browser Compatibility − Cookieを書き込むページから、サポートされているすべてのブラウザでCookieが正しく書き込まれていることを確認することも重要です。
Editing Cookies−アプリケーションがCookieを使用してログイン情報を保存する場合、テスターとして、Cookieまたはアドレスバーのユーザーを別の有効なユーザーに変更してみてください。Cookieを編集しても、別のユーザーアカウントにログインできないようにする必要があります。
Cookieの表示と編集
最新のブラウザは、ブラウザ自体の中で通知されるCookieの表示/編集をサポートしています。編集を正常に実行できるmozilla / chrome用のプラグインがあります。
- Firefox用のCookieプラグインを編集する
- Chrome用のこのCookieプラグインを編集します
Cookieを編集するには、次の手順を実行する必要があります-
ここからChromeのプラグインをダウンロードします
以下に示すように、chromeから「editthiscookie」プラグインにアクセスするだけでcookie値を編集します。
攻撃を実行するための参照として利用できるさまざまな方法論/アプローチがあります。
Webアプリケーション-ペネトレーションテストの方法論
攻撃モデルを開発する際には、以下の基準を考慮に入れることができます。
以下のリストの中で、OWASPが最もアクティブであり、多くの貢献者がいます。Webアプリを設計する前に、各開発チームが考慮に入れるOWASPテクニックに焦点を当てます。
PTES-侵入テスト実行基準
OSSTMM-オープンソースのセキュリティテスト方法論マニュアル
OWASPテスト手法-オープンWebアプリケーションセキュリティプロトコル
OWASPトップ10
Open Web Application Security Protocolチームは、近年Webでより蔓延している脆弱性トップ10をリリースしました。以下は、Webベースのアプリケーションでより一般的なセキュリティ上の欠陥のリストです。
アプリケーション-ハンズオン
それぞれの手法を理解するために、サンプルアプリケーションを使用してみましょう。学習目的でセキュリティ上の欠陥を明示的に開発したJ2EEアプリケーションである「WebGoat」に対して攻撃を実行します。
webgoatプロジェクトに関する完全な詳細は見つけることができます https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project。WebGoatアプリケーションをダウンロードするには、次の場所に移動します。https://github.com/WebGoat/WebGoat/wiki/Installation-(WebGoat-6.0) とgotoダウンロードセクション。
ダウンロードしたアプリケーションをインストールするには、まずポート8080でアプリケーションが実行されていないことを確認します。アプリケーションは、java -jarWebGoat-6.0.1-war-exec.jarという1つのコマンドを使用するだけでインストールできます。詳細については、WebGoatのインストールをご覧ください。
インストール後、次の場所に移動してアプリケーションにアクセスできるようになります。 http://localhost:8080/WebGoat/attack このページは次のように表示されます。
ログインページに表示されているゲストまたは管理者の資格情報を使用できます。
Webプロキシ
クライアント（ブラウザ）とサーバー（この場合はWebgoatアプリケーションがホストされているシステム）間のトラフィックを傍受するには、Webプロキシを使用する必要があります。からダウンロードできるBurpProxyを使用しますhttps://portswigger.net/burp/download.html
以下に示すように、無料版のburpsuiteをダウンロードすれば十分です。
BurpSuiteの設定
Burp Suiteは、ブラウザとWebサーバーが送受信する情報の各パケットを傍受できるWebプロキシです。これは、クライアントが情報をWebサーバーに送信する前にコンテンツを変更するのに役立ちます。
Step 1−以下に示すように、アプリはポート8080にインストールされ、Burpはポート8181にインストールされます。以下に示すように、Burp Suiteを起動し、ポート8181で起動するために次の設定を行います。
Step 2− Burp Suiteがトラフィックを傍受できるように、Burpがアプリケーションがインストールされているポート＃8080をリッスンしていることを確認する必要があります。この設定は、以下に示すように、BurpSuiteの[スコープ]タブで行う必要があります。
Step 3−次に、ブラウザのプロキシ設定を行って、ポート8181（Burp Suiteポート）をリッスンします。したがって、以下に示すように、クライアント（ブラウザ）とサーバー（Webサーバー）間のトラフィックを傍受するようにWebプロキシを構成しました。
Step 4 −以下に示す簡単なワークフロー図を使用して、構成のスナップショットを以下に示します。
インジェクション手法は、アプリケーションの入力フィールドを使用してSQLクエリまたはコマンドをインジェクションすることで構成されます。
Webアプリケーション-インジェクション
SQLインジェクションが成功すると、データベースから機密データを読み取って変更したり、データベースからデータを削除したりできます。また、ハッカーは、DBMSのシャットダウンやデータベースの削除など、データベースの管理操作を実行できます。
簡単な図を使用して、この欠陥の脅威エージェント、攻撃ベクトル、セキュリティの弱点、技術的影響、およびビジネスへの影響を理解しましょう。
例
アプリケーションは、次の脆弱なSQL呼び出しの構築に信頼できないデータを使用します-
String query = "SELECT * FROM EMP WHERE EMPID = '" + request.getParameter("id") + "'";ハンズオン
Step 1 −以下に示すように、アプリケーションのSQLインジェクション領域に移動します。
Step 2−演習で示したように、認証をバイパスするために文字列SQLインジェクションを使用します。SQLインジェクションを使用して、正しいパスワードを使用せずにボス（ 'Neville'）としてログインします。Nevilleのプロファイルを表示できること、およびすべての機能（検索、作成、削除を含む）が使用可能であることを確認します。
Step 3 −パラメータを 'a' = 'a'または1 = 1として送信することにより、パスワードをバイパスできるようにSQLを挿入します。
Step 4 −エクスプロイト後、以下に示すように、管理者であるNevilleとしてログインできます。
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も提供していることを知らずに、上記のリンクを電子メールで送信します。彼の友人がリンクを使用するとき、彼らは彼のセッションとクレジットカードを使用します。
ハンズオン
Step 1− Webgoatにログインし、「セッション管理の欠陥」セクションに移動します。Cookieをスプーフィングして、認証をバイパスしましょう。以下はシナリオのスナップショットです。
Step 2 −資格情報webgoat / webgoatを使用してログインすると、Burp Suiteから、認証が成功すると、JSESSION IDはC8F3177CCAFF380441ABF71090748F2Eであり、AuthCookie = 65432ubphcfxであることがわかります。
Step 3 −資格情報アスペクト/アスペクトを使用してログインすると、認証が成功すると、JSESSION IDはC8F3177CCAFF380441ABF71090748F2Eであり、AuthCookie = 65432udfqtbであることがBurpSuiteからわかります。
Step 4−次に、AuthCookieパターンを分析する必要があります。前半の「65432」は両方の認証に共通です。したがって、ここで、authcookie値の最後の部分（webgoatユーザーの場合は-ubphcfx、アスペクトユーザーの場合はudfqtbなど）を分析することに関心があります。
Step 5− AuthCookieの値を詳しく見ると、最後の部分はユーザー名と同じ長さです。したがって、ユーザー名が何らかの暗号化方式で使用されていることは明らかです。試行錯誤/ブルートフォースメカニズムの結果、ユーザー名を逆にした後、webgoatが見つかりました。最終的にtaogbewになり、その後、前のアルファベット文字がAuthCookieとして使用されます。すなわちubphcfx。
Step 6−このCookie値を渡して、何が起こるかを見てみましょう。ユーザーwebgoatとして認証したら、AuthCookie値を変更して、ユーザーAliceのAuthCookieを見つけ、手順4と手順5を実行してユーザーAliceをモックします。
防止メカニズム
OWASPのアプリケーションセキュリティ検証標準で定義されているすべての認証およびセッション管理要件を満たすように、強力な認証およびセッション管理制御を開発します。
開発者は、セッションIDを盗むために使用される可能性のあるXSSの欠陥を回避する必要があります。
クロスサイトスクリプティング（XSS）は、アプリケーションが信頼できないデータを取得し、検証せずにクライアント（ブラウザー）に送信するたびに発生します。これにより、攻撃者は被害者のブラウザで悪意のあるスクリプトを実行し、ユーザーセッションの乗っ取り、Webサイトの改ざん、またはユーザーの悪意のあるサイトへのリダイレクトを引き起こす可能性があります。
簡単な図を使用して、この欠陥の脅威エージェント、攻撃ベクトル、セキュリティの弱点、技術的影響、およびビジネスへの影響を理解しましょう。
XSSの種類
Stored XSS −永続XSSとも呼ばれる保存されたXSSは、ユーザー入力がデータベース/メッセージフォーラム/コメントフィールドなどのターゲットサーバーに保存されたときに発生します。その後、被害者は保存されたデータをWebアプリケーションから取得できます。
Reflected XSS −非永続的XSSとも呼ばれる反映されたXSSは、ユーザー入力がWebアプリケーションによってエラーメッセージ/検索結果または要求の一部としてユーザーによって提供された入力ですぐに返され、ユーザー提供のデータを永続的に保存しない場合に発生します。
DOM Based 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>ハンズオン
Step 1− Webgoatにログインし、クロスサイトスクリプティング（XSS）セクションに移動します。Stored Cross-site Scripting（XSS）攻撃を実行してみましょう。以下はシナリオのスナップショットです。
Step 2−シナリオに従って、シナリオ自体に記載されているように、パスワード「tom」を使用してTomとしてログインします。[プロファイルの表示]をクリックして、編集モードに入ります。トムは攻撃者なので、これらの編集ボックスにJavaスクリプトを挿入しましょう。
<script>
alert("HACKED")
</script>
Step 3 −更新が終了するとすぐに、トムは「ハッキングされました」というメッセージを含むアラートボックスを受け取ります。これは、アプリが脆弱であることを意味します。
Step 4 −シナリオに従って、jerry（HR）としてログインし、jerryが挿入されたスクリプトの影響を受けるかどうかを確認する必要があります。
Step 5 − Jerryとしてログインした後、以下に示すように「Tom」を選択し、「viewprofile」をクリックします。
ジェリーのアカウントからトムのプロフィールを見ている間、彼は同じメッセージボックスを受け取ることができます。
Step 6 −このメッセージボックスは単なる例ですが、実際の攻撃者はメッセージボックスを表示するだけではありません。
予防メカニズム
開発者は、データが配置される本文、属性、JavaScript、CSS、URLなどのHTMLコンテキストに基づいて、信頼できないすべてのデータを確実にエスケープする必要があります。
入力として特殊文字を必要とするアプリケーションの場合、有効な入力として受け入れる前に、堅牢な検証メカニズムを導入する必要があります。
直接オブジェクト参照は、開発者がファイル、ディレクトリ、データベースキーなどの内部実装オブジェクトへの参照を、攻撃者がこれらの参照を操作して不正なデータにアクセスできる検証メカニズムなしで公開した場合に発生する可能性があります。
簡単な図を使用して、この欠陥の脅威エージェント、攻撃ベクトル、セキュリティの弱点、技術的影響、およびビジネスへの影響を理解しましょう。
例
アプリは、アカウント情報にアクセスしているSQL呼び出しで未確認のデータを使用します。
String sqlquery = "SELECT * FROM useraccounts WHERE account = ?";
PreparedStatement st = connection.prepareStatement(sqlquery, ??);
st.setString( 1, request.getParameter("acct"));
ResultSet results = st.executeQuery( );攻撃者は、ブラウザのクエリパラメータを変更して管理者を指すようにします。
http://webapp.com/app/accountInfo?acct=adminハンズオン
Step 1− Webgoatにログインし、アクセス制御の欠陥セクションに移動します。目標は、tomcat-users.xmlが配置されているパスに移動して、tomcat-users.xmlを取得することです。以下はシナリオのスナップショットです。
Step 2 −ファイルのパスは「現在のディレクトリは」フィールドに表示されます-C：\ Users \ userName $ \。extract \ webapps \ WebGoat \ lesson_plans \ enそして、tomcat-users.xmlファイルが下に保持されていることもわかっていますC：\ xampp \ tomcat \ conf
Step 3−現在のディレクトリから完全に移動し、C：\ Driveから移動する必要があります。Burp Suiteを使用してトラフィックを傍受することで、同じことを実行できます。
Step 4 −試行が成功すると、tomcat-users.xmlに「おめでとうございます。このレッスンは正常に完了しました」というメッセージが表示されます。
予防メカニズム
開発者は、開発フェーズ自体で安全でない直接オブジェクト参照を防ぐためのガイドとして、次のリソース/ポイントを使用できます。
開発者は、間接的なオブジェクト参照に1つのユーザーまたはセッションのみを使用する必要があります。
また、信頼できないソースからの直接オブジェクト参照を使用する前に、アクセスを確認することをお勧めします。
セキュリティ設定の誤りは、セキュリティ設定がデフォルトとして定義、実装、および維持されている場合に発生します。優れたセキュリティには、アプリケーション、Webサーバー、データベースサーバー、およびプラットフォーム用に定義および展開された安全な構成が必要です。ソフトウェアを最新の状態にすることも同様に重要です。
例
セキュリティの設定ミスの典型的な例は次のとおりです。
サーバーでディレクトリリストが無効になっておらず、攻撃者が同じものを発見した場合、攻撃者はディレクトリをリストして任意のファイルを見つけて実行することができます。すべてのカスタムコードを含む実際のコードベースを取得して、アプリケーションの重大な欠陥を見つけることもできます。
アプリサーバーの構成により、スタックトレースをユーザーに返すことができ、根本的な欠陥が明らかになる可能性があります。攻撃者は、エラーメッセージが提供する、侵入するのに十分な追加情報を取得します。
アプリサーバーには通常、十分に保護されていないサンプルアプリが付属しています。本番サーバーから削除しないと、サーバーが危険にさらされる可能性があります。
ハンズオン
Step 1− Webgoatを起動し、安全でない構成セクションに移動して、その課題の解決を試みましょう。同じスナップショットを以下に示します-
Step 2−考えられる限り多くのオプションを試すことができます。構成ファイルのURLを見つけるために必要なのはすべて、開発者が構成ファイルの一種の命名規則に従っていることを知っています。以下にリストされているものであれば何でもかまいません。これは通常、BRUTEフォーステクニックによって行われます。
- web.config
- config
- appname.config
- conf
Step 3 −さまざまなオプションを試してみると、次のことがわかります。http://localhost:8080/WebGoat/conf'は成功しました。試行が成功すると、次のページが表示されます-
予防メカニズム
開発環境、QA環境、本番環境などのすべての環境は、簡単にハッキングできない各環境で使用される異なるパスワードを使用して同じように構成する必要があります。
コンポーネント間の効果的で安全な分離を提供する強力なアプリケーションアーキテクチャが採用されていることを確認します。
また、自動スキャンを実行し、定期的に監査を行うことで、この攻撃の可能性を最小限に抑えることができます。
オンラインアプリケーションは日々インターネットに溢れているため、すべてのアプリケーションが保護されているわけではありません。多くのWebアプリケーションは、クレジットカード情報/銀行口座情報/認証資格情報などの機密性の高いユーザーデータを適切に保護していません。ハッカーは、これらの脆弱に保護されたデータを盗んで、クレジットカード詐欺、個人情報の盗難、またはその他の犯罪を行う可能性があります。
簡単な図を使用して、この欠陥の脅威エージェント、攻撃ベクトル、セキュリティの弱点、技術的影響、およびビジネスへの影響を理解しましょう。
例
セキュリティの設定ミスの典型的な例のいくつかは次のとおりです。
サイトは、認証されたすべてのページにSSLを使用しているわけではありません。これにより、攻撃者はネットワークトラフィックを監視し、ユーザーのセッションCookieを盗んで、ユーザーのセッションを乗っ取ったり、個人データにアクセスしたりすることができます。
アプリケーションは、クレジットカード番号を暗号化された形式でデータベースに保存します。取得時にそれらは復号化され、ハッカーがSQLインジェクション攻撃を実行して、すべての機密情報をクリアテキストで取得できるようにします。これは、公開鍵を使用してクレジットカード番号を暗号化し、バックエンドアプリケーションが秘密鍵を使用してそれらを復号化できるようにすることで回避できます。
ハンズオン
Step 1− WebGoatを起動し、「安全でないストレージ」セクションに移動します。同じスナップショットを以下に示します。
Step 2−ユーザー名とパスワードを入力します。前に説明したさまざまな種類のエンコードおよび暗号化の方法論を学ぶときが来ました。
予防メカニズム
機密データを不必要に保存しないことをお勧めします。不要になった場合は、できるだけ早く破棄する必要があります。
強力で標準的な暗号化アルゴリズムが使用され、適切なキー管理が行われていることを確認することが重要です。
また、パスワードなどの機密データを収集するフォームでオートコンプリートを無効にし、機密データを含むページのキャッシュを無効にすることで回避できます。
ほとんどのWebアプリケーションは、ユーザーがその機能にアクセスできるようにする前に、機能レベルのアクセス権を確認します。ただし、サーバーで同じアクセス制御チェックが実行されない場合、ハッカーは適切な許可なしにアプリケーションに侵入する可能性があります。
簡単な図を使用して、この欠陥の脅威エージェント、攻撃ベクトル、セキュリティの弱点、技術的影響、およびビジネスへの影響を理解しましょう。
例
これは、機能レベルのアクセス制御が欠落している典型的な例です。
ハッカーは単にターゲットURLを強制します。通常、管理者アクセスには認証が必要ですが、アプリケーションアクセスが確認されていない場合、認証されていないユーザーが管理者ページにアクセスできます。
' Below URL might be accessible to an authenticated user
http://website.com/app/standarduserpage
' A NON Admin user is able to access admin page without authorization.
http://website.com/app/admin_pageハンズオン
Step 1 −最初にユーザーとそのアクセス権限のリストを確認して、アカウントマネージャーとしてログインしましょう。
Step 2 −さまざまな組み合わせを試してみると、ラリーがリソースアカウントマネージャーにアクセスできることがわかります。
予防メカニズム
認証メカニズムは、デフォルトですべてのアクセスを拒否し、すべての機能の特定のロールへのアクセスを提供する必要があります。
ワークフローベースのアプリケーションでは、ユーザーがリソースにアクセスできるようにする前に、ユーザーの状態を確認します。
CSRF攻撃は、認証されたユーザー（被害者）に、被害者のセッションCookieを含む偽造されたHTTPリクエストを、脆弱なWebアプリケーションに送信するように強制します。これにより、攻撃者は、被害者のブラウザにリクエストを生成させ、脆弱なアプリが被害者。
簡単な図を使用して、この欠陥の脅威エージェント、攻撃ベクトル、セキュリティの弱点、技術的影響、およびビジネスへの影響を理解しましょう。
例
これがCSRFの典型的な例です-
Step 1 −脆弱なアプリケーションが、暗号化なしで状態変更要求をプレーンテキストとして送信するとします。
http://bankx.com/app?action=transferFund&amount=3500&destinationAccount=4673243243Step 2 −ハッカーは、攻撃者の管理下にあるさまざまなサイトに保存されている画像にリクエストを埋め込むことで、被害者のアカウントから攻撃者のアカウントに送金するリクエストを作成します。
<img src = "http://bankx.com/app?action=transferFunds&amount=14000&destinationAccount=attackersAcct#"
width = "0" height = "0" />ハンズオン
Step 1− Javaスクリプトを画像に埋め込んで、CSRF偽造を実行してみましょう。問題のスナップショットを以下に示します。
Step 2 −次に、転送を1x1画像にモックアップし、被害者に同じ画像をクリックさせる必要があります。
Step 3 −メッセージを送信すると、メッセージは以下のように強調表示されます。
Step 4−被害者が次のURLをクリックすると、転送が実行されます。これは、burpsuiteを使用したユーザーアクションを傍受していることがわかります。以下に示すように、Getメッセージで転送を見つけることで転送を確認できます-
Step 5 − [更新]をクリックすると、レッスン完了マークが表示されます。
予防メカニズム
CSRFは、公開されやすいURLではなくHTTPリクエストの本文で送信される非表示フィールドに一意のトークンを作成することで回避できます。
CSRFを保護するために、ユーザーに再認証を強制するか、ユーザーであることを証明します。たとえば、CAPTCHAです。
この種の脅威は、アプリ内で使用されるライブラリやフレームワークなどのコンポーネントがほとんどの場合、完全な権限で実行される場合に発生します。脆弱なコンポーネントが悪用されると、ハッカーの仕事が簡単になり、深刻なデータ損失やサーバーの乗っ取りが発生します。
簡単な図を使用して、この欠陥の脅威エージェント、攻撃ベクトル、セキュリティの弱点、技術的影響、およびビジネスへの影響を理解しましょう。
例
次の例は、既知の脆弱性を持つコンポーネントの使用例です。
攻撃者は、IDトークンの提供に失敗することにより、完全な権限で任意のWebサービスを呼び出すことができます。
式言語インジェクションの脆弱性を伴うリモートコード実行は、Javaベースのアプリ用のSpringFrameworkを通じて導入されます。
予防メカニズム
データベース/フレームワークだけでなく、Webアプリで使用されているすべてのコンポーネントとバージョンを特定します。
公開データベース、プロジェクトのメーリングリストなどのすべてのコンポーネントを最新の状態に保ちます。
本質的に脆弱なコンポーネントの周りにセキュリティラッパーを追加します。
インターネット上のほとんどのWebアプリケーションは、ユーザーを他のページまたは他の外部Webサイトにリダイレクトおよび転送することがよくあります。ただし、これらのページの信頼性を検証せずに、ハッカーは被害者をフィッシングサイトやマルウェアサイトにリダイレクトしたり、転送を使用して不正なページにアクセスしたりする可能性があります。
簡単な図を使用して、この欠陥の脅威エージェント、攻撃ベクトル、セキュリティの弱点、技術的影響、およびビジネスへの影響を理解しましょう。
例
未検証のリダイレクトと転送のいくつかの典型的な例は次のとおりです-
アプリケーションにページ-redirect.jspがあり、パラメーターredirectrulを受け取るとします。ハッカーは、フィッシングを実行したりマルウェアをインストールしたりするユーザーをリダイレクトする悪意のあるURLを追加します。
http://www.mywebapp.com/redirect.jsp?redirectrul=hacker.comユーザーをサイトのさまざまな部分に転送するために使用されるすべてのWebアプリケーション。同じことを実現するために、一部のページでは、操作が成功した場合にユーザーをリダイレクトする場所を示すパラメーターを使用しています。攻撃者は、アプリケーションのアクセス制御チェックに合格するURLを作成し、攻撃者がアクセス権を取得していない管理機能に攻撃者を転送します。
http://www.mywebapp.com/checkstatus.jsp?fwd=appadmin.jsp予防メカニズム
リダイレクトと転送の使用は避けることをお勧めします。
やむを得ない場合は、宛先のリダイレクトにユーザーパラメータを使用せずに実行する必要があります。
非同期JavascriptおよびXML（AJAX）は、リッチなユーザーエクスペリエンスを提供するためにWebアプリケーションを開発するために使用される最新の手法の1つです。これは新しいテクノロジーであるため、まだ確立されていない多くのセキュリティ問題があり、以下はAJAXのいくつかのセキュリティ問題です。
確保する入力が多いほど、攻撃対象領域は多くなります。
また、アプリケーションの内部機能も公開します。
認証情報とセッションの保護の失敗。
クライアント側とサーバー側の間には非常に狭い境界線があるため、セキュリティミスを犯す可能性があります。
例
これがAJAXセキュリティの例です-
2006年、Yahoo Mailのオンロードイベント処理の脆弱性を利用した、XSSとAJAXを使用したワームに感染したyahooメールサービス。感染した電子メールが開かれると、ワームはJavaScriptを実行し、感染したユーザーのすべてのYahoo連絡先にコピーを送信しました。
ハンズオン
Step 1− XMLインジェクションを使用して、許可された一連の報酬にさらに報酬を追加する必要があります。以下はシナリオのスナップショットです。
Step 2− BurpSuiteを使用してリクエストとレスポンスの両方をインターセプトするようにしてください。以下と同じ設定です。
Step 3−シナリオで指定されたアカウント番号を入力します。対象となるすべての報酬のリストを取得できるようになります。5つのうち3つの報酬を受け取る資格があります。
Step 4−次に、[送信]をクリックして、応答XMLで何が得られるかを確認します。以下に示すように、私たちが適格である3つの報酬はXMLとして私たちに渡されます。
Step 5 −次に、これらのXMLを編集し、他の2つの報酬も追加しましょう。
Step 6−これで、すべての報酬がユーザーに表示され、ユーザーが選択できるようになります。追加したものを選択し、[送信]をクリックします。
Step 7 −「*おめでとうございます。このレッスンは正常に完了しました。」というメッセージが表示されます。
予防メカニズム
クライアント側-
- .innerHtmlの代わりに.innerTextを使用します。
- evalは使用しないでください。
- セキュリティのためにクライアントロジックに依存しないでください。
- シリアル化コードの記述は避けてください。
- XMLを動的に構築することは避けてください。
- シークレットをクライアントに送信しないでください。
- クライアント側のコードで暗号化を実行しないでください。
- クライアント側でセキュリティに影響を与えるロジックを実行しないでください。
サーバー側-
- CSRF保護を使用します。
- シリアル化コードの記述は避けてください。
- ユーザーはサービスを直接呼び出すことができます。
- 手作業でXMLを作成することは避け、フレームワークを使用してください。
- 手作業でJSONを構築することは避け、既存のフレームワークを使用してください。
最新のWebベースのアプリケーションでは、Webサービスの使用は避けられず、攻撃を受ける傾向もあります。Webサービスは複数のWebサイトからのフェッチを要求するため、開発者はハッカーによる侵入を回避するために、いくつかの追加の対策を講じる必要があります。
ハンズオン
Step 1− WebgoatのWebサービス領域に移動し、WSDLスキャンに移動します。他のアカウント番号のクレジットカードの詳細を取得する必要があります。シナリオのスナップショットは以下のとおりです。
Step 2 −名を選択すると、「getFirstName」関数呼び出しはSOAPリクエストxmlを介して行われます。
Step 3− WSDLを開くと、クレジットカード情報を取得するメソッド「getCreditCard」があることがわかります。次に、以下に示すように、BurpSuiteを使用して入力を改ざんしましょう。
Step 4 −次に、以下に示すように、BurpSuiteを使用して入力を変更しましょう。
Step 5 −他のユーザーのクレジットカード情報を取得できます。
予防メカニズム
SOAPメッセージはXMLベースであるため、渡されたすべての資格情報をテキスト形式に変換する必要があります。したがって、常に暗号化する必要のある機密情報を渡す際には、細心の注意を払う必要があります。
パケットの整合性を確保するために適用されるチェックサムなどのメカニズムを実装することにより、メッセージの整合性を保護します。
メッセージの機密性の保護-非対称暗号化は、対称セッションキーを保護するために適用されます。これは、多くの実装で1つの通信に対してのみ有効であり、その後破棄されます。
バッファオーバーフローは、プログラムが意図したよりも多くのデータを一時データストレージ領域（バッファ）に格納しようとしたときに発生します。バッファは有限量のデータを含むように作成されるため、余分な情報が隣接するバッファにオーバーフローし、バッファに保持されている有効なデータが破損する可能性があります。
例
これは、バッファオーバーフローの典型的な例です。これは、動作を制御するために外部データに依存する最初のシナリオによって引き起こされる単純なバッファオーバーフローを示しています。ユーザーが入力するデータの量を制限する方法はありません。プログラムの動作は、ユーザーが入力した文字数によって異なります。
...
char bufr[BUFSIZE];
gets(bufr);
...ハンズオン
Step 1−インターネットにアクセスするには、名前と部屋番号でログインする必要があります。これがシナリオのスナップショットです。
Step 2 −以下に示すように、BurpSuiteで「非表示のフォームフィールドの再表示」も有効にします。
Step 3−ここで、名前と部屋番号のフィールドに入力を送信します。また、部屋番号フィールドにかなり大きな番号を挿入しようとします。
Step 4−非表示フィールドは以下のように表示されます。[利用規約に同意する]をクリックします。
Step 5 −攻撃は成功し、バッファオーバーフローの結果、隣接するメモリ位置の読み取りが開始され、以下に示すようにユーザーに表示されます。
Step 6−表示されたデータを使用してログインしましょう。ロギング後、以下のメッセージが表示されます-
予防メカニズム
- コードレビュー
- 開発者トレーニング
- コンパイラツール
- 安全な機能の開発
- 定期的なスキャン
サービス拒否（DoS）攻撃は、ハッカーがネットワークリソースを利用できないようにする試みです。通常、インターネットに接続されているホストを一時的または無期限に中断します。これらの攻撃は通常、銀行、クレジットカード支払いゲートウェイなどのミッションクリティカルなWebサーバーでホストされているサービスを標的としています。
DoSの症状
- ネットワークパフォーマンスが異常に遅くなります。
- 特定のWebサイトが利用できない。
- Webサイトにアクセスできない。
- 受信するスパムメールの数が劇的に増加しました。
- Webまたはインターネットサービスへのアクセスの長期的な拒否。
- 特定のウェブサイトが利用できない。
ハンズオン
Step 1− WebGoatを起動し、「サービス拒否」セクションに移動します。シナリオのスナップショットを以下に示します。DBスレッドプールの最大サイズに違反して、そこで複数回ログインする必要があります。
Step 2−まず、有効なログインのリストを取得する必要があります。この場合、SQLインジェクションを使用します。
Step 3 −試行が成功すると、すべての有効な資格情報がユーザーに表示されます。
Step 4− DoS攻撃を成功させるために、少なくとも3つの異なるセッションでこれらのユーザーのそれぞれにログインします。DB接続で処理できるスレッドは2つだけであることがわかっているため、すべてのログインを使用すると3つのスレッドが作成され、攻撃が成功します。
予防メカニズム
徹底的な入力検証を実行します。
CPUを大量に消費する操作は避けてください。
データディスクをシステムディスクから分離することをお勧めします。
開発者は、脆弱な可能性のある入力をファイルと直接使用または連結したり、入力ファイルが本物であると想定したりすることがよくあります。データが適切にチェックされていない場合、脆弱なコンテンツがWebサーバーによって処理または呼び出される可能性があります。
例
古典的な例のいくつかは次のとおりです。
- .jspファイルをWebツリーにアップロードします。
- サイズを変更する.gifをアップロードします。
- 巨大なファイルをアップロードします。
- タグを含むファイルをアップロードします。
- .exeファイルをWebツリーにアップロードします。
ハンズオン
Step 1− WebGoatを起動し、悪意のあるファイルの実行セクションに移動します。シナリオのスナップショットを以下に示します-
Step 2 −このレッスンを完了するには、上記の場所にguest.txtをアップロードする必要があります。
Step 3−jspの実行時にguest.txtファイルが作成されるようにjspファイルを作成しましょう。jspファイルのコンテンツを実行しているため、jspの命名はこのコンテキストで果たす役割はありません。
<HTML>
<% java.io.File file = new
java.io.File("C:\\Users\\username$\\.extract\\webapps\\WebGoat\\mfe_target\\guest.txt");
file.createNewFile(); %>
</HTML>Step 4− jspファイルをアップロードし、アップロード後に同じファイルのリンク位置をコピーします。アップロードには画像が必要ですが、jspをアップロードしています。
Step 5 − jspファイルに移動すると、ユーザーへのメッセージは表示されません。
Step 6 − jspファイルをアップロードしたセッションを更新すると、「*おめでとうございます。レッスンは正常に完了しました」というメッセージが表示されます。
予防メカニズム
- Webサイトのアクセス許可を使用してWebサイトを保護します。
- Webアプリケーションのセキュリティ対策を採用します。
- IIS7.0の組み込みのユーザーアカウントとグループアカウントを理解します。
アプリケーションのセキュリティテストを実行するために利用できるさまざまなツールがあります。エンドツーエンドのセキュリティテストを実行できるツールはほとんどありませんが、システムの特定の種類の欠陥を見つけることに専念しているツールもあります。
オープンソースツール
いくつかのオープンソースのセキュリティテストツールは次のとおりです-
| S.No. | ツール名 |
|---|---|
| 1 | Zed Attack Proxy セキュリティ上の欠陥を発見するための自動スキャナーおよびその他のツールを提供します。 https://www.owasp.org |
| 2 | OWASP WebScarab HttpおよびHttpsリクエストを分析するためにJavaで開発されました。 https://www.owasp.org/index.php |
| 3 | OWASP Mantra 多言語のセキュリティテストフレームワークをサポート https://www.owasp.org/index.php/OWASP_Mantra_-_Security_Framework |
| 4 | Burp Proxy トラフィックを傍受および変更するためのツールであり、カスタムSSL証明書を処理します。 https://www.portswigger.net/Burp/ |
| 5 | Firefox Tamper Data tamperdataを使用して、HTTP / HTTPSヘッダーとPOSTパラメーターを表示および変更します https://addons.mozilla.org/en-US |
| 6 | Firefox Web Developer Tools Web Developer拡張機能は、さまざまなWeb開発者ツールをブラウザーに追加します。 https://addons.mozilla.org/en-US/firefox |
| 7 | Cookie Editor ユーザーがCookieを追加、削除、編集、検索、保護、およびブロックできるようにします https://chrome.google.com/webstore |
特定のツールセット
次のツールは、システムの特定のタイプの脆弱性を見つけるのに役立ちます-
| S.No. | リンク |
|---|---|
| 1 | DOMinator Pro − Testing for DOM XSS https://dominator.mindedsecurity.com/ |
| 2 | OWASP SQLiX − SQL Injection https://www.owasp.org/index.php |
| 3 | Sqlninja − SQL Injection http://sqlninja.sourceforge.net/ |
| 4 | SQLInjector − SQL Injection https://sourceforge.net/projects/safe3si/ |
| 5 | sqlpowerinjector − SQL Injection http://www.sqlpowerinjector.com/ |
| 6 | SSL Digger − Testing SSL https://www.mcafee.com/us/downloads/free-tools |
| 7 | THC-Hydra − Brute Force Password https://www.thc.org/thc-hydra/ |
| 8 | Brutus − Brute Force Password http://www.hoobie.net/brutus/ |
| 9 | Ncat − Brute Force Password https://nmap.org/ncat/ |
| 10 | OllyDbg − Testing Buffer Overflow http://www.ollydbg.de/ |
| 11 | Spike − Testing Buffer Overflow https://www.immunitysec.com/downloads/SPIKE2.9.tgz |
| 12 | Metasploit − Testing Buffer Overflow https://www.metasploit.com/ |
商用ブラックボックステストツール
開発するアプリケーションのセキュリティ問題を見つけるのに役立つ商用ブラックボックステストツールのいくつかを次に示します。
| S.No | ツール |
|---|---|
| 1 | NGSSQuirreL https://www.nccgroup.com/en/our-services |
| 2 | IBM AppScan https://www-01.ibm.com/software/awdtools/appscan/ |
| 3 | Acunetix Web Vulnerability Scanner https://www.acunetix.com/ |
| 4 | NTOSpider https://www.ntobjectives.com/products/ntospider.php |
| 5 | SOAP UI https://www.soapui.org/Security/getting-started.html |
| 6 | Netsparker https://www.mavitunasecurity.com/netsparker/ |
| 7 | HP WebInspect http://www.hpenterprisesecurity.com/products |
無料のソースコードアナライザー
| S.No | ツール |
|---|---|
| 1 | OWASP Orizon https://www.owasp.org/index.php |
| 2 | OWASP O2 https://www.owasp.org/index.php/OWASP_O2_Platform |
| 3 | SearchDiggity https://www.bishopfox.com/resources/tools |
| 4 | FXCOP https://www.owasp.org/index.php/FxCop |
| 5 | Splint http://splint.org/ |
| 6 | Boon https://www.cs.berkeley.edu/~daw/boon/ |
| 7 | W3af http://w3af.org/ |
| 8 | FlawFinder https://www.dwheeler.com/flawfinder/ |
| 9 | FindBugs http://findbugs.sourceforge.net/ |
商用ソースコードアナライザー
これらのアナライザーは、脆弱性が発生しやすいソースコードの弱点を調査、検出、および報告します。
| S.No | ツール |
|---|---|
| 1 | Parasoft C/C++ test https://www.parasoft.com/cpptest/ |
| 2 | HP Fortify http://www.hpenterprisesecurity.com/products |
| 3 | Appscan http://www-01.ibm.com/software/rational/products |
| 4 | Veracode https://www.veracode.com |
| 5 | Armorize CodeSecure http://www.armorize.com/codesecure/ |
| 6 | GrammaTech https://www.grammatech.com/ |