daffainfo
/
nuclei-templates
mirror of https://github.com/daffainfo/nuclei-templates.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Update GUIDE.md

patch-1
Ice3man 2020-04-04 22:17:48 +05:30 committed by GitHub
parent 3eb7ad2748
commit 656b88aed8
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 98 additions and 79 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

177
GUIDE.md
View File

@ -6,20 +6,20 @@ The templates are written in `YAML` which specifies a simple human readable form
Let's start with the basics and define our own workflow file for detecting the presence of a `.git/config` file on a webserver and take it from there. Let's start with the basics and define our own workflow file for detecting the presence of a `.git/config` file on a webserver and take it from there.
[TOC]
## Template Details
### Defining a .git/config detection template
Each template has a unique ID which is used during output writing to specify the template name for an output line. Each template has a unique ID which is used during output writing to specify the template name for an output line.
The template file ends with **.yaml** extension. Start by creating a file named `git-config.yaml` in your favorite text editor and defining an **<u>id</u>** for our sample template. The template file ends with **.yaml** extension. The template files can be created any text editor of your choice.
```yaml ```yaml
# id contains the unique identifier for the template. # id contains the unique identifier for the template.
id: git-config id: git-config
``` ```
We name our template file as `git-config`. You can go ahead and name it whatever you desire. ### **Info**
Next important piece of information about a template is the <u>**info**</u> block. Info block provides more context on the purpose of the template and the **author**. It can also contain a **severity** field which indicates the severity of the template. Next important piece of information about a template is the <u>**info**</u> block. Info block provides more context on the purpose of the template and the **author**. It can also contain a **severity** field which indicates the severity of the template.
@ -40,6 +40,8 @@ Actual requests and corresponding matchers are placed below the info block and t
Each template file can contain multiple requests to be made. The template is iterated and one by one the desired HTTP requests are made to the target sites. Each template file can contain multiple requests to be made. The template is iterated and one by one the desired HTTP requests are made to the target sites.
### **Requests**
Requests start with a request block which specifies the start of the requests for the template. Requests start with a request block which specifies the start of the requests for the template.
```yaml ```yaml
@ -49,106 +51,124 @@ requests:
Requests can be fine tuned to perform the exact tasks as desired. Nuclei requests are fully configurable meaning you can configure and define each and every single thing about the requests that will be sent to the target servers. Requests can be fine tuned to perform the exact tasks as desired. Nuclei requests are fully configurable meaning you can configure and define each and every single thing about the requests that will be sent to the target servers.
1. First thing in the request is <u>**method**</u>. Request method can be **GET**, **POST**, **PUT**, **DELETE**, etc depending on the needs. #### **Method**
```yaml First thing in the request is <u>**method**</u>. Request method can be **GET**, **POST**, **PUT**, **DELETE**, etc depending on the needs.
# method is the method for the request
method: GET
```
2. The next part of the requests is the **path** of the request path. Dynamic variables can be placed in the path to modify its behaviour on runtime. Variables start with `{{` and end with `}}` and are case-sensitive. ```yaml
# method is the method for the request
method: GET
```
1. **BaseURL** - Placing BaseURL as a variable in the path will lead to it being replaced on runtime in the request by the original URL as specified in the target file. #### **Path**
2. **Hostname** - Hostname variable is replaced by the hostname of the target on runtime.
Some sample dynamic variable replacement examples - The next part of the requests is the **path** of the request path. Dynamic variables can be placed in the path to modify its behaviour on runtime. Variables start with `{{` and end with `}}` and are case-sensitive.
```yaml 1. **BaseURL** - Placing BaseURL as a variable in the path will lead to it being replaced on runtime in the request by the original URL as specified in the target file.
path: {{BaseURL}}/.git/config 2. **Hostname** - Hostname variable is replaced by the hostname of the target on runtime.
# this path will be replaced on execution with BaseURL
# When BaseURL = https://abc.com
# path will get replaced to the following -
https://abc.com/.git/config
```
Multiple paths can also be specified in one request which will be requested for the target. Some sample dynamic variable replacement examples -
3. **Headers** can also be specified to be sent along with the requests. Headers are placed in form of Key-Value pairs. An example header configuration is - ```yaml
path: {{BaseURL}}/.git/config
# this path will be replaced on execution with BaseURL
# When BaseURL = https://abc.com
# path will get replaced to the following -
https://abc.com/.git/config
```
```yaml Multiple paths can also be specified in one request which will be requested for the target.
# headers contains the headers for the request
headers:
# Custom user-agent header
User-Agent: Some-Random-User-Agent
# Custom request origin
Origin: https://google.com
```
4. **Body** specifies a body to be sent along with the request. For instance - #### **Headers**
```yaml Headers can also be specified to be sent along with the requests. Headers are placed in form of Key-Value pairs. An example header configuration is -
# body is a string sent along with the request
body: "{\"some random json\"}"
```
5. **Matchers** are the core of nuclei. They are what make the tool so powerful. Multiple type of combinations and checks can be added to ensure that the results you get are free from false positives. ```yaml
# headers contains the headers for the request
headers:
# Custom user-agent header
User-Agent: Some-Random-User-Agent
# Custom request origin
Origin: https://google.com
```
Multiple matchers can be specified in a request. There are basically 4 types of matchers - #### **Body**
| Matcher Type | Part Matched | Body specifies a body to be sent along with the request. For instance -
| ------------ | -------------------------- |
| status | Status Code of Response |
| size | Content Length of Response |
| word | Response body or headers |
| regex | Response body or headers |
To match status codes for responses, you can use the following syntax. ```yaml
# body is a string sent along with the request
body: "{\"some random json\"}"
```
```yaml #### **Matchers**
matcher:
# match the status codes
- type: status
# some status codes we want to match
status:
- 200
- 302
```
To match size, similar structure can be followed. If the status code of response from the site matches any single one specified in the matcher, the request is marked as successful. Matchers are the core of nuclei. They are what make the tool so powerful. Multiple type of combinations and checks can be added to ensure that the results you get are free from false positives.
**Word** and **Regex** matchers can be further configured depending on the needs of the users. ##### **Types**
Multiple words and regexes can be specified in a single matcher and can be configured with different conditions like **AND** and **OR**. Multiple matchers can be specified in a request. There are basically 4 types of matchers -
1. **AND** - Using AND conditions allows matching of all the words from the list of words for the matcher. Only then will the request be marked as successful when all the words have been matched. | Matcher Type | Part Matched |
2. **OR** - Using OR conditions allows matching of a single word from the list of matcher. The request will be marked as successful when even one of the word is matched for the matcher. | ------------ | -------------------------- |
| status | Status Code of Response |
| size | Content Length of Response |
| word | Response body or headers |
| regex | Response body or headers |
Multiple parts of the response can also be matched for the request. To match status codes for responses, you can use the following syntax.
| Part | Matched Part | ```yaml
| ------ | ------------------------------------ | matcher:
| body | Body of the response | # match the status codes
| header | Header of the response | - type: status
| all | Both body and header of the response | # some status codes we want to match
status:
- 200
- 302
```
Example matchers for response body using AND condition - To match size, similar structure can be followed. If the status code of response from the site matches any single one specified in the matcher, the request is marked as successful.
```yaml **Word** and **Regex** matchers can be further configured depending on the needs of the users.
matcher:
# match the body word ##### **Conditions**
- type: word
# some words we want to match Multiple words and regexes can be specified in a single matcher and can be configured with different conditions like **AND** and **OR**.
words:
- "[core]" 1. **AND** - Using AND conditions allows matching of all the words from the list of words for the matcher. Only then will the request be marked as successful when all the words have been matched.
- "[config]" 2. **OR** - Using OR conditions allows matching of a single word from the list of matcher. The request will be marked as successful when even one of the word is matched for the matcher.
# both words must be found in the response body
condition: and ##### **Matched Parts**
# we want to match request body (default)
part: body Multiple parts of the response can also be matched for the request.
```
| Part | Matched Part |
| ------ | ------------------------------------ |
| body | Body of the response |
| header | Header of the response |
| all | Both body and header of the response |
Example matchers for response body using AND condition -
```yaml
matcher:
# match the body word
- type: word
# some words we want to match
words:
- "[core]"
- "[config]"
# both words must be found in the response body
condition: and
# we want to match request body (default)
part: body
```
Similarly, matchers can be written to match anything that you want to find in the response body allowing unlimited creativity and extensibility. Similarly, matchers can be written to match anything that you want to find in the response body allowing unlimited creativity and extensibility.
##### **Example Template**
The final template file for the `.git/config` file mentioned above is as follows - The final template file for the `.git/config` file mentioned above is as follows -
```yaml ```yaml
@ -168,4 +188,3 @@ requests:
words: words:
- "[core]" - "[core]"
``` ```