Talking about PHP security protection-Web attacks and security protection web

Talking about PHP security protection-Web attacks and security protection web

SQL Injection attacks)

Attackers can insert SQL commands into the input field of Web forms or the string requested by the page to trick the server into executing malicious SQL commands. In some forms, the content entered by users is directly used to construct (or affect) dynamic SQL commands or as input parameters of stored procedures. Such forms are particularly vulnerable to SQL injection attacks.

Common SQL injection attacks include:

1. A Web application has a logon page that controls whether the user has the right to access the application. It requires the user to enter a name and password;

2. The content entered on the logon page will be directly used to construct dynamic SQL commands or directly used as parameters of stored procedures;

For example:

$query = 'SELECT * from Users WHERE login = ' . $username . ' AND password = ' . $password;

3. The attacker enters 'or '1' = '1' In the username and password input boxes;

4. after the content entered by the user is submitted to the server, the server runs the code above to construct an SQL command to query the user. However, because the content entered by the attacker is very special, the final SQL command is changed:

SELECT * from Users WHERE login = '' or '1'='1' AND password = '' or '1'='1'；

5. The server executes the query or storage process and compares the user-entered identity information with the identity information saved on the server;

6. Because SQL commands have been modified by injection attacks and cannot actually authenticate user identities, the system will incorrectly authorize attackers.

If the attacker knows that the application will directly use the content entered in the form for identity authentication queries, he will try to input some special SQL strings to tamper with the query and change its original function, the spoofing system grants access permissions.

The system environment is different, and attackers may cause different damages, which is mainly determined by the security permissions of the application to access the database. If the user's account has administrator or other advanced permissions, attackers may perform various operations on the database table, including adding, deleting, or updating data, the table may even be deleted directly.

Defense methods:

1. Check the variable data type and format

2. filter special characters

3. bind variables and use precompiled statements.

Cross-Site Scripting (XSS)

Attackers inject malicious code into the webpage, and other users execute the code when loading the webpage. Attackers may obtain higher permissions, such as performing some operations), private webpage content, sessions, cookies, and other content. These malicious codes are usually JavaScript, HTML, and other client scripting languages.
For example:

<? Phpecho "Welcome,". $ _ GET ['name'];

If you input a script<script>[code]</script>The script will also be executed. Using this URL will execute the JavaScript alert function to bring up a dialog box:http://localhost/test.php?name=<script>alert(123456)</script>

Common attack methods include:

Use cookies to obtain sensitive information;

Use iframe, frame, XMLHttpRequest, or Flash to perform some management actions as (attacked) users, or perform some common operations, such as sending Weibo posts, adding friends, and sending private messages;

Requests for operations that are not allowed at ordinary times, such as improper voting activities, as the attacked domain is subject to the trust of other domains;

XSS can attack some small websites on pages with high traffic volumes to achieve DDoS attacks.

Defense method: Use the htmlspecialchars function to convert special characters into HTML encoding and filter output variables.

Cross-Site Request Forgery (CSRF)

The attacker spoofs the HTTP request of the target user and then sends the request to a website with the CSRF vulnerability. After the website executes the request, it triggers a Cross-Site Request Forgery attack. The attacker uses a concealed HTTP connection to allow the target user to click the link without looking at it. Because the user clicks the link, the target user has the legal permissions, therefore, the target user can execute specific HTTP links on the website to achieve attackers.

It is different from the XSS attack method. XSS uses the vulnerability to affect users on the site. The attack targets users on the same site, however, CSRF uses disguise as a victim user to send malicious requests to affect the interests of the victim users in the Web system.

For example:

When purchasing a product on a shopping website, use http://www.shop.com/buy.php? Item = watch & num = 100: The item parameter determines the item to be purchased, and the num parameter determines the quantity to be purchased. If an attacker sends a link to the target user in a hidden manner
If the target user accidentally accesses the instance, the number of purchased instances becomes 100.

Defense methods:

1. Check the webpage Source

2. Check the built-in hidden variables.

