Re: WebInspect 10.1: How to determine state from URL (522 Views)
Reply
Occasional Visitor
liuzhouwu
Posts: 1
Registered: ‎01-10-2014
Message 1 of 2 (565 Views)

WebInspect 10.1: How to determine state from URL

[ Edited ]

Hi,

 

I am trying to scan some APEX based apps with WebInspect. The URL in the apps are mostly like:

 

https://10.10.0.10/console/f?p=7700:100:15570571751825::LEVEL1:::

 

The string like 15570571751825 is used as the session state by the inner APEX logic.

 

So it's crucial for WebInspect to capture this state, otherwise it will keep log in and out all the time.

 

I try several ways but don't work fine.

 

1. In HTTP Parsing, I put [\d]{14,} in 'HTTP Parameters Used For State', checking Query, Post and Custom

2. I also try to put p_instance in 'HTTP Parameters Used For State', checking Post, since I notice p_instance parameter in the post date(see below)

3. I also try to put [\d]{14,} in 'Determine State From URL Path'

 

Can anyone give me some advice here?

 

Thanks in advance.

 

A tipical get request looks like:

 

GET /console/f?p=7700:LOGIN:1758023415424 HTTP/1.1
Host: 10.10.0.10
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.29pre) Gecko/20110614 Firefox/3.6.3
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Pragma: no-cache
Cookie: ORA_WWV_APP_7700=ORA_WWV-W0URD5LtSRUwWU1N/bPKTLVu
X-WIPP: AscVersion=10.1.275.0
X-Scan-Memo: Category="Crawl.EventMacro.Startup"; SID="B975F8F8D3B49E1DE8E6C52B78CB98F1"; SessionType="StartMacro"; CrawlType="None";
X-RequestManager-Memo: Category="EventMacro.Login"; MacroName="av_auditor_login";
X-Request-Memo: ID="69fe75db-0fd3-45d2-b896-75e4aa6692ca"; ThreadId="37";

 

And the post looks like:

 

POST /console/wwv_flow.accept HTTP/1.1
Host: 10.10.0.10
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.29pre) Gecko/20110614 Firefox/3.6.3
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: https://10.10.0.10/console/f?p=7700:LOGIN:1758023415424
Pragma: no-cache
Cookie: ORA_WWV_APP_7700=ORA_WWV-W0URD5LtSRUwWU1N/bPKTLVu
Content-Type: application/x-www-form-urlencoded
Content-Length: 476
X-WIPP: AscVersion=10.1.275.0
X-Scan-Memo: Category="Crawl.EventMacro.Startup"; SID="B9BF4E43D12264C9776F5F2A384FFD21"; SessionType="StartMacro"; CrawlType="None";
X-RequestManager-Memo: Category="EventMacro.Login"; MacroName="av_auditor_login";
X-Request-Memo: ID="bd09567a-276c-4f3b-9286-1eaa24feb893"; ThreadId="40";

p_flow_id=7700&p_flow_step_id=101&p_instance=1758023415424&p_page_submission_id=32854657251508&p_request=LOGIN&p_debug=LEVEL2&p_arg_names=237170818995114169&p_t01=&p_arg_names=123047554405256884&p_t02=avauditor&p_arg_names=123047657826256884&p_t03=Welcome_1&p_arg_names=2172402732910034&p_t04=&p_arg_names=2224030107349037&p_t05=100&p_arg_names=1930819192146724&p_t06=NONE&p_arg_names=1866705164761926&p_t07=360&p_md5_checksum=&p_page_checksum=11CE44CBDF653287ED919E3CC2F224BE

 

 

Respected Contributor
HansEnders
Posts: 613
Registered: ‎07-01-2008
Message 2 of 2 (522 Views)

Re: WebInspect 10.1: How to determine state from URL

When there is a part of the URI that determines state, that is generally not handled by the Custom State-Keeping setting.  For that situation, you would instead look to the HTTP Parsing panel of the scan settings, at the center field for "Determine State From URL Path".  There are some ancient, sample signatures already defined there, such as for ASP.NET 1.1.  This field generally requires a regex to help identify the portion of the URI that is state-keeping.  The Regular Expression Editor tool can be helpful in formulating the necessary regex.

 

However, with your particular Request/Response data, this field would not necessarily be appropriate for you.

 

 

 

Since there is a clearly named parameter holding the state-keeping value, you would normally proceed with using the field at the top of the HTTP PArsing panel, for "HTTP Parameters Used For State".  Simply put in the parameter's name, such as "p" (no quotes), and WebInspect will honor and utilize whatever value the target server assigns for it, even if the server reassigns it to a new value mid-scan.  Note that you may also need to mark this same custom state-keeping parameter within your Login Macro so that it Plays fine, i.e. the macro dynamically updates the value rather than replaying the originally recorded value.

 

 

If you were unsure if you had a custom or standard state-keeping parameter, you could go down to the scan settings panel for Attack Exclusions.  Here you will find all of the standard state-keeping parameters we have identified in the wild and declared them to WebInspect as being off-limits to auditing.  It is possible you will want to add your custom state-keeping parameter's name here as well.  The reason being, items declared on the HTTP Parsing panel are managed intelligently by WebInspect, but may still be audited "lightly".  If any amount of auditing will cause you scan state issues, then adding the same parameter name to the Attack Exclusions prevents any and all fuzzing for that item.

 

 

Now, let's review the parameter you have in the Request/Response data.  The first thing that worried me was that the value of the parameter "p" has colons in it.  I am unsure if WebInspect will identify those characters as separators and as separate parameters (bad), or if the entire value will be accepted for "p" (good).  You may need to contact Fortify Support to verify this.  However, after you add the "p" parameter to HTTP Parsing, you could simply review the Traffic Monitor capture within a test/short scan to see if the value is used intact or not.  So for this parameter, I would simply Add the name, "p" (no quote marks), to the HTTP Parsing field for state-keeping parameters.  Since I am lazy, I would enable this entry for both POST and Query data so it will cover all the bases possible during the scan.

 

Unfortunately, I see in the HTTP Response that a portion of the value of "p=7700:LOGIN:1758023415424" may be reused for other parameters.  Examples of this include "p_instance=1758023415424", and possibly "p_request=LOGIN" and "p_flow_id=7700".  It is possible that these are additional state-keeping parameters which collect their value from the value assigned to "p".  If so, simply adding "p" to HTTP Parsing may not manage those other parameters.

  For starters, you could try adding "p_instance" and "p_flow_id" to the HTTP Parsing scan setting just as you had added "p".  The application might push or suggest the field value to WebInspect, and then WebInspect would carry it forward in subsequent HTTP Requests.  If entering these into HTTP Parsing does not manage it, you may need to build a Custom Parameter scan setting for these.  I was recently involved in a Support case where the value from one parameter had to be assigned to a second parameter simultaneously, and the Developer on duty was able to make that happen with some script used in the Custom Parameter scan setting.

 

If you have investigated these items and are still at an impasse, you may need to contact Fortify Support (support.fortify.com) to dig into it further.


-- Habeas Data
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.