Possible Security Improvements

[safesploit]

A discussion around possible security improvements to Doogle

[safesploit]

Unique Salt for Each User

When user login is enabled consider looking at Valhalla2 which had a Salt class which handled the unique salt for each user: Valhalla2 used PBKDF2.

Having a unique salt for each user protects against:

• Preventing Rainbow Table Attacks: Without a unique salt, an attacker could use a precomputed table of hash values (a "rainbow table") to quickly look up the plaintext password for any given hash. By adding a unique salt to each password before it's hashed, you make these precomputed tables useless, because they would need to be computed for each possible salt value.

• Avoiding Hash Collisions: Even with different passwords, it's possible (though extremely unlikely) for two passwords to produce the same hash. This is called a "collision". By using a unique salt for each user, you drastically reduce the chances of a collision, because even if two users have the same password, their hashes will be different due to the unique salts.

When a user sets or changes their password, you should generate a new random salt.

[safesploit]

bcrypt could be a possible alternative too.

[safesploit]

Least Privilege Principle

Least Privilege Principle: Create separate users for different parts Doogle, each with only the permissions they need. This can limit the potential damage if one part of your application is compromised.

In the context of the MySQL database, this means creating separate database users for different parts of Doogle, each with a different set of permissions.

Present Configuration

At present the configuration focuses on convenience.
A new admin could easily forget to change the wildcard % for the host which is equivalent to 0.0.0.0/0.
Likewise, the compromise of doogle user's password would also allow full database access with permissions SELECT, INSERT and UPDATE.

CREATE USER IF NOT EXISTS 'doogle'@'%' IDENTIFIED BY 'PASSWORD_HERE';
GRANT SELECT, INSERT, UPDATE ON `doogle`.* TO 'doogle'@'%';

Potential Configuration Hardening

1. The web crawler (crawl.php and Crawler.php), which inserts and updates data in the sites and images tables.
2. The site search functionality (SiteResultsProvider.php and search.php), which reads data from the sites table to provide search results.
3. The image search functionality (ImageResultsProvider.php and search.php), which reads data from the images table to provide search results.
4. The link click tracking functionality (updateLinkCount.php), which updates data in the sites table.
5. The broken image tracking functionality (setBroken.php), which updates data in the images table.
6. The image click tracking functionality (updateImageCount.php), which updates data in the images table.

-- User for the web crawler
CREATE USER 'crawler_user'@'localhost' IDENTIFIED BY 'password1';
GRANT SELECT, INSERT, UPDATE ON doogle.sites TO 'crawler_user'@'localhost';
GRANT SELECT, INSERT, UPDATE ON doogle.images TO 'crawler_user'@'localhost';

-- User for the site search functionality
CREATE USER 'site_search_user'@'localhost' IDENTIFIED BY 'password2';
GRANT SELECT ON doogle.sites TO 'site_search_user'@'localhost';

-- User for the image search functionality
CREATE USER 'image_search_user'@'localhost' IDENTIFIED BY 'password3';
GRANT SELECT ON doogle.images TO 'image_search_user'@'localhost';

-- User for the link click tracking functionality
CREATE USER 'link_click_user'@'localhost' IDENTIFIED BY 'password4';
GRANT UPDATE ON doogle.sites TO 'link_click_user'@'localhost';

-- User for the broken image tracking functionality
CREATE USER 'broken_image_user'@'localhost' IDENTIFIED BY 'password5';
GRANT UPDATE ON doogle.images TO 'broken_image_user'@'localhost';

-- User for the image click tracking functionality
CREATE USER 'image_click_user'@'localhost' IDENTIFIED BY 'password6';
GRANT UPDATE ON doogle.images TO 'image_click_user'@'localhost';

It could be argued that users broken_image_user and image_click_user are redundant because they both perform GRANT UPDATE ON doogle.images, but I might argue this practice will allow for more granularity at a future date.

Potential New Management System (Needs more thought/new functionality)

Create a separate database user for each of these components, with permissions tailored to their specific needs:

-- User for registration and authentication
CREATE USER 'auth_user'@'localhost' IDENTIFIED BY 'password1';
GRANT SELECT, INSERT, UPDATE ON doogle.users TO 'auth_user'@'localhost';

-- User for content management
CREATE USER 'content_user'@'localhost' IDENTIFIED BY 'password2';
GRANT SELECT, INSERT, UPDATE, DELETE ON doogle.sites TO 'content_user'@'localhost';
GRANT SELECT, INSERT, UPDATE, DELETE ON doogle.images TO 'content_user'@'localhost';

