Dimuthu's Blog » security

Security Considerations in Firefox When Accessing Different Domains

dimuthu — Mon, 22 Dec 2008 18:14:57 +0000

If you are a web developer you may have experienced that there are many situations that you need to access remote domains for data sources. For an example if you are building a weather mashup, you may like to connect to some weather forecasting services like http://www.weather.gov or http://weather.cnn.com/weather/forecast.jsp. Mostly these services are very simple, so you can build these services from Javascript itself. (FYI you can use the blog post, I wrote sometime back, Calling Simple Web Services From Javascript.) But browsers doesn’t make it this much straight forward.

For an example if you try running the following code, which basically do a simple AJAX call to an external domain,

    // some external domain
    var url = "http://test.dimuthu.org";

    // doing the ajax call
    var req = new XMLHttpRequest();

    req.open("GET", url, true);
    req.onreadystatechange = function (e) {
        if (req.readyState == 4) {
            if(req.status == 200) {
                alert(req.responseText);
            }
        }
    }

    req.send(null);

You will get a security exception from the Firefox (opera too gives a similar exception).

uncaught exception: Access to restricted URI denied (NS_ERROR_DOM_BAD_URI)

In order to avoid this, you have do some special work.

You need to add the following code before doing any AJAX request to external domains, This will give the script special privileges to access any domain through XMLHttpRequest object.

    try {
        netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead");
    } catch (e) {
        alert("Permission UniversalBrowserRead denied.");
    }

If your script always jump to the exception, you have to configure your browser to allow the above setting. You can do this by going to the “about:config” page in Firefox (Just type the “about:config” in the url field and hit Enter) where it shows a list of configurations, there you need to set “signed.applets.codebase_principal_support” field to “true”. By default this field is set to false in Firefox 3.0

After you completed above 2 steps, the page will show you an warning message saying that it is asking more privileges, in which the client have to click the “allow” button to continue.

This procedure is not much difficult to setup, but still it will be really painful for an average user, so it is better you avoid this as much as possible in your code.

The main reason this special setup is arranged in Firefox (and most of the other browsers) is attackers can run malicious scripts in some page which you trust, (for an example from one of your email message) and send your private data to some other domain that you don’t know and don’t trust.

Apart from XMLHttpRequest another famous way of accessing different domains from a web page is using framesets or iframes. using this technique, You can show an external web page inside yours as it is one part of that.

Before Firefox 3.0 and IE 7.0 you were able to change that external page (appearance or the content) according to your need when it is shown in a frame or iframe. This was possible to do by manipulating the DOM of that external page. But with Firefox 3.0 and IE 7.0 it is impossible. That is you still you can show an external page inside your web page, but you can’t change anything of it even it shows inside your page. Because it doesn’t allow you to access the DOM of that external page. See this issue is discussed in details at here, https://bugzilla.mozilla.org/show_bug.cgi?id=397828

With this improvement, you can’t call the window.document if the page of the window is from external domain.

The reason to this limitation is apparent, if you ever thought of modifying external pages and put it in your web page, you will be able feel many security holes in there. You can show some web based email login page in one of iframe, and fool some users. If that web based email application is not changed by the iframe container, it won’t be a problem, but how it is changed to submit your username, password to the parent site by updating the submit event (onclick attribute) of the DOM of that external page.

In fact Firefox and most of the browsers are trying to protect your from all these security attacks by restricting lot of functionalities of the browsers. They are doing what they can do it in the client side, but you don’t know what exactly happens in the server side since it is always a black box. The all the restriction mentioned above (i.e. accessing remote services, changing and showing an external web page) can be done in very simple PHP or .NET code in server side. So it is right that you should use the right tools, but more important thing is you are aware of these attacks and you selectively browse web while avoiding them

Sending Encrypted Binary Messages With PHP Web Services

dimuthu — Sun, 14 Dec 2008 17:51:04 +0000

Web services has made the communication between heterogeneous environments (say PHP with .NET or Java) a reality. It has defines standards for communicate not only with texts but also with binaries. And more importantly you can keep these communication confidential using encrypted messages according to your requirement. In this post, we will look at how we can implement such a system with PHP in one side.

In web services we can send/receive binary messages in two basic forms.

Setting the binary inside the SOAP message. – Binary should be converted to base64 to make sure the SOAP body contains only texts. Since base64 converted data span longer than the binary data, we call this form as non-optimized way of sending binaries.
Setting the binary outside the SOAP message – Binary would be sent as a MIME part in the message. And some element inside SOAP body keeps a reference to the binary using the MIME id. MTOM is a standard for referencing the MIME from inside the SOAP body. Since the binary is encoded, this will keep the message optimum with the binaries.

In WSF/PHP you can use any of these methods as you prefer. Lets forget about the encryption for now. We will check how we can send binaries in both of the above mentioned forms.

// first the request xml. Note tht xop:Include element that is referring the attachment with the id "myid1".
$reqPayloadString = <<"http://wso2.org/wsfphp/samples/mtom">
               test.jpg
               "image/jpeg" xmlns:xmlmime="http://www.w3.org/2004/06/xmlmime">
                  Include xmlns:xop="http://www.w3.org/2004/08/xop/include" href="cid:myid1">
               

XML;

