The mainstream browser developer tools (F12) are superior and inferior in security testing

<!--the mainstream browsers referred to in this article are Chrome, Firefox, ie-->

<!--

0x01 scenario Hypothesis

0x02 Chrome

0x03 Firefox

0x04 IE

0x05 Conclusion

-

0x01 scenario Hypothesis

Three browser developer tool use and page debugging skills, this article does not describe, only said in the security test encountered the situation.

Consider the following scenario: To do a security test for a Web application now, the client/server uses HTTPS bidirectional authentication, and the client uses a tool of the U-Shield.

According to the above scenario: the lack of any link to the certificate, the communication cannot occur, the client private key is written in the hardware, you can not export the certificate by using the HTTP proxy to grab packets, change packets.

Then: For data that cannot be controlled without changing the package (such as when the previous page reads and sends the account to the server), when the proxy server cannot be used, only the browser is available for us to use.

In the three big browsers, IE has the fewest extensions, Chrome and Firefox have more extensions/plugins, but are they really useful? We can continue testing without relying on plugins?

Many times, we use a variety of tools to improve testing efficiency, in extreme cases a browser is enough, but not all browsers can.

0x02 Chrome

No matter surfing the Internet or debug page, I believe Chrome is the first choice for many people, Chrome's extension app/plugin is also a lot of names, now look at the actual test of chrome performance.

Chrome has a live HTTP headers and other extensions can easily monitor traffic, but it can only see can not be changed. There are also extensions that can modify the request headers, such as user-agent, cookies.

If the extension works, you don't necessarily need to use devtool. The real situation is that the extension cannot change the requested post data, only by F12.

As for why it can't be changed, it can only be said that Google has not developed API. Using Devtool to modify HTTP Form data is no problem, but for the data sent through JS, asynchronous request, I can only say that it is powerless.

You can change the data in the console, by means of value overrides, but the actual value sent does not change. As a result, Chrome's developer tools, while useful, are limited.

Take a look at the developer tools:

　　

From: Using the Angular.js framework, XMLHttpRequest asynchronously sends the data.

Recent usage feel: The Chrome developer tool is best compared to the other two, which makes it easy to break breakpoints on Dom, XHR, and event.

Results: For the code, look at the traffic, set breakpoints, Chrome Devtool is the best choice, just can't tamper with the data sent by JS, not to the desired effect.

Reference: Debugging asynchronous JavaScript with Chrome DevTools etc.

　　

0x03 Firefox

The Firefox load page is really slow in comparison, and often crash or stuck during testing for various reasons, but it helped me to successfully modify the data.

First look at a picture:

　　

Firefox can also distinguish between XHR data, right-click request can set breakpoints on Xxx.json, although different from the beginning of chrome can be on all xhr breakpoints, compared to the following article IE is a lot better.

Actual Grab bag look:

　　

Setting a breakpoint on a script, setting a breakpoint on an asynchronous request, and successfully catching the data I want, the best thing is that I can directly modify the value of the variable to make it effective.

When the data processing changes, it is possible to feel clearly cut off the request, but the actual change after the situation is invalid:

　　

This can only indicate the location of the wrong breakpoint, so there will be one aspect of the script still stuck on the breakpoint, on the other hand, the View network panel found that has returned the OK.

What if I can't find the correct breakpoint location? Look closely at the figure above and the answer will be revealed.

　　

0x04 IE

In terms of personal use, ie is often limbo, but does not mean that it is poor (IE11 or good), personal preferences.

And some scenarios such as net silver Landing, due to Chrome, Firefox version update too fast, can only use IE.

　　

IE is not easy to use, above a picture can be seen. For the processing of ordinary requests, IE and Chrome and Firefox are not very different, nothing more than the use of customary differences.

However, for processing asynchronous requests, IE is obviously at a disadvantage (use). IE also can't change xhr data, use tamper IE tool, can only intercept URL, and very inconvenient.

　　

0x05 Conclusion

In the case of the Web app supporting the above three browsers, the actual testing of Firefox developer tools to meet the needs of security testing, chrome and IE F12 can not be changed XHR post data (Tamperdata also cannot change).

From the convenience of use and the effect of the interface, Chrome>firefox>ie.

Integrated in all aspects (including others not mentioned in this article), Firefox is better than Chrome,ie at the bottom of the security test.

Attached: The above content and the opinion for oneself in the safety test process obtained, does not guarantee the opinion is completely correct, if chrome/ie has other techniques to change the data or to feel to the IE's comment injustice, please correct me!

　　

The mainstream browser developer tools (F12) are superior and inferior in security testing