Shulou(Shulou.com)05/31 Report--

Js files can get what information, I believe that many inexperienced people do not know what to do, so this paper summarizes the causes of the problem and solutions, through this article I hope you can solve this problem.

01 introduction

JavaScript has become one of the most common technologies in modern Web browser development. Some testers only audit the html source code and ignore the source code in the js file. Today we will talk about what information can be obtained from the audit js file.

02 detailed explanation

By auditing the information that can be obtained from the source code of the js file, I personally divide it into the following four categories: sensitive information, business logic, encryption algorithms, and Ajax requests.

Sensitive information

The most intuitive thing about auditing js files is that it is possible to get sensitive information such as account password and configuration.

HTML defines the page structure, CSS defines the decoration style, and JavaScript defines the front-end work, mainly listening for events to execute actions, such as logical judgment, or sending requests to the server, and so on. To perform these actions correctly, there are usually some simple configurations.

The most common configuration is to set the root path of the website, but it is often encountered to configure the account password directly in the js file; what is more, some developers define the SQL statement directly in the js file, and then send the front end to the server for execution. This not only leaks database information, but also increases the risk of SQL injection vulnerabilities.

This is one case of obtaining sensitive information, and the other is comments.

In order to better maintain and debug the code, we often see all kinds of comments in the source code. For example, in order to facilitate debugging, the account password is directly written in the Javascript code, and after debugging, the statement is commented out rather than deleted; sometimes the system changes, some new interfaces are introduced, and developers comment out the old interfaces and use the new interfaces, but the server does not turn off the old interfaces.

The above situation not only allows us to collect more target information, but also increases the attack surface of the system, can only say: these developers are really fucking talents.

Business logic

In addition to obtaining sensitive information, audit js files can also obtain some business logic of the Web system.

When it comes to business logic, front-end verification is involved. Some systems only do front-end verification, and as long as the response package meets the conditions, the next step will be performed. The server will not further verify whether there is a problem with the next request. We only need to modify the response package to bypass the detection.

For example, enter the wrong account password and respond to false and ask to re-enter the account password; we intercept the response package, change false to true, the front end detects true, thinks that the account password is correct, sends a request to jump to the system, but the server does not recheck whether there is a problem with the request, and responds the internal page of the system to the front end.

To bypass the front-end check, it is easy to guess how to modify it, such as 0ram 1 and true/false, but some systems may have more than a dozen response codes, or multiple response codes, and it will cost a lot of time if we have the patience to try them one by one.

For example, 0 is a user name error, 1 is a password error, 2 is a CAPTCHA error, and 9999 is a successful login. If we start from 0 and try one by one, we may not be able to try it out. Unless you first enter the correct account password to get the correct response code, then enter the wrong account password, and then replace the wrong response code with the correct response code obtained before, try to see if there is a problem with front-end verification.

The problem is: if it is a security service, customers may also provide account passwords, but attack and defense drills and holes are generally made from scratch, where there is no account password for you. The front-end business logic is usually implemented by js, and you can basically determine how to construct the response package through code audit to try to bypass the front-end validation. I just want to say: information collection is really important.

Encryption algorithm

The third kind of information that the audit code can get is the encryption algorithm. In today's environment, enterprises pay more and more attention to security, using a variety of protection means to improve the security factor of the system and increase the attack cost of attackers, among which there is encryption mechanism.

Maybe many testers grab the package and find that the parameter values are encrypted and just let it go. But this kind of front-end encryption can be found in js, either in the js of the html file or included in the js file.

Of course, we do not need to know what the encryption algorithm is like, directly enter the test plaintext Payload, the system will naturally use the encryption algorithm to output the corresponding encrypted data. This Payload will not work. Let's type in the next plaintext Payload to test it.

The time cost of the above methods will increase a lot, and sometimes the system will first detect whether the input data contains illegal characters, and no illegal characters will be encrypted and sent to the server. As long as we find the corresponding encryption algorithm, we can manually construct or write scripts to generate the encrypted data we want in batch, and then test whether there are loopholes in the system.

According to the current work experience, when it comes to encrypted parameters, the probability of vulnerabilities is much higher. Because after the front end is encrypted, the back end must be decrypted before it can be used. But in many cases, the security detection of the system is only when the request is sent, the detection is bypassed without detecting illegal characters during encryption, and the back-end can run rampant after decryption.

Ajax request

The information that can be obtained by auditing js files is also Ajax requests, which are also the worst-hit areas of vulnerabilities. However, the invocation of Ajax request is usually hidden, and the trigger condition of Ajax request is irregular, so it is easy to be omitted or ignored.

Ajax requests are usually triggered by individual events, and the triggers of these events often need to meet certain conditions. But very often, even if the event trigger condition is not met, we can still get the response from the server when we construct the data packet of the Ajax request and send it to the server.

The server has improper access control and does not detect whether the user sends Ajax requests through normal business logic, nor does it detect whether the user has permission to operate. The server believes that the requests sent by the client are correct, which brings back the nature of security: all input is insecure. And each Ajax request corresponds to an interface, which increases the attack surface, and each request may form an independent attack process.

To take a real case: to change the password, you have to pass the SMS verification code before you can change the new password. Only the administrator can change the password, and the Ajax request to change the password is called by the password modification function, which is not available to ordinary users. (for some reason, there is no screenshot, so have a whim.)

The developer believes that all users will trigger the request step by step according to the business logic of the system, click send CAPTCHA first, then fill in the CAPTCHA for verification, jump to the page where the password is changed after verification, enter the new password, and finally modify it successfully. And only the administrator has this feature page.

However, through the code audit, the Ajax request to change the password is found directly in the js file, and the request parameter is only the new password. Now that we have found the request to change the password, we can skip the previous series of checksum requests and just construct the request to change the password.

And this Ajax request is written in the js file, the system will not call different js files because of different user permissions, so ordinary users can also find the corresponding js code, there is no administrator to say.

After reading the above, have you mastered the method of what information can be obtained from js files? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

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.