Scan Settings: Custom Parameters
To access this feature, click the Edit menu and select Default Scan Settings or Current Scan Settings. Then, in the Scan Settings category, select Custom Parameters.
Custom Parameters are used to accommodate sites that use URL rewriting techniques and/or Representation State Transfer (REST) web services technologies. You can write rules for these custom parameters, or you can import rules from a common configuration file written in Web Application Description Language (WADL).
URL Rewriting
Many dynamic sites use URL rewriting because static URLs are easier for users to remember and are easier for search engines to index the site. For example, an HTTP request such as
http://www.pets.com/ShowProduct/7
is sent to the server's rewrite module, which converts the URL to the following:
http://www.pets.com/ShowProduct.php?product_id=7
In this example, the URL causes the server to execute the PHP script "ShowProduct" and display the information for product number 7.
When Fortify WebInspect scans a page, it must be able to determine which elements are variables so that its attack agents can thoroughly check for vulnerabilities. To enable this, you must define rules that identify these elements. You can do so using a proprietary Fortify WebInspect syntax.
Examples:
HTML: <a href="someDetails/user1/">User 1 details</a>
Rule: /someDetails/{username}/
HTML: <a href="TwoParameters/Details/user1/Value2">User 1 details</a>
Rule: /TwoParameters/Details/{username}/{parameter2}
HTML: <a href="/Value2/PreFixParameter/Details/user1">User 1 details</a>
Rule: /{parameter2}/PreFixParameter/Details/{username}
RESTful Services
A RESTful web service (also called a RESTful web API) is a simple Web service implemented using HTTP and the principles of REST. It has gained widespread acceptance across the Web as a simpler alternative to web services based on SOAP and Web Services Description Language (WSDL).
The following request adds a name to a file using an HTTP query string:
GET /adduser?name=Robert HTTP/1.1
This same function could be achieved by using the following method with a Web service. Note that the parameter names and values have been moved from the request URI and now appear as XML tags in the request body.
POST /users HTTP/1.1 Host: myserver
Content-Type: application/xml
<?xml version="1.0"?>
<user>
<name>Robert</name>
</user>
In the case of both URL rewriting and RESTful web services, you must create rules that instruct Fortify WebInspect how to create the appropriate requests.
To create a rule:
-
Click New Rule.
-
In the Expression column, enter a rule. See Path Matrix Parameters for guidelines and examples.
The Enabled check box is selected by default. Fortify WebInspect examines the rule and, if it is valid, removes the red X.
To delete a rule:
-
Select a rule from the Custom Parameters Rules list.
-
Click Delete.
To disable a rule without deleting it:
-
Select a rule.
-
Clear the check mark in the Enabled column.
To import a file containing rules:
-
Click
. -
Using a standard file-selection dialog box, select the type of file (.wadl or .txt) containing the custom rules you want to apply.
-
Locate the file and click Open.
Enable automatic seeding of rules that were not used during scan
The most reliable rules for custom parameters are those deduced from a WADL file or created by developers of the Web site. If a rule is not invoked during a scan (because the rule doesn't match any URL), then Fortify WebInspect can programmatically assume that a valid portion of the site has not been attacked. Therefore, if you select this option, Fortify WebInspect will create sessions to exercise these unused rules in an effort to expand the attack surface.
Double Encode URL Parameters
Double-encoding is an attack technique that encodes user request parameters twice in hexadecimal format in an attempt to bypass security controls or cause unexpected behavior from the application. For example, a cross-site scripting (XSS) attack might normally appear as:
<script>alert('FOO')</script>
This malicious code could be inserted into a vulnerable application, resulting in an alert window with the message “FOO.” However, the web application can have a filter that prohibits characters such as < (less than) > (greater than) and / (forward slash), since they are used to perform Web application attacks. The attacker could attempt to circumvent this safeguard by using a "double encoding" technique to exploit the client’s session. The encoding process for this JavaScript is:
| Char | Hex encode | Encoded % Sign | Double encoded result | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| < | %3C | %25 | %253C | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| / | %2F | %25 | %252F | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| > | %3E | %25 | %253E | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Finally, the malicious code, double-encoded, is:
%253Cscript%253Ealert('XSS')%253C%252Fscript%253E
If you select this option, Fortify WebInspect will create double-encoded URL parameters (instead of single-encoded parameters) and submit them as part of the attack sequence. This is recommended when the Web server uses, for example, Apache mod-rewrite plus PHP or Java URL Rewrite Filter 3.2.0.
See Also
Scan Settings: Cookies/Headers