Github Blog: Is your Web system really secure?

A thousand mile dam is broken by a swarm of ants.

In Web systems, a small bug can often lead to serious consequences. Therefore, Web security is a key consideration in the design, development, operation and maintenance of every system.

Nowadays, many Defense measures adopted by Web systems tend to be basic and simple. They only defend against common security vulnerabilities, such as:

  • Csrf
  • XSS
  • Sql injection

And so on. These basic defense measures are necessary and inexpensive to implement, but they are only the foundation of system security defense. It’s dangerous for many developers to think that doing this is enough for most situations. 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. Here is a list of some common business logic bugs that we’ve encountered in the past.

Session credential management is chaotic

We all know that HTTP itself is stateless. In order to enable browsers and servers to know each other’s identity and trust each other, most Web systems are implemented with the use of “tokens”, which are generated after users log in and become invalid after users log out or over a period of time. In other words, if the request carries the corresponding token, the server can obtain the token and perform the corresponding verification. If the verification passes, the request will be trusted and the relevant business logic will be executed. If the request does not carry, an illegal or expired token will be considered illegal. This may seem innocuous, but the actual implementation may have holes in it.

Let’s look at two examples:

1. When writing the logic for users to click the exit button, Front-end developer Xiao Ming simply cleared the token value in cookie or localstorage (the token is generally stored in these two places), and did not send a request to the background to make the token expire in the business. Then the validity of the token essentially goes against the user’s intention, and there is a very big risk. When the user voluntarily exits, the token is still valid. If the token is obtained and recorded by others in some way, it can perfectly replay the operations performed by the user, such as changing user information, placing an order, etc.

2. In the above example, we mentioned that tokens are set to expire. Reasonable expiration time can effectively reduce risks. However, in the configuration of setting token expiration, the developer may have confused his hands, typed an extra digit, or misunderstood the unit, and used MS value in the S-level unit, then the expiration time would be set very long. It is very dangerous for users who do not like to actively exit or hang the page for a long time after logging in. Tokens are valid even if the user does not use them for a long time, and can do a lot of bad things if someone else gets hold of them.

Check the failure

File uploading is a common function in Web applications, such as uploading profile pictures and uploading files to Web disks. Malicious users may upload Trojan horses, viruses, and malicious scripts. When these files are executed on the server, serious consequences may occur. This kind of attack is cheap and easy to be exploited by attackers. The more file types that are allowed to be uploaded, the greater the vulnerability. When a malicious program is successfully uploaded, it can be downloaded by the user, executed on the user’s computer and poisoned. It is also possible to execute malicious programs on the server, causing the server to be controlled, and then the server to crash, data loss.

Under normal circumstances, the program will judge the file type and only allow files that we think are valid to be uploaded to the server. However, in some Web applications, this judgment is only done on the front end, not the back end. This provides an opportunity for attackers to easily string requests and upload illegal files.

The right thing to do is to defend against restrictions such as file extension judgment, MIME detection, and uploading file size limits on the back end. In addition, files can be saved on a server that is isolated from the business to prevent malicious files from attacking the business server and making the service unavailable.

Enumeration data

In the login system, most systems will determine whether the user exists when the user logs in, and then give a prompt “the mobile phone number is not registered”. If this logic is done with a separate interface, there is a risk of violent enumeration. Through this interface, the attacker can use the phone number database to enumerate requests and identify which phone numbers have been registered in the system, which brings opportunities for brute force cracking passwords.

For this problem, the recommendation is to put the judgment into the interface for login authentication and not return an explicit prompt. You’ll see a well-done website that says, “This phone number is unregistered or your password is incorrect.” It’s less of a user experience, but it’s also more secure.

Data write replay

Take the Posting of a forum for example, use the packet capture tool to capture the request process of the forum Posting, and replay the process through the tool, it will find that the list of posts appeared two same posts, this is the replay attack. If you speed up the replay frequency, you will not only generate a lot of garbage data in the system, but also put a lot of pressure on the business database because of frequent writes.

You are advised to add a request frequency limit to the request frequency limit. For example, you can determine the timestamps of two requests and set them above a certain time value to be valid.

Access holes

Permission verification is a basic function of Web systems, such as a corporate organizational structure management system, which provides the function of modifying department names and department managers. The addition of permission verification is a good way to prevent any user from using these functions to modify information that he does not have permission. Permissions verification must be implemented in such systems, but is it actually implemented correctly?

Assume that A user can change the department name only when the user has the supermanagement permission and belongs to Department A. Often in the actual code implementation, the developer only decides whether the user is supermanaged, not whether the user belongs to the department. In this case, we can modify the name of Department A by using the super account of Department B, which is equivalent to modifying the name of department A beyond our authority, which is obviously not the result we expect. Even if the super management user of department B cannot find the entry for modifying the department name of Department A on the interface, the super management user can retrieve the parameters to modify the department name.

In addition to overstepping their authority to modify, of course, can also overstepping their authority to view. We certainly don’t expect A supersupervisor in Department A to see department information in Department B, do we?

It is recommended that your system strictly check and restrict user access to roles.

Safety is no small matter, as said at the beginning, any vulnerability is likely to bring a devastating blow, I hope we can pay attention to. Focus not only on business design, but also on code review to avoid low-level bugs due to implementation.

These are just a few of the many security vulnerabilities. For more serious Web application security risks, check out OWASP Top10 security Issues 2017. www.owasp.org.cn/owasp-proje…