Silverstripe security enhancements based on OWASP (+ NIST, PCI & ISO27001) guidelines

Most of this is based on various OWASP Authentication Cheat Sheets.

Installation

• Make sure youre logged in before deploying the files to the server (else you may run into problems logging in)
• Install using composer
• dev/build & flush
• activate the required configs

Authentication General Guidelines

• User IDs: Make sure your usernames/user IDs are case-insensitive @fw/default
• Set password validations sec-enh/conf
• Notify users of changed password/login name via e-mail (on both old & new email address if changed)
• Send out notification on change of email address as well (and various other security related events)
• Log & notify alterations to Member's Groups
• Add max password length (typically 128 to allow password phrases) to prevent long password Denial of Service attacks.
  • check if hashing before blowfish (nope), else the max password length before cutoff will be 72 (or 56) bytes -> 72 bytes indeed, set as max length
  • check with some unicode "correct battery horse staple Noël 💩 M̡̢̛̖̗̘̙̜̝̞̟̠̀́̂̃̄̅̆̇̉̊̋̌̍̎̏̐̑̒̓̔̕̚"
• Ensure credential rotation when a password leak: password expiry-on-next-login & randomized-reset task
  • Note: NIST/PCI requires & NIST recommends credential rotation enforcement at max every 90 days (ISO27k1 does not), but this is considered bad practice so only uncomment/apply these config settings if required...

Transport Layer Protection

"SSL", "SSL/TLS" and "TLS" are frequently used interchangeably, and in many cases "SSL" is used when referring to the more modern TLS protocol

• Require SSL connections for forms/submissions see Transmit Passwords Only Over TLS or Other Strong Transport
• Implement HSTS
• And other Security Headers & Silverstripe security headers
• Transmit Passwords Only Over TLS or Other Strong Transport

Protect Against Automated Attacks

Multi-factor authentication (MFA)

is by far the best defense against the majority of password-related attacks, including credential stuffing and password spraying, with analysis by Microsoft suggesting that it would have stopped 99.9% of account compromises. As such, it should be implemented wherever possible; however, depending on the audience of the application, it may not be practical or feasible to enforce the use of MFA.

In order to balance security and usability, multi-factor authentication can be combined with other techniques to require for 2nd factor only in specific circumstances where there is reason to suspect that the login attempt may not be legitimate, such as a login from:

• A new browser/device or IP address.
• An unusual country or location.
• Specific countries that are considered untrusted.
• An IP address that appears on known blacklists.
• An IP address that has tried to login to multiple accounts.
• A login attempt that appears to be scripted rather than manual.

CAPTCHA

The use of an effective CAPTCHA can help to prevent automated login attempts against accounts. However, many CAPTCHA implementations have weaknesses that allow them to be solved using automated techniques or can be outsourced to services which can solve them. As such, the use of CAPTCHA should be viewed as a defence-in-depth control to make brute-force attacks more time consuming and expensive, rather than as a preventative.

It may be more user-friendly to only require a CAPTCHA be solved after a small number of failed login attempts, rather than requiring it from the very first login.

Security Questions and Memorable Words

The addition of a security question or memorable word can also help protect against automated attacks, especially when the user is asked to enter a number of randomly chosen characters from the word. It should be noted that this does not constitute multi-factor authentication, as both factors are the same (something you know). Furthermore, security questions are often weak and have predictable answers, so they must be carefully chosen.

The Choosing and Using Security Questions cheat sheet contains further guidance on this.

IP Blacklisting

Less sophisticated attacks will often use a relatively small number of IP addresses, which can be blacklisted after a number of failed login attempts. These failures should be tracked separately to the per-user failures, which are intended to protect against brute-force attacks. The blacklist should be temporary, in order to reduce the likelihood of permanently blocking legitimate users.

Additionally, there are publicly available blacklists of known bad IP addresses which are collected by websites such as AbuseIPDB based on abuse reports from users.

Consider storing the last IP address which successfully logged in to each account, and if this IP address is added to a blacklist, then taking appropriate action such as locking the account and notifying the user, as it likely that their account has been compromised.

• Account Lockout Login Delay: exponential lockout delay, where the duration doubles after each failed login attempt sec-enh -> implemented as delay of the request response
• Account Lockout
  • Measures to prevent Account Lockout being used as a vector for DOS attacks
• Secondary Passwords, PINs and Security Questions
• Detection of Password Spraying or Credential Stuffing
• Require/recommend Silverstripe MFA module (SS4.1+ or tag 3.x for SS3.7+) or camfindlay/silverstripe-twofactorauth (2.x tag for SS3, SS4 deprecated)
• Experiment with Perishable Press 6/7G Firewall + (aggressive scanning uploads addon)
• Implement IP checking with Project Honey Pot (free, API key required) or AbuseIPDB (free <1000 reqs/day, API key required)
  
  See: https://packagist.org/packages/clash82/cachedhttpbl (13K installs, maintained)
  
  Or: https://packagist.org/packages/joshtronic/php-projecthoneypot (22K installs, stale but functional)
  
  Or: Use one of the free IP lists from Myip.ms (trustworthy?). This page shows three options to download, among which .htaccess and plaintxt format. Possibly auto-update .htaccess (little dangerous & rigorous), or just to check for blacklisted IPs and applying additional security.

