Types of vulnerabilities and secure programming rules in PHP

One of the most significant issues for web programmers is the security of php scripts or vulnerabilities in PHP. All programmers to some extent use different methods to secure their project, but, unfortunately, in most cases, protection from several vulnerabilities is used, and the remaining problematic areas are not even considered.
This article lists the main types of vulnerabilities in PHP and discusses how to protect against them.

 

Types of vulnerabilities in PHP

  1. Demonstration of errors to the user
    Sense: with any errors in the code, the user is shown information about the error that occurred. It is not a critical vulnerability, but it prevents the attacker from gaining additional information about the structure and operation of the server.
  2. Availability of data about the characteristics of the system to the user.
    Meaning: the user can access data that gives an idea of ​​the system. It is not a critical vulnerability, but it prevents the attacker from gaining additional information about the structure and operation of the server. The reason for this vulnerability is the errors and “oversights” of the programmer. An example is the presence of a file phpinfo.phpwith the same name function in free access.
  3. Accessibility of data about the program code to the user.
    Meaning: the user can access the program codes of the modules having an extension other than php. It is a critical vulnerability, since it allows the attacker to get enough information about the structure and operation of the server, to reveal its vulnerabilities.
  4. Simple passwords for accessing administrative pages.
    Meaning: a cracker can pick up a simple password to an administrative page that gives him more opportunities for hacking. It is a critical vulnerability, since it allows the attacker to affect the server.
  5. Ability to specify global variables
    Meaning: with incorrect PHP settings, it is possible to specify global script variables, via the query string. It is a critical vulnerability, as an attacker can influence the progress of the script in his favor.
  6. PHP-injection
    Sense: a parameter specifying the work of PHP with files or program code is passed to a link to a third-party program code or the code itself. It is a critical vulnerability, since an attacker can execute his scripts on the server. Code execution is carried out by means of functions: eval(), preg_replace(), require_once(), include_once(), include(), require(), create_function(), readfile(), dir(), fopen().
  7. PHP injection through file uploading
    Meaning: if you can set global variables in a parameter that specifies the file uploaded to the server, a link is sent to a third-party program code or confidential file on the server. It is a critical vulnerability, because an attacker can execute his scripts on the server or access confidential data. This vulnerability is possible only if it is possible to specify global variables and incorrect organization of the mechanism for downloading files.
  8. e-mail-injection
    Sense: a parameter specifying the work of PHP with e-mails is passed to a link to a third-party program code or the code itself. It is a critical vulnerability, as an attacker can execute his scripts on the server or access data stored by the user.
  9. SQL injection
    Sense: the parameter that defines the SQL query is passed data that forms a query to access the private data. It is a critical vulnerability, as an attacker can obtain confidential data stored in the database. To change the request attacker can use the following structure: SELECT, UNION, UPDATE, INSERT, OR, AND.
  10. Crossite scripting or XSS
    Meaning: a parameter that specifies the data to be displayed to the user is passed to a third-party program code. It is a critical vulnerability, since an attacker can obtain confidential data stored in the client’s browser. To modify the request, the attacker uses html-tags.

 

The rules for writing secure code in PHP

  1. Blocking the output of errors
    For this it is enough to specify in the program code error_reporting(0)or .htaccessadd a line in the filephp_flag error_reporting 0
  2. Using complex passwords to access administrative pages
    It is sufficient to use multi-valued passwords that do not have semantic meaning (for example, K7O0iV98dq).
  3. Logging critical user actions
    Does not provide protection directly, but it allows you to identify the attackers and identify the vulnerabilities that they used. To do this, the user’s actions and the data transferred to him, which concern the critical moments of the system, is enough to write to a plain text file.
    Example of the logging function and its operation:
    function writelog($typelog, $log_text) {<br/>
    $log = fopen('logs/'.$typelog.'.txt','a+');<br/>
    fwrite($log, "$log_text\r\n");<br/>
    fclose($log);<br/>
    }<br/>
    writelog('authorization', date("y.m.d H:m:s")."\t".$_SERVER['REMOTE_ADDR']."\tУспешный вход");
  4. Closing access to site modules
    Provides protection against attempts to view their content or execution. To do this, it is enough to .htaccessconfigure the file access to the modules’ files using the FilesMatchand Files.
    For example, we close access to all modules with an extension phpother than the file capcha.php:
    image
  5. Disabling the ability to specify global variables
    For this, it is enough to specify in the server settings register_globals = off;or .htaccessadd a line in the file php_flag register_globals off. The ini_set('register_globals',0);problem does not solve the problem the way variables are set before the script is executed.
  6. Disabling the ability to use deleted files
    For this, it is enough to set in the server settings allow_url_fopen = off;. This provides partial protection against PHP injection, but not complete, since an attacker can transmit not a link to a program code file, but the program code itself. To fully protect against PHP injections, you must additionally use the filtering of incoming data. Sometimes this protection measure can not be used because of the features of the project (you need to access remote files).
  7. Filtering incoming data
    Provides protection against most vulnerabilities. There is no universal solution. It is advisable to use the “white” list of symbols in conjunction with checking for forbidden words. “White” refers to the list of allowed characters. This list should not include dangerous characters such as <>. To forbidden words it is possible to carry:, script, http, SELECT, UNION, UPDATE, exe, exec, INSERT, tmpand also html-tags.
    Example of incoming data filtering:
    // Проверка по белому списку. Допускаются только русские и латинские буквы, цифры и знаки _- <br/>
    if (preg_match("/[^(\w)|(А-Яа-я-)|(\s)]/",$text)) {<br/>
    $text = '';<br/>
    }<br/>
    // Фильтрация опасных слов<br/>
    if (preg_match("/script|http|<|>|<|>|SELECT|UNION|UPDATE|exe|exec|INSERT|tmp/i",$text)) {<br/>
    $text = '';<br/>
    }
  8. Check for uploading a file using HTTP POST
    Provides protection against PHP injection through downloading files. To ensure this, the files uploaded to the server must be checked by the function is_uploaded_file()or moved by the function move_uploaded_file(). This type of protection can not be used if global variables can not be set.
  9. Screening characters of data quotes sent to the database
    Provides protection against SQL injections. The most optimal method is the processing of all received non-numeric data using the function mysql_real_escape_string(). You can also use automatic screening, incoming data. To do this, it is enough to .htaccessadd a line to the file php_value magic_quotes_gpc on, but this method is not reliable, as it can lead to double escaping.
    An example of escaping quotes with the function mysql_real_escape_string():
    if (!is_numeric($text)) {<br/>
    $textrequest = mysql_real_escape_string($text);<br/>
    }
  10. Convert special characters in the html entity before output
    Provides protection against XSS. To do this, the data entered by the user, which can contain unwanted html tags, is enough to handle the function in the output htmlspecialchars(). This type of protection can not be used if filtering incoming data filters out dangerous html-tags.

As you can see, the creation of a well-thought-out script security system is not as labor-intensive as it seems.
This article does not pretend to be a security scripts tutorial, but I hope it will encourage php programmers to use more sophisticated security methods.

Leave a Reply