Best approach to evaluate software security

Security testing is most essential aspect of software testing. The developed software that is not able to protect the sensitive data inside it, and is not able to sustain the data as per the requirement is of no use. Penetration testers use different kind of approaches to  evaluate the security of web applications. some testers totally relay on automated tools and some uses manual testing methods. 

Automated testing is where a one piece of software is used to test another piece of software in compiled or source code form. On the other hand, manual testing is the process where a person is performing the tests directly by hand.

There are number of advantages and disadvantages in both approaches. Manual test done by real thinking person and he can made different set of test cases which suite for the application under test. Therefore the quality of the test tends to be better. This approach is not much suitable for the large scale applications

Additionally, manual tests often provide inconsistent and difficult to verify results.

Automated test are consistent and suit well with larger applications. Those results are easy to reproducible and easy to verify the results. The disadvantage of automated testing practices is that the rate of false-positives may be high and therefore the outcome of the test may not be particularly useful.

The best approach is often to combine automated and manual tests. Automated tests are very useful at the initial stages where the requirement is to cover as much area as possible. The results from the test are analyzed and manual investigation is performed in the areas that seem critical. The process can be repeated until a satisfactory level of coverage is reached.

 

Solving Compound class names are not supported error in Selenium

When your running your selenium based test cases if you come across a issue like

"org.openqa.selenium.InvalidSelectorException: Compound class names are not supported. Consider searching for one class name and filtering the results or use CSS selectors." 

This issue is getting due to currently selendroid can not find elements by name or className with value contains white space. 

 
This is a simple way to resolve the issue.

Imagine you have a Div class like div class ="ddArrow arrowoff" and you want to use the Xpath to identify the element and you will get the above error.

  @FindBy(how = How.CLASS_NAME, using = "ddArrow arrowoff")
    private static WebElement ddarrow;

To resolve the issue you need to use cssSelector . The selector will be 

"div.dwn-arrow" 

 

