Daily chat

Hello, everyone! It’s raining in Shanghai today. I like rainy days very much, listening to music, doing everything is very happy. There is only one thing I hate about rainy days, and that is the feeling of being wet.

I’ve been working from home for three weeks now. How can I describe this feeling? At the beginning, it was ok. I thought it could be controlled for a week at most. And now it’s a long story. I’m sure I don’t need to describe it too much.

So many days at home, almost no downstairs, the whole person is very boring. There’s nowhere to go downstairs, so I can only walk around the neighborhood. Other places are afraid to go, because now in Shanghai, there could be people walking around with no symptoms.

In the last week, prices in Shanghai have also risen. Vegetable shops and fruit shops on the doorstep have almost doubled their prices. And the vegetables and fruits, they’re not so fresh anymore.

So, or hope it as soon as possible in the past, good look forward to the May Day.

Cut to the chase: What is Webfuzz

Well, today I would like to introduce a tool written at home during the recent outbreak: Webfuzz.

You might be a little confused about this what is it? And what is it for?

Let’s take a quick look at two images to get a feel for it:

1. Request intercepts directly, tampering with return:

2. Page on the resource file, destroyed:

3. The service is tampered with and data is lost:

4. CSS styles are broken:

Ok, after reading these, I believe you know some of the things webfuzz does.

So what is Webfuzz?

Speaking of webfuzz, what exactly does it do? A background summary needs to be inserted here:

Background:

Some time ago, I made a small business requirement about the player.

About the player, if you know, you may know that the playback resources pulled by the player are in the form of streams. The player kernel will decode, instance and play the video stream according to a set of decoding contracts agreed with the video cloud.

Then, there is a question about whether the video stream can be properly parsed, whether the pull stream will be destroyed in the process of sending, whether the stream itself will have jitter due to network conditions, and so on.

So what happens to the player when that happens? Whether the instantiation fails and whether the playing page is affected.

I encountered these problems, so I tried to do some work. Exception handling of video stream.

So Webfuzz is also removed from this scenario, to interfere with the destruction of file resources in the page, service applications. To achieve a means of testing on the Web, and then to verify the impact of these breaches on the Web UI.

In simple terms, it is a page dependent on all/part of the resources, or application services, unknown damage, so that the occurrence of alarms, errors and other cases of the page UI will be a state.

Analysis of webfuzz system

That said, the description of how Webfuzz is derived and what it does is not complete enough. The above is to destroy the flow, to achieve the player pull flow parsing on the exception. So this is just for the player.

One caveat: Not for the entire Web, not all pages contain players. So we need to do a general treatment. And get rid of the player as a concrete point.

For the whole Web, it includes: JS, CSS, IMG, media, XHR and so on. So for fuzz, what you need to do is fuzz your page, and actually these points need to be designed in.

And any type of file, it’s a request, and if it’s a request, it contains the request header, the request body, the return body. You just need to distinguish between these different types.

In the case of fuzz, it can fuzz out any request header, parameter, or response body. So the implementation logic is consistent,

Resource files, however, are handled slightly differently because they are almost always read directly because resources like these are already configured. So your fuzz is only going to affect the ability of these resources to read properly.

There are some differences for specific XHR requests. Because this layer will be the implementation of the concrete business logic, regardless of the request method, you need to consider the request parameters, and the response body. Depending on your needs, fuzz your pass parameter or return it.

Therefore, for resource file types, you only need to determine their req.resourceType(), and then determine whether all or part of the type fuzz is required according to the application scenario. Only fuzz blocks can be used.

Fuzz for XHR

Here is a detailed description of the FUzz of XHR, the fuzz of this side is the core of the system design. Here’s a picture:

This diagram is designed as a fuzz for specific requests, including your request header, your request body, and even your return. The meaning of fuzz here is more important than anything else.

You can go back to the first few images and look at the third one, which is the application service of the business logic, which is fuzz removed, affecting the entire UI display of the page.

About the design of the system

Ok, above told you so much, here to tell you about the specific design of the Webfuzz system.

Take a look:

An important part of the system is fuzz service. Because what we do is fuzz. So let’s talk more about fuzz services.

At the heart of the Fuzz service is a tool: puppeteer. More or less, you probably know this. Why is this tool central here? Because this is an important part of the design. Take a look at the official code:

Page. On (' request, the request = > {/ / = = = = = = = directly to tamper with the return to the body. Respond ({status: 404, contentType: 'text/plain', body: 'Not Found! '}); Req. continue({// // url: newURL, // // method: "", // // postData: {}, // headers: "{}", // }); });Copy the code

As you can see from the official code above, it can intercept requests. That is, whatever request you have coming in, as long as you have your fuzz configuration information, you can use this to custom intercept your request and tamper with it so that you can perform the relevant operation through breakpoints like this.

So intercept processing, how to judge whether it is successful? You also need a listener function here. If any of your fuzz requests come in and I intercept them, let me know if I handled them well. So there’s another core that’s needed here, and again, here’s the official code:

page.on("response", async (res) => { if (res.url() === nowurl) { // console.log(res.url()); // Display the URL of the response, string // console.log(res.headers()); // Display the header object for the response // console.log(res.status()); // Displays the status code of the response, numeric // console.log(res.ok()); // Displays whether the response was successful, Boolean // console.log(res.request()); // Display the request object res.text().then((body) => {console.log("body: ", body); }); }});Copy the code

That is, any interception you make, whether or not it hits the real service, will listen through this response and tell your fuzz service whether the execution succeeds or fuzz is complete.

Another point is that screenshots need to be performed according to the return and callback of this response for comparison and matching.

The system shows

In addition to customizing the fuzz service, the system also designed some intelligent fuzz scenes, these intelligent matching is a general design, to intelligent matching you need to fuzz page some requests, and do fuzz action, can be selected according to their actual needs:

Ok, about Webfuzz, temporarily said here, this share, is not comprehensive and detailed, only contains the general implementation, as well as part of the core design, later opportunity, will be open source, but need to wait for approval.

The words of share

The ocean of life is not like the west Lake of blue ripples, with the flow of time, it is sometimes calm as a mirror, sometimes splashing waves, sometimes the waves… People often become stronger after they have been tested by strong winds and waves.

Well, that’s all for today’s sharing. I hope this epidemic will end soon. Bye bye ~