Safety and Protection Against DOS Attacks
For scripting systems open to untrusted user-land scripts, it is always best to limit the amount of resources used by a script so that it does not consume more resources that it is allowed to.
These are common vectors for Denial of Service (DOS) attacks.
Most Important Resources
- Continuously grow a string, an array, a BLOB or object map until all memory is consumed.
Deep recursive call that exhausts the call stack.
Large array or object map literal that exhausts the stack during parsing.
Degenerated deep expression with so many levels that the parser exhausts the call stack when parsing the expression; or even deeply-nested statements blocks, if nested deep enough.
Numeric overflows and/or underflows.
Divide by zero.
Bad floating-point representations.
Read from and/or write to private, secret, sensitive data.
Such security breach may put the entire system at risk.
internals feature allows third-party access to Rust internal data types and functions (for
AST and related types).
This is usually a Very Bad Idea™ because:
Messing up Rhai’s internal data structures will easily create panics that bring down the host environment, violating the Don’t Panic guarantee.
Allowing access to internal types may open up new attack vectors.
Internal Rhai types and functions are volatile, so they may change from version to version and break code.
internals only if the operating environment has absolutely no safety concerns – you’d
be surprised under how few scenarios this assumption holds.
One example of such an environment is a Rhai scripting
Engine compiled to WASM where the
AST is further translated to include environment-specific modifications.
Don’t Panic Guarantee – Any Panic is a Bug
Rhai is designed to not bring down the host system, regardless of what a script may do to it. This is a central design goal – Rhai provides a Don’t Panic guarantee.
When using Rhai, any panic outside of API’s with explicitly documented panic conditions is considered a bug in Rhai and should be reported as such.
All these safe-guards can be turned off via the
unchecked feature, which disables all safety
checks (even fatal ones).
This increases script evaluation performance somewhat, but very easy for a malicious script to bring down the host system.