try {
    $f = file_get_contents("my_binary_file.jpg");

    // here in the attachments option we define the binaries
    // corresponding to the id defined in the above XML
    $reqMessage = new WSMessage($reqPayloadString,
                                array("to" => "http://localhost/simple_upload_service.php",
                                      "action" => "http://wso2.org/upload",
                                      "attachments" => array("myid1" => $f)));

    // creating the WSClient
    // here the option useMTOM will decide whether the
    // attachment is set MTOM or base64
    $client = new WSClient(array("useWSA" => TRUE,
                                 "useMTOM" => TRUE));

    // sending the message and retrieving the response
    $resMessage = $client->request($reqMessage);

    printf("Response = %s \\n", $resMessage->str);

} catch (Exception $e) {

    if ($e instanceof WSFault) {
        printf("Soap Fault: %s\\n", $e->Reason);
    } else {
        printf("Message = %s\\n",$e->getMessage());
    }
}

As mentioned in the inline comment we can choose the preferred form of sending binary using the “useMTOM” option. if it is true, the binary is set as a MTOM, (referencing from the body) or if it is set false, the binary will be set as a base64 binary within the SOAP body.
To encrypt the message you only need to write few additional lines. First you define your policy that you need to encrypt this message using a WSPolicy object. Then the security token including the service public key and your private key. You need to give these two option as a constructor argument in WSClient. Here is that little additional code you need to write to add the encryption.

    // loading the keys
    $rec_cert = ws_get_cert_from_file("receiving_server.cert");
    $pvt_key = ws_get_key_from_file("my_private_key.pem");

    // here we defines the policies and create WSPolicy object
    $sec_array = array("encrypt" => TRUE,
                       "algorithmSuite" => "Basic256Rsa15",
                       "securityTokenReference" => "IssuerSerial");

    $policy = new WSPolicy(array("security" => $sec_array));

    // defining Security Tokens
    $sec_token = new WSSecurityToken(array("privateKey" => $pvt_key,
                                           "receiverCertificate" => $rec_cert));

    // modifing WSClient with adding WSPolicy and WSSecurityToken object
    $client = new WSClient(array("useWSA" => TRUE,
                                 "useMTOM" => TRUE,
                                 "policy" => $policy,
                                 "securityToken" => $sec_token));

You can implement the receiving side of the message similar to the sending side that we just described above. The most important thing is it doesn’t need to be written in PHP. It can be a Java code or .NET code.If you already have web services that use encrypted binary messaging, the above php code can be use out of the box to communicate with it.

WS-SecurityPolicy With PHP

dimuthu — Wed, 19 Nov 2008 16:20:43 +0000

WS-SecurityPolicy specification defines standards for defining security policies for your web service. WSF/PHP allows you to declare your security policies according to these standards.

You can take one of following approaches to associate policies to your web service or client.

PHP Array to represent your policies
Policy file compliant with WS-Security Policy.
Declaring policies inline with the WSDL.

Declaring Policies with a PHP Array

This is a WSF/PHP specific API to declare policies for a web service. You don’t need to learn WS-Security Policy to write policies with this approach. You can set whether you want to use encryption, signing or usernameToken in a PHP array and create a WSPolicy object using it.

// here is the security array to declare your policies in simple manner
$sec_array = array("encrypt" => TRUE,
 "algorithmSuite" => "Basic256Rsa15",
 "securityTokenReference" => "IssuerSerial");

// creating WSPolicy instance using the policy array
$policy = new WSPolicy(array("security"=> $sec_array));

You can use this policy object to create a service along with a WSSecurityToken which contain the user parameters like the server private key and the client certificate.

$sec_token = new WSSecurityToken(array(
 "privateKey" => $server_pvt_key,
 "receiverCertificate" => $client_pub_key));

$svr = new WSService(array("actions" => $actions,
 "operations" => $operations,
 "policy" => $policy,
 "securityToken" => $sec_token)); // here is the policy object you just created

$svr->reply();

You can invoke this service just by writing a simple web service client. There also you need to provide the policies declared in the service, so the client can build his request to validate with server policies. You will be using a similar WSPolicy object to set these policies at the client side too, as show in the below code segment.

 $sec_token = new WSSecurityToken(array(
   "privateKey" => $pvt_key,
   "receiverCertificate" => $rec_cert));

 $client = new WSClient(array("useWSA" => TRUE,
    "policy" => $policy, /* the policy object */
    "securityToken" => $sec_token));

 $resMessage = $client->request($reqMessage);

Declaring Policies with a Policy File

You can set your policies in the server or client side using a policy file compliant with WS-Security Policy specification. You have to take this approach if your policy requirements are too complicated, like you want to sign only some parts of the message or you want to encrypt some soap headers.

Similar to the above method, here too you will use the WSPolicy object to set your policies. But unlike the above where you give the policies as a PHP array , here you can just give the policy file as an argument to the WSPolicy constructor.

// creating the WSPolicy instance from a policy file
$policy_xml = file_get_contents("policy.xml");
$policy = new WSPolicy($policy_xml);

Here is an example of a complete policy file written according to the WS-Security Policy standards. And you can find a quick guide on WS-Security Policy from the article Understanding WS-Security Policy Language written by Nandana, a key leader of Apache Rampart project.

Declaring Policies inline in a WSDL

We use WSDL to describe our web services. WSDL has the information about the service endpoint, the transport protocols (e.g. http), messaging protocols (e.g. SOAP) and the message schemas and many others about the service. You can attach your policies inside a WSDL.

Here is an example of a WSDL with inline policies. The difference in this approach is you can set your policies separately for each messages or each operations or each endpoints of your service. The following segment of a WSDL shows how you refer to different policies which are declared in the early part of the WSDL.

      name="CalendarSOAP12Binding" type="ns1:CalendarPortType">
       
         URI="#transport_binding_policy"/>
         transport="http://schemas.xmlsoap.org/soap/http" style="document"/>
         name="login">
            soapAction="urn:login" style="document"/>
           >
              
               URI="#username_token_policy"/>
               use="literal"/>
           >
           >
               use="literal"/>
           >
         >
          name="register">