9

I've tried to use soapUI to set up a Boundary Scan security test, using the sample wsdl provided in the soapUI tutorial. I changed it so that it has a restriction on the username field for the loginRequest action (cf. below). Yet whenever I try to run the security test, the boundary scan gets "SKIPPED". No error messages get displayed. Does anyone know how to set up a (working) Boundary Scan with SoapUI's free edition?

Changes to WSDL
I replaced the following line

<xsd:schema targetNamespace="http://www.example.org/sample/">

by

   <!-- CHANGED/ADDED -->
    <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.example.org/sample/" xmlns:tns="http://www.example.org/sample/" >
         <xsd:simpleType name="usernameType">
               <xsd:restriction base="xsd:string">
               <xsd:length value="9"/>
            </xsd:restriction>
         </xsd:simpleType>
         <!-- END ADDED -->

and

  <wsdl:message name="loginRequest">
    <wsdl:part name="username" type="xsd:string"/>

by

  <wsdl:message name="loginRequest">
    <wsdl:part name="username" type="tns:usernameType"/> <!-- CHANGED -->

I've provided more detail of what exactly I did on soapUI's bug tracker board and I'm using soapUI v4.6.4. I'm not sure it's a bug or a simple mistake on my part, so any help would be much appreciated!

UPDATE: When selecting the parameter in the Boundary Scan window, soapUI does complain "parameter is missing type in schema" - which I can't quite understand, because the type is there; cf. XML snippet above.

UPDATE: PARTIALY RESOLVED I just tried the same exercise with our own WSDL, and got a different "error" message: "No restrictions in schema are specified for this parameter!" Turns out soapUI has the xsd namespace hard-coded in; changing it in our own WSDL to xsd (so it reads xsd:restriction) fixes the issue for our own WSDL. No idea what the initial error (with the sample WSDL) is about, though. Hints are still appreciated. But at least it's now working for us...

3
  • 2
    I just tried the same exercise with our own WSDL, and got a different "error" message: "No restrictions in schema are specified for this parameter!" Turns out soapUI has the xsd namespace hard-coded in; changing it in our own WSDL to xsd (so it reads xsd:restriction) fixes the issue for our own WSDL. No idea what the initial error (with the sample WSDL) is about, though. Hints are still appreciated. But at least it's now working for us...
    – Christian
    Commented Jan 28, 2014 at 13:49
  • 1
    It might be an idea to move your comment above to an answer to your own question so as to preserve it for the future. Commented Nov 18, 2015 at 18:42
  • I tried to replicate the same thing in ReadyAPI and can't work out the cause. I think this might be one to raise as a bug to SoapUI. My past expirience has always been quick responses from them.
    – ECiurleo
    Commented Oct 5, 2016 at 8:55

2 Answers 2

1

This bug has been raised with SmartBear and details can be found here;

https://community.smartbear.com/t5/SoapUI-NG/4-6-4-Boundary-tests-not-working-skipped/td-p/38588

At time of writing, there is a workaround, but not a "fix" in place.

1

Security Scans are what soapUI uses to identify potential security vulnerabilities in your target services. Each scan sends a number of malicious requests to your service to try to provoke and identify a behavior that could indicate a security vulnerability that needs to be handled.

Security testing is done to unveil the flaws and security gaps present in the security mechanism of the software system that protects data and other sensitive information.It is supported by SoapUI to ensure authorization and authentically in request and response model of web services and web APIs.

Step 1: Right click on the TestCase “FirstProjectTestCase1” in the navigator, a drop drown menu will pop up from which select and click “New SecurityTest” as shown in the screenshot below.

enter image description here

Step 2:After selecting the “New Security Scan” option, it will open a dialogue window with setup options of Empty Test, Automatic and Full control. Each of these setup option do the following. Empty Test: It will create an empty security test and you have to manually select and configure desired security test scans.

Automatic: It will create the default setup which has common security scans and default assertions.
Full Control: I provides the full control of which security scans to add and how to configure them initially.
We are going to select the Empty Test, so that we can add desired tests later.

enter image description here

Step 3: This will open a dialogue window asking you to specify the name of the SecurityTest. Either enter any customized namethat you think of or just use the default one as shown below in the screenshot. Click on the OK button to proceed to add the security test node into the navigator.

Step 4: After click of OK button, security test console will get opened as shown in the below screenshot which is empty and has no security scans in it. In the next step we are going to add the boundary value security scan.

Step 5: On the security test console click on the”+” button present just below “TestSteps”, it will open a drop down menu which has all the security scans that can be added to the security test. To proceed with any of these scan just select it and click on the OK button to add it to the current security test. Step 6: Click on the Boundary Scan and click on the OK button. It will open below dialogue below where you can add the actual assertion by clicking green “+” button and choosing the appropriate assertion as follows. Step 7: In the above window dialogue, you can add the parameters and assertion to proceed with the required security test. Again click on “+” to add the assertions which we discussed earlier. Below dialogue box shows the type of assertions that could be added. Step 8: Select “Sensitive Information Exposure” to check for tokens UID and Password which could be added by “+” button. Click OK to complete adding of this assertion.

Step 9: Add the required parameters for boundary scan as shown in the below screenshot, click OK to complete it.

Step 10: Once the boundary scan is set, click on the green arrow button at the left corner to start the security test. Below screen represents the result of Boundary scan security test once it is completed. In Pro version you may get the detailed PDF Report.

Step 11: Check the security log, after clicking on the Security Log button present on the left bottom corner of the SoapUI tool. This is shown in the below screenshot.

enter image description here

SQL Injection: SQL Injection scan in SoapUI exploits bad database integration coding. It scans and detects for any potential SQL injections that could harm database, thus securing database.
XPath Injection: XPath Injection exploits bad XML processing inside the web service as target.
Boundary Scan: Boundary scan checks for the bad handling of the values for the web service which are outside the range definition.
Invalid Types: This type of security scan checks and exploit invalid input data.
Malformed XML: This type of security scan checks and exploit bad handling of invalid XML which may be either present on server or in web service.
XML Bomb: The term XML Bomb is used as it does the security scan for the handling of malicious XML requests which may corrupt the entire web service on server or steal the sensitive information.
Malicious Attachment: This security scans exploits bad handling of attached files.
Cross Site Scripting: This type of security scan finds any vulnerable cross-sites scripts. It scans and detects for any exposure of service parameters in the structured messages during cross site scripting.
Custom Script: This type of security scan permits to use a script for preparing custom parameters fuzzing values.

Other SoapUI Security Scan features:

Stack Overflow: SoapUI has the capability to scan and detect for huge documents within the message that could cause stack overflow.
Lifesaving Scans: SoapUI has the capability to do number of scans and ensures the security of the web services and web APIs. These scans are vulnerability scans, fuzzing scans and boundary scans to mitigate the potential erratic behavior of the web services.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.