driver.findElement(By.cssSelector("div.dwn-arrow")

How the ESB Publish-Subscribe Channel works

Publish-Subscribe is an  EIP pattern where the sender can sends the message to the different subscribers who subscribes to it. The Publish-Subscribe Channel EIP receives messages from the input channel (publisher) and then splits and transmits them among its subscribers through the output channel.

This blog post explains  how the Publish-Subscribe Channel EIP works.

The message comes from publisher and it directs to the WSO2 ESB. The "Event" mediator resides in proxy service allows you to define set of receivers and redirect the incoming event to the correct event topic.

To understand how this works, follow the steps given below.

Here we use echo service hosted in WSO2 application server to explain this.

1.Create a topic called “pubsub1" in ESB topics and subscribed to it using following end points

http://localhost:9763/services/echo

http://localhost:9767/services/echo

Note : You  need to start two WSO2  Application server instances



2. Create a proxy service in ESB as follows

<?xml version="1.0" encoding="UTF-8"?>

<proxy xmlns="http://ws.apache.org/ns/synapse"

name="pubsub"

transports="https,http"

statistics="disable"

trace="disable"

startOnLoad="true">

<target>

<inSequence>

<log level="full"/>

<event topic="pubsub1"/>

</inSequence>

<faultSequence>

<log level="full">

<property name="MESSAGE" value="Executing default &#34;fault&#34; sequence"/>

<property name="ERROR_CODE" expression="get-property('ERROR_CODE')"/>

<property name="ERROR_MESSAGE" expression="get-property('ERROR_MESSAGE')"/>

</log>

<drop/>

</faultSequence>

</target>

<description/>

</proxy>

Send the following message

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:p="" xmlns:xsd="http://service.carbon.wso2.org/xsd">

<soapenv:Header/>

<soapenv:Body>

<p:echoString>

<in>a</in>

</p:echoString>

</soapenv:Body>

</soapenv:Envelope>

This is how you verify whether the message is subscribed successfully.

Invoke the proxy and go to the following location in application server " Home     > Monitor     > System Statistics".  Verify the request count is changed according to the no of times you invoke the proxy. Check theses in both server instances.


Server Instance 1

Home     > Monitor     > System Statistics
 

 

 Server Instance 2

How the Message Translator EIP Works

If you need to connect two applications, the main impotent point is both applications should use common data type compatible with each other. To facilitate this, some intermediary translation should happen between the sender and receiver. The translator in between  should change the context of the message form one data type to another.

This blog post explains how ESB Message Translator EIP works.

To explain this EIP pattern we use echo service hosted in application server connect with ESB proxy service. In here sender sends the request in one format and the translator transforms that message compatible with the back end service. Here we used the payload factory mediator type “xml “and format the message  coming in to in-sequence compatible with the back end service hosted in application server. The echo service deployed in application  server receives the message compatible with it. 

 Now lets see the how to implement this pattern.

1. Create a proxy service in ESB as follows.

<?xml version="1.0" encoding="UTF-8"?>
<proxy xmlns="http://ws.apache.org/ns/synapse"
       name="translatorProxy"
       transports="https,http"
       statistics="disable"
       trace="disable"
       startOnLoad="true">
   <target>
      <inSequence>
         <log level="full"/>
         <log level="custom">
            <property xmlns:p="http://service.carbon.wso2.org"
                      name="Value"
                      expression="//p:string"/>
         </log>
         <payloadFactory media-type="xml">
            <format>
               <p:echoString xmlns:p="http://echo.services.core.carbon.wso2.org">
                  <in>$1</in>
               </p:echoString>
            </format>
            <args>
               <arg xmlns:p="http://service.carbon.wso2.org"
                    evaluator="xml"
                    expression="//p:string"/>
            </args>
         </payloadFactory>
         <log level="full"/>
         <send>
            <endpoint>
               <address uri="http://localhost:9764/services/echo"/>
            </endpoint>
         </send>
      </inSequence>
      <outSequence>
         <send/>
      </outSequence>
      <faultSequence>
         <log level="full">
            <property name="MESSAGE" value="Executing default &#34;fault&#34; sequence"/>
            <property name="ERROR_CODE" expression="get-property('ERROR_CODE')"/>
            <property name="ERROR_MESSAGE" expression="get-property('ERROR_MESSAGE')"/>
         </log>
         <drop/>
      </faultSequence>
   </target>
   <description/>
</proxy>  

                            

2. Open "SOAPUI"/"Try it" Client and send the below message to the ESB proxy

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:p="http://service.carbon.wso2.org">

<soapenv:Body>
<p:string>testString</p:string>

</soapenv:Body>

</soapenv:Envelope>

3. After sending the request, the payload factory mediator in ESB proxy  converts the request compatible with the receiver. 

The message format compatible with the receiver is as follows

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:p="http://service.carbon.wso2.org">

<soapenv:Body>

<p:echoString xmlns:p="http://echo.services.core.carbon.wso2.org">

<in xmlns="http://ws.apache.org/ns/synapse">testString</in>

</p:echoString>

</soapenv:Body>

</soapenv:Envelope>

How the Message Router EIP can be implemented using WSO2 ESB

Introduction to Message Router.

Message router reads the content of the message, and based on the content of the message it directs to the incoming message to the correct recipient. Message router is useful handling scenarios like when the specific logical function is distributed among several physical systems and we need to deliver the message to the correct service.

The following diagram describes behavior of message router.

Message router by practical example

Now lets have a look on how message router works by a practical scenario.

Assume that we have deployed "Echo" service in WSO2 Application server. Here we need to deliver the incoming message (string or integer) to the different locations. What you need to do is first create a proxy service in WSO2 ESB by giving the end points of the services and WSDL of the echo service deployed in Application server.

Create a proxy service as follows in WSO2 ESB

<?xml version="1.0" encoding="UTF-8"?>
<proxy xmlns="http://ws.apache.org/ns/synapse"
       name="test1"
       transports="https,http"
       statistics="disable"
       trace="disable"
       startOnLoad="true">
   <target>
      <inSequence>
         <log level="full"/>
         <switch source="local-name(/*/*/*)">
            <case regex="echoString">
               <log level="custom">
                  <property name="return" value="String"/>
               </log>
               <send>
                  <endpoint>
                     <address uri="http://localhost:9763/services/echo"/>
                  </endpoint>
               </send>
            </case>
            <case regex="echoInt">
               <log level="custom">
                  <property name="return" value="Int"/>
               </log>
               <send>
                  <endpoint>
                     <address uri="http://localhost:9764/services/echo"/>
                  </endpoint>
               </send>
            </case>
            <default>
               <log level="custom">
                  <property name="return" value="default case"/>
                  <property name="return" expression="local-name(/*/*/*)"/>
               </log>
            </default>
         </switch>
      </inSequence>
      <outSequence>
         <send/>
      </outSequence>
      <faultSequence>
         <log level="full">
            <property name="MESSAGE" value="Executing default 'fault' sequence"/>
            <property name="ERROR_CODE" expression="get-property('ERROR_CODE')"/>
            <property name="ERROR_MESSAGE" expression="get-property('ERROR_MESSAGE')"/>
         </log>
         <drop/>
      </faultSequence>
   </target>
   <publishWSDL uri="http://localhost:9763/services/echo?wsdl"/>
   <description/>
</proxy>

What happens in this proxy service is switch mediator observes the message and filters out the content based on the given xpath  expression. If the filtered content is matched with the case,(string/integer) the message will be routed to the specific endpoint. if the matching condition is not fount the message will be directed to the default case.

Once you invoke the above proxy you will receive a responses as follows.

case 1 - string

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:echo="http://echo.services.core.carbon.wso2.org">
<soapenv:Body>
      <echo:echoString>
         <!--Optional:-->
         <in>chathurika</in>
      </echo:echoString>
   </soapenv:Body>
</soapenv:Envelope>

[2014-04-06 00:01:46,824]  INFO - LogMediator return = String

case 2 - integer

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:echo="http://echo.services.core.carbon.wso2.org">
<soapenv:Body>
      <echo:echoInt>
         <!--Optional:-->
         <in>123</in>
      </echo:echoInt>
   </soapenv:Body>
</soapenv:Envelope>

[2014-04-06 00:05:28,934]  INFO - LogMediator return = Int

Case - default

<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"><soapenv:Body><p:echoStringArrays xmlns:p="http://echo.services.core.carbon.wso2.org">
<!--0 or more occurrences--><a>aaa</a>
<!--0 or more occurrences--><b>bbbb</b>
<!--0 to 1 occurrence--><c>vvvvv</c>
</p:echoStringArrays></soapenv:Body>
</soapenv:Envelope>

[2014-04-06 00:33:55,953]  INFO - LogMediator return = default case, return = echoStringArrays

Working with ESB XSLT Mediator

What is ESB XSLT Mediator ? 

ESB XLST Mediator supports mediates the messages  when there are dynamic (not predefined/ not static) request for  ESB proxy. The XLST  mediator applies specified XLST transformation to a selected element of current message payload.

Working with XSLT Mediator

This blog post explains how XSLT mediator works, with a simple example.

Let's assume we have a simple calculator service which defines to  work only for "a" and "b" payloads for all four  operations. Assume this service is hosted in WSO2 Application server.

<add>
         <a>?</a>
         <b>?</b>
 </add>

<divide>        
         <a>?</a>
         <b>?</b>
</divide>

<multiply>        
         <a>?</a>
         <b>?</b>
</multiply>

<subtract>
         <a>?</a>
         <b>?</b>
 </subtract>

But what happens if we give payloads as "c" and "d" ? The calculator service won't identify the payloads and give us error response. As a solution for this we can use  ESB XSLT mediator.

This is the created XSLT file for solve  the above problem and save that in ESB local entries.

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:p="http://ws.myeclipseide.com" version="1.0">
      <xsl:output method="xml" encoding="utf-8" indent="yes"></xsl:output>
      <xsl:template match="p:add">
         <p:addition xmlns="http://ws.apache.org/ns/synapse">
            <p:c>
               <xsl:value-of select="p:a"></xsl:value-of>
            </p:c>
            <p:d>
               <xsl:value-of select="p:b"></xsl:value-of>
            </p:d>
         </p:addition>
      </xsl:template>
   </xsl:stylesheet>

Please note this XSLT  representation only for "add" operation.

Create a proxy service in ESB by adding XSLT mediator as follows.

<?xml version="1.0" encoding="UTF-8"?>
<proxy xmlns="http://ws.apache.org/ns/synapse"
       name="testR"
       transports="https,http"
       statistics="disable"
       trace="disable"
       startOnLoad="true">
   <target>
      <inSequence>
         <xslt key="xsltNew"/>
         <send>
            <endpoint>
               <address uri="http://localhost:8280/services/Calculator/"/>
            </endpoint>
         </send>
      </inSequence>
      <outSequence>
         <send/>
      </outSequence>
   </target>
   <publishWSDL uri="http://localhost:9764/services/Calculator?wsdl"/>
   <description/>
</proxy>

Now create a new project in SoapUI by adding the WSDL of the created calculator  service.

Invoke the calculator service by sending the payloads as "c" and "d". Now the requests are receiving to ESB as "c" and "d" . The XSLT mediator in ESB proxy converts this to "a"and "b" and send to the Application server where the calculator service is hosted. Inside Application  server the calculations are  done and the respond is send back to the ESB. Then the XSLT mediator in ESB Proxy service understands that, this is the the response for "c" and "d" and it send the answer to the client.

How to get a JSON response for XML request using SoapUI

This is a small tip on how to  get a JSON response from XML request while you are working with soapUI.

1. Download and start the latest version of Application server. (at the moment its 5.2.1) . In order to get the JSON response you need to change the following configurations.

2.Add following parameter to 'axis2_client.xml' in AppServer_HOME}/repository/conf/axis2/' directory. because the default is set to false.

'<parameter name="httpContentNegotiation">true</parameter>'

3. Now restart the server.

4. Deploy the Jaxrs_Basic service to simulate this.

5.Open SoapUI and create a new project for Jaxrs_Basic service.

6. Now the new REST project is created and you need to set the  media type to "application /xml"

7. Add header name value pairs  Name :" Accept" Value :"application/json"

 

you can see the converted response to JSON.

8.Same as you can convert the JSON request to XML