ディレクトリ構造の注意点:
スクリプト generate-directories.py は、GitHubからVRT構造の最新バージョンを取得し、欠落しているディレクトリを作成します。VRTから削除された項目に基づいてディレクトリを削除または名前変更することはありません。
スクリプトは標準のエントリ名に従い、VRTの id フィールドで指定されたアンダースコアと大文字小文字を保持します。
このリポジトリでは「Protected Master」が有効になっています。つまり、プロジェクト管理者のみがプルリクエストを介してmasterブランチにコミットできます。整合性を確保するため、すべての更新はプルリクエスト経由で行う必要があります。
以下は、SSHアクセスが正しく設定されていることを前提としています。
まず、masterブランチをチェックアウトします:
git clone [email protected]:bugcrowd/templates.git ## n.b. using SSH aliases can make this much simpler
masterをシステムに取得したら、これから行う作業用のブランチを作成する必要があります:
git checkout -b <branch-name>
ブランチ名の例としては、XXE-templates や XSS-templates など、作業内容を表すものが考えられます。ブランチは小さく保ち、できればテンプレートのグループ程度に留めてください。コミットとプッシュを頻繁に行いましょう!
git commit -am "Comments about what you changed go here" は、変更をローカルのgitリポジトリに保存します。常に説明的なコミットメッセージを残してください。
テンプレートが完成したら、リポジトリにプッシュできます。これらはまだ独自のブランチですが、プッシュするとリンターが実行され、一連のルールに対してmarkdownを検証します。サンプルテンプレートに従い、あまり逸脱していなければ、テンプレートは合格するはずです。
git push --set-upstream origin <branch-name> これにより、originサーバー（github）上にブランチが作成され、変更がプッシュされます。これはブランチに対して一度だけ行う必要があり、以降のブランチへのプッシュは git push で実行できます。
リンターが正常に実行されたら、プルリクエスト（PR）を作成できます。
GitHubのインターフェースでブランチを選択してください。コードの上に「Pull request」ボタンが表示されます。
そのボタンをクリックし、プロジェクト管理者がレビューできるように変更内容の詳細を入力して、「Create pull request」をクリックします。
これで完了です! 私たちがPRをレビューし、適切にマージまたは却下します。
PRが承認されたら、ブランチを削除して問題ありません。
git branch -d <branch-name>
以下はテンプレートの例です。すべてのセクションに正しい情報を記入してください。
## Overview of the Vulnerability
Provide a 1-2 sentence description of the vulnerability.
This format is a good guide:
[VULNTYPE] in [COMPONENT] in [APPLICATION] allows [ATTACKER] to [IMPACT] via [VECTOR]
## Business Impact
Provide an example of the impact to the business. This could be reputational damage, financial loss, a loss in customer trust, etc.
## Steps to Reproduce
Provide a step-by-step walkthrough on how to access the vulnerable injection point, and how to exploit the vulnerability.
Example:
1. Login to in-scope asset at <www.bugcrowd.com/login>
1. Browse to account page
1. Modify ID token to add single quote
1. View error which states 'SQL Syntax Error'
1. Replace ID value with `1' waitfor delay '00:00:10'; `
## Proof of Concept (PoC)
Your submission must include evidence of the vulnerability and not be theoretical in nature.
You may present your evidence as output from a tool, such as SQLMap, unless the program forbids the use of these tools. Evidence may also be in the format of terminal output, screenshots, or video.
Use this section to demonstrate clearly the effect of the vulnerability. However, do not access Personally Identifiable Information (PII).
これはテンプレートの例です:
# Reflected Cross-Site Scripting (Non-self)
## Overview of the Vulnerability
Reflected Cross-Site Scripting (XSS) is a type of injection attack where malicious JavaScript code is injected into a website. When a user visits the affected web page, the JavaScript code executes and its input is reflected in the user’s browser. Reflected XSS can be found on this domain which allows an attacker to create a crafted URL. When opened by a user, this URL will execute arbitrary Javascript within that user’s browser in the context of this domain.
When an attacker can control code that is executed within a user’s browser, they are able to carry out any actions that the user is able to perform, including accessing any of the user's data and modifying information within the user’s permissions. This can result in modification, deletion, or theft of data, including accessing or deleting files, or stealing session cookies which an attacker could use to hijack a user’s session.
## Business Impact
Reflected XSS could lead to data theft through the attacker’s ability to manipulate data through their access to the application, and their ability to interact with other users, including performing other malicious attacks, which would appear to originate from a legitimate user. These malicious actions could also result in reputational damage for the business through the impact to customers’ trust.
## Steps to Reproduce
1. Enable a HTTP interception proxy, such as Burp Suite or OWASP ZAP
1. Use a browser to navigate to: {{URL}}
1. Forward the following request to the endpoint:
```HTTP Request
{{request}}
```
1. Observe the JavaScript payload being executed
## Proof of Concept (PoC)
Below is a screenshot demonstrating the injected JavaScript executing at the vulnerable endpoint:
{{screenshot}}
可能な限り受動態を使用してください。例:
正しい:
WebアプリケーションでSQLインジェクションの脆弱性が発見されました。
間違った:
私はWebアプリケーションでSQLインジェクションの脆弱性を発見しました。
間違った:
BugcrowdはWebアプリケーションでSQLインジェクションの脆弱性を発見しました。
間違った:
私たちはWebアプリケーションでSQLインジェクションの脆弱性を発見しました。
間違った:
調査工程全体を通じて、バックエンドデータベースから個人を特定できる情報を攻撃者が窃取できる可能性がある、重大度が高いSQLインジェクションがWebアプリケーション（<www.example.com>）で発見されました。
正しい:
悪意のある攻撃者が個人を特定できる情報を窃取できるSQLインジェクションが、<www.example.com>で発見されました。
間違った:
悪意のある攻撃者が個人を特定できる情報（メールアドレスを含む）を窃取できるSQLインジェクションが、<www.example.com>で発見されました。これはGDPR違反とみなされ、重大なビジネスリスクをもたらします。
正しい:
悪意のある攻撃者が個人を特定できる情報を窃取できるSQLインジェクションが、<www.example.com>で発見されました。取得可能なデータには、パスワード、メールアドレス、氏名が含まれます。これはGDPR違反であり、重大なビジネスリスクをもたらします。
略語を使用する場合は、最初に括弧内に略語を入れて完全な表記を必ず行ってください。完全な表記が一度行われたら、以降は略語のみを使用できます。
例:
クロスサイトスクリプティング（XSS）は、悪意のある攻撃者が被害者のブラウザでJavaScriptを実行できるようにするクライアントサイド攻撃です。XSSは、ユーザー入力がエンコードされずにブラウザに反映されると発生します。
クロスサイトリクエストフォージェリ（CSRF）がexample.comで発見されました。このCSRFにより、被害者のユーザーに知られることなく、そのユーザーの住所を更新できます。
正しい: Bugcrowd 間違った: BugCrowd、bugcrowd、Bug Crowd、Bug crowd、bug crowd。
正しい: pentest（文法的に必要な場合はPentest） 間違った: pen test、PenTest、Pen Test
「an」は次の単語が子音の音で始まる場合に使用します。それ以外の場合は「a」を使用します。
正しい:
間違った:
使用する言語は常に感情を排し、公平でなければなりません。
例:
{{target}}: プログラムページに記載されているスコープ内ターゲットの名前（例: *.bugcrowd.com）{{application}}: ターゲット内の特定のアプリケーション（例: Acme Inc. Employee Portal）{{type}}: プログラムページでターゲットの横に記載されている実施済みテストの種類（例: ウェブサイトテスト、APIテスト、モバイルアプリケーションテスト、ハードウェアテストなど）{{url}}: URLのプレースホルダー（例: https://bugcrowd.com/vulnerability-rating-taxonomy）{{version}}: テスト対象ソフトウェアの特定のバージョン番号（例: 13.3.7）{{program}}: プログラム名（例: Bugcrowd）{{screenshot}}: 実行された概念実証を示す写真またはビデオの証拠。{{action}}: 悪意のある攻撃者がそれを悪用した場合に実行できるアクション（例: セッショントークンの窃取、管理アカウントの完全な制御、PIIのダンプなど）{{parameter}}: クライアントからサーバーへデータを送信する変数で、さまざまなタイプのデータを格納できます。その処理はサーバーサイドのコードによって決定されます。（例: id=1337）{{hardware}}: IoTまたは自動車関連アセットを悪用するために使用される特定のハードウェア{{software}}: アセットを悪用するために使用される特定のソフトウェア（例: burp、nessus、niktoなど）{{payload}}: アセット上で実行されるコマンドまたはペイロード{{value}}: 特定のメトリック値（秒、ミリ秒、周波数など）このリポジトリには bugcrowd_templates gemが含まれています。このgemは、VRTの選択に基づいて、提出物の説明と方法論のメモ用の templates を取得するために使用されます。これは Bugcrowd Engineering によって使用・保守されています。
アプリケーションのGemfileに次の行を追加してください:
gem 'bugcrowd_templates'
開発の利便性のために、gemを試すためのプレイグラウンドを起動するユーティリティを提供しています。次のコマンドで呼び出すことができます:
bin/console
以下は、提出物の説明フィールドと方法論のメモフィールドで templates を取得するための BugcrowdTemplates の呼び出し例です。