Security Module for Altis
Home Page: https://www.altis-dxp.com/resources/docs/security/
SecuritySecurity features for Altis.
The security module provides high-level security focused features to Altis. It is not meant to "make Altis secure", and all other modules and components of Altis should be secure in their own right. This module is concerned with security features such as Multi Factor Authentication, Password Strength Rules, Password Expiration, Audit Logging etc.
![dependabot-preview[bot] avatar](https://avatars.githubusercontent.com/in/2141?v=4 "dependabot-preview[bot]")
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot]")
Steps to reproduce:
something.altis.cloud/some/pathI expected a functional 2FA form. Instead, we see 404s for all the two-factor plugin scripts and styles, because they get registered as,
https://subdomain.site.altis.cloud/sub/directory/vendor/humanmade/two-factor/assets/js/force-2fa.js
instead of
https://subdomain.site.altis.cloud/vendor/humanmade/two-factor/assets/js/force-2fa.js
The two-factor plugin (both our fork and the upstream copy) use plugins_url( '...blah.js', __FILE__ ) to deduce the URL for the asset. That resolves to full/site/path/vendor... instead of /vendor... when used in an Altis site where the plugin is installed to vendor/humanmade/two-factor.
Acceptance criteria:
This plugn hasn't been working properly and can result in db writes during logins - this is a problem during brute force login attempts.
We have infra level protection already anyway so it's somewhat superfluous.
Related to #79
If you click the wp-signup/activate link in the email, require-login will redirect you to login first.
Original report from @fklein-lu
Describe the bug
This error is generated when running the CLI command wp core multisite-convert when migrating a single site install to Altis.
PHP Fatal error: Uncaught Error: Call to undefined function Altis\Security\get_site() in /usr/src/app/vendor/altis/security/inc/namespace.php:84
To Reproduce
Steps to reproduce the behavior:
wp core multisite-convertExpected behavior
The command should be successful with no errors.
Steps to reproduce:
There should be a prompt to enter the username and password.
I think the way environment checks are incorporated into the plugin is very confusing. Environments should be opted in to explicitly by type or globally as required.
In the meantime though the plugin integration should be fixed so that the docs are accurate.
Acceptance criteria:
Currently the filter apply_filters( 'hm-require-login.allowed_pages', $allowed, $page ); is undocumented, we should add that and explain it's use cases.
This is good for tracking which action was caused by what request, if we ever needed to get more data.
It's impossible to disable require-login on a non-public site. This means it's not possible to have a site that is publicly accessible but blocked to search engines, because it will always require visitors to be logged in to access it.
Related docs: https://docs.altis-dxp.com/security/require-login/#overrides
Steps to reproduce:
require-login:
"modules": {
"security": {
"require-login": false
}
}
Discourage search engines from indexing this site checkboxrequire-login being falseProblem code:
altis-security/inc/namespace.php
Lines 39 to 41 in 700050b
altis-security/inc/namespace.php
Lines 79 to 84 in 700050b
Altis Security versions linked to Altis on WP 5.6+ should require hm-require-login 1.0.4 which has fixes for the applications password feature that debuted with WP 5.6. Otherwise it's possible to pin Altis Security to a version that breaks APW support.
Steps to reproduce:
require-login in the Altis config.http OPTIONS /wp-json/ -H 'Cookie: wordpress_logged_in.... request (psuecode)Expected:
Allow HTTP header should be presentAcceptance criteria:
The code that is causing this is in https://github.com/humanmade/hm-require-login/blob/master/inc/namespace.php#L21, as you can see, it will shortcircuit all REST API OPTIONS requests regardless of whether the user is logged in.
As far as I can tell, all those REST API exceptions should be placed below the logged in checks at https://github.com/humanmade/hm-require-login/blob/master/inc/namespace.php#L49-L61
This ticket addresses the issues raised by the documentation linting
composer dev-tools lintdocs all -l packages/security
File Issues:
None
Markdown issues:
Linting: 8 file(s)
Summary: 284 error(s)
Style issues:
11 errors, 0 warnings and 0 suggestions in 8 files.
The require-login functionality can't be disabled. While the value can be set to true in the config, this enables it on all sites. There's no reverse of this to disable the functionality altogether.
hm-limit-login-attempts does not appear to be functioning as designed. A support request came in describing being able to attempt a log in more than 5 times. I've been able to reproduce the issue by attempting logging in with bogus credentials on a test environment. Often It simply reset the counter to "3 attempts remaining." Other times it'd say "too many failed login attempts," and on the subsequent request display another counter. Eventually, our nginx configuration kicks in and blocks the repeated attempts.
Steps to reproduce:
Describe what you expected to see:
User is blocked from an attempted login.
Screenshots are helpful too if the bug is visual:
I have one recording that's more in line with my original description, but it had information from 1Password I didnt want to expose. This one is more sanitized, but with less of what I observed:
Acceptance criteria:
Acceptance criteria:
The recommended setup is to define everything in your composer.json file, including the username and passwords. The same configuration in the below, manual setup example could be handled in the Composer file like this:
https://github.com/humanmade/altis-security/blob/master/docs/basic-auth.md
The recommended setup is to define everything in your composer.json file, including the username and passwords. The same configuration in the manual setup example below, could be handled in the Composer file like this:
Generate Verification Codes and Register New Key links are overlapping each other in the top-right of the screen.
Logout link is obscured by the Query Monitor bar.
Acceptance criteria:
Steps to reproduce:
The site should have Basic Auth required, however it does not.
This is due to the merging of the config always setting the php-basic-auth config rather than using environment overrides correctly, which means it then has environment-specific behaviour. Due to this, you cannot enable it on production per the docs.
I'm filing a hotfix for this which explicitly checks the environment configuration, but we should look at reworking this to be standard instead.
Acceptance criteria:
Notice: Undefined index: host in /usr/src/app/vendor/humanmade/two-factor/providers/class.two-factor-fido-u2f.php on line 95
Seen when starting local server.
I think it's not clear enough to not include at least the "security": key.
{
"limit-login-attempts": false
}
https://www.altis-dxp.com/resources/docs/security/limit-login-attempts/#enabledisable
"extra": {
"altis": {
"modules": {
"security": {
"limit-login-attempts": false
}
}
}
}
or
"extra": {
"altis": {
"modules": {
//... other config options
"security": {
"limit-login-attempts": false
}
// ... other config options
}
}
}
When a user gets added or invited to a site which requires multi-factor authentication to be enabled on their account, the initial MFA setup workflow is very confusing. It appears to be optimised for allowing users to use more than one MFA method, but I would expect the most common use case is using one MFA method.
This is the interstitial MFA configuration screen that a user sees after signing in for the first time. You can trigger this on an account by deleting the _two_factor_* user meta fields for a user.
The two-factor auth plugin expects to be installed as a normal WP plugin (or MU plugin), and there are some issues with generating the correct URLs for the plugin modules in a subdirectory multisite environment. Additionally, if for whatever reason the /vendor directory is not accessible over HTTP due to client domain configuration, the two-factor system does not work at all.
It would be helpful to have some way to "proxy" the scripts, or load them from a virtual route within the site domain, rather than hitting vendor/ directly.
Audit Log doesn't really need to be a top-level menu; can we move it under either Tools or Settings?
From an internal survey:
Retain deleted users so that posts and Stream logs continue to show a history of users for audit trails
(HMers can see the internal issue below.)
We could filter the authentication cookies to be set with the secure flag and also to be HTTP Only which prevents accessing the cookies from client side script.
https://www.owasp.org/index.php/HttpOnly
Equivalent PHP ini directives.
ini_set('session.cookie_httponly', true);
ini_set('session.cookie_secure', true);
ini_set('session.use_only_cookies', true);Wanted to note this idea down while it was fresh in my head.
At the cybersec conference I was at the holy grail for 2FA was to keep everything "in-band" eg. encrypted network traffic between the user and the app only rather than going "out-of-band" via email or sms. Web push / desktop notifications would be the way to achieve this.
Granted not an issue really when using 1pass with the 1 time password field but this method might actually be easier to set up / use for some people and would be an interesting one to explore.
One for down the line.
Some non-production sites are being indexed unintentionally, or at least some content is as the require login and basic auth features both block access to robots.txt which is generated by WP.
Acceptance criteria:
User-agent: *
Disallow: /
For WordPress' Export Personal Data feature, perhaps we should also include all the stream entries that have to do with that user, as this probably counts as their data.
Steps to reproduce:
It #turnsout that the currently selected options are for the current user, not the user you are editing, so though updating a user will work, you won't see the changes. And if you were to go update that user's name or something, they would be, by default, updated with the current user's options.
This is happening in https://github.com/humanmade/two-factor/blob/force-2fa/class.two-factor-core.php#L625 get_available_providers_for_user takes a WP_User object, not an id, and this function falls backs to the current user.
After finishing the setup and visiting the admin, I see a notification: `
The plugin stream/stream.php has been deactivated due to an error: Plugin file does not exist.
There is an existing project here by Zach Tollman, we couldd consider integrating a CSP reporting service into Altis itself https://github.com/tollmanz/wordpress-https-mixed-content-detector
This may at least initially be valuable for local builds and easier to incorporate at this level.
We currently don't document the ways in which the require login feature affects the behaviour of the public/private site setting in WordPress. This is used to prevent search engine indexing typically but can be confusing because it hard codes the
"Discourage search engines" option value even though it looks like it can be changed in the admin still.
We should provide an easy way to configure the content security policy.
As inspiration:
When resetting a lost password through wp-login.php, it is possible to use a weak password by ticking the 'Confirm use of weak password' box.
When resetting through the user's profile, the confirmation box has been removed to enforce a strong password. We should remove the checkbox here too.
Tested on a fresh local install of V9 (screenshot above) and an existing client project on Altis V8. Screencast available in Slack.
2fa has options to force-require it for all users, and also on a per-role basis. This is done via the network admin atm, but we should add support for configuring via the platform config.
Currently the private flag is all-or-nothing, so can't be activated on a per-site basis.
We can instead use the private flag of the site, which is how our other solutions for this work. Upstream issue at humanmade/hm-require-login#5
Steps to reproduce:
WP_Application_Passwords::is_in_use() to return true by setting the using_application_passwords network setting)Publicly-accessible API endpoints should be accessible; instead, they return a 401.
This is increased priority, as if sending REST API requests from the browser, the 401 returned by Application Passwords causes the browser's internal auth cache to be reset, which requires users to log in again repeatedly.
Basic Auth should take priority here as it's site-wide, but this will mean that Application Passwords can't actually be used in combination. I think that's an acceptable compromise, as regular Require Login can be used in those cases instead, but we should ensure it's documented.
Acceptance criteria:
/wp-json/) should return a 200 responseSeems to be after updating to the official package, we will need to hook into either wp altis migrate or some other hook to ensure the tables are created just in time.
Steps to reproduce:
https://github.com/humanmade/altis-security/blob/master/inc/namespace.php#L108
The line above code is like below:
if ( is_array( $config ) && ( ! empty( $config['required'] ) || is_bool( $config['required'] ) ) ) {
return $config['required'];
}
May be this condition means "config is array and 'required' param is set, use it".
But this condition test config with is_bool() in spite of non-existent key. This causes notice message.
It's better.
if ( is_array( $config ) && isset( $config['required'] ) && is_bool( $config['required'] ) ) {
return $config['required'];
}
Thanks!
I noticed this item in the debug log, but I'm not able to reproduce - might've been only at setup as I've recently setup the local server from scratch
[01-Jul-2020 13:45:51 UTC] WordPress database error Table 'wp_stream' already exists for query CREATE TABLE wp_stream (
ID bigint(20) unsigned NOT NULL AUTO_INCREMENT,
site_id bigint(20) unsigned NOT NULL DEFAULT '1',
blog_id bigint(20) unsigned NOT NULL DEFAULT '1',
object_id bigint(20) unsigned NULL,
user_id bigint(20) unsigned NOT NULL DEFAULT '0',
user_role varchar(50) NOT NULL DEFAULT '',
summary longtext NOT NULL,
created datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
connector varchar(100) NOT NULL,
context varchar(100) NOT NULL,
action varchar(100) NOT NULL,
ip varchar(39) NULL,
PRIMARY KEY (ID),
KEY site_id (site_id),
KEY blog_id (blog_id),
KEY object_id (object_id),
KEY user_id (user_id),
KEY created (created),
KEY connector (connector),
KEY context (context),
KEY action (action)
) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_520_ci made by include('phar:///usr/local/bin/wp/php/boot-phar.php'), include('phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/wp-cli.php'), WP_CLI\bootstrap, WP_CLI\Bootstrap\LaunchRunner->process, WP_CLI\Runner->start, WP_CLI\Runner->load_wordpress, require('wp-settings.php'), do_action('init'), WP_Hook->do_action, WP_Hook->apply_filters, WP_Stream\Install->verify_db, do_action('wp_stream_before_db_notices'), WP_Hook->do_action, WP_Hook->apply_filters, WP_Stream\Install->check, WP_Stream\Install->install, dbDelta, Altis\Cloud\DB->query, wpdb->print_error
It doesn't seem to break anything obvious and the audit log is displayed normally
We should add a framework for Sub-Resource Integrity (SRI). This adds an integrity parameter to script/link[rel=style] tags which contains a hash of the resource, allowing sites to avoid being MITM'd as well as CDNs changing assets out on you.
For assets loaded from the filesystem, we can automatically generate integrity hashes and serve these up. We should disable this behaviour for local environments, as it's common to change assets without bumping the version.
For external assets, we can provide an API for registering integrity hashes.
With 3.4.3 the Composer releases now include built assets, so we can move off our fork.
Noted by @jazzsequence in the frontend guild hangout we can make it easy to help prevent click-jacking by sending the X-Frame-Options header from the CMS.
We should default to sameorigin, and add documentation for setting deny or allow from <url>.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options
In some cases require-login isn't the best solution to building and developing a site. You may need to test authentication scenarios on staging / dev servers for instance.
@jazzsequence has built a PHP Basic Auth plugin that would be straightforward to integrate and configure as an Altis feature.
https://github.com/humanmade/PHPBasicAuth
Acceptance criteria:
composer.json config, off by defaultcomposer.jsonWhen a password is not strong enough, the submit button on the profile page is disabled. We need to be clearer about this, as particularly on long profile pages, it may not be obvious why the button is disabled.
Suggested microcopy: "Your password does not meet the minimum requirements. Please select a stronger password."
If a user tried to change their password to something considered too weak, they are unable to update their profile. There is no error state to tell them why this is the case.
With regular WordPress, there is a checkbox that the user must check to confirm the password. This appears and disappears depending on the password strength, drawing the users attention to it.
As this functionality has been removed, we should instead show an additional warning that the password is not accepted.
Acceptance criteria:
The Stream plugin only creates its tables on activation, and the way it is used in this project, that step will never necessarily be hit. This means that (especially in local environments) you can end up in a situation where you have no DB tables for stream, and your errors are littered with warnings about it.
Steps to reproduce:
composer server cli -- db clean and reinstall your local install, or import a databaseWordPress database error Table 'wordpress.wp_stream' doesn't exist
I would expect to see no errors of this type, because I would expect the Altis Security module to orchestrate ensuring the tables are present if they did not previously exist.
As a stopgap for now, you can manually recreate these tables by invoking the stream plugin activation directly:
wp_stream_get_instance()->install->check();
Acceptance criteria:
Shout-out to @tomjn for figuring this one out, this issue documents discussion we just had in Slack. Tom has opened a related issue on the upstream Stream repo (two of them, actually), but this is something we could fix at this level, too.
I assume this must've been a merging issue. PHP Basic Auth is not being required in the composer file so when the autoload fires, it throws an error file not found.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.