Abstract: Embodiments herein prevent or mitigate attacks on inverse query engines by providing safe mode routines that allow for the acceptance of third party messages and/or query expressions, as well as prevent trusted sources from accidental attacks. The mitigations fall into two categories: compile-time and runtime. Compile-time mitigations prevent query expressions from being accepted and compiled that are susceptible to known attacks. For example, the complexity of query expressions may be limited to functions with linear runtimes; constant memory usage; or ones that do not create large strings. Further, language constructs for the criteria in the query expression may not allow for nested predicates complexities. Runtime mitigations, on the other hand, monitor the data size and processing lengths of messages against the various query expressions. If these runtime quotas are exceeded, an exception or other violation indication may be thrown (e.g., abort), deeming the evaluation as under attack.

Abstract: Provided herein are optimizations for an instruction tree of an inverse query engine. Secondary sub-expression elimination trees are provided, which are data structures configured to include nodes that allow for temporary variables that hold processing context or state for idempotent fragments of query expression(s). As such, when sub-paths for a query expression are processed against a message, the processing context may be stored within nodes of one or more sub-expression elimination trees. The next time this same fragment is processed, regardless of where it appears within the instruction tree, the data structure is accessed to identify and retrieve the state information such that the idempotent fragment is only calculated or evaluated once.

Abstract: Embodiments herein prevent or mitigate attacks on inverse query engines by providing safe mode routines that allow for the acceptance of third party messages and/or query expressions, as well as prevent trusted sources from accidental attacks. The mitigations fall into two categories: compile-time and runtime. Compile-time mitigations prevent query expressions from being accepted and compiled that are susceptible to known attacks. For example, the complexity of query expressions may be limited to functions with linear runtimes; constant memory usage; or ones that do not create large strings. Further, language constructs for the criteria in the query expression may not allow for nested predicates complexities. Runtime mitigations, on the other hand, monitor the data size and processing lengths of messages against the various query expressions. If these runtime quotas are exceeded, an exception or other violation indication may be thrown (e.g., abort), deeming the evaluation as under attack.