https://appsec.guide/docs/languages/rust/Recent content in Rust on Testing HandbookHugoen-ushttps://appsec.guide/docs/languages/rust/security-overview/Mon, 01 Jan 0001 00:00:00 +0000https://appsec.guide/docs/languages/rust/security-overview/Rust security overview # Safety and security # The Rust compiler guarantees the memory safety of safe Rust: absent unsafe code, no undefined behavior or data race will happen during runtime, no matter the inputs. This guarantee does not extend to unsafe code—including unsafe code hidden in dependencies—which can cause undefined behavior if it is unsound. Therefore, when security-testing Rust programs, it’s important to understand what is and what is not considered undefined behavior (UB).https://appsec.guide/docs/languages/rust/dynamic-analysis/Mon, 01 Jan 0001 00:00:00 +0000https://appsec.guide/docs/languages/rust/dynamic-analysis/Rust dynamic analysis # There are two categories of dynamic analysis: fuzz testing and “standard” testing, like unit and functional testing. In this chapter, we will focus on standard testing. This is the basic level of testing that every project should have implemented. While basic, standard testing can be built up with a lot of security-wise improvements. To read about Rust fuzzing, see the Rust fuzzing chapter of this handbook.https://appsec.guide/docs/languages/rust/static-analysis/Mon, 01 Jan 0001 00:00:00 +0000https://appsec.guide/docs/languages/rust/static-analysis/Rust static analysis # Static analysis involves analyzing source code without executing it. Clippy # Clippy is the fundamental linter. Just use it. Clippy lints are categorized into groups and levels. Groups categorize lints by the types of issues they detect. Levels indicate what to do when a lint finds an issue: Allow: Ignore the issue Warn: Print a message to stderr Deny: Return an error code (useful in CI pipelines) Clippy is a wrapper over the rustc compiler, so when Clippy is run, it executes its own set of lints in addition to rustc’s.https://appsec.guide/docs/languages/rust/gotchas-and-footguns/Mon, 01 Jan 0001 00:00:00 +0000https://appsec.guide/docs/languages/rust/gotchas-and-footguns/Rust gotchas and footguns # This section provides a checklist that can be used during manual Rust code reviews. The list represents common issues we have encountered during our audits. It is not comprehensive, but it is a good starting point to quickly bootstrap an audit. For safe code # Check string comparisons. Often partial-match (starts_with, ends_with, contains) is used instead of equality. Case (in)sensitivity of comparisons often results in issues.https://appsec.guide/docs/languages/rust/memory-zeroization/Mon, 01 Jan 0001 00:00:00 +0000https://appsec.guide/docs/languages/rust/memory-zeroization/Rust memory zeroization # Zeroization in the presence of optimizing compilers is difficult. In Rust, it is particularly tricky because of the constraints the compiler imposes on memory management. The compiler can infer significant aliasing information that allows unexpected copies of secret data to appear on the stack. For example, consider the pitfall described in the blog post “A pitfall of Rust’s move/copy/drop semantics and zeroing data”. There are three levels of “zeroization security” that can be considered, depending on the security goals.https://appsec.guide/docs/languages/rust/model-checking/Mon, 01 Jan 0001 00:00:00 +0000https://appsec.guide/docs/languages/rust/model-checking/Rust model checking # Model checking means verifying that a program works correctly for all possible inputs. Instead of testing with a single value (like with unit testing) or with a set of values (like with property testing), we check all possible values—and hope that smart algorithms will make it possible to finish testing in a reasonable time. Prusti # Prusti is based on Viper, a framework for building verification tools.https://appsec.guide/docs/languages/rust/specialized-testing/Mon, 01 Jan 0001 00:00:00 +0000https://appsec.guide/docs/languages/rust/specialized-testing/ Rust specialized testing # Concurrency testing # Shuttle Unsound, but scalable Works analogously to property testing Loom Sound, but slow Works analogously to model checkers Fault injection # MadSim Replaces the tokio and tonic crates with simulated versions Injects faults and increases randomness fail-rs Needs you to manually add fail_point! macros into the codehttps://appsec.guide/docs/languages/rust/supply-chain-analysis/Mon, 01 Jan 0001 00:00:00 +0000https://appsec.guide/docs/languages/rust/supply-chain-analysis/Rust supply chain analysis # Vetting # The tools in this section are more for “understanding” than “checking.” That is, running them does not produce bug reports, but can help you assess the maturity and security of dependencies. The tools below are quantitative rather than qualitative; you will need to perform manual, in-depth review of the outputs to extract any solid evidence about the maturity. cargo-supply-chain # cargo-supply-chain reveals who you are implicitly trusting via dependencies.