WiNK edit

wiki /NetKernel /News /2 /42 /August_19th_2011

NetKernel News Volume 2 Issue 42

August 19th 2011

What's new this week?

Repository Updates
Announce: NetKernel Europe Bootcamp - Brussels, Belgium, Thursday 27th October 2011
Reminder: Java 5 Support - End of Life Heads Up, October 2011
SSH Client Port Forwarding
Cross Site Scripting Attacks (XSS) a Resource Oriented Perspective
Why is ROC measurably secure?

Catch up on last week's news here

Repository Updates

The following update is available in the NKEE and NKSE repositories...

ssh-client 1.3.1
- Adds support for port forwarding (see below)

Announce: NetKernel Europe Bootcamp - Brussels, Belgium, Thursday 27th October 2011

Reminder: Java 5 Support - End of Life Heads Up, October 2011

Last week we gave a heads-up that Java 5 support will reach end-of-life in October 2011. Please see the notice for details.

Please let us know if you have concerns or need assistance with planning/testing for this transition.

SSH Client Port Forwarding

The update of the ssh-client package in the repos introduces a new SSH port forwarding capability active:sshLocalPortForward. Here's an example of how it can be used to set up a port forward of a remote server's NetKernel admin fulcrum to your localhost interface's port 1070...

req=context.createRequest("active:sshLocalPortForward")
req.addArgument("remote", "ssh://some.server.com")
req.addArgument("credentials", "res:/resources/my-ssh-credentials-for-server.com")
req.addArgument("forward", "1070:localhost:1060")
req.setVerb(INKFRequestReadOnly.VERB_NEW)
context.issueRequest(req);

The port forward is persistent - we've modelled it as a NEW resource (how else?). When you want to close the port forward connection you DELETE the port forward resource like this...

req=context.createRequest("active:sshLocalPortForward")
req.addArgument("remote", "ssh://some.server.com")
req.addArgument("credentials", "res:/resources/my-ssh-credentials-for-server.com")
req.addArgument("forward", "1070:localhost:1060")
req.setVerb(INKFRequestReadOnly.VERB_DELETE)
context.issueRequest(req);

This example shows how you could map a clustered NK instance to a local cluster manager instance and then issue some requests to it over the SSH tunnel before closing the tunnel and managing another NK instance etc.

But since this is just ssh tunneling, you can now have NK create arbitrary light-weight VPNs for any service using ssh port forwarding.

Cross Site Scripting Attacks (XSS) a Resource Oriented Perspective

Earlier in the week I was prompted to take a look at the OWASP Web Application Firewall (WAF). The term WAF is one of those very grand titles - but like any security technology it adds no value if you don't fundamentally understand what it does or the principles behind the vulnerability it is supposed to eliminate. It turns out that when you do understand it, and if you have a resource oriented perspective, you really don't need it...

So I was led to do some research on XSS attacks. It seems that a WAF is mostly a front-end HTTP request filter to do HTML encoding of user-submitted input parameters and validation of cookies.

Actually I was a bit shocked and I couldn't believe what I learned about XSS vectors...

http://en.wikipedia.org/wiki/Cross-site_scripting

More particularly, being a first-principles kind-of-a-guy, I was shocked at how the vectors are even possible. So here's a short primer on XSS and then an explanation of how if you use ROC you can be provably immune...

XSS a primer

XSS is a fundamental flaw in certain approaches to server-side web development. In particular it is a vulnerability of page-based web development models (eg ASP, JSP, PHP etc etc). The pattern goes like this...

An attacker submits some "input state" to a page (either in a URL query param, or in the POST content of a url-encoded form). A developer accepts this input state and then either directly, by using a parameter value in a page template, or indirectly (storing in a DB then subsequently using the value in another template) uses the literal value provided by the attacker.

If the attacker crafts the submission to include a <script> tag then that tag is inserted into the page template and the attacker's code is run by the browser. If the site is compromised in a suitable way, then the attacker can get that script to run on the browser of any subsequent viewer of the page that is using the tainted state.

Here's a very simple example. Lets say a page is generated by just inserting the value of the name URL parameter to a page...

http://site/page.xsp?name=foobar<script type="text/javascript">alert("Gotcha");</script>

The page template might look like this...

<div>
Hello $name
</div>

And so the response received by the browser would be ...

