![]() ![]() You'll need a proxy set up for each tcp port in use.įor instance, setting up port 443 will look like: That pcap file created in step 2 might come in really handy, or you can just look at the various tests in the Test Suite to get all of these ports. I've noticed developers lately have started using not just tcp/80 and 443, but have started getting "cute" with the https ports, often using 4443, 8443, 8843 and so on. Also be very sure that you enable it for each port in use. Be sure to enable it for the address you are targeting as proxy, or enable it for everything. Instead of the real IP of the target, use the IP of the Burp machine, so that the Test Suite is directed at Burp.Ĥ/ Over to Burp to the Burp machine, fire up Burp, and enable Transparent Proxy. Many Linux hosts don't do DNS Caching, so you might need to run tcpdump and capture unique dns queries instead (or extract the DNS records used by the SOAP tests from your local DNS Server logs, but that's not as reliable)ģ/ Next, on the SoapUI machine edit the local hosts file (c:\windows\system32\drivers\etc\hosts, or /etc/hosts) and add a host entry for each of the API targets. Or, since you just want the hostnames and IPs (in short, the actual DNS records), run: I'm going to assume that these are both Windows boxes, but this works just as well with Linux of courseġ/ Out of the box, run all the tests within the SoapUI project, as received from the developersĢ/ Now flip out to a command prompt and dump your DNS cache, so you know which hosts are being called in the API (they're not always the hosts you think they are). Install SoapUI on one, and Burp on the other. Mainly because my mantra is that you really need a good reason to rn anything physical. I use the "Invisible Proxy" feature within Burp (any other product would call this "transparent" instead of "invisible" proxy). And if I miss one, that'll be the one that would have given me SQL injection or something else equally good. If I need to update all of the test cases in an API, that's generally somewhere between 1-3 mods per API call, and when the developer comes out with the next version (as they are wont to do), I have to do all of that all over again. These solutions against the grain for me, mostly because I'm lazy. ( and for instance lay out two ways to take this path). The solutions that folks have generally come up with have also in some cases been complex, and most of them include the step "change the SoapUI test for this case from HTTPS to HTTP" (counting on BURP to flip it back to HTTPS). And the SoapUI solution to get around this is pretty convoluted. However, what folks are finding is that the proxy function within SoapUI simply doesn't work, especially for HTTPS. The simple way is to run the developers test suite, usually coded up as a project file in SoapUI, through BURP. Often the API is based on SOAP, and it's been an interesting discussion on how best to scan these new Web Services based on WSDL for vulnerabilities. Something I've noticed recently is that most of the websites I've been asked to assess now seem to be "new, improved, and with an API". ![]()
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |