← All changes | includes/class-settings.php +287 -1 2.11.9 → 2.11.12 View file →

		@@ -869,12 +869,278 @@
869	869	* @since 2.11.8 The file_integrity module and scan_critical_config.
870	870	*
871	871	* @return array<string,string[]>
872	872	*/
	873	+ /**
	874	+ * The two factor policy that governs this installation
	875	+ *
	876	+ * On a network the answer must not depend on which site the login happens to
	877	+ * arrive at, because the cookie WordPress issues does not: COOKIEHASH comes
	878	+ * from the network siteurl (wp-includes/default-constants.php) and
	879	+ * COOKIE_DOMAIN covers every host of the network
	880	+ * (wp-includes/ms-default-constants.php). Until 2.11.10 the settings, the
	881	+ * enforced roles and the TOTP table were all read per site, so somebody
	882	+ * holding the password of an administrator protected by 2FA on the main site
	883	+ * posted the login to a subsite where that account has no role, was never
	884	+ * asked for a code, and came out with a session valid across the network.
	885	+ * Measured on the Multisite install on 12 sep 2026 (user_requires_2fa true on
	886	+ * the main site, false on demo2 for the same account) and found by the
	887	+ * file-by-file review of 2.11.10.
	888	+ *
	889	+ * So the policy of the main site governs the whole network. On a single site
	890	+ * this is the site's own configuration and nothing changes.
	891	+ *
	892	+ * @since 2.11.10
	893	+ *
	894	+ * @return array The two_factor section that applies.
	895	+ */
	896	+ public static function two_factor_policy() {
	897	+ $options = is_multisite()
	898	+ ? get_blog_option( get_main_site_id(), self::OPTION_NAME, array() )
	899	+ : get_option( self::OPTION_NAME, array() );
	900	+
	901	+ if ( ! is_array( $options ) ) {
	902	+ return array();
	903	+ }
	904	+
	905	+ $login = isset( $options['login_security'] ) && is_array( $options['login_security'] )
	906	+ ? $options['login_security']
	907	+ : array();
	908	+
	909	+ return ( isset( $login['two_factor'] ) && is_array( $login['two_factor'] ) ) ? $login['two_factor'] : array();
	910	+ }
	911	+
	912	+ /**
	913	+ * Whether two factor is required for this account, anywhere in the network
	914	+ *
	915	+ * Union, and deliberately so. Reading the policy only from the main site,
	916	+ * which is what this release did at first, would have switched two factor off
	917	+ * for every network that has it configured per subsite, which until now was
	918	+ * the only way it could be configured at all: a silent downgrade of the very
	919	+ * protection being fixed. Found by the cross review of 2.11.10. So the
	920	+ * question is asked of every site the account belongs to, plus the main site,
	921	+ * each with its own enforced roles and exclusions, and one yes is enough.
	922	+ *
	923	+ * That also closes the bypass: the settings, the roles and the enrolment used
	924	+ * to be read from whichever site the login arrived at, while the cookie
	925	+ * WordPress issues is valid across the whole network (COOKIEHASH comes from
	926	+ * the network siteurl and COOKIE_DOMAIN covers every host of it), so an
	927	+ * account protected on one site could log in through another and come out
	928	+ * with a session valid everywhere.
	929	+ *
	930	+ * @since 2.11.10
	931	+ *
	932	+ * @param WP_User $user User being authenticated.
	933	+ * @return bool
	934	+ */
	935	+ public static function two_factor_required_for( $user ) {
	936	+ return array() !== self::two_factor_demands_for( $user );
	937	+ }
	938	+
	939	+ /**
	940	+ * Which second factor methods this account is asked for, across the network
	941	+ *
	942	+ * Empty when nothing asks. On a network there can be more than one, because
	943	+ * each site keeps its own settings and the requirement is the union of them.
	944	+ *
	945	+ * @since 2.11.10
	946	+ *
	947	+ * @param WP_User $user User being authenticated.
	948	+ * @return string[] Methods asked for, without repeats.
	949	+ */
	950	+ public static function two_factor_methods_for( $user ) {
	951	+ $methods = array();
	952	+
	953	+ foreach ( self::two_factor_demands_for( $user ) as $settings ) {
	954	+ $method = isset( $settings['method'] ) ? (string) $settings['method'] : 'email';
	955	+
	956	+ // A method this version does not know is read as the default rather
	957	+ // than left to fall through. Registering nothing at all is how the
	958	+ // second factor of a whole network went quiet in silence: a saved
	959	+ // value of '' (which validate_section() lets through on an import,
	960	+ // since only the tab has an allowlist) matched neither class, so no
	961	+ // filter was registered anywhere while every screen still said two
	962	+ // factor was on. Found by the third cross review of 2.11.10.
	963	+ $methods[] = in_array( $method, array( 'email', 'totp' ), true ) ? $method : 'email';
	964	+ }
	965	+
	966	+ return array_values( array_unique( $methods ) );
	967	+ }
	968	+
	969	+ /**
	970	+ * Which of the two second factor classes handles this login
	971	+ *
	972	+ * The method cannot be read from one site's settings, and reading it from the
	973	+ * main site was the hole the third cross review of 2.11.10 found: with the
	974	+ * main site on totp and a subsite asking for a code by email, the class that
	975	+ * registered was TOTP, the account had no enrolment, and the "not set up yet"
	976	+ * branch let the login through. In 2.11.9 that same login was asked for its
	977	+ * emailed code. So the question is asked per account, not per site.
	978	+ *
	979	+ * The order is what keeps it closed at both ends:
	980	+ *
	981	+ * 1. An enrolment already made wins while some site asking for a second
	982	+ * factor asks for an authenticator app. It is the strongest factor the
	983	+ * account has and it is ready to use, wherever in the network it was set
	984	+ * up.
	985	+ * 2. Otherwise, if any site asking for a second factor asks for email, email
	986	+ * handles it. Email needs no enrolment, so it can never fall into the
	987	+ * branch that lets a login through for lack of one.
	988	+ * 3. Only when every site asking wants an authenticator app does TOTP handle
	989	+ * it, which is the case the grace period was written for.
	990	+ *
	991	+ * The condition on the first step came in 2.11.11. Without it an enrolment
	992	+ * left from a time when the site asked for an app outranked the method the
	993	+ * site asks for now: a single site set to email asked those accounts for an
	994	+ * authenticator code, which 2.11.9 never did and which locks out whoever
	995	+ * removed the app after the switch. Dropping that enrolment opens nothing,
	996	+ * because the account then goes to email, which needs no enrolment.
	997	+ *
	998	+ * @since 2.11.10
	999	+ * @since 2.11.11 An enrolment only wins while an authenticator app is asked for.
	1000	+ *
	1001	+ * @param WP_User $user User being authenticated.
	1002	+ * @param bool $enrolled Whether the account has a TOTP enrolment anywhere.
	1003	+ * @return string 'email', 'totp', or '' when nothing asks.
	1004	+ */
	1005	+ public static function two_factor_handler_for( $user, $enrolled ) {
	1006	+ $methods = self::two_factor_methods_for( $user );
	1007	+
	1008	+ if ( ! $methods ) {
	1009	+ return '';
	1010	+ }
	1011	+
	1012	+ if ( $enrolled && in_array( 'totp', $methods, true ) ) {
	1013	+ return 'totp';
	1014	+ }
	1015	+
	1016	+ return in_array( 'email', $methods, true ) ? 'email' : 'totp';
	1017	+ }
	1018	+
	1019	+ /**
	1020	+ * The two factor settings of every site that asks this account for one
	1021	+ *
	1022	+ * @since 2.11.10
	1023	+ *
	1024	+ * @param WP_User $user User being authenticated.
	1025	+ * @return array[] The two_factor section of each site that asks.
	1026	+ */
	1027	+ private static function two_factor_demands_for( $user ) {
	1028	+ if ( empty( $user->ID ) ) {
	1029	+ return array();
	1030	+ }
	1031	+
	1032	+ if ( ! is_multisite() ) {
	1033	+ $roles = ( isset( $user->roles ) && is_array( $user->roles ) ) ? $user->roles : array();
	1034	+ $policy = self::two_factor_policy();
	1035	+
	1036	+ return self::two_factor_site_requires( $policy, $user, $roles ) ? array( $policy ) : array();
	1037	+ }
	1038	+
	1039	+ $demands = array();
	1040	+ $blog_ids = array( (int) get_main_site_id() );
	1041	+
	1042	+ /*
	1043	+ * A super administrator is a member of almost no site (measured on the
	1044	+ * Multisite install: of three sites, the network owner belongs to one),
	1045	+ * yet can log in through any of them and the cookie is valid everywhere.
	1046	+ * Asking only the sites they belong to left the account with the most
	1047	+ * power in the network outside the policy, which is the bypass upside
	1048	+ * down. So for them every site of the network is consulted. There are
	1049	+ * few super administrators. It does not only run at login, though, which
	1050	+ * this note claimed until 2.11.11: the dashboard hooks of the TOTP class
	1051	+ * ask it on every admin screen of every site of a network, at least once
	1052	+ * per hook.
	1053	+ */
	1054	+ if ( is_super_admin( $user->ID ) ) {
	1055	+ $blog_ids = array_merge( $blog_ids, get_sites( array( 'fields' => 'ids', 'number' => 200 ) ) );
	1056	+ }
	1057	+
	1058	+ foreach ( get_blogs_of_user( $user->ID ) as $blog ) {
	1059	+ if ( ! empty( $blog->userblog_id ) ) {
	1060	+ $blog_ids[] = (int) $blog->userblog_id;
	1061	+ }
	1062	+ }
	1063	+
	1064	+ foreach ( array_unique( $blog_ids ) as $blog_id ) {
	1065	+ $options = get_blog_option( $blog_id, self::OPTION_NAME, array() );
	1066	+
	1067	+ if ( ! is_array( $options ) || empty( $options['login_security']['two_factor'] ) ) {
	1068	+ continue;
	1069	+ }
	1070	+
	1071	+ /*
	1072	+ * A site whose Login Security module is off asks for nothing, and
	1073	+ * reading only the sub-setting made it ask anyway: a subsite that had
	1074	+ * switched the whole module off, leaving an orphan two_factor.enabled
	1075	+ * behind, imposed a second factor on every account of the network,
	1076	+ * with no screen anywhere explaining why. It is the two-level toggle
	1077	+ * trap of this plugin read upside down. Found by the third cross
	1078	+ * review of 2.11.10.
	1079	+ */
	1080	+ if ( empty( $options['modules']['login_security'] ) ) {
	1081	+ continue;
	1082	+ }
	1083	+
	1084	+ $elsewhere = new WP_User( $user->ID );
	1085	+ $elsewhere->for_site( $blog_id );
	1086	+
	1087	+ // A super administrator can hold no role row anywhere, and is judged
	1088	+ // as an administrator so the strictest policy of the network reaches
	1089	+ // the account with the most power in it.
	1090	+ $roles = ( isset( $elsewhere->roles ) && is_array( $elsewhere->roles ) && $elsewhere->roles )
	1091	+ ? $elsewhere->roles
	1092	+ : ( is_super_admin( $user->ID ) ? array( 'administrator' ) : array() );
	1093	+
	1094	+ if ( self::two_factor_site_requires( $options['login_security']['two_factor'], $user, $roles ) ) {
	1095	+ $demands[] = $options['login_security']['two_factor'];
	1096	+ }
	1097	+ }
	1098	+
	1099	+ return $demands;
	1100	+ }
	1101	+
	1102	+ /**
	1103	+ * Whether one site's two factor settings cover this account
	1104	+ *
	1105	+ * @since 2.11.10
	1106	+ *
	1107	+ * @param array $settings The two_factor section of one site.
	1108	+ * @param WP_User $user User being authenticated.
	1109	+ * @param string[] $roles Roles the account holds on that site.
	1110	+ * @return bool
	1111	+ */
	1112	+ private static function two_factor_site_requires( $settings, $user, $roles ) {
	1113	+ if ( ! is_array( $settings ) || empty( $settings['enabled'] ) ) {
	1114	+ return false;
	1115	+ }
	1116	+
	1117	+ $excluded = isset( $settings['excluded_users'] ) ? array_map( 'absint', (array) $settings['excluded_users'] ) : array();
	1118	+
	1119	+ if ( in_array( (int) $user->ID, $excluded, true ) ) {
	1120	+ return false;
	1121	+ }
	1122	+
	1123	+ $enforced = isset( $settings['enforced_roles'] ) ? (array) $settings['enforced_roles'] : array( 'administrator', 'editor' );
	1124	+
	1125	+ return (bool) array_intersect( (array) $roles, $enforced );
	1126	+ }
	1127	+
	1128	+ /**
	1129	+ * Settings that only a network administrator may change on the main site
	1130	+ *
	1131	+ * @return array<string,string[]>
	1132	+ */
