policy: filter_username rejects User-Names containing an xlat opener

Reject the '%{' and '%name(' expansion openers in User-Name so there's no chance of poorly written API code reflecting them back and having nested evaluation occur.

This is a belt and braces change, as expansion defaults to disabled in v4 for the rest module, and it's somewhat unlikely that an admin woul insert one of these raw values into an SQL policy.  It's probably unecessary but at least it quiets the CVE farmers.

Author: arr2036

raddb/policy.d/filter

@@ -34,6 +34,19 @@ filter_username {
 		}
 	}
 	elsif (User-Name) {
+		#
+		#  Prevention of injection attacks if external datastores or APIs fail to sanitise text
+		#
+		#  Matches the "%{" and "%name(" xlat expansion openers.
+		#  "%%" is the documented escape sequence for a literal "%".
+		#
+		if (User-Name =~ /%%([{]|[[:alnum:]._-]+[(])/) {
+			request += {
+				Module-Failure-Message = "User-Name contains expansion sequences"
+			}
+			reject
+		}
+
 		#
 		#  reject mixed case e.g. "UseRNaMe"
 		#