Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Why You Don’t Know the Client Browsers

DZone's Guide to

Why You Don’t Know the Client Browsers

Let's explore client-server architecture and HTTP, and explain a bit about how the plethora of web browsers out there make web security difficult.

· Web Dev Zone
Free Resource

Add user login and MFA to your next project in minutes. Create a free Okta developer account, drop in one of our SDKs to your application and get back to building.

Client-server architecture comes from the early days of computing. In the beginning, computers solved 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 main 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. For instance, one benefit is 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 that 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 nor 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 individual 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 session in memory, or in a database. The client is not concerned at all how this is happening.

On the client, applications with offline support are common for mobile. This enables the client app to store its own 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 implications for security.

Browser Usage

This story becomes more interesting when you see the plethora of browsers out there. Each 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 on 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 in nature.

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 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.

Launch your application faster with Okta’s user management API. Register today for the free forever developer edition!

Topics:
security ,web ,javascript

Published at DZone with permission of Pedro Fortuna. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}