Hướng dẫn dùng local-php-security-checker trong PHP
The Local PHP Security Checker is a command line tool that checks if your PHP application depends on PHP packages with known security vulnerabilities. It uses the Security Advisories Database behind the scenes. Download a binary from the
Releases page on Github, rename it to From a directory containing a PHP project that uses Composer, check for known vulnerabilities by running the binary without arguments or flags: You can also pass a
By default, the output is optimized for terminals, change it via the
All packages are checked for
security vulnerabilities by default. You can skip the checks for packages listed in
When running the command, it checks for an updated vulnerability database and downloads it from Github if it changed since the last run. If you want to avoid the HTTP round-trip, use If you want to continuously check for security issues on your applications in production, you can use this tool in combination with croncape to get an email whenever a new security issue is detected: A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch? Many web developers are unaware of how SQL queries can be tampered with, and assume that an SQL query is a trusted command. It means that SQL queries are able to circumvent access controls, thereby bypassing standard authentication and authorization checks, and sometimes SQL queries even may allow access to host operating system level commands. Direct SQL Command Injection is a technique where an attacker creates or alters existing SQL commands to expose hidden data, or to override valuable ones, or even to execute dangerous system level commands on the database host. This is accomplished by the application taking user input and combining it with static parameters to build an SQL query. The following examples are based on true stories, unfortunately. Owing to the lack of input validation and connecting to the database on behalf of a superuser or the one who can create users, the attacker may create a superuser in your database. Example #1 Splitting the result set into pages ... and making superusers (PostgreSQL)
= $argv[0]; // beware, no input validation! Normal users click on the 'next', 'prev' links where the $offset is encoded into the URL. The script expects that the incoming $offset is a decimal number. However, what if someone tries to break in by appending a urlencode()'d form of the following to the URL 0; insert into pg_shadow(usename,usesysid,usesuper,usecatupd,passwd) select 'crack', usesysid, 't','t','crack' from pg_shadow where usename='postgres'; -- If it happened, then the script would present a superuser access to him. Note that
A feasible way to gain passwords is to circumvent your search result pages. The only thing the attacker needs to do is to see if there are any submitted variables used in SQL statements which are not handled properly. These filters can be set commonly in a preceding form to customize Example #2 Listing out articles ... and some passwords (any database server)
= "SELECT id, name, inserted, size FROM products The static part of the query can be combined with another ' union select '1', concat(uname||'-'||passwd) as name, '1971-01-01', '0' from usertable; -- If this query (playing with the SQL UPDATE's are also susceptible to attack. These queries are also threatened by chopping and appending an entirely new query to it. But the attacker might fiddle with the Example #3 From resetting a password ... to gaining more privileges (any database server)
But if a malicious user submits the value
A frightening example of how operating system level commands can be accessed on some database hosts. Example #4 Attacking the database hosts operating system (MSSQL Server)
= "SELECT * FROM products WHERE id LIKE '%$prod%'"; If attacker submits the value
= "SELECT * FROM products MSSQL Server executes the SQL statements in the batch including a command to add a new user to the local accounts database. If
this application were running as
Image courtesy of » xkcd Avoidance TechniquesWhile it remains obvious that an attacker must possess at least some knowledge of the database architecture in order to conduct a successful attack, obtaining this information is often very simple. For example, if the database is part of an open source or other publicly-available software package with a default installation, this information is completely open and available. This information may also be divulged by closed-source code - even if it's encoded, obfuscated, or compiled - and even by your very own code through the display of error messages. Other methods include the user of common table and column names. For example, a login form that uses a 'users' table with column names 'id', 'username', and 'password'. These attacks are mainly based on exploiting the code not being written with security in mind. Never trust any kind of input, especially that which comes from the client side, even though it comes from a select box, a hidden input field or a cookie. The first example shows that such a blameless query can cause disasters.
Besides these, you benefit from logging queries either within your script or by the database itself, if it supports logging. Obviously, the logging is unable to prevent any harmful attempt, but it can be helpful to trace back which application has been circumvented. The log is not useful by itself, but through the information it contains. More detail is generally better than less. |