Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

How do I get a latest scan from the list of scans for a specific site?

Manasa | Last updated: Nov 08, 2021 11:04AM UTC

I'm using the following query to get the list of scans associated with a site. It returns me list of scans associated with the specific site. But how do I get the latest scan out of it? query getScans($site_id : ID!) { scans(site_id: $site_id) { id, status, start_time, end_time, scan_delta { new_issue_count }, site_id } }

Uthman, PortSwigger Agent | Last updated: Nov 08, 2021 11:46AM UTC

Hi,

You can sort your results by various fields listed here.

To retrieve the last scan from your example, you can set the limit to '1' like below: 

query getScans($site_id : ID!) {
  scans(site_id: $site_id, limit: 1) {
    id,
    status,
    start_time,
    end_time,
    scan_delta {
      new_issue_count
    },
    site_id
  }
}

Manasa | Last updated: Nov 08, 2021 02:30PM UTC

Thanks much for the quick response. A follow-up to this, Once this scan is retrieved I would like to get all the associated issues with each of the scan. For now, here is what I'm doing. In the scans object, i'm getting the typeIndex using the below query. query getScan($id : ID!) { scan(id: $id) { id, issue_type_groups(severities: [high, medium, low, info], confidences: [tentative, firm, certain, false_positive], novelties:[repeated, new, regression, first]) { issue_type{ type_index, name, description_html, remediation_html, vulnerability_classifications_html, references_html } } } Once the typeIndex is retrieved, using the same scan endpoint to retreive the Issues with the typeIndex as a parameter. query getScan($id : ID!) { scan(id: $id) { issues(type_index: 16777472, start: 0, count: 10, severities: [info, high, medium, low], confidences: [tentative, firm, certain, false_positive], novelties: [repeated, new, regression, first]) { serial_number, path, origin } } } Again for fetching issue specific information, this serial_number is used in Issues object. This solution involves more API calls and looks tedious too. Is there an anyother efficient way to fetch list of issues associated with a scan?

Uthman, PortSwigger Agent | Last updated: Nov 08, 2021 02:43PM UTC

Have you tried just omitting the type_index from issues? Does the query below meet your requirements? 

query GetScan {
  scan(id: 132) {
    id
    issues(start: 0, count: 1000) {
      issue_type {
        name
        description_html
        remediation_html
      }
      path
      origin
      serial_number
    }
  }
}

The output would look something like this: 

{
  "data": {
    "scan": {
      "id": "132",
      "issues": [
        {
          "issue_type": {
            "name": "Serialized object in HTTP message",
            "description_html": "<p>Applications may submit a serialized object in a request parameter. This behavior can expose the application in various ways, including:</p>\n<ul>\n<li>Any sensitive data contained within the object can be viewed by the user.</li><li>An attacker may be able to interfere with server-side logic by tampering with the contents of the object and re-serializing it.</li><li>An attacker may be able to cause unauthorized code execution on the server, by controlling the server-side function that is invoked when the object is processed.</li></ul>\n<p>Actual exploitation of any code execution vulnerabilities arising from the application's use of serialized objects will typically require the attacker to have access to the source code of the server-side application. This may mitigate the practical impact of this issue in many situations. However, it is still highly recommended to fix the underlying vulnerability. Vulnerabilities in native deserialization functions often allow practical exploitation without source code access.</p>",
            "remediation_html": "<p>The best way to avoid vulnerabilities that arise from the use of serialized objects is not to pass these in request parameters, or expose them in any other way to the client. Generally, it is possible to transmit application data in plain non-serialized form, and handle it with the same precautions that apply to all client-submitted data. If it is considered unavoidable to place serialized objects into request parameters, then it may be possible to prevent attacks by also placing a server-generated cryptographic signature of the object into the same request, and validating the signature before performing deserialization or other processing on the object.</p>"
          },
          "path": "/csp/deser.html",
          "origin": "https://portswigger-labs.net",
          "serial_number": "8493150730268619776"
        },
        {
          "issue_type": {
            "name": "Serialized object in HTTP message",
            "description_html": "<p>Applications may submit a serialized object in a request parameter. This behavior can expose the application in various ways, including:</p>\n<ul>\n<li>Any sensitive data contained within the object can be viewed by the user.</li><li>An attacker may be able to interfere with server-side logic by tampering with the contents of the object and re-serializing it.</li><li>An attacker may be able to cause unauthorized code execution on the server, by controlling the server-side function that is invoked when the object is processed.</li></ul>\n<p>Actual exploitation of any code execution vulnerabilities arising from the application's use of serialized objects will typically require the attacker to have access to the source code of the server-side application. This may mitigate the practical impact of this issue in many situations. However, it is still highly recommended to fix the underlying vulnerability. Vulnerabilities in native deserialization functions often allow practical exploitation without source code access.</p>",
            "remediation_html": "<p>The best way to avoid vulnerabilities that arise from the use of serialized objects is not to pass these in request parameters, or expose them in any other way to the client. Generally, it is possible to transmit application data in plain non-serialized form, and handle it with the same precautions that apply to all client-submitted data. If it is considered unavoidable to place serialized objects into request parameters, then it may be possible to prevent attacks by also placing a server-generated cryptographic signature of the object into the same request, and validating the signature before performing deserialization or other processing on the object.</p>"
          },
          "path": "/csp/deser.html",
          "origin": "https://portswigger-labs.net",
          "serial_number": "5602828530204716032"
        }
      ]
    }
  }
}

You must be an existing, logged-in customer to reply to a thread. Please email us for additional support.