Website security check list

No matter what the website is, security should be taken into consideration first, and the security of the website should be very important. In the past, when I was doing something on my own, I always thought that I could do this project. But now I think it is a very big mistake. For a very fragile system, there is no need to make it out of a system that cannot tolerate any errors. What can be done. A website should first tolerate users' unintentional mistakes (or errors), then prevent malicious attacks, and handle system errors, prevent unnecessary information from being exposed, and then process the wrong URL address (this does not exist URL address, the parameters passed in the URL are incorrect, and the access permission is insufficient ). Next we will briefly list the threats to your website and how to prevent them. 1. Cross-site scripting (XSS): Send the structure of data provided by unchecked users to the browser. The problem with the data provided by the user is that it completely exceeds your control, and it is very easy to forge the HTTP referrer value and hide the value in the form field. Therefore, when processing the form, carefully verify the data and use the "deny all, allow a small number" policy, that is, the so-called "Blacklist" and "White List. Blacklist is to deny some characters that are considered dangerous and then allow all the remaining characters. whitelist is to accept only characters that I acknowledge, and deny all other characters. The whitelist is better than the blacklist, because we always miss something more or less when considering the blacklist, moreover, we cannot imagine how malicious users will attack the system. For a whitelist, for example, registering a user name, I only allow the user name to contain English characters and numbers, deny all others to prevent malicious user names. In addition, if HTML tags are allowed when posting a blog or forum post, the layout of the entire page may be damaged. 2. injection attacks: SQL injection may be the most common website attacks we have talked about. The defense method is simple, that is, to escape all the data received from the user. 3. malicious file execution: allowing attackers to execute any scripts that do not reside on the server to delete the files will make it possible for attackers to execute arbitrary code on the server. The consequences of this attack include imperceptible data extraction from applications or full server leaks. Malicious file execution attacks apply to any system with a file name (in whole or in part) or a file from the user. 4. unsafe direct object reference: one form is to modify the value of parameters in the URL address, and you want to obtain other information that does not belong to you or does not exist; in addition, it is implemented by referencing files in the script. What does the second case mean? That is to say, we include the corresponding file through the passed URL parameter, but if the passed parameter is malicious, it will contain unexpected files and be attacked. Therefore, we should also check the parameters passed by the URL address. Remember-the information submitted by the user is not limited to URL and form parameters! Check to ensure that the unchecked cookie value, HTTP request header, and HTTP content value are not used in the script. 5. Cross-Site Request Forgery (CSRF): This type of attack forces victims to perform behavior on another site without permission. To protect the automatic submission of forms, you can create a random token that is generated every time you browse the form. It is placed in a session variable and is located in a hidden field in the form. When a form is submitted, the script checks the matching between the token and the value in the session variable, only when the form is loaded from the real site is valid-if the request comes from somewhere else, the page will be invalid. 6. Information Leakage and improper handling: When an error occurs in the script, information about the attacker swimming may be leaked in the error message. For example: Warning: mysql_connect (): Access denied for user 'sitepoint @ db.sitepoint.com '(usering password: YES) in var/www/index. php on line 12. This information provides potential attackers with the name, name, and username of the database server. Similarly, an error message that outputs incorrect SQL statements gives attackers a small opportunity to observe the structure of your database. Therefore, after the website is officially launched, we should disable the error output to the browser and record the error information to the log file. 7. Imperfect authentication and session calendars: imperfect authentication and session management are closely related to inadequate account and session data protection. If a session is hijacked before a user logs on, the attacker only needs to wait for the user to log on to obtain full control of the personal account. PHP provides the session_regenerate_id function, which should be used before any modification at the privileged level. When a session ID is changed, it maintains session data. Therefore, after a user logs on, the user fires a new session ID, and any session before being hijacked by the attacker becomes invalid. You should also stick to PHP's skills and cookie management functions-do not write your own scripts or use third-party scripts. Measures can also be taken to ensure that session data is completely destroyed by the site logout function, and the user is automatically logged out after the user is not active for a period of time. We recommend that you do not send a password in plain text in email or display the password on the screen. 8. Insecure Password Storage: First, do not change your code in terms of encryption technology; second, do not change your code. Remember that someone else can decrypt the data by using an algorithm that is intended to be decoded. Strictly speaking, MD5 and SHA are not encryption algorithms (that is, an MD5 string cannot be decrypted to obtain its original data). They are information digest algorithms. But if you don't need a value on the interface, use the SHA-256, which is available in the hash function in PHP5.1.2. If this option is not optional, you can select MD5 with a lower security level and use it through the md5 function. 9. Insecure communication: it is only a bad habit to use Plaintext to send sensitive data. For example, if you are asking a user to log on or provide credit card details, or the application causes your server to have a session with another server, you should use SSL to ensure communication security. 10. Failed to restrict URL access: Most applications restrict their available links based on the user's privilege level. However, the user authorization system of many applications stops working at that point, and the access permissions will be chaotic. Make sure that your users can only see the links they can use, but also ensure that each page should check the user's privilege level before allowing users to continue to use. In fact, there are many other types of website attacks. The above just summarizes several common types.