Security Layer:
SQL injection is an old security problem. Now no program should have such a problem. Its principle is very simple. In the past, most programs were in the database of the rectum, therefore, if you splice SQL statements without filtering parameters or generating SQL statements using parameters, malicious code entered on the page may be directly executed in the database. The harm of SQL injection is that the entire website has 1000 data points. If one of them has a vulnerability, the data on the entire site is actually dangerous, many developers focus on finance-related modules, but ignore news-related modules. If a database is used, a vulnerability of unimportant modules will affect the entire site. Some developers will pay attention to the get parameter verification but ignore the post parameter verification. This is also very prone to problems. Post is not as secure as it is not displayed on the URL, the content is submitted by the user input in the form. I want developers to be aware of the problem of SQL injection. The security factor of the whole site is measured by the weakest module of the whole site, just like the windows experience score is based on the lowest number, instead of the highest number. A front-end UI framework that can improve development efficiency by 500%!
This awareness is required for website development. The data submitted by any client is untrusted, including the get parameter, post parameter, and cookie content. All of these can be forged. the browser only provides an HTTP data submitter and an HTTP tag Parser for convenience. Hackers will not use the browser, the content in the HTTP header and body can be changed at will. Therefore, any data transmitted from the client must be strictly filtered and checked. If you have such an idea in mind, you can avoid many security problems. In addition, because cookies exist locally and are also transmitted from the client, security issues include the inability to trust the values stored in cookies, you cannot store sensitive data on the client to avoid leaking your privacy information. In a simple example, if we use the user name in the cookie to determine whether the user has logged on, it is unreasonable to use the user name in the clear code, if you change the username of an administrator, does the system assume that the Administrator has logged on to the system? The solution is to save an encrypted user name, but this is also insecure, because once the encryption method is not cracked, it will still generate a huge vulnerability, therefore, the user name and password can be stored in the cookie at the same time, that is to say, the website uses your user name and password to help you automatically log on within a period of time, instead of truly remembering your login, because we also need to ensure that the user's password will not be leaked (if there is a password on the user's machine, it is also not responsible for the user to save the password ), therefore, we need to store the encrypted user name and the hash password in the cookie. To ensure security, we can encrypt the two data and save it in the cookie. A front-end UI framework that can improve development efficiency by 500%!
My Architecture Experience series-backend architecture-Security Layer