3. Use POST instead of GET or $ _ REQUEST to process variables.

Session Fixation)

The core point of this attack method is to allow legal users to use the session id preset by the attacker to access the attacked application. Once the user's session ID is fixed, attackers can use this session id to impersonate users to access the application.

For example:

1. The attacker accesses the website http: // www.bank.com and obtains his own session id, for example, SID = 123;

2. The attacker sends a link to the target user and carries his session id, for example, http: // www.bank.com /? SID = 123;

3. The target user clicks http: // www.bank.com /? SID = 123. As usual, enter your username and password to log on to the website;

4. Because the session id of the server remains unchanged, attackers can click http: // www.bank.com /? If SID = 123, the user has the identity of the target user and can do whatever he wants.

Defense methods:

1. Regularly change the session id

Session_regenerate_id (TRUE); // Delete the old session file. A new session id is generated each time. The default value is false. The old session is retained.

2. Change the session name.

The default session name is PHPSESSID. This variable is stored in the cookie. If attackers do not capture packets for analysis, they cannot guess the name and block some attacks.

session_name("mysessionid");

3. Disable transparent session id

Transparent session id indicates that when the http request in the browser does not use the cookie to specify the session id, sessioin id uses the link to transmit

int_set("session.use_trans_sid", 0);

4. Check the session id only from the cookie

Int_set ("session. use_cookies", 1); // indicates using cookies to store session idint_set ("session. use_only_cookies", 1); // indicates using cookies only to store session IDs

5. Use URL to pass hidden Parameters

$ Sid = md5 (uniqid (rand (), TRUE); $ _ SESSION ["sid"] = $ sid; // although attackers can obtain session data, however, you cannot know the value of $ sid. You only need to check the value of sid to check whether the current page is called by the web program.

Session Hijacking)

Session hijacking means attackers use various methods to obtain the session id of the target user. Once the session id is obtained, attackers can use the identity of the target user to log on to the website and obtain the operation permissions of the target user.

Attackers can obtain the session id of the target user:

1. brute-force cracking: try various session IDs until they are cracked;

2. calculation: if the session id is generated in a non-random manner, it may be calculated;

3. Theft: obtained through network interception and xss attacks.

Defense methods:

1. Regularly change the session id

2. Change the session name.

3. Disable transparent session id

4. Set HttpOnly. By setting the HttpOnly of a Cookie to true, You can prevent client scripts from accessing the Cookie and effectively prevent XSS attacks.

File Upload Attack)

The file upload vulnerability allows an attacker to bypass the system's file verification and processing policies by exploiting program defects to upload malicious code to the server and obtain the ability to execute server commands.

Common attack methods include:

Upload the Web script code. The Web Container interprets and executes the uploaded malicious script;

Upload the Flash Cross-Domain Policy file crossdomain. xml and modify the access permission (the usage of other policy files is similar );

Upload viruses and trojan files to trick users and administrators into downloading and executing them;

Upload images containing scripts. some low-level versions of browsers execute the script for phishing and fraud.

In general, the uploaded files are either executable (malicious code) or vulnerable to server behavior (configuration files ).

Defense methods:

1. Set the File Upload directory to unexecutable;

2. Determine the file type and set the whitelist. For image processing, you can use the compression function or the resize function to destroy the HTML code that may be contained in the image while processing the image;

3. Use a random number to rewrite the file name and file path: files like shell.php.rar.rar and crossdomain. xml cannot be attacked due to renaming;

4. Set the domain name of the file server separately: Due to the relationship between the browser's same-origin policy, a series of client attacks will become invalid, such as uploading crossdomain. xml, uploading XSS containing Javascript, and other issues will be solved.

References:

Http:// OS .51cto.com/art/201204/328938.htm

Https://www.zhihu.com/question/22953267

Http://wt7315.blog.51cto.com/10319657/1865580

Http://www.plhwin.com/2014/06/13/web-security-sql/

Summary

The above is all about the Web attack of PHP security protection. I hope this article will help you in your study or work. If you have any questions, please leave a message.