Require Re-authentication for Sensitive Features

In order to mitigate CSRF and session hijacking, it's important to require the current credentials for an account before updating sensitive account information such as the user's password, user's email, or before sensitive transactions, such as shipping a purchase to a new address. Without this countermeasure, an attacker may be able to execute sensitive transactions through a CSRF or XSS attack without needing to know the user's current credentials. Additionally, an attacker may get temporary physical access to a user's browser or steal their session ID to take over the user's session.

• Re-authentication helper for Controllers-> this functionality seems implemented in the new MFA module;

Sudo mode

With the introduction of CMS permissions to manage MFA on a site, we’ve introduced ‘sudo mode’ for some actions, requiring a user to re-enter their password to avoid any malicious actions.

Security logging & reporting

It is important to keep audit records when password change requests were submitted. This includes whether or not security questions were answered, when reset messages were sent to users and when users utilize them. It is especially important to log failed attempts to answer security questions and failed attempted use of expired tokens. This data can be used to detect abuse and malicious behavior. Data such as time, IP address, and browser information can be used to spot trends of suspicious use.

Enable logging and monitoring of authentication functions to detect attacks/failures on a real-time basis

• Ensure that all failures are logged and reviewed

• Ensure that all password failures are logged and reviewed

• Ensure that all account lockouts are logged and reviewed

• Log CSP header violations: report-uri CSP header

From: OWASP Logging Cheat Sheet + look at sucuri and their WP plugin

• Events to log
  • [~] Input validation failures e.g. protocol violations, unacceptable encodings, invalid parameter names and values
  • [~] Output validation failures e.g. database record set mismatch, invalid data encoding
  • Authentication successes and failures
  • Authorization (access control) failures
  • Session management failures e.g. cookie session identification value modification
  • Application errors and system events e.g. syntax and runtime errors, connectivity problems, performance issues, third party service error messages, file system errors, file upload virus detection, configuration changes
  • Application and related systems start-ups and shut-downs, and logging initialization (starting, stopping or pausing)
  • [~] Use of higher-risk functionality e.g. network connections, addition or deletion of users, changes to privileges, assigning users to tokens, adding or deleting tokens, use of systems administrative privileges, access by application administrators,all actions by users with administrative privileges, access to payment cardholder data, use of data encrypting keys, key changes, creation and deletion of system-level objects, data import and export including screen-based reports, submission of user-generated content - especially file uploads
  • [~] Legal and other opt-ins e.g. permissions for mobile phone capabilities, terms of use, terms & conditions, personal data usage consent, permission to receive marketing communications
• Optionally (selection):
  • Excessive use
  • Data changes
  • Modifications to configuration
  • Application code file and/or memory changes
• What to log
  • When
    • Log date and time (international format)
    • Event date and time - the event time stamp may be different to the time of logging e.g. server logging where the client application is hosted on remote device that is only periodically or intermittently online
    • [~] Interaction identifier (all events belonging to one request/action)
  • Where
    • Application identifier e.g. name and version
    • Application address e.g. cluster/host name or server IPv4 or IPv6 address and port number, workstation identity, local device identifier
    • Service e.g. name and protocol
    • [~] Geolocation
    • Window/form/page e.g. entry point URL and HTTP method for a web application, dialogue box name
    • Code location e.g. script name, module name
  • Who (human or machine user)
    • Source address e.g. user's device/machine identifier, user's IP address, cell/RF tower ID, mobile telephone number
    • User identity (if authenticated or otherwise known) e.g. user database table primary key value, user name, license number
  • What
    • Type of event Note B
    • Severity of event Note B e.g. {0=emergency, 1=alert, ..., 7=debug}, {fatal, error, warning, info, debug, trace}
    • Security relevant event flag (if the logs contain non-security event data too)
    • Description
• Additionally consider recording:
  • [~] Secondary time source (e.g. GPS) event date and time
  • Action - original intended purpose of the request e.g. Log in, Refresh session ID, Log out, Update profile
  • Object e.g. the affected component or other object (user account, data resource, file) e.g. URL, Session ID, User account, File
  • Result status - whether the ACTION aimed at the OBJECT was successful e.g. Success, Fail, Defer
  • Reason - why the status above occurred e.g. User not authenticated in database check ..., Incorrect credentials
  • HTTP Status Code (web applications only) - the status code returned to the user (often 200 or 301)
  • Request HTTP headers or HTTP User Agent (web applications only)
  • User type classification e.g. public, authenticated user, CMS user, search engine, authorized penetration tester, uptime monitor (see "Data to exclude" below)
  • [~] Analytical confidence in the event detection Note B e.g. low, medium, high or a numeric value
  • [~] Responses seen by the user and/or taken by the application e.g. status code, custom text messages, session termination, administrator alerts
  • [~] Extended details e.g. stack trace, system error messages, debug information, HTTP request body, HTTP response headers and body
  • [~] Internal classifications e.g. responsibility, compliance references
  • [~] External classifications e.g. NIST Security Content Automation Protocol (SCAP), Mitre Common Attack Pattern Enumeration and Classification (CAPEC)

