Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

How does the browser work in Web application security

2025-02-24 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Development >

Share

Shulou(Shulou.com)06/02 Report--

This article introduces the knowledge of "how browsers work in Web application security". Many people will encounter this dilemma in the operation of actual cases, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Here first explain the function of the browser and how to execute it. Since most customers will interact with web applications through browsers, it is important to understand the basics of these excellent programs.

The browser is a rendering engine whose job is to download a web page and render it in a way that humans can understand.

Although this is almost an oversimplification, all we need to know now.

The user enters an address in the browser bar.

The browser downloads the document from the URL and renders it.

You may be used to using one of the popular browsers such as Chrome,Firefox,Edge or Safari, but that doesn't mean there are no different browsers.

For example, lynx is a lightweight, text-based browser that works on the command line. The core principle of lynx is exactly the same as that of other "mainstream" browsers. The user enters the web address (URL), and the browser gets the document and renders it-- the only difference is that lynx does not use a visual rendering engine, but uses a text-based interface, which makes sites like Google look like this:

We have a general idea of what browsers do, but let's take a closer look at the steps these witty applications do for us.

What does the browser do?

To make a long story short, the work of the browser mainly includes:

DNS parsing

HTTP switching

Render

Repeat the following steps

DNS parsing

This process ensures that once the user enters URL, the browser knows which server it must connect to. The browser contacted the DNS server and found that google.com was translated into 216.58.207.110, which is an IP address that the browser can connect to.

HTTP switching

Once the browser has determined which server will serve our request, it will initiate a TCP connection with it and start an HTTP exchange. This is just one way for the browser to communicate with the server and for the server to reply.

HTTP is just the name of the communication protocol used on Web, while browsers typically communicate with the server through HTTP. The HTTP exchange involves the client (our browser) sending a request and the server responding.

For example, when the browser successfully connects to the server behind the google.com, it sends a request like this:

GET / HTTP/1.1 Host: google.com Accept: * / *

Let's break down the request one by one:

GET / HTTP/1.1: on the first line, adding that the rest of the requests will follow the HTTP/1.1 protocol (it can also use 1.0 or 2)

Host: google.com: this is a required HTTP header in HTTP/1.1. Because the server may serve multiple domains (google.com, google.co.uk). The client here mentions that the request is for a specific host.

Accept: * / *: an optional header where the browser tells the server to accept any type of response. The server can have available resources in JSON, XM L, or HTML format, so it can choose the format it likes.

After the browser as the client sends the request, it is the server's turn to respond, which is in the following format:

HTTP/1.1 200 OK Cache-Control: private, max-age=0 Content-Type: text/html; charset=ISO-8859-1 Server: gws X-XSS-Protection: 1; mode=block X-Frame-Options: SAMEORIGIN Set-Cookie: NID=1234; expires=Fri, 18-Jan-2019 18:25:04 GMT; path=/; domain=.google.com; HttpOnly.

In the body of the response, the server is represented according to the response type included in the Content-Type header. In our example, the content type is set to text/ html, so we expect the HTML tag in the response-this is what we found in the body.

This is the real bright spot of browsers. It parses the HTML, loads additional resources contained in the markup (for example, you might need to get an JavaScript file or CSS document), and presents them to the user as soon as possible.

The end result is something that ordinary people can understand:

If you want to know more about what happens when we press enter in the browser's address bar, we suggest reading "What happens when..." This is a very subtle attempt to explain the mechanism behind the process

Since this is a series of articles focused on security, you can mention a hint from what you just learned: attackers can easily make a living by exploiting vulnerabilities in the HTTP exchange and rendering section. Vulnerabilities and malicious users are also lurking elsewhere, but better security methods at these levels have allowed you to make progress in improving security.

Supplier

Four very popular browsers belong to different companies:

Google's Chrome

Mozilla's Firefox

Apple's Safari

Microsoft Edge

In addition to competing with each other to increase market penetration, vendors also cooperate with each other to improve web standards, which is a very low requirement for browsers.

W3C is the main body of standard development, but it is not uncommon for browsers to develop their own features and eventually become web standards, and security is no exception.

For example, Chrome 51 introduces SameSite cookie, which allows Web applications to get rid of a specific type of vulnerability called CSRF (described in more detail later). Other vendors thought it was a good idea and followed suit, making SameSite the web standard: so far, Safari is the only mainstream browser without SameSite cookie support.

This tells us two things:

Safari doesn't seem to care about user security (joke: SameSite cookie will be available in Safari 12, which may have been released by the time you read this article)

Fixing a loophole in a browser does not mean that all users are secure

The first is an attempt at Safari (as I mentioned, joking!), and the second is very important. When developing web applications, we need to make sure that not only do they look the same in different browsers, but also that our users are equally protected on different platforms.

