Forum Discussion

NikosG's avatar
NikosG
Occasional Contributor
6 years ago

XSS scripting assertion on REST PATCH request via GET method

Hello to all

The subject may not make much sence so here it goes

 

I have a REST service and i'd like to check the Cross Site Scripting test options provided with SoapUI Pro (i have downloaded a trial version, even though it is the same with the community version if I'm not mistaken). The target of the test is one of the PATCH methods.

 

The problem is in seting up a proper assertion. I see that the default is performing the assertion on the actual response which is not very helpful in my case and there is no website whose url I could provide.

 

Ideally I'd like when I send something like this in the json request body 

{
"id": "resourceID",
"data": <IMG src=\"javascript&colon;alert('XSS');\">"
}

to be able to configure an assertion where I issue a GET request for the resource with the same id and detect any cross site scripting in the "data" element in the GET response

 

Has anyone else bumped into a similar problem?

Any comment would be highly appreciated

 

 

 

Assertions
REST
  • nmrao's avatar
    nmrao
    Champion Level 3
    6 years ago
    Not sure what the issue is.

    If you need to send a payload, use POST method. GET does not allow to send payload.
    • NikosG's avatar
      NikosG
      Occasional Contributor
      6 years ago

       Hi nmrao 

       

      Let me clarify a bit 

       

      As I said I'm trying out the security tests on trial version of SoapUI Pro

      I'm using the XSS security tests on a PATCH method that is used in our API in order to update a specific resource. Configuring the test I am able to issue PATCH requests for a specific resource id like so

      {
      id: <uniqueId>,
      data: <string replaced by the preconfigured XSS strings>
      }

      As I see SoapUI iterates through a list of preconfigured XSS strings and applies them to each of the request body fields. One field at a time.

       

      The "problem" is when it is time to check if the XSS string has actually gone through.

      As it is the application provides two options of doing that when you are setting up the Cross Site Scripting assertion:

      1. Check the immediate response
      2. Enter a custom script that returns a list of URLs to check for Cross Site Scripts

      None of these are applicable in my case as:

      1. The immediate response can be a simple 204 (success) and I have no way of knowing if the XSS string has reached the backend as it was sent by SoapUI or some form of sanitation has taken place.
      2. I have no website that visualizes the data affected by the PATCH so as to scan a webpage for XSS (if this is what it is doing)

      The only way to know if something like "data: <SCRIPT>alert("1")</SCRIPT>" has reached our database is by executing a GET on the resource with the same id and execute a check on the REST GET response, this way I can verify that the input has been sanitized or not.

       

      So in each iteration of the Cross Site Scripting Scan I need to
      a. get the request sent and extract the "id" from the request body of the PATCH request and field that was targeted
      b. execute a GET REST request with the same id
      c. scan the response for the XSS strings on the field defined in (a)

       

      Since my last post I tried going via the custom script assertion

      • Extract to a file all the SoapUI XSS strings
      • Create a test step that performs a GET on a hardcoded "id" that is also used by PATCH
      • Issue the GET request and get the response using something like testCase.testSteps["GET_testCase"].testRequest.response.contentAsString
      • Iterate through the entries of the file to see if the response contains any of them

      It seemed promissing but

      • I still miss the way to isolate the exact field that was used in the PATCH request for the XSS test. So i have to scan the whole GET response. This way I may get a positive for a field that I have already checked in a previous iteration.
      • While working with a specific id may work in PATCH (used for updates) in a POST case (used for creating new) where the id has to be unique between each iteration this will fail 

       

      Hope this helps to clarify things on my case

       

       

      • nmrao's avatar
        nmrao
        Champion Level 3
        6 years ago
        If I understand it right, you want to test the resource with particular payload instead of SoapUI generating on its own where it does not allow users to manipulate payload. Correct?

Recent Discussions