Unique Parameter Value for Each Request

I am working on testing a web service that requires a unique value for a particular parameter each time a request is made. I thought I would be able to figure out how to make this happen, but I can't seem to find any way to accomplish it.

Essentially what I need is for a particular XML tag in a POST request to a REST web service to increment as the scanning activity takes place. Lets say the tag is <TestParam>, I need for that parameter to be unique for each request. There are additional length and complexity requirements, but if I can get passed the initial hurdle, I should be able to figure out the rest.

Here is a quick idea of what I need to make happen:

POST Request 1: 
<WebService>

<TestParam>e4ca8d3c2000000001</TestParam>

</WebService>

POST Request 2:

<WebService>

<TestParam>e4ca8d3c2000000002</TestParam>

</WebService>

 

I can manage this with Burp, but I would really like to be able to leverage Web Inspect for this particular project. Any help will be greatly appreciated.

Tags:

Parents
  • If the first TestParam is a Known Value, then you might be able to get away with a set of Filter scan settings.  They permit dynamic replacement of text in either the HTTP Request or HTTP Response.

    If the TestParam value is dynamically assigned, then you might still be able to get away with this trick using regex rather than straight replacement.

    Why precisely does this parameter need to be incremented each time?  It does not sound like session state or a menu list.  If you have a functional testing script that already runs through these, couldn't you simply pre-record that traffic as a Workflow Macro using Web Proxy, and then use that in a Workflow-driven scan?

  • HansEnder,

    Thanks for the helpful reply.  I have to ask, are you a single person, or does HP have multiple people that just use the same user account on this forum? If you are in fact a single person, you deserve some serious recognition for your efforts.

    On to my follow-up: This parameter does not have a specified value. My understanding is that it is normally a randomly generated value that is used to uniquely identify transactions that are taking place through this web service. Multiple requests might use the same value if they are related to the same overall interaction with the service.

    However, in my case, it will be used on the backend to uniquely identify requests sent in to the web service during my testing activities. For testing purposes, this will allow the developers to review attacks and results on a per-request basis by referencing this parameter. It's a slightly odd request, since we can compare notes in a number of other ways, but it is one that I can't proceed without fulfilling. 

    It sounds like what you are suggesting will work. Will this approach allow me to specify the start value and increment by one until the scan is finished? Although the string can be alphanumeric, I think that starting at 000000000000000001 and replacing 0's with the increasing value as the count increases is probably the easiest way to address this.

    On a semi related note, is there a way to force web inspect to abort a scan when a particular string is seen in an XML parameter? For example, if <ID>199567</ID> is observed in the body of a response, abort scanning. If you would prefer, I can ask this question in a separate thread so that it can help others that may have this same need.

  • I most definitely am a real and single person!  My manager would probably love to hear this, so PM me for his contact information.  LOL   I have simply made it a habit to vist all of our user forums weekly, since ~2005, so it adds up.  I like to help, and it helps me "sharpen the saw".

     

    So this TestParam is an artifice used for tracking and not for the app itself.  I suppose you could do something similar by adding a Custom Header to WebInspect's scan settings, e.g. "TestCode: value".  That might actually be simpler since you would have it included in each and every HTTP Request.  The difficulty here is that the Crawler and Attacks run multipl-threaded and you can expect several thousands of individual HTTP Requests to be made during one scan.  My thought on incrementing with Filters will not be scalable, as it does not permit "n 1" variables, but would be a giant list of straight replacmeent rules.  But I will ask our internal Dev team if there are any hidden features that could meet this need.

     

    To get this incrementing from a single value might also be challenging.  The Web Form Editor permits you to prepare dummy values the Crawler will use as it encounters inputs/parameters.  Setting an entry there for TestParam with a value of 000001 would have the Crawler populate that field with that value, but it might do that every time it crawls new sessions that have that same parameter name..  So uisng Web Forms Editor might be fine for the first visit, but then you have the following ones that need to be incremented.  I think instead you might just add a replacement rule that replaces the first (assumed) blank entry "?TestParam=&" with "?TestParam=000001&", and then have another rule that increments that as it is encoutered later.

     

    Again, I will have to double-check with our internal specialists if there is a better way.

  • Yet another (terrible) idea would be to change the Requestor scan settings to use a Single Shared Requestor.

    This will slow down the scan to it's absolute slowest, but every HTTP Request/Response pair would be perfectly aligned in the order they were made.  With this setting, no HTTP Request is sent until the prior HTTP Response is received or times out.  If any HTTP Response times out, WebInspect's default behavior is to Retry that same request 1 more time, waiting the same 20 seconds before marking that session/Request as null and moving on to the next one in its queue.

    Again, this is a terribly slow process, but maybe that will provide you the sequential order you are seeking.

Reply
  • Yet another (terrible) idea would be to change the Requestor scan settings to use a Single Shared Requestor.

    This will slow down the scan to it's absolute slowest, but every HTTP Request/Response pair would be perfectly aligned in the order they were made.  With this setting, no HTTP Request is sent until the prior HTTP Response is received or times out.  If any HTTP Response times out, WebInspect's default behavior is to Retry that same request 1 more time, waiting the same 20 seconds before marking that session/Request as null and moving on to the next one in its queue.

    Again, this is a terribly slow process, but maybe that will provide you the sequential order you are seeking.

Children
No Data