Clarification on Webservices scanning
I have some clarifications on web service testing.
Is burp suite capable of performing testing webservices against all known vulnerabilities associated with web services ?
All scanning options present under Active Scanning areas are applicable for web service testing ? or it is limited to subset of those ?
I browsed a website and it captured a webservice URL (and many sub URLs)
In the target, I expanded one of the URLs and in the right hand side I see the method as GET
But in the Request pane in the bottom, I can see the request going as OPTIONS and not get.
(All the webservice URLs show the same behavior)
Why does it go with a OPTIONS instead of a GET ?
For the above scenario, the response code is HTTP/1.1 204 No Content and Content-Length is 0
But if I take the URL and paste it in browser (Request goes as GET instead of OPTIONS) there is a HTTP/1.1 200 OK response with content-length greater than 0 and there is a valid data in the response.
Could you please clarify ?
1. Burp can scan web services / SOAP requests but it doesn’t natively parse WSDL files and generate SOAP requests. You have two options: (a) use a tool like soapUI to generate SOAP requests and proxy the traffic via Burp, then test it in the normal way; (b) try the Wsdler extension in the BApp Store, which does parse WSDL files and generate suitable requests.
2. There was a bug like this in the site map a while ago but it has been fixed. Are you using the latest Pro version?
3. OPTIONS and GET requests do very different things, and so typically receive different responses. You can copy the URL and in Repeater choose “Paste URL as request” from the context menu, to send a suitable GET request within Burp, which should receive a normal response.
So, is it supported via BURP ?
Yes, Burp can work with REST endpoints. If you access these in the normal way via Burp, Burp can scan and test the resulting requests in the normal way.
Note that if the application places data parameters into the URL file path, then you need to enable “REST-style URL parameters” at Scanner / Options / Attack insertion points.
There is no difference in the approach to testing for services using HTTPS as opposed to plain HTTP.
->after getting response in burp Repeater how to test vulnerabilities.
Once you have a valid request in Repeater, the first step is to do an active scan.
You may also want to do some manual investigation – modifying some parts of the request and reviewing the application’s response. Manual testing requires considerable skill and experience. If you are interested there are many books, online materials, and vulnerable applications for training purposes.