<div>
Hello foobar
  <script type="text/javascript">alert("Gotcha");</script>
</div>

The aim of a XSS hacker is to craft an input submission that not only gets served back to them in their context, but to everyone else that views any page with the state they submitted. (Think of an avatar image or location field in a forum or product review etc etc).

The primary motive behind such attacks is to construct a script which will capture username, passwords, credit card details etc etc. The script would "scrape" this data out of a user's page and then construct an iframe or other window.location event to make the browser request the URL of the attacker's receiving server with the captured data as query parameters. The attacker than just sits back and lets their database fill up with the raw material for identity theft.

A more difficult but fundamentally equivalent variant of this attack would be if data in a DB or remote service is compromised - whether directly, or by somehow originating from a compromised 3rd party supplier - and this tainted data is then inserted into a page template.

XSS is now ranked as the most significant internet security threat to end-users. But the staggering and utterly amazing thing about this is that it is entirely, 100% preventable. And not by introduction of magic-bullet data filters or over-engineered "Web Application Firewalls", but by using our brains, stepping away from code and considering the resources and the resource representation model...

A Resource Oriented Computing analysis of XSS

OK lets get back to first principles. What is a web-page? Clue: it is absolutely not a "string" of characters. It is also absolutely not a "page".

A web-page is a tree structured program. The tree structure is serializable for network transfer over the HTTP protocol. A browser receiving the serialized web-page uses a range of tolerant fallback techniques to parse the serialized representation into a linked tree structure model of the program. The browser then, using increasingly sophisticated engines, renders (reserializes) the state of the program to create the "raster view" representation you see in the browser window.

In ROC terms, the browser is a runtime for a domain specific tree-structured programming language called "HTML".

Increasingly the client-side tree-structure model is not passive. With client-side scripting the web-page is an "active tree". The browser detects the active nodes in the tree, it uses the textual value of the node (either literal by-value or by attribute reference) as code, compiles and executes it. The executed node often results in subsequent dynamic modification of the tree structure model (so called AJAX applications) which are reflected to the user in a dynamic rendering of the "page".

Because the browser runtime has to be fast and efficient only nodes in the tree with a special name are treated as active. You may have seen them, they're called "script".

The objective of an XSS attack is to insert active script nodes into the tree-structure.

The Category Error of Page-Based Web Technologies

If you're starting to see the world with ROC-eyes you may by now have already have spotted the "category error" implicit to page-based server-side web technologies (ASP, JSP, PHP etc etc).

Its tempting at this point to "do a Fermat" and leave you to work it out for yourselves. But I wouldn't be so cruel...

Here's the thing: You can only ever be exposed to XSS attack when in the serialized domain.

Page-based server-side web technologies make the fundamental error of thinking of a "web-page" as a page, ie as a serialized stream of characters. In the serialized domain, whenever you use external state (whether from the client-side or from the data-base tier) you are vulnerable to "injected structure attacks".

Any character state that constitutes serialized tags, when inserted into the serial-domain representation of the web-page will, when "state transfered" to the browser, become transferred to the tree structure programme executing in the browser.

Web Application Firewalls offer the least possible and most dumb amelioration of this attack vector. They filter all inbound user state and replace any markup tags with HTML escaped values. For example here's a utility method...

public static String HTMLEncode(String s)
{   if(s==null)
    {   return null;
    }
    StringBuffer sb = new StringBuffer();
    for (int i = 0; i < s.length(); i++)
    {   char c = s.charAt(i);
        if (c >= 'a' && c <= 'z' || c >= 'A' && c <= 'Z' || c >= '0' && c <= '9')
        {   sb.append(c);
        }
        else
        {   sb.append("&#"+(int)c+";");
        }
    }
    return sb.toString();
}

The reason this is a very weak defence, is that it only protects you from one possible source of the attack - the client-side, but what about the data-side?

There is a far far far more powerful defence. Quite simply: don't work in the serial domain.

In ROC terms, be like the browser and on the server-side us a tree structured representation model. If the resource representation state on the server-side is tree structured something wonderful happens. You have two orthogonal dimensions in which you can compute. The structural domain of the branches and nodes of the tree. And the text-domain of the textual values of nodes and attributes.

