TLDR: Before I’d do another SOAP Web services test, I’d ask (demand) the following from the dev team:

• WSDLs for all services in scope

• SoapUI project file populated with valid request for each Web service (so I can distinguish responses and app behavior).

Now here’s the long version:

I was asked to run a site through an AppSpider scan, and my first challenge was that this site redirected to an SSO page. I was having issues with that, so I ended up recording a macro for the login on my locally installed AppSpider on a Windows VM.

Then I had a new problem. Of the 11-12 WSDL files I was provided with, only 1-2 would properly parse/load into AppSpider. I contacted Rapid7 support and they encouraged me to validate the WSDLs through wsdl-analyzer.com, but we didn’t want to send these to a third party service.

So I created a SoapUI project, loaded the WSDLs, and sent requests. They failed. I learned this was because they needed to inherit certain cookies from a logged-in account.

I proxy’d SoapUI and Firefox through Burp and learned that I could bring cookies along for SoapUI requests if I:

• Clicked Options->Sessions
• Edit the "Use Cookies from Burp’s Cookie Jar"
• Click Scope
• Click the Proxy checkbox
• Click Use Suite Scope (make sure your site scope is defined)

Once I did that, SoapUI requests were still failing. I learned from the dev team that this was because each request also needed a specific parameter passed in the URL string. I was kind of at my wit’s end, and so while I’m sure there’s a slick way to do this through Burp, I went old school and Ctrl+C Ctrl+V’d all the SoapUI requests. At this point the requests were valid, BUT many contained improperly formatted or incomplete data, so they weren’t much good anyway. So…please see the TLDR section at the top of this post 🙂

One final note before I forget! I had an issue where a few days after installing SoapUI, one morning I opened it and it complained I didn’t have a valid license file. I re-fed it my license file and then it did nothing when I clicked Next. Didn’t throw an error. Didn’t freeze. I could click that Next button all day long, but my only choice was to cancel out of the dialogue box.

I was going to call SoapUI support but of course you can’t call a live person there, you have to resort to their support forums or email ticket system. I opened a ticket, but then went to scour the Googs, and one site taught me that the license file lived in C:\Users\Brian.soapui. I went to that folder and there was a soapui.key file and a soapui.key.new file. The .new file had a timestamp of right about the time the program stopped working, so I created a temp dir and moved the file in there. Then I started SoapUI again…and all was right with the world. Sigh.