Why You Don't Know The Client Browsers

Do you know the client browsers?

Client-server architecture comes from the early days of computing. Computers solve problems by talking to other machines on a network.

UNIX, for example, came from a family of multitasking and multiuser computer operating systems. The design was a client terminal from which you log into the computer server. This architecture enables time-sharing, a way to interact with computers over a network. Through time-sharing, you begin to see the birth of the web and cloud computing.

This client-server architecture has many benefits, like decoupling underlying implementation details on clients that share the same resource.

A resource-driven architecture provides more flexibility and scalability in the solution. It is no accident the web is the de facto standard for modern computing.

Modern web solutions take advantage of asynchronous multitasking across many nodes in a network.

What is the Internet?

I know what you may be thinking, isn’t the Internet too nebulous? The modern architecture of the web sits on top of a set of clear and well-defined standards.

Once engineers figured out client-server solutions had great potential, the next step was to rally behind a common protocol, known as HTTP.

HTTP stands for Hypertext Transfer Protocol, and it is the backbone of the Internet. The protocol is a text message that talks to a computer over a network. The client initiates a message as a request to the server. The server then responds to the message with a resource.

A simple hypertext response can do, for example:

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Date: Mon, 26 Dec 2016 16:40:44 GMT
Connection: keep-alive
Content-Length: 27

{"message":"Hello, World!"}

Note the protocol has a resource content type. In this example, it is responding with JSON. The server is not concerned with how clients handle this resource. JavaScript on the client, for example, can do whatever it needs with this content type.

HTTP is hypertext messages over a network. It is both intelligible and fascinating.

A Stateless Protocol

What follows from a system of decoupled hypertext messages is a stateless protocol. This means HTTP is not concerned with persistence on the client or the server.

The state itself is an implementation detail. It can go on the client or the server. Persistence is a responsibility that gets delegated to each layer.

Imagine an app where you begin a user session on a desktop browser. Then, continue where you left off on a mobile device. In this instance, the server uses a persistence mechanism decoupled from the client. The server can choose to store user sessions in memory or a database. The client is not concerned at all about how this is happening.

On the client, applications with offline support are common for mobile. This enables the client app to store its state. The client keeps the state and syncs up with the server once the network becomes available. In this example, the state gets handled by the client. The client app must decide whether the network is or is not available.

The implication of a stateless protocol leads to a fascinating conclusion. It means applications over the web are client-server agnostic. Any computer program with the correct hypertext message can interact with your web solution.

This stateless nature has security implications.

Browser Usage

This story becomes more interesting when you see the plethora of browsers out there. Each is capable of sending hypertext messages over the web.

According to Stat Counter, Chrome is the most popular browser as of the time of this writing. On mobile, Safari is the second most popular.

The web is a place full of diverse browser clients. Because of this, it is both scary and fascinating. There is little chance to know in advance which browser end-users use on the client.

This means you have little to no control over the web solution. End-users are free to use whatever browser can interact with your solution. This level of freedom comes at a price.

For security, this means there are many attack vectors because attackers have many choices. Each layer is vulnerable, an attack on the server can come from an agnostic client. An attack on the client can target a specific vulnerability in code that runs on the client.

Conclusion

In the end, you can’t trust the client. In the open web, the client is the layer you can’t control. Once your server receives a request, it can come from anywhere since it’s a hypertext message. The open web is both scary and fascinating.

With the proliferation of JavaScript on the client, many modern solutions put more and more business logic on the client. Single-page applications, for example, are ubiquitous on the web. Many solutions depend on the functionality provided by the browser.

Modern browsers have become the best programming platform on the web. The APIs available add richness and ease of use to any solution.

So, where does this lead? What can you do to secure modern solutions?

With Runtime Application Self-Protection (RASP), you can trust the client.

Jscrambler, for example, offers the most effective level of protection for client-driven applications.

A RASP solution protects against tampering and adds self-protection. This solution is ideal for JavaScript applications that run on the client.