Your network security policy should vary depending on what the browser vendor allows us to do. Today, most browsers support the same feature set and rarely deviate from their common roadmap, but the above example still happens, which is something we need to consider when defining a security policy.

In our example, if we decide to mitigate CSRF attacks only through SameSite cookie, then we should be aware that we are putting Safari users at risk. Our users should know this, too.

Then, you should remember that you can decide whether or not to support browser versions: it would be impractical to support each browser version (think Internet Explorer 6). While ensuring support for mainstream browsers in recent versions is usually a good decision, if you don't plan to provide protection on a particular platform, it's generally recommended to let your users know.

Professional tip: you should not encourage your users to use outdated browsers or actively support them. Although you may have taken all the necessary precautions, other web developers may not. Users are encouraged to use new versions supported by mainstream browsers.

Supplier or standard bug?

The fact that ordinary users access our applications through third-party clients (browsers) adds another level of indirectness: there may be security vulnerabilities in the browser itself. '

Vendors often offer rewards (bug bonuses) to security researchers who can discover vulnerabilities in the browser itself. These bug have nothing to do with your implementation, but with the way the browser itself handles security.

For example, the Chrome incentive program allows security engineers to contact the Chrome security team to report vulnerabilities they have discovered. If these vulnerabilities are identified, patches are released, and security advice notices are usually issued to the public, and researchers receive (usually financial) rewards from the program.

Companies like Google have invested relatively large amounts of money in their Bug bounty programs, allowing them to attract researchers by promising financial benefits when finding any problems with the application.

In a vulnerability reward program, everyone wins: vendors try to improve the security capabilities of their software, and researchers are paid for it. We will discuss these procedures later because I believe that the Bug bounty program should have its own section in the area of security.

Jake Archibald, a Google developer, recently discovered a vulnerability that affects multiple browsers. In an interesting blog post, he recorded his efforts, how he contacted different suppliers, and their reactions. I suggest you read this article.

Developer's browser

So far, we should understand a very simple but rather important concept: browsers are just HTTP clients built for ordinary web surfers.

They are certainly more powerful than the platform's pure HTTP client (for example, consider NodeJS's require ('HTTP')), but in the final analysis, they are "just" the natural evolution of the simpler HTTP client.

As a developer, the HTTP client we chose might be Daniel Stenberg's cURL, which is one of the most popular software programs that web developers use every day. It allows us to perform an HTTP exchange in real time by sending an HTTP request from the command line:

Curl-I localhost:8080 HTTP/1.1 200 OK server: ecstatic-2.2.1 Content-Type: text/html etag: "23724049-4096 -" 2018-07-20T11:20:35.526Z "last-modified: Fri, 20 Jul 2018 11:20:35 GMT cache-control: max-age=3600 Date: Fri, 20 Jul 2018 11:21:02 GMT Connection: keep-alive

In the above example, we requested the document on localhost:8080/ and the local server responded successfully.

Here, instead of displaying the body of the response on the command line, we use the-I flag, which tells cURL that we are only interested in the response header. Further, we can instruct cURL to display more information, including the actual requests it executes, to better view the entire HTTP exchange. The option you need to use is-v (detailed):

$curl-I-v localhost:8080 * Rebuilt URL to: localhost:8080/ * Trying 127.0.0.1. * Connected to localhost (127.0.0.1) port 8080 (# 0) > HEAD / HTTP/1.1 > Host: localhost:8080 > User-Agent: curl/7.47.0 > Accept: * / * > < HTTP/1.1 200 OK HTTP/1.1 200 OK < server: ecstatic-2.2.1 server: ecstatic-2.2.1 < Content-Type: text/html Content-Type: text/html < etag: "23724049-4096 -" 2018-07-20T11: 20last-modified 35.526Z "" etag: "23724049-4096 -" 2018-07-20T11:20:35.526Z "< last-modified: Fri 20 Jul 2018 11:20:35 GMT last-modified: Fri, 20 Jul 2018 11:20:35 GMT < cache-control: max-age=3600 cache-control: max-age=3600 < Date: Fri, 20 Jul 2018 11:25:55 GMT Date: Fri, 20 Jul 2018 11:25:55 GMT < Connection: keep-alive Connection: keep-alive < * Connection # 0 to host localhost left intact

Mainstream browsers can get almost the same information through their DevTools.

As we can see, browsers are nothing more than well-designed HTTP clients. Of course, they add a lot of functionality (think of credential management, bookmarks, history, etc.), but the fact is, they were born as human HTTP clients. This is important because in most cases, you don't need to use a browser to test the security of a Web application, because you can simply view the response information through the curl command.

Enter the HTTP protocol

As we mentioned, the HTTP exchange and rendering phase is our main concern, as they provide a large number of attack vectors for malicious users.

That's all for "how browsers work in Web application security". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Development

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report