Learn PHP essentials, write efficient PHP code security _php Tutorials

First, filter the input, avoid the output

Sometimes we abbreviated the phrase "filter input, avoid output" to Fieo, which has become a security mantra for PHP applications.

1, using CType to verify

Ctype:http://php.net/ctype

2. Validation with Pcre (Perl-compatible regular expressions)

Pcre:http://php.net/pcre

Second, cross-site scripting

Cross-site scripting is often referred to as XSS, and the attack vector is targeted at the location of the user-supplied variable in the application output, but the variable is not properly escaped. This allows an attacker to inject a client script of their choice as part of the value of this variable. The following is an example of the code being attacked by this type:

<action= "
  
    ">    <type = "Submit" value = "Submit" /> 
  
    form> 

Online resources:

1, http://ha.ckers.org/xss.html

2, Http://shiflett.org/articles/cross-site-scripting

3, Http://seancoates.com/blogs/xss-woes

Third, forge cross-site scripts

For example, an attacker would like to get an expensive item from a popular online store without paying for it. Instead, they want an unsuspecting victim to pay the amount. The weapons they choose are: a forged cross-site request. The goal of this type of attack is to have the victim send a request to a specific website to take advantage of the identity information that the victim has registered on the site.

Online resources:

1, Http://shiflett.org/articles/cross-site-request-forgeries

2, Http://shiflett.org/articles/foiling-cross-site-attacks

Four, session fixed

As shown earlier, user sessions are a frequently targeted target, and the ability to identify potential victims and target sites makes some attacks an advantage. Here are 3 ways for attackers to get valid session identifiers. They are arranged in the order of difficulty, respectively:

1. Fixed

2. Capture

3. Forecast

Online resources:

1, Http://shiflett.org/articles/session-fixation

2, http://phpsec.org/projects/guide/4.html#4.1

3, Http://www.owasp.org/index.php/Session_fixation

V. Session HIJACKING

Session hijacking is a difficult word to understand because we use it to describe two things:

1. The attacker was able to access the session associated with the victim's account on the site, regardless of any type of attack that he gained access to.

2. You need to capture an established session identifier rather than a specific type of attack that takes a session identifier through a fixed technology or prediction.

Online resources:

1, http://shiflett.org/articles/session-hijacking

2, Http://shiflett.org/articles/the-truth-about-sessions

3, http://phpsec.org/projects/guide/4.html#4.2

Vi. SQL injection

The nature of this type of attack is related to the previously mentioned "filter input, avoid output". Basically, SQL injection is very similar to XSS, where an attack object causes the application to think that the user input has more meaning than the data it represents. The purpose of XSS is to allow those inputs to be executed as client-side code, whereas SQL injection is intended to make these inputs considered an SQL query or part of a query.

Online resources:

1, Http://shiflett.org/articles/sql-injection

2, http://phpsec.org/projects/guide/3.html#3.2

Seven, storage password

In situations where a Web application can effectively handle user input in a database query, an attacker would need to access the user account in a more extensive way. In general, it also includes accessing the victim's access credentials to visit their data.

One implementation is to forcibly enter the database server used by the Web application. Depending on what database you use, how the database is configured, and so on, attackers have many intrusive methods.

Online resources:

1, Http://php.net/mcrypt

2, http://www.openwall.com/phpass/

3, http://codahale.com/how-to-safely-store-a-password/

Eight, brute force attack

For an attacker, the threshold for hacking into a database or decrypting cryptographic cryptography is too high. In this case, an attacker could attempt to use a script that simulates a normal user's HTTP request to log in to the Web application using a browser, and they try to log in with a given user name and random password until they find the correct password. This approach becomes a "brute force attack".

Online resources:

1, Https://www.owasp.org/index.php/Brute_force_attack

2, Http://en.wikipedia.org/wiki/Brute-force_attack

Nine, SSL

Online resources:

1, HTTP://ARST.CH/BGM

2, Http://www.owasp.org/index.php/SSL_Best_Practices

PHP Security-related resources:

1. The http://www.php.net/manual/en/security.php PHP Manual has chapters on various security issues

2, http://phpsecurity.org/This is "Essential PHP Security" a book related to the website

3. One of the projects of the Http://phpsec.org/projects/guide/PHP Safety Association is the PHP Security Guide

4. http://www.enigmagroup.org/The site provides information and practical exercises on many of the potential attack vectors for Web applications and forums.

http://www.bkjia.com/PHPjc/780761.html www.bkjia.com true http://www.bkjia.com/PHPjc/780761.html techarticle First, filter input, avoid output sometimes we filter the phrase input, avoid the output abbreviation for FIEO, which has become the security mantra of the PHP application. 1, the use of CType to verify CType: ...

