This phase is used in a modifying extension and is optional for its operation (the
generate section may be either absent or present in the YAML file).
This phase should be absent from the non-modifying extension's YAML file.
Read about the extension types in detail here.
When creating a FAST extension, you need to understand the structure of the HTTP request sent to the application and that of the HTTP response received from the application in order to correctly describe the request elements that you need to work with using the points.
To see detailed information, proceed to this link.
This phase specifies a payload to be inserted in the particular parameters of a baseline request to create a test requests that are based on this request.
generate section has the following structure:
generate: - into: - parameter 1 - parameter 2 - … - parameter N - method: - postfix - prefix - random - replace - payload: - payload 1 - payload 2 - … - payload N
intoparameter allows the specification of single or multiple request elements that the payload should be inserted into. This parameter's value can be a string or an array of strings. You can use a Ruby-formatted regular expression as the
This parameter is optional and it may be absent in the section. If the
intoparameter is omitted, the payload is inserted into the request element that is allowed to be modified according to the given test policy.
Let us suppose that the following mutable request elements were extracted from the baseline request according to the test policy:
The extension will sequentially process all of the mutable elements (also known as insertion points).
intoparameter is absent, then the payloads will be sequentially pasted into the
GET_uid_valueparameter and the produced test requests will be used to check the target application for vulnerabilities. Then, after the test request results are processed, the extension processes the
HEADER_COOKIE_valueparameter and similarly inserts the payloads into this parameter.
intoparameter contains the
GET_uid_valuerequest parameter, as shown in the following example, then the payload will be inserted into the
GET_uid_valueparameter but not the
into: - 'GET_uid_value'
Because the following example contains only one parameter, the into parameter value may be written in one line:
method— this optional parameter specifies the list of the methods that will be used to insert the payload into the baseline request element.
prefix— insert the payload before the baseline request element value.
postfix— insert the payload after the baseline request element value.
random— insert the payload into a random place in the baseline request element value.
replace— replace the baseline request element value with the payload.
methodparameter is absent, the
replacemethod will be used by default.
The number of test requests created depends on the number of specified
methods: one test request per insertion method.
For example, if the following insertion methods are specified:
method: - prefix - replace
then for a single payload, two test requests are created; for two payloads, four test requests are created (two test requests for each payload), and so on.
payloadparameter specifies the list of payloads to be inserted into the request parameter to create a test request that will then test the target application for vulnerabilities.
This parameter is obligatory, and it should always be present in the section. The list should contain at least one payload. If there are multiple payloads, the FAST node sequentially inserts payloads into the request parameter and tests the target application for vulnerabilities using each of the test requests created.
The payload is a string that is inserted into one of the parameters during the request processing.
Example of multiple payloads.
payload: - "') or 1=('1" - "/%5c../%5c../%5c../%5c../%5c../%5c../%5c../etc/passwd/"
You can use special markers as a part of the payload to further expand the possibilities of vulnerability detection.
STR_MARKER— insert a random string into the payload exactly in the position where the
For example, the
STR_MARKERcan be used to check the application for an XXS vulnerability.
CALC_MARKER— insert a string containing a random arithmetic expression (for example,
1234*100) into the payload exactly in the position where the
For example, the
CALC_MARKERcan be used to check the application for an RCE vulnerability.
'; bc <<< CALC_MARKER'
DNS_MARKER— insert a string containing a random domain (for example,
r4nd0m.wlrm.tl) into the payload exactly in the position where the
For example, the
DNS_MARKERcan be used to check the application for DNS Out-of-Bound vulnerabilities.
'; ping DNS_MARKER'
If the Detect phase detects a marker from any payload in the server's response, then the attack is successful, meaning that the vulnerability was successfully exploited. To see detailed information about the Detect phase operating with markers, proceed to this link.