General Security Considerations

Using Regular Expressions

Regular expressions provide the capability to search, match, and manipulate data. What is achievable with the scope they provide is hard to quantify or analyze. As such, the effective threat surface area they expose is too large to enumerate completely. This section serves to provide information and context around the security implications when using regular expressions.

Regular expressions might be configured for particular features of the Traffic Manager. They might also be used in arbitrary ways through functions available to TrafficScript rules.

Two vectors are potentially available to a highly-skilled attacker:

1.Denial of Service: Also known as “ReDoS”. It is possible to create regular expressions, "Evil Regexes", that when executed can consume a considerable amount of either memory or CPU.

2.Data Exfiltration: Following on from the discovery of CPU-cache-based side-channel attacks (for example, “Spectre”), a regular expression could be used to generate a widget, through the just-in-time code generator, that could be used to exfiltrate data from your Traffic Manager processes.

Ivanti must emphasize that such attacks are not trivial to construct or execute. However, this section aims to provides context for proactive mitigation and policy decisions. The following suggestions provide ways to address such threats:

1.Sanitize data used in the construction of a regular expression. In the simplest case, use \Q and \E quoting to avoid considering the provided data as part of the regex syntax.

2.Use the group permissions capability in the Traffic Manager to assign administrators with only those permissions that they require, following the principle of least privilege.