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 application has a login page that controls whether the user has access to the app, which requires the user to enter a name and password, and 2. The input on the login page will be used to construct the dynamic SQL command directly or as a parameter of the stored procedure; For example:

$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:

 select * from Users Span style= "COLOR: #0000ff" >where login =  "or  ' 1" Span style= "COLOR: #808080" >= "1  ' and password =  "or " 1  "="  1           

5. The server performs a query or stored procedure that compares the identity information entered by the user with the identity stored on the server; 6. Because the SQL command has actually been modified by an injected attack, it cannot really authenticate the user, so the system incorrectly authorizes 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: 1. Check the variable data type and Format 2. Filter special symbols 3. Binding variables, using precompiled 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,".  $_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> Commonly used attacks are: stealing cookies, obtaining sensitive information, using IFRAME, frame, xmlhttprequest or the above flash, and so on, to (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 ability to use an attacker's domain to be trusted by other domains, and to request some operations that are not normally allowed, such as improper voting, as trusted sources; XSS on some pages with great traffic can attack small websites and achieve 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 item to buy, num parameter determines the quantity to buy, If the attacker sends the link to the target user in a hidden way, then if the target user is accidentally accessed, the number of purchases becomes 100 precautions: 1, check the source of the page 2, check the built-in hidden variable 3, use post, do not use GET, handle variables and do not directly use $_ REQUEST

Iv. Fixed session attack (session fixation)

The core point of this attack is to allow legitimate users to use the attacker's pre-set session ID to access the attacked application, and once the user's session ID is successfully fixed, an attacker could impersonate the user to access the application through 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 with his session ID, such as: http:/// www.bank.com/? sid=123; 3. The target user clicked http:///www.bank.com/? Sid=123, as usual, enter your username and password to login to the website; 4. Now that the server session ID does not change, the attacker clicks http:///www.bank.com/? Sid=123, he has the identity of the target user, can do whatever he wants. Precautions: 1. Change session ID periodically

session_regenerate_id (TRUE);  deleting the old session file will generate a new session ID each time. 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 means that when the HTTP request in the browser does not use a cookie to set the session ID, the Sessioin ID uses the link to pass

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

MD5 (uniqid (TRUE));  $sid; //The attacker can obtain session data, but cannot know the value of the $sid, as long as the value of the SID is checked, you can confirm whether the current page is the Web program itself called     

V. Session hijacking attack (session hijacking)

Session hijacking refers to the attacker using various means to obtain the target user's session ID. 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. The attacker obtains the target user session ID by: 1. Brute force: Try various session IDs until 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 a precautionary approach: 1. Periodically change session ID 2. Change the name of the session 3. Turn off transparent session ID 4. Set 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)

File upload vulnerability refers to the ability of an attacker to bypass the system's validation and processing of files by using a program flaw to upload malicious code to the server and gain execution of server-side commands. Common attack methods are: Upload Web script code, Web container to interpret the malicious script to perform the upload; upload flash cross-domain policy file crossdomain.xml, modify access rights (other policy files are used similarly); upload viruses, trojan files, and entice 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). Precautions: 1. The file upload directory is set to not executable; 2. Determine the file type, set a 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. Overwrite the file name and path with a random number: one that cannot be accessed after uploading Again, such files as Shell.php.rar.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 relationship, a series of client attacks will fail Issues such as uploading crossdomain.xml, uploading the use of XSS with JavaScript, etc. will be resolved.
Resources: 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/

PHP Security Web Attack