If your use of external state (client-side or database-side) is confined only to the text-dimension you will never ever be the subject of an XSS attack. Any potential attack state is inserted into the text domain not the tree domain. A browser will never run it because a browser initiates script execution from the tree domain (it looks for script nodes in the tree).

NetKernel's Provably XSS-Safe ROC Programming Methodology

It just so happens that NetKernel offers a set of tools which provide a provably XSS-safe methodology for web applications. They are: The HTTPBridge, the XRL runtime, XSLT or E4X, the HDS representation model and the active:sqlXXXX RDBMS tools.

Every one of these tools defaults to tree structured representations.

The HTTPBridge provides all external user-provided state in a tree structure which orthogonally isolates the name from the value.
The XRL runtime provides a composite tree-structured programming language which is devoted to the tree-structure domain.
XSLT and E4X (native to NK's serverside active:javascript runtime) offer independent access to structural construction and textual values in the tree.
The RDBMS tools return database state in an HDS tree structure which may feed another tree structure tool always maintaining the isolation between structure and text-domains.

By combining these (and many other) tools in a composite ROC solution one can measurably and provably show that there has never been a point in your application where external state had access to the serialized domain.

The computed composite tree structure resource is ultimately delivered through the HTTP transport, at which point it is transrepted to the serialized domain - whereby all text-domain resources are automatically "encoded" (since by definition they must be kept separate from the structure domain when in "wire-format"). This is just an inverse of the browser's parser.

But provable security is nothing, when, as no doubt you are sick and tired of me saying, you recognize that using resource oriented composition will magically reveal the reusable resource state in the application and make it hugely more efficient.

Working in the serialized domain is wrong in so many ways. It is hugely dangerous, it is monolithic and brittle, it is constant cost with no possibility of efficiency gains from statistical discovery of collective state - it requires you to constantly translate what you are manipulating and thinking about to the way that the browser actually runs.

Symmetry is the essence of beauty. Why not try symmetric Resource Oriented development. It's beautiful.

Further Practicalities

Of course since NK has so many tools and languages you can be tempted from the path of orthogonal structural composition. We have therefore added some new features to the HTTP server module to cover the key features of a WAF.

Firstly the HTTPBridge now has a secondary set of resources for user provided parameter state in the resource sets...

httpRequest:/paramsHTMLEncoded
httpRequest:/paramHTMLEncoded/foo

Requesting any of these resources will ensure that the parameter state is HTMLEncoded using the algorithm shown earlier.

In addition we have added an XSSSafeCookie class which uses the HttpOnly property to ensure that a browser will prevent any script from getting programmatic access to the cookie state. This cookie is now the default for the session overlay and for a new persistent session model that Tony has developed.

These updates are complete but we will ship them as part of the forthcoming general refresh - this will also include an update of the transport to offer the latest gen-7/8 WebSocket specification which, as a standard, is slowly working through a number of hideous potential security issues!

Why is ROC measurably secure?

ROC is measurably secure since in ROC all state has identity. If you know the origin of state is safe or has been sanitized then it poses no security threat. Or equally if you can show that external state is always orthogonal to structural "code".

For example how do you prove that your application is using HTML encoded user parameters? Just search "httpRequest:/params" and replace with "httpRequest:/paramsHTMLEncoded" (when its released), or alternatively and more sophisticatedly, put a mapper in your application layer which routes all requests for httpRequest:/params to httpRequest:/paramsHTMLEncoded- your developers can't get to the untrusted resources even if they try.

This holds for arbitrary state whether from the client-side or from the data-side. You can always validate that the resources you are using are well-defined and sanitised (whether by the accessor from which they originate or by providing overlay contexts which do secondary sanitisation - ie an internal WAF on the top and bottom of the architecture). And you can always structure the spacial architecture to have "resource firewalls": contextual boundary conditions that guarantee that the set of accessible resources in an application is strictly defined.

ROC is not only the most beautiful, but also, the safest way to program.

Have a great weekend,

Comments

Please feel free to comment on the NetKernel Forum

Follow on Twitter:

@pjr1060 for day-to-day NK/ROC updates
@netkernel for announcements
@tab1060 for the hard-core stuff

To subscribe for news and alerts

Join the NetKernel Portal to get news, announcements and extra features.

NetKernel will ROC your world

Download now

NetKernel, ROC, Resource Oriented Computing are registered trademarks of 1060 Research