TL;DR: If you are not careful, Kickstart can cause security concerns for your site. There are technical measures in place. You need to be aware of them, and make sure you do not circumvent them as your site could get hacked.
Kickstart, by default, allows anyone who knows the URL to it to extract any ZIP, JPA, or JPS file as long as they know the directory the file is stored in. This can be a security issue, especially if the attacker has found a way to upload arbitrary archive files into your site in a known directory. Moreover, Akeeba Kickstart Professional further allows anyone who knows the URL to it to import ZIP, JPA, and JPS files from any URL or Amazon S3 bucket. Likewise, it can be a security issue as it would allow an attacker to import and potentially execute arbitrary code on your site. Finally, if an attacker can access Kickstart AND there is a backup archive taken on the same site present on your site, then the attacker can restore this backup and override your administrator / super user password, taking over your site (unless you have other security measures in place) leading to a complete takeover on your site.
It has always been our very strong recommendation that Kickstart MUST be removed from your site when you are done with the restoration of your site. DO NOT leave it behind.
Moreover, Kickstart has the following technical measures in place to mitigate the aforementioned risks.
Kickstart 9.0.1 and later versions allow you to protect access to it with a password. This is very strongly recommended.
Always use a secure, randomly generated password. We strongly advise using your password manager's tools to generate a password. Alternatively, you can create a secure, random password using random.org.
Do note that the password protection feature relies on PHP's sessions working properly on your server. This is not always the case on self-hosted servers (including some prepackaged local servers) and some badly configured hosts. In this case you can rename the Kickstart file as explained further below instead of using a password.
First, you need to create a configuration file named something.json.phpexample.php then the configuration file MUST be named example.json.php. Alternatively, the file can be named kickstart.json.php regardless of the name of your Kickstart file. If both files exist, the configuration file using the same name as your Kickstart file (in our example: example.json.php) will take precedence for security reasons; the kickstart.json.php file will NOT be read in this case.
The contents of this file must be as follows:
<?php die(); ?>{ "password": "yourpassword"}Watch out! The first line with the die() statement MUST exist to ensure the secrecy of your password! Kickstart will refuse to use a configuration file whose first line DOES NOT exactly match <?php die(); ?>. This is a deliberate security feature.
There are two options for yourpassword.
The simplest one is to type in your password, unencrypted. However, this is insecure! If your server hiccups for any reason and spits out the source of the configuration file (e.g. because of a broken .htaccess file) an attacker will find out what your password is, easily compromising your site.
The second and recommended method is to use a password hashed with the bcrypt method. You can find on-line bcrypt hashing tools if you use your favourite search engine to look for "bcrypt hash online". If you are on a Linux (including Windows Subsystem for Linux - WSL) or macOS and have installed the Apache package for your Operating System you can alternatively use the command htpasswd -bnBC 10 "" " where yourpassword" | tr -d ':\n'yourpassword is the password you want to use.
For example, let's say we want to use the password 2EnNP6QXKNCUfERfvt5am5rUNzy3gaPk using the bcrypt method. Your configuration file will look something like this:
<?php die(); ?>{ "password": "$2y$10$oJrOZ7P3HvQQzPP/onfG8ubhwatMDxYbC5Ad7K/.1GSpHRZ40P5Ny"}Please note that Kickstart will REFUSE to accept the password from the example above. It will run, it will show you the password page, but once you try to use this well-known password it will return an error reminding you that you were explicitly told not to do this. This is a security feature. It prevents you from naively using the well-known example which is as insecure as having no password at all!
Also note that the password feature does not apply to the CLI mode. This is deliberate. If an attacker is running commands on the CLI you are already thoroughly hacked.
Create a random, long (64 characters or longer) password and store it in your password manager. Create a file named kickstart.json.php following the instructions above, and upload it together with kickstart.php every time you want to restore a site. You can even keep these two files together in a folder on your computer for easy access. You now have a very secure installation of Kickstart you can reuse every time you want to restore a site without having to think too hard about it. That's the way.
Side note (for the technically curious): If you followed the instructions above with this example password you may have noticed that the bcrypt hash you code differs from the one illustrated above. This is normal. The bcrypt hash consists of four things: a hash type identifier ($2y$), the cost factor of the algorithm (10 in the example above) followed by a dollar sign, a randomly generated "salt", and the actual password hash. All of them are included in the bcrypt hash string. Every time you generate a bcrypt hash for the same password, a different randomly generated salt is generated, which results in a different hash. Therefore, everything after the first two items ($2y$10$) will be different every time you generate the bcrypt hash of the same password. This is a security feature of the bcrypt hashing algorithm, as it prevents known hash attacks ("rainbow tables").
Kickstart versions prior to 9.0.1 enabled this feature only when using Akeeba Kickstart Professional. Kickstart 9.0.1 and later versions enable this feature regardless of whether you are using Akeeba Kickstart Core or Akeeba Kickstart Professional.
This feature DOES NOT apply in the CLI mode. The idea being that if an attacker can execute commands in the CLI they can easily figure out which filename you are using, therefore there is no point requiring you to rename the file anyway!
If you have not enabled password protection, Kickstart will refuse to run if its filename contains the terms kickstart, ks, or akeeba. If you do not want to enable password-protection, you need to rename Kickstart to a different filename which does not include these terms, e.g. something.php. Remember to change the URL to access Kickstart using the new filename.
If you get an HTTP 403 Forbidden error, please check the following. If you are using Admin Tools Professional's .htaccess Maker or Web Config Maker you will also need to remove or rename the .htaccess (Apache or Litespeed web server) or web.config (Microsoft IIS web server) file. The reason is that, by default, the generated configuration in those files will prevent access to Kickstart's renamed file. If you are using Admin Tools Professional's NginX Conf Maker (NginX web server) you will need to reconfigure your site on NginX, removing the custom code added by Admin Tools. If you are using a third party solution which prevents access to PHP files other than Joomla's/WordPress' index.php you will likewise need to disable it temporarily.
If you try to access Kickstart without renaming its file, and without having set up a password, it will refuse to run. Instead, it will show you a page reminding you to use a password, or rename the file.
To make things easier for you, it proposes a password which is generated using a secure random number generator (PHP's CS-PRNG exposed by the random_bytes() function), and gives you the content you need to add to the Kickstart configuration file.
Moreover, it proposes a fairly long, random filename to rename Kickstart to.
You can choose to follow either advice, or even both at the same time.
You should not allow random visitors to visit your site when the restoration is in progress. An (older) copy of Kickstart that's not secured with a password / uses a renamed file can be used to extract the archive again, which could disrupt your site restoration. Moreover, an arbitrary visitor may access the restoration script which can be problematic; at the very least, they could reset your restoration process, at worst they can take over your site.
Beyond the previously mentioned security features to ensure that archive extraction can be limited to authorised users, Akeeba Backup and Akeeba Solo offer two security features you can use. All versions allow you to set up a Restoration Script Password. This password will be requested before being able to access the restoration interface, thus preventing unauthorised users from disrupting or taking over your site restoration. The Professional versions also allow you to create JPS archives; these are encrypted, and cannot be extracted without a password. You should use these features whenever possible.
In case you are using Kickstart to extract a legacy archive which is not protected with a Restoration Script Password you should instead use Kickstart's Stealth Mode. This works on the Apache and Litespeed web servers only; that said, these are the web servers that more than the vast majority of commercial hosts are using. The Stealth Mode creates a .htaccess file which prevents access to the site from any IP other than yours.
Stealth Mode will not work properly if your server is behind a CDN, transparent proxy, or load balancer. In this case your web server does not see the real IP of the visitor; it always sees the IP of the CDN, transparent proxy, or load balancer. As a result, we urge you to always use the Restoration Script Password in your backup archives.
When the extraction is over, Kickstart shows you a button Run The Installer which opens the restoration script in a new browser tab or window. It also tells you to NOT close the tab / window where Kickstart is running.
After the restoration script is done extracting your file it asks you to close its window / tab and go back to Kickstart's tab / window. There, you will find the Clean Up button. Clicking on it will remove Kickstart, the backup archive, and the restoration script (the installation directory which was extracted into your site). YOU MUST ALWAYS DO THAT. If it fails to delete any of these items automatically, it will let you know so you can do it manually.
Never leave behind Kickstart, the backup archive, or the restoration script (the installation directory) when you are done restoring your site. This can be a security issue.
ALWAYS FOLLOW THE INSTRUCTIONS ON YOUR SCREEN TO REMOVE THESE ITEMS FROM YOUR SITE ONCE YOU ARE DONE RESTORING IT.
If you cannot complete the restoration immediately, or need to come back to it at a later time, you should remove these files and directory from your site. These items, when using all of the aforementioned security features, are safe for the limited time it takes to restore a site but none of them are designed to be left on your server for a very long period of time (several hours, days, or weeks). The password features DO NOT have a rate limiting. While extremely unlikely that an attacker can go through the entire search space when you're using long, randomly generated password, our experience is that people are generally bad at picking secure passwords or following our instructions on doing so. As a result, the typical insecure password selected by the majority of our users could be conceivably guessed by an attacker in a matter of a few hours at the longest. Hence our advice to remove these items from your site.
Please remember that while we give you features and apply technical measures to help you secure your site at every step of the backup and restoration process, you are ultimately in control of your security. We do not enforce the use of most security controls because there are legitimate use cases where they would get in the way.
We recommend that you always make use of the following features in Akeeba Backup / Akeeba Solo and Akeeba Kickstart whenever possible to maximise protection of your site:
Always use HTTPS to access your site when restoring a backup archive. Plain HTTP connections are unencrypted; this makes it possible for a number of attacks to be launched against you, compromising your site.
Always use a trusted device and web browser. If your device or browser is hacked so will your site.
The JPS encrypted archive format (Professional versions only).
Restoration Script Password.
Kickstart password protection, or renaming the Kickstart file.
ALWAYS REMOVE Kickstart, the backup archive, and the restoration script of your site when you are not actively restoring a backup.
Following these simple recommendations you can ensure a secure, trouble-free experience restoring your site.
Finally, we'd like to remind you that when you are using the integrated restoration in Akeeba Backup Professional and Akeeba Solo Professional you do not need to worry about Kickstart password protection, or renaming the Kickstart file. The extraction script used in this case is always protected by a password which is generated and used automatically. Moreover, when using the Site Transfer Wizard, Kickstart is uploaded renamed. All other points for ensuring your security during the restoration process remain valid even in these two use cases.