Rustは「安全な言語」として知られています。特にメモリ安全性の面では優れた言語設計が施されていますが、それだけですべての問題が解決するわけではありません。コンパイラは多くのバグを捕捉してくれますが検出できない落とし穴も存在します。
上記の記事にRustで安全なコードを書く際によく遭遇する落とし穴と、それらを避けるためのベストプラクティスが非常によくまとまっていました。いくつか紹介します。
Rustのコンパイラは優秀ですが、以下のような問題は検出できません：
unwrapやexpectの使用による意図しないパニックbuild.rsスクリプトそれでは、よくある落とし穴とその対策を見ていきましょう。
整数のオーバーフローはよくある問題です。次のコードを見てみましょう：
// 良くない例：オーバーフローの可能性がある
fn calculate_total(price: u32, quantity: u32) -> u32 {
price * quantity // 大きな数値の場合、オーバーフローする可能性あり！
}
この例では、priceとquantityが大きな値の場合、結果がオーバーフローする可能性があります。デバッグモードではパニックしますが、リリースモードではラップアラウンドします（値が最大値を超えると0から再度カウントを始める）。
// 良い例：チェック付き算術演算
fn calculate_total(price: u32, quantity: u32) -> Resultu32, ArithmeticError> {
price.checked_mul(quantity)
.ok_or(ArithmeticError::Overflow)
}
checked_mulなどのメソッドを使うと、オーバーフローが発生した場合にNoneを返してくれるので、適切にエラー処理ができます。
また、Cargo.tomlに以下を追加しておくとリリースビルドでもオーバーフローチェックが有効になるそうです。覚えておきたいですね：
[profile.release]
overflow-checks = true
asを安易に使わない数値型の変換にはよくasキーワードが使われますが、これは安全でない場合があります：
let x: i32 = 1000;
let y: i8 = x as i8; // 値が範囲外なので切り捨てられる！
この例では、i32からi8への変換で値が切り捨てられ、予期しない結果になります。
Rustには3つの主要な数値変換方法があります：
asキーワード：便利だが安全でない（値が切り捨てられる可能性あり）From::from()：データ損失のない変換のみ許可（拡大変換に最適）TryFrom：変換が失敗する可能性がある場合にResultを返す// 良い例：TryFromを使った安全な変換
use std::convert::TryFrom;
let x: i32 = 1000;
let y = i8::try_from(x).map_err(|_| "値が大きすぎます")?;
この方法なら、変換が失敗した場合にエラー処理ができます。
数値が特定の条件を満たす必要がある場合、単純なプリミティブ型ではなく、境界つき型を使いましょう。
// 良くない例：無制限の数値型
struct Product {
price: f64, // マイナスの可能性あり！
quantity: i32, // マイナスの可能性あり！
}
// 良い例：境界つき型
#[derive(Debug, Clone, Copy)]
struct NonNegativePrice(f64);
impl NonNegativePrice {
pub fn new(value: f64) -> ResultSelf, PriceError> {
if value 0.0 || !value.is_finite() {
return Err(PriceError::Invalid);
}
Ok(NonNegativePrice(value))
}
}
struct Product {
price: NonNegativePrice,
quantity: std::num::NonZeroU32, // 0以外の正の整数のみ
}
この方法では、不正な値を持つオブジェクトが作れなくなります。
getメソッドを使う配列やベクトルへの直接のインデックスアクセスは危険です：
let arr = [1, 2, 3];
let elem = arr[3]; // 範囲外アクセスでパニック！
getメソッドでオプション値を返すlet arr = [1, 2, 3];
if let Some(elem) = arr.get(3) {
println!("4番目の要素: {}", elem);
} else {
println!("4番目の要素はありません");
}
split_atよりsplit_at_checkedを使うスライスを分割する際も同様に注意が必要です：
let arr = [1, 2, 3];
let (left, right) = arr.split_at(4); // 範囲外でパニック！
let arr = [1, 2, 3];
match arr.split_at_checked(3) {
Some((left, right)) => println!("分割成功: {:?} と {:?}", left, right),
None => println!("インデックスが範囲外です")
}
文字列などのプリミティブ型をそのまま使うと、バリデーションが困難になります：
// 良くない例：制限のないString型
fn authenticate_user(username: String) {
// ユーザー名が空かも？特殊文字が含まれているかも？
}
#[derive(Debug, Clone, PartialEq, Eq, Hash)]
struct Username(String);
impl Username {
pub fn new(name: &str) -> ResultSelf, UsernameError> {
if name.is_empty() {
return Err(UsernameError::Empty);
}
if name.len() > 30 {
return Err(UsernameError::TooLong);
}
if !name.chars().all(|c| c.is_alphanumeric() || c == '_') {
return Err(UsernameError::InvalidCharacters);
}
Ok(Username(name.to_string()))
}
pub fn as_str(&self) -> &str {
&self.0
}
}
fn authenticate_user(username: Username) {
// ユーザー名は常に有効！
}
この方法なら、関数に渡される時点で値が有効であることが保証されます。
フィールドの組み合わせによっては無効な状態が生じることがあります：
// 良くない例：不正な組み合わせが可能
struct Configuration {
port: u16,
host: String,
ssl_enabled: bool,
ssl_cert: OptionString>, // ssl_enabled=trueなのに証明書がNoneという状態が可能
}
// 良い例：型で状態を強制
enum ConnectionSecurity {
Insecure,
Ssl { cert_path: String }, // 証明書なしのSSLは表現できない
}
struct Configuration {
port: u16,
host: String,
security: ConnectionSecurity,
}
この方法では、「SSL有効だが証明書がない」という無効な状態を表現できなくなります。
Defaultの実装は慎重に何も考えずにDefaultを実装すると問題が生じることがあります：
// 良くない例：不適切なデフォルト値
#[derive(Default)]
struct ServerConfig {
port: u16, // 0になる（有効なポートではない）
max_connections: usize, // 0になる
timeout_seconds: u64, // 0になる
}
// 良い例：明示的な初期化
struct ServerConfig {
port: Port,
max_connections: std::num::NonZeroUsize,
timeout: std::time::Duration,
}
impl ServerConfig {
pub fn new(port: Port) -> Self {
Self {
port,
max_connections: NonZeroUsize::new(100).unwrap(),
timeout: Duration::from_secs(30),
}
}
}
Debug実装時は機密情報に注意Debugトレイトを自動導出すると、機密情報が漏洩する恐れがあります：
// 良くない例：機密情報が表示される
#[derive(Debug)]
struct User {
username: String,
password: String, // デバッグ出力で見えてしまう！
}
Debugを手動実装する#[derive(Debug)]
struct User {
username: String,
password: Password,
}
struct Password(String);
impl std::fmt::Debug for Password {
fn fmt(&self, f: &mut std::fmt::Formatter'_>) -> std::fmt::Result {
f.write_str("[REDACTED]")
}
}
これにより、デバッグ出力時にパスワードが「[REDACTED]」と表示されるようになります。
また、次のような実装もあります：
impl std::fmt::Debug for DatabaseURI {
fn fmt(&self, f: &mut std::fmt::Formatter'_>) -> std::fmt::Result {
// 構造体を分解して、フィールドが追加された場合にコンパイルエラーになるようにする
let DatabaseURI { scheme, user, password: _, host, database, } = self;
write!(f, "{scheme}://{user}:[REDACTED]@{host}/{database}")?;
Ok(())
}
}
serdeのSerializeとDeserializeを自動導出すると、思わぬ問題が生じることがあります：
// 良くない例：チェックなしのシリアライズ
#[derive(Serialize, Deserialize)]
struct UserCredentials {
#[serde(default)] // デシリアライズ時に空文字を受け入れる
username: String,
#[serde(default)]
password: String, // シリアライズ時に平文で出力される
}
#[derive(Deserialize)]
#[serde(try_from = "String")]
pub struct Password(String);
impl TryFromString> for Password {
type Error = PasswordError;
fn try_from(value: String) -> ResultSelf, Self::Error> {
if value.len() 8 {
return Err(PasswordError::TooShort);
}
Ok(Password(value))
}
}
この方法では、デシリアライズ時に自動的に検証が行われます。
機密データを比較する際は、実行時間の差から情報が漏れる可能性があります：
// 良くない例：単純な比較
fn verify_password(stored: &[u8], provided: &[u8]) -> bool {
stored == provided // タイミング攻撃に弱い
}
// 良い例：定数時間比較
use subtle::{ConstantTimeEq, Choice};
fn verify_password(stored: &[u8], provided: &[u8]) -> bool {
stored.ct_eq(provided).unwrap_u8() == 1
}
無制限の入力を受け付けると、DoS攻撃の原因になります：
// 良くない例：サイズ制限なし
fn process_request(data: &[u8]) -> Result(), Error> {
let decoded = decode_data(data)?; // 巨大なデータでメモリを使い果たす可能性
// 処理
Ok(())
}
// 良い例：明示的なサイズ制限
const MAX_REQUEST_SIZE: usize = 1024 * 1024; // 1MiB
fn process_request(data: &[u8]) -> Result(), Error> {
if data.len() > MAX_REQUEST_SIZE {
return Err(Error::RequestTooLarge);
}
let decoded = decode_data(data)?;
// 処理
Ok(())
}
Path::joinの挙動に注意パスを結合する際のPath::joinメソッドには注意が必要です：
use std::path::Path;
fn main() {
let path = Path::new("/usr").join("/local/bin");
println!("{path:?}"); // "/local/bin" と出力される
}
第2引数が絶対パスの場合、第1引数は無視されます。 これは意図しない動作につながる可能性があります。
自分のコードだけでなく、依存ライブラリのunsafeコードも脆弱性の原因になります。
cargo-geigerで依存関係をチェックcargo install cargo-geiger
cargo geiger
このツールを使うと、プロジェクトの依存関係に含まれるunsafe関数の数を確認できます。
Rustのlintツール「Clippy」を使うと、前述の多くの問題をコンパイル時に検出できます：
// 数値演算関連
#![deny(arithmetic_overflow)]
#![deny(clippy::checked_conversions)]
#![deny(clippy::cast_possible_truncation)]
// unwrap関連
#![deny(clippy::unwrap_used)]
#![deny(clippy::expect_used)]
// 配列インデックス関連
#![deny(clippy::indexing_slicing)]
// その他
#![deny(clippy::join_absolute_paths)]
#![deny(clippy::serde_api_misuse)]
覚えておきたいのが：
cargo check はこれらの問題を報告しません
cargo run は実行時にパニックするか失敗します一方
cargo clippy はコンパイル時にすべての問題を検出します！Rustは安全な言語として設計されていますが、コンパイラだけでは検出できない問題も多くあります。実践的な対策も紹介されており大変参考になりました。
Be the first to comment
