Vulnerability Types
Cross Site Scripting (XSS)
This vulnerability allows data to be injected into webpages. This data is then interpreted as code and executed by the viewer‘s web browser, which can effectively be seen as remote controlling a victim‘s browser.
Cross Site Request Forgery (CSRF)
CSRF refers to a type of exploits where the victim‘s browser is being tricked into triggering an authenticated action inside a vulnerable web application. The target website can be affected by CSRF regardless of being susceptible to XSS. How dangerous CSRF can be really depends on the kind of action triggered this way and its impact.
SQL Injection
SQL injection attacks lead to the manipulation of SQL queries. Vulnerable applications allow dynamically built SQL queries to contain unfiltered or improperly sanitised user input. If exploited successfully an attacker can gain access to all data in the database as well as modify data, limited only by the access level of the database user.
Insecure Session Handling
This category covers problems enabling attackers to access or manipulate a session token in order to control or take over a session.
Session Fixation
Session Fixation allows an attacker to control the session of a user. This is done by injecting a known token to be used as a valid session token.
Information Disclosure
As the name suggests, security related information is being divulged by the target system, which may simplify an attack. Such information can be found in various places, e.g. code comments, directory listings, error messages or even in search results of your favourite search engine.
Header Injection
This vulnerability allows HTTP headers to be injected into an HTTP response.
File Inclusion
The inclusion of local or remote files into a web application is a serious security vulnerability, which may lead to arbitrary code execution on the server.
Insecure Configuration
Misconfiguration of server or application software may facilitate or simplify attacks.
Weak randomness
This problem refers to predictable random number generation; e.g. badly chosen random seeds or algorithms using insufficient entropy are known to generate weak random numbers.
Concepts
Secure Input Handling
Input filters and validators can be used to scan user input for specific patterns known to trigger unwanted side effects in web applications. User input can contain fragments of JavaScript, SQL, PHP or other code which – if unfiltered – could then lead to code execution within the context of the web application.
Sanitising
Sanitising functions can be used to “repair” user input, according to the application‘s restrictions (e.g. specific datatypes, maximum length) instead of rejecting potentially dangerous input entirely. In general, the use of sanitising functions is not encouraged, because certain kinds and combinations of sanitising filters may have security implications of their own. In addition, the automatic correction of typos could render the input syntactically or semantically incorrect.
Escaping
There are several different kinds of escaping:
- The backslash prefix “” defines a meta character within strings. For Example: t is a tab space, n is a newline character, … This can be of particular interest for functions where the newline character has a special purpose, e.g. header(). Within regular expressions the backs- lash is used to escape special characters, such as . or *, which is relevant for all functions handling regular expressions.
- HTML encoding translates characters nor- mally interpreted by the web browser as HTML into their encoded equivalents – e.g. < is < or < or < and > is > or > or >. HTML encoding should be used for output handling, where user input should be reflected in HTML without injecting code. (See also: htmlentities())
- URL encoding makes sure, that every character not allowed within URLs, according to RFC 1738, is properly encoded. E.g. space converts to + or %20 and < is %3C. This escaping is relevant for functions handling URLs, such as urlencode() and urldecode().
White-/Blacklisting
There are two different approaches to filtering input data – whitelisting and blacklisting. Blacklisting checks input data against a list of “bad patterns”. This way, unwanted input can be discarded and all other content can be processed further. On the other hand, whitelisting checks input data against a list of known “good patterns”. All unmatched input can be discarded and only input recognised as valid is accepted.
In the real world whitelisting turned out to be far more resistant to security vulnerabilities than blacklisting, since it is usually a lot easier to specify the narrow set of valid patterns for the whitelist than to exclude every invalid input with a blacklist. In particular, whitelisting should be used for input directly controlling the program flow, e.g. for include statements or eval().
Related：
Vulnerabilities & Concepts
Security Related PHP Functions
Secure programming
Hardening the PHP Configuration
Link：http://php-security.org/2010/05/01/article-php-web-security/index.html#vulnerabilitiesconcepts