873	1133	public static function get_main_site_file_settings() {
874	1134	return array(
875	1135	'modules' => array( 'firewall', 'security_headers', 'wp_hardening', 'file_integrity' ),
876		- 'firewall' => array( 'block_bad_bots', 'block_bad_query_strings', 'trusted_proxy_header', 'ip_whitelist', 'ua_whitelist' ),
	1136	+ // trusted_proxies goes with trusted_proxy_header, and leaving it out
	1137	+ // was a hole: the header decides which address the firewall of the
	1138	+ // whole installation acts on, and this list decides which peers may
	1139	+ // set that header. An administrator of the main site without network
	1140	+ // rights who could edit only this half turned every visitor into a
	1141	+ // trusted proxy. Found by the file-by-file review of 2.11.10.
	1142	+ 'firewall' => array( 'block_bad_bots', 'block_bad_query_strings', 'trusted_proxy_header', 'trusted_proxies', 'ip_whitelist', 'ua_whitelist' ),
877	1143	'file_integrity' => array( 'scan_critical_config' ),
878	1144	);
879	1145	}
880	1146
		@@ -1399,8 +1665,28 @@
1399	1665	}
1400	1666	}
1401	1667	}
1402	1668	}
	1669	+
	1670	+ /*
	1671	+ * The lock on the settings the shared files are built from is NOT applied
	1672	+ * here, and that is a decision, not an oversight. The second cross review
	1673	+ * of 2.11.10 raised that register_setting( 'vigilante_options', ... )
	1674	+ * declares this as its sanitize callback with no lock in it, so anything
	1675	+ * reaching options.php with that option group would write the whole
	1676	+ * option. The chain does not close: the plugin prints no settings_fields()
	1677	+ * for that group anywhere, so the nonce it would need is not obtainable,
	1678	+ * and the five places that do save (saving a tab, importing, a preset,
	1679	+ * restoring the defaults, resetting a section) all apply
	1680	+ * keep_locked_file_settings() themselves.
	1681	+ *
	1682	+ * Putting it here instead would be worse than the door it closes. A
	1683	+ * register_setting() callback runs on EVERY update_option() of this
	1684	+ * option, so it would also lock the writes with no user behind them: the
	1685	+ * expiry of Under Attack restoring what it hardened, WP-CLI and cron.
	1686	+ * Those are already covered by matriz-red-ajustes-compartidos.sh, which
	1687	+ * is where such a change would show up as a row that stopped passing.
	1688	+ */
1403	1689
1404	1690	return apply_filters( 'vigilante_validate_options', $validated, $input );
1405	1691	}
1406	1692