diff --git a/CLAUDE.md b/CLAUDE.md index ba6e226f6..605ed9f4e 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -51,7 +51,7 @@ Each protocol (HTTP, DNS, Network, etc.) implements: ### Template System - Templates are YAML files defining vulnerability detection logic - Compiled into executable requests with operators (matchers/extractors) -- Support for workflows (multi-step template execution) +- Support for workflows (multistep template execution) - Template clustering optimizes identical requests across multiple templates ### Key Execution Flow diff --git a/DEBUG.md b/DEBUG.md index dc5c6e8a7..f400d2c1a 100644 --- a/DEBUG.md +++ b/DEBUG.md @@ -22,7 +22,7 @@ When this flag is provided, nuclei will print the list of all helper functions a - `-svd` flag -When this flag is provided, nuclei will print all `variables` pre and post execution of a request for a template. This is useful to understand what variables are available for a template and what values they have. +When this flag is provided, nuclei will print all `variables` pre- and post-execution of a request for a template. This is useful to understand what variables are available for a template and what values they have. - `-elog = errors.txt` flag diff --git a/SYNTAX-REFERENCE.md b/SYNTAX-REFERENCE.md index 8c969912d..33471c651 100755 --- a/SYNTAX-REFERENCE.md +++ b/SYNTAX-REFERENCE.md @@ -4512,7 +4512,7 @@ permutations and combinations for all payloads.
-Payload concurreny i.e threads for sending requests. +Payload concurrency i.e threads for sending requests. diff --git a/integration_tests/protocols/keys/README.md b/integration_tests/protocols/keys/README.md index 7ba87b6f5..4dd2a5b24 100644 --- a/integration_tests/protocols/keys/README.md +++ b/integration_tests/protocols/keys/README.md @@ -1,3 +1,3 @@ ## keys -the keys stored here especially `ci-private-key.pem` and `ci.crt` are used in integration tests to test template signing and verfication functionality introduced in nuclei v3 \ No newline at end of file +the keys stored here especially `ci-private-key.pem` and `ci.crt` are used in integration tests to test template signing and verification functionality introduced in nuclei v3 \ No newline at end of file diff --git a/lib/README.md b/lib/README.md index 3f19ffb48..8d307ef27 100644 --- a/lib/README.md +++ b/lib/README.md @@ -37,7 +37,7 @@ import nuclei "github.com/projectdiscovery/nuclei/v3/lib" ## Advanced Example of using Nuclei Library/SDK -For Various use cases like batching etc you might want to run nuclei in goroutines this can be done by using `nuclei.NewThreadSafeNucleiEngine` +For Various use cases like batching etc. you might want to run nuclei in goroutines this can be done by using `nuclei.NewThreadSafeNucleiEngine` ```go // create nuclei engine with options diff --git a/pkg/input/README.md b/pkg/input/README.md index 4e8e59328..b5936c580 100644 --- a/pkg/input/README.md +++ b/pkg/input/README.md @@ -25,5 +25,5 @@ Currently Nuclei Supports three input providers: func NewInputProvider(opts InputOptions) (InputProvider, error) ``` -This function returns a InputProvider based by appropriately selecting input provider based on the input format (i.e either list or http) and returns the provider that can handle that input format. +This function returns a InputProvider based by appropriately selecting input provider based on the input format (i.e. either list or http) and returns the provider that can handle that input format. diff --git a/pkg/js/CONTRIBUTE.md b/pkg/js/CONTRIBUTE.md index e4c62d9d8..488dd6b89 100644 --- a/pkg/js/CONTRIBUTE.md +++ b/pkg/js/CONTRIBUTE.md @@ -14,7 +14,7 @@ Most of Javascript API Reference documentation is auto-generated with help of co ## Improving Existing Libraries(aka node_modules) -Improving existing libraries includes adding new functions, types, fixing bugs etc to any of the existing libraries in [libs](./libs/) directory. This is very easy to achieve and can be done by following steps below +Improving existing libraries includes adding new functions, types, fixing bugs etc. to any of the existing libraries in [libs](./libs/) directory. This is very easy to achieve and can be done by following steps below 1. Do suggested changes in targeted package in [libs](./libs/) directory 2. Refer [devtools](./devtools/README.md) to autogenerate bindings and documentation @@ -53,7 +53,7 @@ Javascript Protocol Documentation is auto-generated using [jsdoc] and is hosted ### Go Code Guidelines 1. Always use 'protocolstate.Dialer' (i.e fastdialer) to dial connections instead of net.Dial this has many benefits along with proxy support , **network policy** usage (i.e local network access can be disabled from cli) -2. When usage of 'protocolstate.Dialer' is not possible due to some reason ex: imported library does not accept dialer etc then validate host using 'protocolstate.IsHostAllowed' before dialing connection. +2. When usage of 'protocolstate.Dialer' is not possible due to some reason ex: imported library does not accept dialer etc. then validate host using 'protocolstate.IsHostAllowed' before dialing connection. ```go if !protocolstate.IsHostAllowed(host) { // host is not valid according to network policy diff --git a/pkg/js/DESIGN.md b/pkg/js/DESIGN.md index 516ae0c21..66b849c4f 100644 --- a/pkg/js/DESIGN.md +++ b/pkg/js/DESIGN.md @@ -12,7 +12,7 @@ compiler contains abstracted logic for compiling and executing javascript code. ## [devtools](./devtools/README.md) -devtools contains development related tools to automate booring tasks like generating bindings, adding jsdoc comments, generating api reference etc. +devtools contains development related tools to automate boring tasks like generating bindings, adding jsdoc comments, generating api reference etc. ## [generated](./generated/README.md) @@ -28,7 +28,7 @@ generated/js contains a visual representation of all exposed functions and types ## [global](./global/) -global (or builtin) contains all builtin types and functions that are by default available in javascript runtime without needing to import any module using 'require' keyword. Its split into 2 sections +global (or builtin) contains all builtin types and functions that are by default available in javascript runtime without needing to import any module using 'require' keyword. It's split into 2 sections ### [- global/js](./global/js/) diff --git a/pkg/js/devtools/README.md b/pkg/js/devtools/README.md index 65248c2d8..572daafd9 100644 --- a/pkg/js/devtools/README.md +++ b/pkg/js/devtools/README.md @@ -1,6 +1,6 @@ ## devtools -devtools contains tools and scripts to automate booring tasks related to javascript layer/ packages. +devtools contains tools and scripts to automate boring tasks related to javascript layer/ packages. ### bindgen diff --git a/pkg/js/devtools/bindgen/README.md b/pkg/js/devtools/bindgen/README.md index f4028d05e..59737f1eb 100644 --- a/pkg/js/devtools/bindgen/README.md +++ b/pkg/js/devtools/bindgen/README.md @@ -9,6 +9,6 @@ Generated Output is available [here](../../generated/) bindgen generates 3 different types of outputs - `go` => this directory contains corresponding goja bindings (actual bindings code) ex: [kerberos.go](../../generated/go/libkerberos/kerberos.go) -- `js` => this is more of a javascript **representation** of all exposed functions and types etc in javascript ex: [kerberos.js](../../generated/js/libkerberos/kerberos.js) and does not server any functional purpose other than reference +- `js` => this is more of a javascript **representation** of all exposed functions and types etc. in javascript ex: [kerberos.js](../../generated/js/libkerberos/kerberos.js) and does not server any functional purpose other than reference - `markdown` => autogenerated markdown documentation for each library / package ex: [kerberos.md](../../generated/markdown/libkerberos/kerberos.md) diff --git a/pkg/protocols/javascript/js.go b/pkg/protocols/javascript/js.go index 2d927555f..cc7003c53 100644 --- a/pkg/protocols/javascript/js.go +++ b/pkg/protocols/javascript/js.go @@ -76,7 +76,7 @@ type Request struct { // permutations and combinations for all payloads. AttackType generators.AttackTypeHolder `yaml:"attack,omitempty" json:"attack,omitempty" jsonschema:"title=attack is the payload combination,description=Attack is the type of payload combinations to perform,enum=sniper,enum=pitchfork,enum=clusterbomb"` // description: | - // Payload concurreny i.e threads for sending requests. + // Payload concurrency i.e threads for sending requests. // examples: // - name: Send requests using 10 concurrent threads // value: 10 diff --git a/pkg/tmplexec/flow/README.md b/pkg/tmplexec/flow/README.md index f208f7422..9c8383dd7 100644 --- a/pkg/tmplexec/flow/README.md +++ b/pkg/tmplexec/flow/README.md @@ -40,9 +40,9 @@ http: negative: true ``` -but if we carefully re-evaluate this template, we can see that template is sending 9 requests without even checking, if the url actually exists or target site is actually a wordpress site. before v3 it was possible to do this by adding a extractor and sending additional content in say url fragment and it would fail if request was not successful and another way would be writing a workflow (2 templates and 1 workflow file i.e total 3 files for 1 template) but this is `hacky` and not a good solution. +but if we carefully re-evaluate this template, we can see that template is sending 9 requests without even checking, if the url actually exists or target site is actually a wordpress site. before v3 it was possible to do this by adding an extractor and sending additional content in say url fragment and it would fail if request was not successful and another way would be writing a workflow (2 templates and 1 workflow file i.e. total 3 files for 1 template) but this is `hacky` and not a good solution. -With addition of flow in Nuclei v3 we can re-write this template to first check if target is a wordpress site, if yes then bruteforce login with default credentials and this can be achieved by simply adding one line of content i.e `flow: http("check-wp") && http("bruteforce")` and nuclei will take care of everything else. +With addition of flow in Nuclei v3 we can re-write this template to first check if target is a wordpress site, if yes then bruteforce login with default credentials and this can be achieved by simply adding one line of content i.e. `flow: http("check-wp") && http("bruteforce")` and nuclei will take care of everything else. ```yaml id: wordpress-bruteforce @@ -92,7 +92,7 @@ http: part: body negative: true ``` -**Note:** this is just a example template with poor matchers. refer 'nuclei-templates' repo for final template +**Note:** this is just an example template with poor matchers. refer 'nuclei-templates' repo for final template The update template now seems straight forward and easy to understand. we are first checking if target is a wordpress site and then executing bruteforce requests. This is just a simple example of conditional execution and flow accepts any Javascript (ECMAScript 5.1) expression/code so you are free to craft any conditional execution logic you want using for,if and whatnot. @@ -104,11 +104,11 @@ The update template now seems straight forward and easy to understand. we are fi - get/set values from/to template context (global variables) - print/log values to stdout at xyz condition or while debugging - adding custom logic during template execution (ex: if status code is 403 => login and then re-run it) -- use any/all ECMAScript 5.1 javascript (like objects,arrays etc) and build/transform variables/input at runtime +- use any/all ECMAScript 5.1 javascript (like objects,arrays etc.) and build/transform variables/input at runtime - update variables at runtime (ex: when jwt expires update it by using refresh token and then continue execution) - and a lot more (this is just a tip of iceberg) -simply put request execution orchestration can be understood as nuclei logic bindings for javascript (i.e two way interaction between javascript and nuclei for a specific template) +simply put request execution orchestration can be understood as nuclei logic bindings for javascript (i.e. two way interaction between javascript and nuclei for a specific template) To better understand orchestration we can try to build a template for vhost enumeration using flow. which usually requires writing / using a new tool @@ -258,10 +258,10 @@ This section contains a brief description of all nuclei JS bindings and their us **1. Protocol Execution Functions** - Any protocol that is present in a nuclei template can be called/executed in javascript in format `proto_name()` i.e `http()` , `dns()` , `ssl()` etc + Any protocol that is present in a nuclei template can be called/executed in javascript in format `proto_name()` i.e `http()` , `dns()` , `ssl()` etc. If we want to execute a specific request of a protocol (ref: see [nuclei-flow-dns](testcases/nuclei-flow-dns-id.yaml)) this can be achieved by either passing - - index of that request in protocol (ex: `dns(0)`, `dns(1)` etc) - - id of that request in protocol (ex: `dns("extract-vps")`, `dns("probe-http")` etc) + - index of that request in protocol (ex: `dns(0)`, `dns(1)` etc.) + - id of that request in protocol (ex: `dns("extract-vps")`, `dns("probe-http")` etc.) For More complex use cases multiple requests of a single protocol can be executed by just specifying their index or id one after another (ex: `dns("extract-vps","1")`) **2. Iterate Helper Function** @@ -288,12 +288,12 @@ This section contains a brief description of all nuclei JS bindings and their us **4. Template Context** - when using `nuclei -jsonl` flag we get lot of data/metadata related to a vulnerability (ex: template details,extracted-values and much more) . A template context is nothing but a map/JSON containing all this data along with internal/unexported data that is only available at runtime (ex: extracted values from previous requests, variables added using `set()` etc). This template context is available in javascript as `template` variable and can be used to access any data from it. ex: `template["ssl_subject_cn"]` , `template["ssl_subject_an"]` etc + when using `nuclei -jsonl` flag we get lot of data/metadata related to a vulnerability (ex: template details,extracted-values and much more) . A template context is nothing but a map/JSON containing all this data along with internal/unexported data that is only available at runtime (ex: extracted values from previous requests, variables added using `set()` etc.). This template context is available in javascript as `template` variable and can be used to access any data from it. ex: `template["ssl_subject_cn"]` , `template["ssl_subject_an"]` etc ```javascript template["ssl_subject_cn"] // returns value of ssl_subject_cn from template context which is available after executing ssl request template["ptrValue"] // returns value of ptrValue which was extracted using regex with internal: true ``` - Lot of times we don't known what all data is available in template context and this can be easily found by printing it to stdout using `log()` function + Lot of times we don't know what all data is available in template context and this can be easily found by printing it to stdout using `log()` function ```javascript log(template) ``` diff --git a/pkg/tmplexec/multiproto/README.md b/pkg/tmplexec/multiproto/README.md index 7f874a8ae..ce0ad67db 100644 --- a/pkg/tmplexec/multiproto/README.md +++ b/pkg/tmplexec/multiproto/README.md @@ -5,15 +5,15 @@ when template is unmarshalled, if it uses more than one protocol, then order of multiproto is engine/backend for TemplateExecutor which takes care of sharing logic between protocols and executing them in order ### Execution -when multi protocol template is executed , all protocol requests present in Queue are executed in order +when multiprotocol template is executed , all protocol requests present in Queue are executed in order and dynamic values extracted are added to template context. - Protocol Responses apart from extracted `internal:true` values response fields/values of protocol are added to template context at `ExecutorOptions.TemplateCtx` which takes care of sync and other issues if any. all response fields are prefixed with template type prefix ex: `ssl_subject_dn` -### Adding New Protocol to multi protocol execution logic -while logic/implementation of multi protocol execution is abstracted. it requires 3 statements to be added in newly implemented protocol +### Adding New Protocol to multiprotocol execution logic +while logic/implementation of multiprotocol execution is abstracted. it requires 3 statements to be added in newly implemented protocol to make response fields of that protocol available to global context - Add `request.options.GetTemplateCtx(f.input.MetaInput).GetAll()` to variablesMap in `ExecuteWithResults` Method just above `request.options.Variables.Evaluate` @@ -37,9 +37,9 @@ to make response fields of that protocol available to global context outputEvent = generators.MergeMaps(outputEvent, request.options.GetTemplateCtx(f.input.MetaInput).GetAll()) ``` -adding these 3 statements takes care of all logic related to multi protocol execution +adding these 3 statements takes care of all logic related to multiprotocol execution ### Exceptions - statements 1 & 2 are intentionally skipped in `file` protocol to avoid redundant data - file/dir input paths don't contain variables or are used in path (yet) - - since files are processed by scanning each line. adding statement 2 will unintenionally load all file(s) data + - since files are processed by scanning each line. adding statement 2 will unintentionally load all file(s) data