-- User for reporting and analytics
CREATE USER 'reporting_user'@'localhost' IDENTIFIED BY 'password3';
GRANT SELECT ON doogle.users TO 'reporting_user'@'localhost';
GRANT SELECT ON doogle.sites TO 'reporting_user'@'localhost';
GRANT SELECT ON doogle.images TO 'reporting_user'@'localhost';

[safesploit]

Database Credentials

The database username and password are hard-coded in config.php. This isn't a secure practice, especially if the file is in a public directory on your web server. It would be better to store these credentials in a separate configuration file outside the web root, or in environment variables. Making sure the file permissions are set so that only the necessary users (such as the web server user) can read the file.

Why is this bad practice?

• If the codebase is ever exposed, either through an error or a misconfiguration on your web server, attackers could potentially view your code and gain access to your database.
• If the code is version-controlled, for example in Git (hint-hint), the credentials would be included in the commit history. This could expose your credentials to anyone who has access to the repository.
• Hard-coding credentials makes it difficult to change them quickly if necessary, and it also makes it difficult to use different credentials in different environments (for example, development, staging, and production).

To mitigate these risks, there are a few alternatives:

Environment Variables

One common approach is to store sensitive data like database credentials in environment variables. This separates sensitive data from
the code. Environment variables are also easy to change without modifying your code, which is especially useful if needing to use different credentials in different environments.

$dbuser = getenv('DB_USER');
$dbpass = getenv('DB_PASS');

You would then set these environment variables in your server's configuration.

Apache

The exact method will vary, but for Apache web server.

Using the SetEnv directive in your Apache configuration file or in an .htaccess file:

This directive sets environment variables that are available to your PHP scripts:

Apache configuration file (or .htaccess)

SetEnv DB_USER doogle
SetEnv DB_PASS mysecretpassword

Using the envvars file

Apache often uses an envvars file to set environment variables that are used when Apache starts. The location of this file depends on your operating system and Apache installation, but it's often located in the same directory as your main Apache configuration file, /etc/apache2 on Ubuntu.

export DB_USER=doogle
export DB_PASS=mysecretpassword

Note that this method sets environment variables that are available to Apache and all of its child processes, but these variables may not be accessible by the PHP scripts depending on the PHP configuration.

Using putenv in your PHP scripts

While this method doesn't involve Apache directly, environment variables can be set in PHP scripts using the putenv fucntion.
However, these environment variables will only be available for the duration of the script in which they're set.

Also, be aware that environment variables set this way are not encrypted, so anyone with access to these files will be able to see the credentials. Make sure to secure these files appropriately.

Configuration files

Store the credentials in a separate configuration file. This file should be stored outside the public directory of your web server to prevent it from being accessed directly from the web.

Here's an example of a configuration file (config.ini):

[database]
user = doogle
pass = PASSWORD_HERE

You can then read this file in config.php:

$config = parse_ini_file('/path/to/config.ini');
$dbuser = $config['user'];
$dbpass = $config['pass'];

Again, make sure the path to config.ini is outside the web root, and set the file permissions so that only the web server user can read it.

Secrets management systems

A little beyond the scope here, but an outline would be Kubernetes secrets vs environment variables.

[safesploit]

SQL User Hardening

🔐 Recommended Production User Roles for Doogle

Role	Use Case	Host	Permissions
doogle_app	Main web app frontend	localhost or app host IP	SELECT, INSERT
doogle_crawl	Crawler service (e.g. updating URLs/images)	App host / background job	SELECT, INSERT, UPDATE
doogle_read	For BI/reporting/dashboards	Read-only analytics host	SELECT only
doogle_admin	Admin/debug tools (very limited use)	Restricted to trusted ops IPs	ALL PRIVILEGES (scoped access)

---

-- Main app (frontend)
CREATE USER 'doogle_app'@'localhost' IDENTIFIED BY 'app_password';
GRANT SELECT, INSERT ON doogle.* TO 'doogle_app'@'localhost';

-- Web crawler
CREATE USER 'doogle_crawl'@'localhost' IDENTIFIED BY 'crawl_password';
GRANT SELECT, INSERT, UPDATE ON doogle.* TO 'doogle_crawl'@'localhost';

-- Read-only user (optional)
CREATE USER 'doogle_read'@'192.168.1.200' IDENTIFIED BY 'readonly_password';
GRANT SELECT ON doogle.* TO 'doogle_read'@'192.168.1.200';

-- Admin user (restricted host/IP)
CREATE USER 'doogle_admin'@'10.0.0.5' IDENTIFIED BY 'admin_password';
GRANT ALL PRIVILEGES ON doogle.* TO 'doogle_admin'@'10.0.0.5';

FLUSH PRIVILEGES;