What is Network Side Scripting?

This article, the first in a series of four, explains how "Network Side Scripting" should be another technique in your application toolbox. However, why is "putting code on the network" a good idea?

Most networked applications are split between the client and the server, with the network forming a pretty dumb pipe in between. An application developer must decide which application logic to put on the client side, and which to put on the server side:

Network Side Scripting adds another dimension to the picture. With Network Side Scripting, you can also put application logic between the client and the server, on the network itself.

Let’s just pause for a moment because our eager-to-impress security junkie has just walked in...

So, perhaps Network Side Scripting is a legitimate place to put some of your application logic. Is any of this relevant, and why on earth would you want to do it?

The application onion

Applications are built like onions, with multiple layers of different types of code and interfaces. A simple application may interface with a collection of class files, which then interface with the operating system kernel via system calls, which then communicates via the network to a database or display device. Very often, it’s useful to shim a little code in at one of the interfaces, to inspect, monitor or change the way that the application works.

For example, tools like strace or ltrace intercept system calls and library calls for monitoring purposes and are a useful debugging aid. Code injection via a shared library in the link loader can catch calls to a function and override it. JavaScript on the client (browser) side can completely control how the application is presented to the end user.

Application developers use many interfaces to monitor and modify the behavior of an application.

In a client-server application, the network is another interface that you can tap into. In fact, you can regard the server component as a closed box whose entire behavior is defined by the data it receives and the responses it writes on the network. With an appropriate traffic management device, you can intercept this data and begin modifying the behavior of the application.

In fact, the name 'Network Side Scripting' is a little bit limiting, as this technique can allow you to control almost your entire application, not just what happens on the network.

Illustrating network-side scripting

In the next two posts, I’ll consider two typical use cases for Network Side Scripting – modifying the host header in an HTTP request, and modifying the content of an HTTP response. I’ll consider three common traffic management devices capable of this type of network-side scripting – Citrix’s Netscaler VPX, F5’s BigIP Local Traffic Manager and Zeus Traffic Manager.

I’ll round this off with a further post considering some advanced uses of Network Side Scripting.

Articles

• What is Network Side Scripting?
• Modifying HTTP requests with Netscaler VPX, F5 BigIP and Zeus Traffic Manager
• Modifying HTTP responses with Netscaler VPX, F5 BigIP and Zeus Traffic Manager
• Advanced applications of Network-side Scripting

Owen Garrett [Zeus Dev Team] 28 September 2009 1 comment