Sorry for the very broad question but we have some problems, e.g. Checkmarx is complaining about code injection in something like the following
$accesskey = $_GET['accesskey'] ?? $argv[1] ?? null;
if (!$accesskey || !ctype_alnum($accesskey)) {
throw new RuntimeException(sprintf('Passed accesskey "%s" is invalid', $accesskey));
}
$commandParts = ['echo', $accesskey]
$commandParts = array_map('escapeshellarg', $commandParts);
$command = implode(' ', $commandParts);
$command = escapeshellcmd($command);
system($command);
I think the commands are escaped and everything is fine but why is Checkmarx thinking different?
The application's <?php method calls an OS (shell) command with system, at line 1 of REDACTED, using an untrusted string with the command to execute.
This could allow an attacker to inject an arbitrary command, and enable a Command Injection attack.
The attacker may be able to inject the executed command via user input, _GET, which is retrieved by the application in the <?php method, at line 1 of REDACTED.
I'm also wondering if and how Checkmarx is able to understand library or framework code which is installed via Composer? E.g.
Assert::oneOf($unsafeUserInput, ['foo', 'bar']); // throws an Exception if $unsafeUserInput is not 'foo' or 'bar'
// $unsafeUserInput is now safe
or WP related stuff which is also often falsely flagged as being prone to SQL injections
global $wpdb;
$foo = $wpdb->getVar($wpdb->prepare('SELECT foo FROM bar WHERE baz = %s', $_GET['baz'] ?? ''));
If it checks for sanitisation methods is there a specific way they have to look? I honestly want to avoid changing too much code for Checkmarx.
Your question of how well Checkmarx analyzes PHP code could lean towards a subjective answer and your perception of the tool can be biased given that you are using methods (escapeshellcmd) that are not recognized as sanitizers and the framework that you are inquiring about (Wordpress and Composer) are not technically supported.
In fairness to Checkmarx, they do support a variety of PHP frameworks such as Zend, Kohana, CakePHP, Symfony and Smarty which could end in lesser false positives (note: I'm not suggesting you switch platforms)
Any static analyzers would need some help from it users for it to be effective. I would advice you to exclude the Composer files from the scan.
You don't really don't have to make changes to the code and just argue with your AppSec team that these findings are false positives since the prepare method prevent SQL injection attacks and that escapeshellcmd does encode string. My recommendation however is to use escapeshellarg on $accesskey instead
Related
Security release 5.5.42 "disables all serialization / unserialization of cookie values" - https://laravel-news.com/laravel-5-6-30
But I have my values serialized still, only not unserialized. While I do
Cookie::get('key')
I get something like
"s:5:"value";"
Setting protected static $serialize = true; in App\Http\Middleware\EncryptCookies helps, and so does
unserialize(Cookie::get('key'))
But as I understand unserialize() itself is the source of the problem with this security release, not what I do with the unserialized value later, so this kinda beats the purpose of the update.
Why are my cookies serialized here and how to fix this?
This is actually worth an answer as the question itself is quite interesting.
From a Laravel perspective this isn't a cookie problem as much as it's a APP_KEY config key problem combined with serialize/unserialize.
Relevant quote from the docs:
However, if your application's encryption key is in the hands of a
malicious party, that party could craft cookie values using the
encryption key and exploit vulnerabilities inherent to PHP object
serialization / unserialization, such as calling arbitrary class
methods within your application.
The relevant part is this vulnerabilities inherent to PHP object serialization / unserialization.
Usually the form of explot is Object Injection(the most common at least).
OWASP has a very good example here.
Even php.net has a red warning for it's unserliaze function.
Warning
Do not pass untrusted user input to unserialize()
Cookies come from a user and users are NOT to be trusted.
Since an example is in order I'll just leave the OWASP one here too:
class Example1
{
public $cache_file;
function __construct()
{
// some PHP code...
}
function __destruct()
{
$file = "/var/www/cache/tmp/{$this->cache_file}";
if (file_exists($file)) #unlink($file);
}
}
// some PHP code...
$user_data = unserialize($_GET['data']);
// some PHP code...
In this example an attacker might be able to delete an arbitrary file via a Path Traversal attack, for e.g. requesting the following URL:
http://testsite.com/vuln.php?data=O:8:"Example1":1:{s:10:"cache_file";s:15:"../../index.php";}
With that said, I highly recommend reading(even briefly) about serialize/unserliaze vulnerabilities.
If you're using a proper framework, usually, you'll have most security things taken care of IF you don't go out of your way to introduce some vulnerability and you stick to the framework's standards.
It's less efficient but in case of structured data, I replace serialize/unserialize with json_encode/json_decode.
I have developed a project under which several sql query have been used. Now I want to monitor some query in order increase security. So I want every query to be passed through a function first. As there are too many queries so I can not go back and edit every file and query. Is there a way that I can trap into queries before they are sent to mysql server?
There are four ways to accomplish this depending on what you are using, the last being the much more reliable.
The General Query Log
MySQL provides a mechanism to log just about everything that the mysqld process is doing, via the general query log. As you described in your question you probably do not have persistent connections, so you will need to either:
Enable the MySQL general query log when the mysqld process is started, with the --log[=file_name]
Set a global/session variable with SET GLOBAL general_log = 'ON'.
Fore more information about the general query log, see the MySQL 5.1 reference manual.
Using sed (or manually!)
This technique involves creating a a new function, and renaming all of the mysqli_* function calls to call another function.
Presuming your newly created function is named proxy_query(), you can use sed to traverse through all files and change them automatically:
sed i '.bck' 's/mysqli_query/proxy_query/'
The -i paramater specifies that the file should be edited in place, and that a copy should be made of the original file and have a .bck extension appended.
The runkit extension
I must admit that I'm being naive here, and that I haven't used this particular extension before - but it is possible to rename functions with this PECL extension.
The requirements for this extension can be found here, and note that it is not bundled with PHP.
As with above, you can create a proxy function where all calls will go through. Let's assume it's also called proxy_query. Usage would go something like this:
// rename the function (a very bad idea, really!)
runkit_function_renam('mysqli_connect', 'proxy_super');
function mysqli_query($query, $resultmode = MYSQLI_STORE_RESULT)
{
// do something with the SQL in $query
// .. and call mysqli_query, now proxy_super
return proxy_super($query, $resultmode);
}
I have to note here that this method is highly discouraged. You shouldn't ever need to set default PHP functions.
Using Pdo/OO-mysqli
This is the simplest technique, and probably the most reliable as well. If you're using Pdo already, you can simply extend the \Pdo class. A similar approach could be used with MySQL Improved(mysqli):
class MyPdo extends \Pdo
{
public function query($query [, ... ])
{
// do something with $query
return parent::query($query [, ... ]);
}
}
Also note here, that this will only work if you are using Pdo, and if you are able to change the instantiation of the Pdo object, to overwrite it to your own class: MyPdo.
For more information about the \Pdo class, and it's children, see the manual.
If you want to monitor incoming queries using SQL profiler can be an excellent way to gather information on what's going on inside SQL without passing it all through a single function or procedure.
Firstly, I will say that I come from the Java world (this is important, really).
I have been coding PHP for a while, one of the problems that I have encountered is that due to the lack of compilation, sometimes errors that could be easily detected at compilation time (for example, wrong number of parameters for a given function), can silently pass.
That could be easily detected as code coverage increases by adding unit tests. The question is, does it make sense for example to tests constructors in order to check that the passed parameters are correct? I do not mean only the number of parameters, but also the content of such parameters (for example, if a parameter is null, certain objects should launch an exception in order to avoid creating a "dirty" object).
Question is, am I too contaminated by years of Java code? Because after all, increasing the code coverage to "discover" missued functions feels like a (really) primitive way of compiling.
Also, I would like to note that I already use a development environment (PHPStorm), we are also using tools like PHPCodeSniffer.
Any ideas/suggestions?
This is a good question that can be answered on a number of levels:
Language characteristics
Test coverage
CASE tools
1. Language characteristics
As you have pointed out the characteristics of the PHP language differ markedly from the more strongly-typed languages such as Java. This raises a serious issue where programmers coming from the more strongly-typed languages such as Java and C# may not be aware of the implications of PHP's behaviour (such as those you have described). This introduces the possibility of mistakes on the part of the programmer (for example, a programmer who may have been less careful using Java because they know the compiler will catch incorrect parameters may not apply the appropriate care when developing in PHP).
Consequently, better programmer education/supervision is needed to address this issue (such as in-house company coding standards, pair programming, code review). It also (as you have pointed out) raises the question of whether test coverage should be increased to check for such mistakes as would have been caught by a compiler.
2. Test Coverage
The argument for test coverage is very project-specific. In the real world, the level of test coverage is primarily dictated by the error tolerance of the customer (which is dictated by the consequences of an error occuring in your system). If you are developing software that is to run on a real-time control system, then obviously you will test more. In your question you identify PHP as the language of choice; this could apply equally to the ever-increasing number of web-enabled frontends for critical systems infrastructure. On the other side of the coin, if you are developing a simple website for a model railroad club and are just developing a newsletter app then your customer may not care about the possibility of a bug in the constructor.
3. CASE Tools
Ultimately it would be desirable for a CASE tool to be available which can detect these errors, such as missing parameters. If there are no suitable tools out there, why not create one of your own. The creation of a CASE tool is not out of reach of most programmers, particularly if you can hook into an open-source parsing engine for your language. If you are open-source inclined this may be a good project to kick start, or perhaps your company could market such a solution.
Conclusion
In your case whether or not to test the constructors basically comes down to the question: what will the consequences of a failure in my system be? If it makes financial sense to expend extra resources on testing your constructors in order to avoid such failures, then you should do so. Otherwise it may be possible to get by with lesser testing such as pair programming or code reviews.
Do you want the constructor to throw an exception if invalid parameters set? Do you want it to behave that same way tomorrow and next week and next year? Then you write a test to verify that it does.
Tests verify that your code behaves as you want it to. Failing on invalid parameters is code behavior just as much as calculating sales tax or displaying a user's profile page.
We test constructors, as well as the order of the parameters, the defaults when not provided, and then some actual settings. For instance:
class UTIL_CATEGORY_SCOPE extends UTIL_DEPARTMENT_SCOPE
{
function __construct($CategoryNo = NULL, $CategoryName = NULL)
{
parent::__construct(); // Do Not Pass fields to ensure that the array is checked when all fields are defined.
$this->DeclareClassFields_();
$this->CategoryName = $CategoryName;
$this->CategoryNo = $CategoryNo;
}
private function DeclareClassFields_()
{
$this->Fields['CategoryNo'] = new UTIL_ICAP_FIELD_PAIR_FIRST('CCL', 6, ML('Category'), 8);
$this->Fields['CategoryName'] = new UTIL_ICAP_FIELD_PAIR_SECOND('CCL', 32, ML('Name'), 15, array(), array(), NULL, UTIL_ICAP_FIELD::EDIT_DENY, UTIL_ICAP_FIELD::UPDATE_DENY, 'DES');
}
}
We then create our tests to not only check the constructor and its order, but that class and inheritance has not changed.
public function testObjectCreation()
{
$CategoryInfo = new UTIL_CATEGORY_SCOPE();
$this->assertInstanceOf('UTIL_CATEGORY_SCOPE', $CategoryInfo);
$this->assertInstanceOf('UTIL_DEPARTMENT_SCOPE', $CategoryInfo);
$this->assertInstanceOf('UTIL_DATA_STRUCTURE', $CategoryInfo); // Inherited from UTIL_DEPARTMENT_SCOPE
}
public function testConstructFieldOrder()
{
$CategoryInfo = new UTIL_CATEGORY_SCOPE(1500, 'Category Name');
$this->assertEquals(1500, $CategoryInfo->CategoryNo);
$this->assertEquals('Category Name', $CategoryInfo->CategoryName);
}
public function testConstructDefaults()
{
$CategoryInfo = new UTIL_CATEGORY_SCOPE();
$this->assertNull($CategoryInfo->CategoryNo);
$this->assertNull($CategoryInfo->CategoryName);
}
public function testFieldsCreated()
{
$CategoryInfo = new UTIL_CATEGORY_SCOPE();
$this->assertArrayHasKey('CategoryNo', $CategoryInfo->Fields);
$this->assertArrayHasKey('CategoryName', $CategoryInfo->Fields);
$this->assertArrayHasKey('DeptNo', $CategoryInfo->Fields); // Inherited from Parent
$this->assertArrayHasKey('DeptName', $CategoryInfo->Fields); // Inherited from Parent
}
I'm using the code below to automatically load and declare classes so that I only need to put class files in a folder named classes. The part in spl_autoload_regsister() may seem to be unnecessary for you but it is needed to work as a WordPress plugin without errors.
It uses eval() and I've seen so many web pages talking about using eval() is bad and can create a security hole. So how could this be dangerous?
$strDirPath = dirname(__FILE__) . '\\classes\\';
$arrClassFiles = array_map(create_function( '$a', 'return basename($a, ".php");' ), glob($strDirPath . '*.php'));
spl_autoload_register(
create_function('$class_name', '
global $arrClassFiles, $strDirPath;
if (in_array($class_name, $arrClassFiles))
include($strDirPath . $class_name . ".php");' )
);
foreach ($arrClassFiles as $strClassName) {
$strClassName_alpha = $strClassName . "_Alpha";
eval("class $strClassName_alpha extends $strClassName {};");
}
print_r(get_declared_classes());
Maybe, somebody can put a file name of php code in the folder? But I don't see it can compromise the system.
If they can name a class file something like randomclass {}; echo $db_password;//.php, then you could have a code execution attack.
I'm pretty sure that's not a valid file name, but there are people far wilier than me at crafting valid malicious inputs.
It's just usually not an attack surface you need to open yourself up to, given that it's practically always possible to avoid with better code structure.
If an error condition is handled, I don't see a problem here.
Just be sure that if someone tries to call a different class that does exist (i.e. code that would be valid here, but that you wouldn't want your hacker to run directly because it would bypass a restriction on your system), that it won't be a security problem - or that it wouldn't be possible to run that class at all from this context.
Just in case, deny any attempts to run code with the words "class," or other keywords, or any built in class names, or built in function names, other builtins, etc. and you should be fine, but even that probably isn't necessary in your particular case here because would probably result in an error.
Despite its inadvisability, using PHP's shell commands to interact with non-php system commands remains a common way of quickly achieving certain results in web applications.
Has anyone abstracted out the common use cases into a class library (something in Zend maybe?) that offers a more sane/common way of handling this? Every time I encounter (or have to produce) this kind of code it's a bunch of procedural spaghetti, copy-pasted over and over again. I was wondering if (hoping that) the PHP community had come up with a better way of handling using command line applications in your web/php applications.
Executing commandline applications is nothing dirty. In fact, it's the Unix way. And most mostly it's saner than trying to reimplement e.g. ImageMagick in pure PHP code. (Due to the disparity of its cmdline args, imagemagick is a bad example case if you look for a nice exec() abstraction.)
There isn't much wrapping up you can do. At best you can summarize in-/output to your external binary in a method:
function exec($args) {
$args = implode(" ", array_map("escapeshellcmd", func_get_args()));
$opts = $this->opts();
return `{$this->bin} {$args} {$opts}`;
}
So you just call ->exec("-o", "$file") where needed. Your code can only be gneralized further with specialized exec submethods, if the particular cmdline app has an inherent system in its --argument naming scheme.
Depending on your actual use case, you might be able to stash a few standard options away. I did this for pspell, where you have an almost 1:1 relationship of option names to --cmdline=args:
function opts() {
$map = array(
"--ignore" => $this->ignore,
"--verbose" => $this->verbose,
"--dir={$this->dir}" => isset($this->dir),
);
return implode(" ", array_keys(array_intersect($map, array(1=>1))));
}
A very generic abstraction class for exec/popen (for a wide range of cmdline programs) probably doesn't exist.