Related learning recommendations: javascript
Your Web Is the system really safe?
In the Web system, a small vulnerability can often cause extremely serious consequences. Therefore, Web security is an issue that every system must consider during the design, development, operation and maintenance.
Nowadays, the defensive measures taken by many Web systems are biased toward basic and simple, often only targeting common security vulnerabilities, such as:
and so on. These basic defensive measures are necessary and are not expensive to implement, but they are only the basic part of system security defense. Many developers think that doing these things is enough to cope with most situations. This idea is very dangerous. In fact, in addition to these basic and standardized vulnerabilities, the business logic of each business system itself is also likely to become the target of hacker attacks. Once caught and broken, the consequences will be very serious. Below we will list some common business logic loopholes. These loopholes have also been encountered when developing systems before. I hope they can inspire everyone.
We all know that HTTP itself is stateless. In order to allow the browser and server to know each other's identities and trust each other, most web systems use "tokens" This is implemented using agreed credentials. The token will be generated after the user logs in, and will expire when the user actively logs out or after a period of time. That is to say, if the request brings the corresponding token, then the server can get the token and perform corresponding verification. If the verification passes, it will trust the request and execute the relevant business logic. If it does not bring it, it will bring an illegal or expired one. is considered illegal. This doesn't seem to be a problem, but there may be hidden loopholes in the actual implementation.
Let’s look at two examples:
1. When front-end developer Xiao Ming wrote the logic for the user to click the exit button, he simply cleared the token value in the cookie or localstorage (the token is generally stored in These two places), and did not initiate a request to the backend to let the token expire in the business. Then the validity of this token essentially goes against the user's intention, and there is a very high risk at this time. When the user spontaneously exits, the token is still valid. If the token is obtained and recorded by others in some way, he can perfectly play back the operations performed by the user, such as changing user information, placing orders, etc.
2. In the above example, we mentioned that the token needs to be set to expire. A reasonable expiration time can effectively reduce risks. But the backend development guy may be dazzled and his hands are shaking when setting the token expiration configuration, and enter an extra digit, or he may misunderstand the unit and use MS-level values for S-level units, then the expiration time will be set The order is very long. It is very dangerous for users who do not like to actively log out after logging in or who stay on the page for a long time. The token is still valid even if the user does not use it for a long time. If someone else gets the token, they can do a lot of bad things.
File uploading should be a common function in web applications, such as uploading avatars, uploading files to network disks, etc. Malicious users may upload Trojans, viruses, malicious scripts and other files when uploading. If such files are executed on the server, they will have serious consequences. This attack method is relatively low-cost and relatively easy to be exploited by attackers. The more file types that are allowed to be uploaded, the greater the potential for attack. When the malicious program is successfully uploaded, it may be downloaded by the user and poisoned after being executed on the user's computer. Malicious programs may also be executed on the server, causing the server to be controlled, resulting in server paralysis and data loss.
Under normal circumstances, the program will judge the file type and only allow files that we think are legal to be uploaded to the server. However, in some web programs, this judgment is only made on the front end and not on the back end. This creates opportunities for attackers, who can easily modify requests to upload illegal files.
The correct approach should be for the backend to perform file extension judgment, MIME detection, and limit upload file size and other restrictions to defend against it. In addition, files can be saved on a server isolated from the business to prevent malicious files from attacking the business server and causing service unavailability.
When logging in to the system, most systems will determine whether the user exists when the user logs in, and then give a prompt "This mobile phone number is not registered". If this logic is done using a separate interface, there is a risk of brute force enumeration. An attacker can use this interface to use the mobile phone number library to perform request enumeration and identify which mobile phone numbers have been registered in the system, which will provide opportunities for brute force password cracking in the next step.
Regarding this problem, it is recommended to put this judgment in the login verification interface and not return a clear prompt. You will see that on well-made websites, it will usually prompt "The mobile phone number is not registered or the password is wrong." Although this compromises the user experience, it is also more secure.
Take a forum post as an example, use a packet capture tool to capture the request process of the forum post, and replay the process through the tool, you will find that the post list appears Two identical posts, this is a replay attack. If the replay frequency is accelerated, not only will a lot of junk data be generated in the system, but frequent writing will also put huge pressure on the business database.
For such requests with replay risks, it is recommended to add a request frequency limit. For example, you can determine the timestamps of two requests and set them to be valid if they are greater than a certain time value.
Permission verification is a basic function of the Web system, such as a company organizational structure management system, which provides the function of modifying department names and department managers. Adding permission verification can effectively prevent any user from modifying information that he does not have permission to use through these functions. Permission verification will definitely be implemented in such systems, but is it actually implemented correctly?
Suppose we stipulate that a user in the system needs to meet two conditions: having super management authority and belonging to department A in order to modify the department name. Often in actual code implementation, developers only determine whether the user is a super administrator, but do not determine whether the user belongs to the department. In this case, we can use the super management account of department B to modify the name of department A, which is equivalent to modifying it beyond the authority. This is obviously not the result we expect. Even if the super-administrator user of Department B cannot find the entrance to modify the department name of Department A on the interface, they can still modify the parameters by grabbing the request.
In addition to unauthorized modification, of course, you can also view it beyond your authority. We certainly don’t expect the super manager of department A to be able to see the department information of department B, right?
It is recommended that your system strictly checks and restricts user access rights to roles.
Security is no small matter. As mentioned at the beginning, any vulnerability may bring devastating blows. I hope everyone will pay attention to it. Not only should we pay attention to business design, but we should also pay attention to code review to avoid low-level vulnerabilities caused by implementation.
The above are just a few of the many security vulnerabilities. For more serious web application security risks, please refer to the Top 10 security issues released in OWASP Top 10 2017. www.owasp.org.cn/owasp-proje…
The above is the detailed content of Using JS detection, is your web system really safe?. For more information, please follow other related articles on the PHP Chinese website!
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
