Logging user-provided values directly can put application vulnerable to multiple attack vectors. Superglobal variables contains values specified by the user, which are considered as tainted and untrusted. Therefore, it is discouraged to pass these variables directly to the logger.
eval()
function found PHP-A1000eval()
function allows execution of an arbitrary PHP code. Executing code dynamically is security-sensitive and should be avoided.
Debugging functions such as var_dump
, print_r
or var_export
should not be kept in production code. These functions display information about the variable, which can be helpful during development. However, if they contain any sensitive information, the presence of these functions in production code can expose that. Therefore, it is advised to avoid using it in production.
Cipher algorithm used to encrypt data is not strong. Using weak cipher algorithm such as RC2, RC4, DES, MD5, etc. for encrypting sensitive data can be vulnerable to several attacks.
The include
(or require
) statements are used to include and copy all the text/code/markup from an external file into the file that uses the include statement. This issue flags the use of this statement when a user-provided value is directly used in it.
Using user-provided values to construct the include
/require
statement can allow an attacker to control which files are included, giving them the ability to execute arbitrary code.
Using user-provided data while executing an SQL query can lead to SQL injection attacks. An SQL injection attack consists of the insertion or "injection" of a malformed SQL query via the input data given to an application. It is a prevalent attack vector and causes significant damage if the incoming data is not properly sanitized.
HttpOnly
attribute PHP-A1003Cookies set without the httponly
flag can be read by a client-side script, leading to cookie theft from Cross-Site Scripting (XSS) attacks.
Using md5()
, sha1()
function is not recommended to generate secure passwords. Due to its fast nature to compute passwords too quickly, these functions can become really easy to crack a password using brute force attack.
It is recommended to use PHP's password hashing function password_hash()
to create a secure password hash.
secure
attribute PHP-A1005Cookies set without the secure
flag can cause the user agent to send those cookies in plaintext over an HTTP session with the same server. This can be observed by an unauthorized person, leading to a man-in-the-middle attack.
Excessive permissions are granted when creating a directory. This issue is raised when permission greater than 0755
is given, or permissions argument is not specified when creating a directory using mkdir()
function. By default, mkdir()
function gives universal access(0777
) to created folders.
The permission number can be a 3 or 4-digit numeric, where the first digit states permissions for the file owner, the second digit is for the file group, and the last digit states the permission all other users. Each write, read, and execute permissions have the following number value:
r
(read) = 4w
(write) = 2x
(execute) = 1So as an example, to give full permission to file owner and read permission to the group and all other users, use 0744
while creating a directory.
Generating session ID manually can allow an attacker to hijack another user's session. The application can become vulnerable if the session ID is not generated using a strong secure pseudo-random generator or, the session ID length is too short.
Therefore, it is discouraged to generate session IDs manually. Instead, always use language-specific function like session_regenerate_id()
to generate new session IDs.
Using exec
, passthru
, shell_exec
or, system
functions to execute command can make the application vulnerable to arbitrary commands execution, if the user-supplied data is escaped or sanitized properly before passing them.
Though functions like escapeshellarg
and escapeshellcmd
exists which can be used to escape the command and shell argument. But the lack of cross-operating system compatibility of these functions relying on it is discouraged.
XML specification allows the use of entities that can be internal or external(file system or network, etc.) which could lead to vulnerabilities such as SSRF or confidential file disclosures. Therefore, enabling external entity substitution via LIBXML_NOENT
option can make an application vulnerable to XML External Entity (XXE) attacks.
libxml_disable_entity_loader()
PHP-W1086The libxml_disable_entity_loader()
function has been deprecated since PHP 8.0.0. Relying on this function is highly discouraged. It is recommended to use libxml_set_external_entity_loader()
to suppress loading of external entities.