Various

Account Lockout

The counter of failed logins should be associated with the account itself, rather than the source IP address, in order to prevent an attacker from making login attempts from a large number of different IP addresses. There are a number of different factors that should be considered when implementing an account lockout policy in order to find a balance between security and usability:

The number of failed attempts before the account is locked out (lockout threshold).
The time period that these attempts must occur within (observation window).
How long the account is locked out for (lockout duration).
Rather than implementing a fixed lockout duration (e.g., ten minutes), some applications use an exponential lockout, where the lockout duration starts as a very short period (e.g., one second), but doubles after each failed login attempt.

When designing an account lockout system, care must be taken to prevent it from being used to cause a denial of service by locking out other users' accounts. One way this could be performed is to allow the user of the forgotten password functionality to log in, even if the account is locked out.

Identifying Leaked Password

When a user sets a new password on the application, as well as checking it against a list of known weak passwords, it can also be checked against passwords that have previously been breached. The most well known public service for this is Pwned Passwords. You can host a copy the application yourself, or use the API.

In order to protect the value of the source password being searched for, Pwned Passwords implements a k-Anonymity model that allows a password to be searched for by partial hash. This allows the first 5 characters of a SHA-1 password hash to be passed to the API.

• Check/validate new passwords against passwords that have previously been breached: HIBP
• Ensure credential rotation at the time of compromise identification: check HIBP on login
  • @todo: enforce credential rotation (right now it gets 'suggested' by expiring the password but is is possible to ignore this and keep being logged in and using the system)

Password Managers

Web applications should at least not make password managers job more difficult than necessary by observing the following recommendations:

• Use standard HTML forms for username and password input with appropriate type attributes.
• Avoid plugin-based login pages (such as Flash or Silverlight).
• Allow long passwords (at least 64 characters)
  • For this we need to (SHA?) hash the passwords before encrypting them with blowfish (which has a max password length of 72, after which additional characters will be ignored)
  • 'LongPassword' handling will need to be implemented around Security::encrypt_password() or PasswordEncryptor::create_for_algorithm(), or in the blowfish encryptor implementation(?)
• Allow any printable characters to be used in passwords.
• Allow users to paste into the username and password fields.
• Allow users to navigate between the username and password field with a single press of the Tab key.

Compare Password Hashes Using Safe Functions

Where possible, the user-supplied password should be compared to the stored password hash using a secure password comparison function provided by the language or framework, such as the password_verify() function in PHP. Where this is not possible, ensure that the comparison function:

• Has a maximum input length, to protect against denial of service attacks with very long inputs.
• Explicitly sets the type of both variable, to protect against type confusion attacks such as Magic Hashes in PHP.
• Returns in constant time, to protect against timing attacks.

SDM (Some Day Maybe)

• Email address / User ID Validation (maybe altering flow to validate e-mail address by clicking emailed link)
• User IDs: For high-security applications, usernames could be assigned and secret instead of user-defined public data
• Consider Strong Transaction Authentication
  Some applications should use a second factor to check whether a user may perform sensitive operations. For more information, see the Transaction Authorization Cheat Sheet.
  • TLS Client Authentication (optional)
• Facilitate side channel like SMS or secondary e-mail for receiving tokens
• Require Re-authentication for Sensitive Features (reauth is needed to change password, should also be to change e-mail/primary ID)
• Add password strength indicator eg zxcvbn.js (unmaintained) or comparable

Notes / inspiration / developments

• Silverstripe is getting its commercial products ISO27001
  certified (p34) – this will have flow-on benefits to Silverstripe CMS
• Silverstripe is looking at automated vulnerability scanning
• Snyk vulnerability scanning may be interesting
• silverleague/silverstripe-logviewer module SilverStripe log entries in the CMS (hooks into Monolog\Logger).
• Apache/PHP level WAFs cannot give a very high level of protection but might be worth investigating: Perishable Press 6/7G Firewall (recent aggressive scanning uploads addon) is included in the Wordpress All In One WP Security & Firewall module and works by filtering requests via .htaccess rules (makes sense). Another project is Shieldon (this is a single dev PHP project which doesn't seem too convincing...). A far better approach to implemented WAF would be at server level, eg OWASP ModSecurity Core Rule Set (CRS).

Silverstripe password config

From SilverStripe 4.3 onwards, the default password validation rules are configured in the framework's passwords.yml file. You will need to ensure that your config file is processed after it. For SilverStripe <4.3 you will need to use a _config.php file to modify the class's config at runtime (see _config.php installed in your mysite/app folder if you're using silverstripe/recipe-core).

See: Silverstripe security