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:Local PHP Security Checker
local-php-security-checker and make it executable.$ local-php-security-checker
You can also pass a --path to check a specific directory:
$ local-php-security-checker --path=/path/to/php/project
$ local-php-security-checker --path=/path/to/php/project/composer.lock
By default, the output is optimized for terminals, change it via the --format flag [supported formats: ansi, markdown, json, junit, and yaml]:
$ local-php-security-checker --format=json
All packages are checked for
security vulnerabilities by default. You can skip the checks for packages listed in require-dev by passing the no-dev flag:
$ local-php-security-checker --no-dev
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 --local. To force a database update without checking for a project, use
--update-cache.
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:
MAILTO=
50 23 * * * croncape php-security-checker --path=/path/to/php/project
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]
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 0; is to supply a valid offset to the original query and to terminate it.
Note:
It is common technique to force the SQL parser to ignore the rest of the query written by the developer with
--which is the comment sign in SQL.
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 WHERE, ORDER BY,
LIMIT and OFFSET clauses in SELECT statements. If your database supports the UNION construct, the
attacker may try to append an entire query to the original one to list passwords from an arbitrary table. Using encrypted password fields is strongly encouraged.
Example #2 Listing out articles ... and some passwords [any database server]