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-06 00:54:04 +05:30 committed by GitHub
parent c36b3dc35e
commit b1c401a8f8
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 132 additions and 107 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

239
GUIDE.md
View File

@ -1,10 +1,10 @@
Templating Guide # Templating Guide
Nuclei is based on the concepts of YAML based template files that define how the requests will be sent and processed. This allows easy extensibility capabilities to nuclei. **Nuclei** is based on the concepts of `YAML` based template files that define how the requests will be sent and processed. This allows easy extensibility capabilities to nuclei.
The templates are written in YAML which specifies a simple human readable format to quickly define the execution process. The templates are written in `YAML` which specifies a simple human readable format to quickly define the execution process.
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.
Table of Contents Table of Contents
================= =================
@ -24,178 +24,203 @@ Table of Contents
* [Extractors](#extractors) * [Extractors](#extractors)
* [<strong>Example Template</strong>](#example-template) * [<strong>Example Template</strong>](#example-template)
Template Details ## Template Details
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. The template files can be created any text editor of your choice. The template file ends with **.yaml** extension. The template files can be created any text editor of your choice.
# id contains the unique identifier for the template. ```yaml
id: git-config # id contains the unique identifier for the template.
id: git-config
```
ID must not contain spaces. This is done to allow easier output parsing. ID must not contain spaces. This is done to allow easier output parsing.
Info ### **Info**
Next important piece of information about a template is the info 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.
Let's add an info block to our template as well. 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.
info: Let's add an **info** block to our template as well.
# name is the name of the template
name: Git Config File Detection Template ```yaml
# author is the name of the author for the template info:
author: Ice3man # name is the name of the template
# severity is the severity for the template. name: Git Config File Detection Template
severity: medium # author is the name of the author for the template
author: Ice3man
# severity is the severity for the template.
severity: medium
```
Actual requests and corresponding matchers are placed below the info block and they perform the task of making requests to target servers and finding if the template request was succesful. Actual requests and corresponding matchers are placed below the info block and they perform the task of making requests to target servers and finding if the template request was succesful.
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**
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.
# start the requests for the template right here ```yaml
requests: # start the requests for the template right here
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.
Method #### **Method**
First thing in the request is method. Request method can be GET, POST, PUT, DELETE, etc depending on the needs. 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 ```yaml
method: GET # method is the method for the request
method: GET
```
Path #### **Path**
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. 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.
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. 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.
2. Hostname - Hostname variable is replaced by the hostname of the target on runtime. 2. **Hostname** - Hostname variable is replaced by the hostname of the target on runtime.
Some sample dynamic variable replacement examples - Some sample dynamic variable replacement examples -
path: {{BaseURL}}/.git/config ```yaml
# this path will be replaced on execution with BaseURL path: {{BaseURL}}/.git/config
# When BaseURL = https://abc.com # this path will be replaced on execution with BaseURL
# path will get replaced to the following - # When BaseURL = https://abc.com
https://abc.com/.git/config # 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. Multiple paths can also be specified in one request which will be requested for the target.
Headers #### **Headers**
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 - 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 -
# headers contains the headers for the request ```yaml
headers: # headers contains the headers for the request
# Custom user-agent header headers:
User-Agent: Some-Random-User-Agent # Custom user-agent header
# Custom request origin User-Agent: Some-Random-User-Agent
Origin: https://google.com # Custom request origin
Origin: https://google.com
```
Body #### **Body**
Body specifies a body to be sent along with the request. For instance - Body specifies a body to be sent along with the request. For instance -
# body is a string sent along with the request ```yaml
body: "{\"some random json\"}" # body is a string sent along with the request
body: "{\"some random json\"}"
```
Matchers #### **Matchers**
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. 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.
Types ##### **Types**
Multiple matchers can be specified in a request. There are basically 4 types of matchers - Multiple matchers can be specified in a request. There are basically 4 types of matchers -
Matcher Type Part Matched | Matcher Type | Part Matched |
status Status Code of Response | ------------ | -------------------------- |
size Content Length of Response | status | Status Code of Response |
word Response body or headers | size | Content Length of Response |
regex Response body or headers | word | Response body or headers |
| regex | Response body or headers |
To match status codes for responses, you can use the following syntax. To match status codes for responses, you can use the following syntax.
matcher: ```yaml
# match the status codes matcher:
- type: status # match the status codes
# some status codes we want to match - type: status
status: # some status codes we want to match
- 200 status:
- 302 - 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. 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.
Word and Regex matchers can be further configured depending on the needs of the users. **Word** and **Regex** matchers can be further configured depending on the needs of the users.
Conditions ##### **Conditions**
Multiple words and regexes can be specified in a single matcher and can be configured with different conditions like AND and OR. Multiple words and regexes can be specified in a single matcher and can be configured with different conditions like **AND** and **OR**.
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. 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.
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. 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.
Matched Parts ##### **Matched Parts**
Multiple parts of the response can also be matched for the request. Multiple parts of the response can also be matched for the request.
Part Matched Part | Part | Matched Part |
body Body of the response | ------ | ------------------------------------ |
header Header of the response | body | Body of the response |
all Both body and header of the response | header | Header of the response |
| all | Both body and header of the response |
Example matchers for response body using AND condition - Example matchers for response body using AND condition -
matcher: ```yaml
# match the body word matcher:
- type: word # match the body word
# some words we want to match - type: word
words: # some words we want to match
- "[core]" words:
- "[config]" - "[core]"
# both words must be found in the response body - "[config]"
condition: and # both words must be found in the response body
# we want to match request body (default) condition: and
part: body # 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.
Extractors #### Extractors
Extractors are another important feature of nuclei. Extractors can be used to extract and display in results a match from the response body or headers based on a regular expression. Extractors are another important feature of nuclei. Extractors can be used to extract and display in results a match from the response body or headers based on a regular expression.
Currently on regex type extractors are supported. A sample extractor for extracting API keys from the response body is as follows - Currently on `regex` type extractors are supported. A sample extractor for extracting API keys from the response body is as follows -
# A list of extractors for text extraction ```yaml
extractors: # A list of extractors for text extraction
# type of the extractor, only regex for now. extractors:
- type: regex # type of the extractor, only regex for now.
# part of the response to extract (can be headers, all too) - type: regex
part: body # part of the response to extract (can be headers, all too)
# regex to use for extraction. part: body
regex: # regex to use for extraction.
- "(A3T[A-Z0-9]|AKIA|AGPA|AROA|AIPA|ANPA|ANVA|ASIA)[A-Z0-9]{16}" regex:
- "(A3T[A-Z0-9]|AKIA|AGPA|AROA|AIPA|ANPA|ANVA|ASIA)[A-Z0-9]{16}"
```
Example Template ## **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 -
id: git-config ```yaml
id: git-config
info:
name: Git Config File info:
author: Ice3man name: Git Config File
severity: medium author: Ice3man
severity: medium
requests:
- method: GET requests:
path: - method: GET
- "{{BaseURL}}/.git/config" path:
matchers: - "{{BaseURL}}/.git/config"
- type: word matchers:
words: - type: word
- "[core]" words:
- "[core]"
```