Today we live the era of the web and your browser is an integral part of it. As a developer, it is essential to know how stuff works to some degree, and understand how you might affect this behavior to increase security. This post is an intro to that topic!
Let’s start with a bit of context, shall we? First, let’s try to define what web browsers are!
They are applications used to render data; data that is fetched from a remote location. Chances are, this data is created by someone other than you. Your browser connects to the server using a rather hostile medium called the Internet and downloads content. Once that is done, it parses and executes it. Your browser is a “remote code execution container” for the web.
You would never download untrusted executables and run them on your computer, yet this is exactly what you do when you browse the web. You trust your browser to protect you.
Rightly so, browsers are mostly prepared to handle this. It creates enormous complexity though and that yields quite a few new bugs every year.
Moving on, what do you think the number one goal of your web browser is?
Rendering the page, at all cost!
Browsers are a perfect example of Postel’s Law, also known as the robustness principle. They do their best to display a webpage, even if it is broken. Unfortunately this has quite noticeable tradeoffs regarding security: relaxed content type handling, TLS fallbacks, parsing incorrect HTML, etc. These behaviors open up new attacks: e.g. dangling markup injection.
Browsers are magnificent creatures, and they work with data in all three states. Let’s take a bit more detailed view at these.
Rendering
Rendering a page is processing data and it is a pretty complicated workflow. It involves parsing the source of the page, fetching extra resources, creating the DOM, parsing extra markup like CSS and Javascript. And finally running included scripts. Once all this has finished, it will render the DOM and display the page to the user.
During this phase the browser also enforces various security settings some of which you can explicitly configure. I will cover these in another post, for now just remember that security is not forgotten, quite the opposite, it is built in.
Network stack
Browsers do a whole lot more than just rendering. From our point of view, they are in charge of the network operations (a.k.a. data in transit): establishing (secure) connections (TCP, HTTPS), negotiating protocols (QUIC, SPDY, HTTP/2), querying DNS servers, etc. Just like during rendering, security is enforced and it is possible to prescribe certain rules the browser will strictly follow.
Persistence
At first, this may not be apparent, but your browser is also handling data at rest. Think about remembering passwords or storing cookies. Browser’s persistence features also open up whole new use cases, like tracking, advanced single page applications utilizing local storage or the caching of files.
It’s no surprise that security plays a vital role in this area as well. Be it cookies or cache settings, the browser has critical responsibilities when securing data at rest.
Conclusion
Today’s browsers have come a long way. Security is baked into them and is considered a top priority. They also have extra features like SafeBrowsing. Some go to extremes, like WebKit on iOS, just to protect its users.
We use these tools every day to explore the wilderness of the Internet and trust them with our security. You may start to get a feeling as to why this is.
Browsers can be a reliable ally in the field of security. As a seasoned web developer you must learn to utilize them effectively to tighten your website’s security. This is a huge topic, and I am here to guide you. Stay tuned!