PHP Security Web Attack

One, SQL injection attack (SQL injection)

An attacker inserts a SQL command into a Web form's input domain or a page request string, tricking the server into executing a malicious SQL command. In some forms, user-entered content is used directly to construct (or influence) dynamic SQL commands, or as input parameters to stored procedures, which are particularly susceptible to SQL injection attacks. Common SQL injection attack process classes such as:
1. A Web App has a login page that controls whether the user has access to the app and asks the user to enter a name and password;
2. The contents entered on the login page will be used to construct the dynamic SQL command directly or as the parameters of the stored procedure.
For example:

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

3. The attacker enters ' or ' 1 ' = ' 1 ' in the user name and password input box;
4. After the user input content is submitted to the server, the server runs the above code to construct the SQL command that queries the user, but the resulting SQL command becomes a result of the very special input of the attacker:

SELECT * from Users WHERE login = ' or ' 1 ' = ' 1 ' and password = ' or ' 1 ' = ' 1 ';

5. The server executes the query or stored procedure, compares the identity information entered by the user and the identity information stored in the server;
6. Because the SQL command has actually been modified by an injected attack, the user's identity cannot be verified, and the system is incorrectly authorized to the attacker.
If an attacker knew that the app would use the input in the form to authenticate the query directly, he would try to enter some special SQL string tampering query to change its original functionality and spoof the system to grant access.
The system environment is different, the attacker may cause different damage, 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 privileges, an attacker could perform various actions on the database's tables, including adding, deleting, or updating data, and possibly even deleting the table directly
Precautionary approach:
1. Check the variable data type and format
2. Filter Special symbols
3. Binding variables, using preprocessing statements

Second, cross-site scripting attacks (crossing site Scripting, XSS)

Attackers inject malicious code onto a Web page, and other users execute code as they load the Web page, and attackers may get a variety of content including but not limited to higher permissions, such as performing some actions, private web content, conversations, and cookies. These malicious code is typically JavaScript, HTML, and other client-side scripting languages.
For example:

