Path matrix parameters
There are three ways rules can be created in the system. Rules may be:
-
Entered manually
-
Generated from a WADL file specified by the user or received through OpenText DAST Agent
-
Imported from a flat file containing a list of rules
When entering rules manually, you specify the path segments of a URL that should be treated as parameters.
The rules use special characters to designate parts of the actual URL that contain parameters. If a URL matches a rule, OpenText DAST parses the parameters and attacks them. Notable components of a rule are:
-
Path (
gp/c/{book_name}/) -
Query (anything that follows "
?") -
Fragment (anything that follows "
#")
Definition of path segment
A path segment starts with ‘/’ characters and is terminated either by another ‘/’ character or by end of line. To illustrate, path "/a" has one segment whereas path "/a/" has two segments (the first containing the string “a” and the second being empty. Note that paths "/a" and "/a/" are not equal. When attempting to determine if a URL matches a rule, empty segments are considered.
Special elements for rules
A rule may contain the special elements described in the following table.
| Element | Description |
|---|---|
*
|
Asterisk. May appear in production defined below; presence in non-path productions means that this part of the URL will not participate in matching (or, in other words, will match anything). |
{ }
|
Group; a named parameter that may appear within the path of the rule. The content has no special meaning and is used during reporting as the name of the attacked parameter. The character set allowed within the delimiting brackets that designate a group
A group’s content cannot include the "open bracket" and "close bracket" characters, unless escaped as pct-encoded element. |
The rules for placing * out of path are described below. Within a path segment, any amount of * and {} groups can be placed, provided they’re interleaved with plain text. For example:
Valid rule: /gp/c/*={param}
Invalid rule: /gp/c/*{}
Rules with segments having **, *{}, {}* or {}{} entries are invalid.
For a rule to match a URL, all components of the rule should match corresponding components of the crawled URL. Path comparison is done segment-wise, with * and {} groups matching any number of characters (including zero characters), plain text elements matching corresponding plain text elements of the path segment of the URL. So, for example:
/gp/c/{book_name} is a match for these URLs:
-
http://www.amazon.com:8080/gp/c/Moby_Dick
-
http://www.amazon.com/gp/c/Singularity_Sky?format=pdf&price=0
-
https://www.amazon.com/gp/c/Hobbit
But it is not a match for any of these:
-
http://www.amazon.com /gp/c/Moby_Dick/ (no match because of trailing slash)
-
http://www.amazon.com/gp/c/Sex_and_the_City/Horror (no match because it has a different number of segments)
OpenText DAST will treat elements of path segments matched by {…} groups in the rule URL as parameters, similar to those found in a query. Moreover, query parameters of crawled URLs matched by rule will be attacked along with parameters within the URL’s path. In the following example of a matched URL, OpenText DAST would conduct attacks on the format and price parameters and on the third segment of the path (Singularity_Sky):
http://www.amazon.com/gp/c/Singularity_Sky?format=pdf&:price=0
Asterisk placeholder
The “*” placeholder may appear in the following productions and subproductions of the URL:
-
Path – cannot be matched as a whole, since
*in path matches a single segment or less. -
Path segments – as in
/gp/*/{param}, which will match URLs with schema HTTP, hostname www.amazon.com, path containing three segments (first is exactly “gp”, second is any segment, and the third segment will be treated as parameter and won’t participate in matching). -
Part of path segment – as in
/gp/ref=*, which will match URLs with path containing two segments (first is exactly “gp”, second containing any string with prefix “ref=”). -
Query – as in
/gp/c/{param}?*, which matches any URL with path of three segments (first segment is “gp”, second segment is “c” and third segment being a parameter, so it won’t participate in matching); this URL also MUST contain a query string of arbitrary structure. Note the difference between rules/gp/c/{param}and/gp/c/{param}?*. The first rule will match URL http://www.amazon.com/gp/c/Three_Little_Blind_Mice, while the second will not.-
Key-value pair of query – as in
/gp/c/{param}?format=*which will match URL only if query string has exactly one key-value pair, with key name being “format.” -
Key-value pair of query – as in
/gp/c/{param}?*=pdfwhich will match URL only if query string has exactly one key-value pair, with value being “pdf.”
-
- Fragment – as in case
/gp/c/{param}#*which matches any URL with fragment part being present
Benefit of using placeholders
The main benefit of using placeholders is that it enables you to create rules that combine matrix parameters and URL path-based parameters within single rule. For relevant URL
http://www.amazon.com/gp/color;foreground=green;background=black/something?format=dvi
the following rule will allow attacks on all parameters
gp/*/{param}
with the matrix parameter segment being ignored by * placeholder within second segment of the path, but recognized by OpenText DAST and attacked properly.
Multiple rules matching a URL
In the case of multiple rules matching a given URL, there are two options:
-
Stop iterating over the rules once a match is found and so use only the first rule.
-
Iterate over all of the rules and collect all custom parameters that match.
For instance, for the following URL
http://mySite.com/store/books/Areopagitica/32/1
the following rules both match
-
*/books/{booktitle}/32/{paragraph} -
store/*/Areopagitica/{page}/{paragraph}
OpenText DAST will try to collect parameters from both rules to ensure the greatest attack coverage, so all three segments (“Areopagitica”, “32” and “1” in the example above) will be attacked.