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

How to capture SOAP / XML messages with WireShark

When you are debugging a web service calls some times you may want to capture requests and responses . Using WireShark you can see exactly what requests are coming and what are the responses are going out from service. This blog explains how to capture SOAP /XML  message using wire shark.

First you need to start a web service in your machine. Here the used service is Jaxrs_Basic and deploy it in your machine.

1. Open SOAP UI , get the WADL of Jaxrs_Basic service and create a new SOAP UI project.

2. Open WireShark in your machine giving “sudo wireshark”

3. Create a “ Capture Filter” as follows.

• Select Capture from menu bar → Interfaces → Select your interface where your web service is running
• Click options on “Capture Interface Menu”-> It will direct you to “wireshark capture options” window.
• Click on the selected interface and it directs to the edit interface settings window.
• Set your capture filter as display in screen shot.
  
  

4.Enable network name resolution (makes identifying traffic much easier)

Now we are ready to capture required packets.

5. Invoke the Jaxrs_Basic service using SOAP UI.

6. Here you can see packets are receiving through WireShark.

7. Now you need to filter the SOAP/XML messages. To do this just type the filter “xml” at filter box and click at Apply. This will capture the soap messages in invoked web service.

8. Select one message-> right click on it ->”Select follow TCP Stream” from available menu.

9. You can view the soap/xml  message clearly.

Working with ESB JIRA Connector

This blog post explains how to create test data using Developer Studio and how to create an issue using ESB JIRA connector using the created test data .

1. First open the Developer Studio Application and go to the dashboard. Create an ESB Config Project by clicking the “ESB Config Project Link” .

2. It will Direct you to the “New ESB Project” window. Select “ New ESB Config Project”

3.Give a name for the project expect to create and browse and mention the location of the project .

Now the ESB Config project is created and we need to create a proxy service to work with JIRA operations.

4. Go to the dash board again and click on “Proxy Services” link

 

5. Select “Create New Proxy Services” Option

 

6. Create a Custom proxy by entering details to the required fields and click on finish to complete.

  

7. Go to the Project Explorer and select the created ESB Config project and right click on it . You can see the menu available → Select “Import Cloud connector” from menu . It will direct you to the ESB Cloud Connector window. Browse and locate the JIRA connector location.

 

 

8.Go to the palette and open the created XML file and verify the JIRA Connector Tab is available in the palette, expand the JIRA connector pallet and you can see all the JIRA Connector operations available.

9. Here I'm going to explain how to create a new issue using JIRA connector . So drag and drop the “Config' and “Create Issue” JIRA operations in to the XML design view and verify the source code is created accordingly for the added JIRA operations by navigating to the “Source” tab.

 

Source View of the above operation should be like this. 

 

10. Now go to the dashboard of the developer studio and select “carbon application project” link to create new carbon application project.

11. Enter the project name and the location of the new carbon application project and click on finish button.

 

 12. Now save the created carbon application project in preferred location

 

13.Now export the created and saved carbon application by right clicking the carbon application project available at project explorer and click on the “Export Carbon Application project” option. It will open the the “WSO2 Platform Distribution” window. Export the carbon application in to the preferred destination.

14. Now Start the ESB server, Go to the management console and log in to the application. Then go to the connectors section of the main tab →click on “Add Connectors” and it will direct you to browse the location where the connectors are available. Select the JIRA Connector from the available location and upload the connector. 

15. The JIRA Connector uploaded successfully displayed in the connectors window .Enable the uploaded JIRA connector.

16. Then go to the Carbon applications section at the main page and click on “Add” to upload the created carbon application using Developer Studio Previously.

 

17.Browse the location of the exported carbon application and upload the carbon application.

18. Go to the services section at the main tab and Click on “List” to check whether the uploaded carbon application is deployed with the proxy.

Go to the service dashboard of the created proxy and get the end points of the URI

http://chathurika:8280/services/<proxy>

Invoke the proxy using curl -v http://chathurika:8280/services/<proxy>

The JIRA issue will be created according to the given instructions in the proxy.

For any JIRA operation you can create test data using the Developer studio application and deploy it in ESB as a carbon application . After that you can invoke the created proxy using CURL or SOAPUI.

Installing PostgresSQL on Ubuntu

1.Verify that you do not already have installed PostgreSQL in your machine

Run the following command in your console

ps ax | grep postgres

2.If you get a response similar to the one below, then you have PostgreSQL installed

Ss 0:00 postgres: writer process

Ss 0:00 postgres: wal writer process

Ss 0:00 postgres: autovacuum launcher process

Ss 0:00 postgres: stats collector process

3.Install PostgreSQL on your system

sudo apt-get update

sudo apt-get install postgresql-9.1

4.Configure your PostgreSQL Password

sudo -u postgres psql template1

ALTER USER postgres with encrypted password 'your_password';

Press ctrl-d

5.Configure MD5 Autentication

sudo nano /etc/postgresql/9.1/main/pg_hba.conf

6.Update the

local all postgres

7.Entry to

local all postgres md5

8.Enable TCP/IP connections

sudo nano /etc/postgresql/9.1/main/postgresql.conf

Locate the line

#listen_addresses = 'localhost'

and change it to

listen_addresses = 'localhost'

9.Restart the postgresql

sudo service postgresql restart

10.Create the database

create database testdb;

11.List available databases

\list

12.List users

\du >>> List Users