<?phpecho "Welcome you,". $_get[' name ';

If a script <script>[code]</script> is passed in, then the script executes. The alert function that will execute JavaScript with such a URL pops up a dialog box: Http://localhost/test.php?name=<script>alert (123456) </script>
Common attack methods are:
Misappropriation of cookies to obtain sensitive information;
The use of IFRAME, frame, xmlhttprequest or the above flash, and so on (attacked) the identity of the user to perform some management actions, or perform some general such as tweet, add friends, send private messages and other operations;
The use of the vulnerable domain by other domain trust characteristics, the identity of the trusted source to request some normally not allowed operations, such as improper voting activities;
XSS on some of the most visited pages can attack some small web sites and achieve the effect of DDoS attacks.
Precautionary approach: Use the Htmlspecialchars function to convert special characters to HTML encoding, filter output variables

Iii. Cross-site request for forgery attacks (crosses site request forgeries, CSRF)

The attacker forges the HTTP request of the target user and then sends the request to a Web site with a CSRF vulnerability, which causes a cross-site request forgery attack after the Web site executes the request. The attacker uses a covert HTTP connection to allow the target user to click on the link without notice, because the user clicks on it, and the legitimate user has legal rights, so the target user can execute a specific HTTP link within the site to achieve the attacker's purpose.
It is different from the XSS attack method, the XSS exploits the vulnerability to affect the users within the site, the target is the user in the same site, and CSRF by masquerading as a victim to send malicious requests to affect the user's interests in the web system.
For example:
When buying a product on a shopping site, use the Http://www.shop.com/buy.php?item=watch&num=100,item parameter to determine what items to buy, num parameters determine the quantity to buy, If an attacker sends a link to a target user in a hidden way
, then if the target user is accidentally accessed, the number of purchases will be 100
Precautionary approach:
1, check the source of the Web page
2. Check the built-in hidden variables
3. Use post, do not use GET, handle variables and do not use $_request directly

Iv. Fixed session attack (session fixation)

The attacker pre-sets the session ID to allow legitimate users to use the session ID to access the attacked application, and once the user's session ID is successfully fixed, an attacker could impersonate the user to the application using this session ID.
For example:
1. The attacker accesses the website http:///www.bank.com, obtaining his own session ID, such as: sid=123;
2. The attacker sends a link to the target user and takes his session ID, such as: http:///www.bank.com/?SID=123;
3. The target user clicked on the http:///www.bank.com/?SID=123, as usual, enter their own user name, password login to the website;
4. Since the session ID of the server does not change, now that the attacker clicks on http:///www.bank.com/?SID=123, he has the identity of the target user and can do whatever he wants.
Precautionary approach:
1. Change session ID periodically

SESSION_REGENERATE_ID (TRUE);//delete the old session file, each time a new session ID is generated. Default false to keep the old session

2. Change the name of the session
The default name of the session is PHPSESSID, which is stored in the cookie and cannot be guessed if the attacker does not capture packet analysis, blocking part of the attack

Session_name ("Mysessionid");

3. Turn off transparent session ID
Transparent session ID refers to the Sessioin ID used to pass a link when an HTTP request in the browser does not use a cookie to set the session ID.

Int_set ("Session.use_trans_sid", 0);

4. Check session ID from Cookie only

Int_set ("Session.use_cookies", 1);//means using cookies to store session idint_set ("Session.use_only_cookies", 1);// Indicates that only the session ID is stored using cookies

5. Using URL to pass hidden parameters

$SID = MD5 (Uniqid (rand ()), TRUE), $_session["sid"] = $sid;//The attacker can retrieve the SESSION data, but cannot know the value of $sid, as long as the value of the SID is checked, You can confirm that the current page is the one that the Web program calls itself

V. Session hijacking attack (session hijacking)

Attackers use various means to obtain the session ID of the target user. Once the session ID is obtained, the attacker can use the identity of the target user to log on to the Web site and get the permissions of the target user.
How the attacker obtains the target user session ID:
1. Brute force: Try various session IDs until they are cracked;
2. Calculation: If the session ID is generated in a non-random way, then it is possible to calculate it;
3. Stealing: Using network interception, XSS attacks and other methods to obtain
Precautionary approach:
1. Change session ID periodically
2. Change the name of the session
3. Turn off transparent session ID
4. Set the HttpOnly. By setting the HttpOnly of the cookie to true, the client script can be prevented from accessing this cookie, thereby effectively preventing XSS attacks.

Vi. File Upload vulnerability attack (Files Upload Attack)

Attackers use program defects to bypass the system's validation and processing of files to upload malicious code to the server and gain the ability to execute server-side commands.
Common attack methods are:
Upload Web script code, Web container to interpret the malicious script that performs the upload;
Upload Flash cross-domain policy file crossdomain.xml, modify access rights (other policy files are used in a similar way);
Upload viruses, trojan files, and trick users and administrators to download and execute;
Upload a picture containing the script, and some low-level versions of the browser will execute the script for phishing and fraud.
In general, the upload files used are either executable (malicious code) or have the ability to affect server behavior (configuration files).
Precautionary approach:
1. The file upload directory is set to not executable;
2. Determine the file type and set the whitelist. For image processing, you can use the compression function or the Resize function to manipulate the image while destroying the HTML code that may be included in the image;
3. Use random numbers to overwrite filenames and file paths: One is not accessible after uploading, and the file like Shell,. php,. rar, and Crossdomain.xml will not be able to attack because of renaming;
4. Set the domain name of the file server separately: Due to the browser-homologous policy, a series of client-side attacks will fail, such as uploading crossdomain.xml, uploading the JavaScript-containing XSS exploits, and so on.

See MORE:
Develop a small program example tutorial
HTTP protocol Collation
Second-kill system design optimization
MySQL optimization
Common IO models under Linux

PHP Security Web Attack