PHP programming Security Guide

From: http://www.codingforums.com/showthread.php? T = 176717

PHP programming Security Guide
1. General
1) lamp system security settings
2) PHP. ini Security Settings
3) use the MVC Framework

2. Data Transmission
1) In $ _ get's $ _ post, $ _ cookie, and $ _ Request, sanitize and verify all the data contained in the data programmatically.
2) SQL Injection
Definition: code injection technology. A security vulnerability occurs at the database layer of an application. This vulnerability exists. When an SQL statement or user input is not strong in an incorrect character string escape character, filtering is performed unexpectedly.
Prevention: mysql_real_escape_string ($ string)
 
3) cross-site scripting (XSS)
Definition: a security vulnerability. It is usually used by other users of a Web application to browse the Web page. It allows malicious web users to inject code. This example includes client scripts (JavaScript.
Prevention: htmlentities (strip_tags ($ string ))
 
3. browser requests
1) Cross-Site Request Forgery (csrf)
Definition: Attacks work by Adding links or scripts to pages authorized to users. For example, Bob, a website user, may be browsing a chat forum, and Alice, another user, is also in the Forum. The latter has just published an image message with a bank link of Bob. Assume that Alice has compiled a form submission link on Bob's bank site, and uses this link as an Image Tag. If Bob's bank saves his authorization information in the cookie and the cookie does not expire, Bob will submit the withdrawal form and his cookie when trying to load the image, in this way, the transaction is authorized without Bob's consent.
Prevention: generate a unique "token", usually at the beginning of a browser session. The token is used in all post and GET requests. Following the post/get action, check the existing session token and confirm that the mail token/get is the same as the token stored in the session. (Like the MVC Framework of CakePHP, this makes it easier to unify the entire application .)

4. Sessions
1) Destroys session data when a session is killed.
After a session is completed ("deregistered"), destroy its data, instead of simply clearing the cookie. Otherwise, malicious users can restore the cookie and use the session again. You can leave all indexes in $ _ Session empty.
2) store the webroot file of the session on the website or the webroot file stored in the database as a file
The default path for saving sessions on the server can be hijacked, especially in a shared host environment.

5. Password
1) Use strong passwords
Password that requires numbers, symbols, upper and lower case letters
The password must be 12 to 14 characters long.
2) Encryption
At least sha1 () hash encryption (MD5 () is not used). The Hash () function provides some additional hash options, including sha256. Add a "Specific Application" for encryption

6. General PHP. ini configuration
1) Disable register_globals
Prevention: register_globals = off
2) Disable magic quotes
Prevention: magic_quotes_gpc = off
3) Disable Error Reporting
Prevention: display_errors = off
4) enable error logging and save log file to a directory above web root
Prevention: log_errors = on;
Ignore_repeated_errors = on;
Html_errors = off;
Error_log =/path/above/webroot/logs/php_error_log
5) Save the session data to the webroot directory.
Prevention: Session. save_path =/path/above/webroot/sessions

7. The. htaccess file downloaded by webroot
1) Disable directory listings site-wide
Prevention: Options-Indexes

8. Important/sensitive files
1) prevent unauthorized access/download
This includes website management/members and some website/database configuration files.
2) use a script file as an intermediary and as an attachment
3) constantly update the password of your script (WordPress, phpMyAdmin, etc.
4) when you are in use, you can use phpMyAdmin to allow access, which can prevent other people from damaging your use of the "zero-day vulnerability ".
Zero-day (zero-day) is also a zero-time attack. It is a security vulnerability that is immediately exploited after being discovered. In general, security patches and flaws are exposed within the same day, and related malicious programs appear. Such attacks are often sudden and destructive.
 
9. File Upload
1) Verify $ _ files before data operations to determine whether the file is already in $ _ files.
2) Please note that the provided MIME type may be spoofed or lead to its incorrect method.
3) All files uploaded by users should be moved to a directory above the root directory of the website.
4) do not execute user-uploaded files or include files uploaded by users, such as include require.
5) Try not to set the script type to application/octet-stream, "" Application/unknown, "or" plain/text"

10. Others
"Utility" files/programs created and used by website developers under webroot. If they are not intended to be accessed and used by website users, therefore, all of them should be deleted before they are put on the Internet to reduce the security risks of the website.