Rustは、5回目で最も愛されているプログラミング言語です。これは私たちの新しいセキュリティの救世主なのでしょうか？

ここ数年、世界中のソフトウェアエンジニアがプログラミングにRustを十分に活用できていないようです。この比較的新しいシステムプログラミング言語は Mozillaは、Stack Overflow コミュニティの心を捉えています。そして、コホートとして、何かに投票しても、愚か者に苦しむことはまずありません。」最も愛されているプログラミング言語「5年連続で、今こそ私たち全員が立ち上がって注目する時です。

Rustプログラミング言語には、一般的に使用されている言語の既知の要素や機能的な要素が組み込まれており、パフォーマンスと安全性を導入しながら、複雑さを排除するという異なる考え方に基づいています。これは学習に時間がかかり、多くの開発者はあまり使いこなす機会を得ていません- スタック・オーバーフローに関する調査対象者のわずか5.1％ よく使われています。しかし、それはさておき、この言語がエキサイティングな言語であり、C や C++ のような以前のものよりもはるかに強力なセキュリティ機能を備えていることは否定できません。大量採用には、動作面と技術面の両方で、いくらかの変更が必要になるでしょう... しかし、今のところ、理論的なレベルではまだ開発者の注目を集めています。

... しかし、ちょっと待ってください、もう1つ明らかにしておく必要があります。Rustはメモリの安全性と、一般的なメモリ管理の問題に関連するセキュリティバグの根絶を優先するプログラミング言語であることに注意することが重要です。これらは大きな問題ですが (アプリケーション・セキュリティ・チームの片頭痛の原因となることは間違いありません)、私たちが直面しているセキュア・コーディングの課題はそれだけではありません。

Rustは正確には何を防ぎますか？そして、セキュリティ環境の中で、私たちがいまだに危険にさらされているのはどこでしょうか？最新のプログラミングユニコーンを解き明かしましょう。

最新のメモリセーフシステムプログラミングの新たなフロンティア

Mozilla の研究開発チームはこれまでにいくつかの素晴らしいプロジェクトに取り組んできましたが、オープンソースの先駆者としての Rust プログラミングへの投資も例外ではありません。彼らの 紹介ビデオ 彼らの精神についてある程度の洞察を提供していますが、重要なテーマは非常に明確になっています。それは、ソフトウェアセキュリティに対する現在のアプローチには欠陥があり、Rustはその問題の多くを解決するように設計されているということです。

単純すぎるように思えます。特に、最近報告された恐ろしい失敗のように、私たちは一日おきに大規模なデータ侵害に直面しているからです。 イージージェット。何百万ものデータレコードが頻繁に侵害されており、そのほとんどはウェブアプリケーションの脆弱性によるものです。 セキュリティの設定ミス、またはフィッシング攻撃、C++などの言語は何十年も前から存在しています。しかし、開発者がセキュア・コーディングのベスト・プラクティスを実装するまでに習得するには十分な時間ではありませんでした。Rust はなぜ他と違うべきなのでしょうか？新しい言語は以前に登場してきましたが、よくある脆弱性を根絶する方法や、書かれたコードがコンパイル時に魔法のように完璧であることを保証する方法を見つけたわけではありません。

コンセプトは単純かもしれませんが、複雑な質問を克服するのは単純な答えである場合もあります。Rustは、あらゆる意味において、メモリセーフ・システム・プログラミングにおける革命であり、さまざまな方法でその約束を果たしています。そして、検出されなければ大きな問題を引き起こす可能性のあるエラーを起こしやすい開発者の助けになることは間違いありません。Java、C、C++、さらには Kotlin や Golang のような新しい言語でさえ、セキュリティに詳しくない開発者にとっては依然としてかなり容赦のない言語です。これらに関しては、組み込みの警告はなく、コンパイルされたばかりの素晴らしい機能の内部にセキュリティ・グレムリンが隠れているという兆候は特にありません。

それでは、さらに深く掘り下げてみましょう。

なぜRustはそんなに安全なのでしょうか？

通常、デベロッパーは機能的で使いやすい機能を構築することを第一の目標としています。おそらく、履歴書で喜んで見せびらかしたいという誇りの源でもあります。開発者が素晴らしいソフトウェアを作ってリリースし、次の大きなプロジェクトに移るのはごく普通のことです。この時点で、セキュリティチームは脆弱性をチェックし、見つかった場合、「完成した」アプリケーションはホットフィックスを求めてチームに返送される可能性があります。問題は単純な場合もあれば、開発者が修正できる範囲から完全に外れている場合もあります。

問題は、表面的にはセキュリティバグがまったく明らかになっておらず、スキャン、テスト、手動によるコードレビューで検出できない場合、攻撃者がその小さな機会を利用してバグを悪用する可能性があることです。

現在、Rustは、そもそも多くの脆弱性がコードに侵入するのを防ごうとしています。シンタックスエラーや、SDLCの全段階で本番環境の問題を引き起こすその他のメモリ安全性のバグがあると、コンパイルされないだけです。これは設計上メモリセーフなプログラミングであり、(ソフトウェアがどのように実行されても) 無効なメモリにアクセスできないようにしています。そして、 すべてのセキュリティバグの 70% はメモリ管理関連の問題によるものです、これは素晴らしい偉業です。

Rustはフラグを立てて次のことを防ぎます。

• バッファオーバーフロー
• 無料利用後
• ダブルフリー
• ヌルポインターデリファレンス
• 初期化されていないメモリの使用

RustのコードスニペットをC++と比較すると、デフォルトでは安全であることが明らかになります。このバッファオーバーフローのバグの例を見てください。

#include<iostream></iostream>
#include<string.h></string.h>
int メイン (ボイド) {
文字 a [3] =「12";
char b [4] =「123";
strcpy (a, b);//b の len が a より大きいため、バッファオーバーフローが発生する
std:: cout << a <<「;" << b << std:: endl;
}

対。

パブファンメイン () {
次のように入力しましょう:[文字; 2] = [1, 2];
b: [文字; 3] = [1, 2, 3];
a.スライスからのコピー (&b);
}

Rustはセキュリティ警告を表示し、実行時にバッファオーバーフローを防ぐためにcopy_from_slice関数に到達するとパニックになりますが、コンパイル時には発生しません。

そういう意味では、まさに「スタートレフト」言語の一つです。エラーを浮き彫りにし、メモリ関連のセキュリティバグが発生しないように開発者に正しいコードの書き方を強制します。そのため、期限に間に合うかどうかは、コーダーが注意を払い、修正し、デリバリーパスに忠実であり続けるかどうかにかかっています。

この言語のアプローチは単純そうに見えますが、この強力なロジックで動作するようになれば素晴らしい偉業だったでしょうし、実際にその道を歩んでいます。セキュリティの観点から見ると、Rustは大きな飛躍です... もっと多くの人が使っていればよかったのに。Dropbox のような企業は、大規模な企業規模での利用を先駆けて進めており、それは素晴らしいことです。しかし、より安全な未来を阻んでいるのは採用問題だけだという結論に達するまでには、他にも考慮すべき点があります。

ラスト・レコニング

いくつか小さな (まあまあ大きな) 問題があります。つまり、Rustでのプログラミングは、見た目よりも柔軟にバグを発生させることができるということです。そうなるでしょう。 じゃない 侵害や遅延、そして安全でないコーディング技法の一般的な文化を引き起こし続けている、非常に重要な OWASP Top 10 の脆弱性を修正します。また、天使と悪魔のようなダイナミック、あるいはもっと広く知られているようなものもあります。 安全な錆と危険なさび。
‍

で説明されているように 公式文書、Safe RustはRustの「真の」形であり、Unsafe Rustには「絶対に安全ではない」と見なされる関数が含まれていますが、別の言語での何かとの統合が必要な場合など、必要な場合もあります。ただし、Unsafe Rust を使用しても、追加できる機能のリストはまだ限られています。Unsafe Rust では、安全でないブロック内で次の操作を行うことができます。

• 未処理のポインターを逆参照
• 安全でない関数 (C 関数、コンパイラ組み込み関数、生のアロケータを含む) を呼び出す
• 安全でない特性を実装する
• 変異統計
• ユニオンのフィールドにアクセスします。

いわゆる「安全でない」モードでも、Rustプログラミングの超能力の1つである「ボローチェッカー」は依然として機能します。一般に、静的コード解析によってメモリの問題、並列計算での衝突、その他多くのバグを防ぎますが、この分析でもやはり安全でないブロックをチェックします。特定の状況では、コンパイラがガイダンスを受けずに安全でないコンストラクトを書くのに多くの作業が必要になるだけです。

これはほとんどの経験豊富な開発者にとって大きな問題ではないように思えます。結局のところ、私たちはアプリケーションを最大限に活用し、いくつかのクールな機能を開こうと工作することで知られていますが、重大な構成ミスやセキュリティの脆弱性につながるブラックホール、つまり未定義の動作につながる可能性があります。Rustでプログラミングすると（安全に使用されていない場合でも）、CやC++と比較して脆弱性の可能性はかなり抑えられますが、未定義の動作を呼び出すことはリスクがあります。

これで開発者主導のセキュアコーディングへの依存は終わりですか？

さっきRustにはよく知られた言語のコンポーネントがあると言ったことを覚えていますか？Rust の主なセキュリティ上の脆弱性のひとつは、よく知られた言語、つまり C 言語のコンポーネントが含まれていることです。

Rustはまだ「安全なプログラミング言語」ですが、繰り返しになりますが、ユーザーの紹介によって行き詰まりが解消されます。それでも開発者はエラーにフラグを付けずに実行できるように微調整できます (この提案はより多くの機能をアンロックできるので魅力的な提案です)。そして基本的に、安全な状態であっても、開発者が望むだけ「危険」な状態になることがあります。なぜなら、物事が実際に洋ナシの形になる前にガイダンスと保護の層があるからです。

そして、Rustの結果はスキャンツールに似ているため、上記の両方のシナリオはより深く掘り下げるにつれてより危険になります。すべての脆弱性、すべての攻撃ベクトル、すべての問題をスキャンするSwiss Army SAST/DAST/RAST/IASTツールがないのと同じように、Rustもそうではありません。Rust を使っても 一部の脆弱性はまだ簡単に導入できます。

Unsafe Rustを実行する際の未定義の動作リスクは、整数オーバーフローの問題を引き起こす可能性がありますが、一般的には、安全な構成であっても、セキュリティの設定ミスによる人為的ミスを防ぐことはできません。 ビジネスロジック、または既知の脆弱性を持つコンポーネントを使用する。これらの問題は、パッチを当てないままにしておくと依然として非常に現実的な脅威となります。また、真のRustのような「安全と想定される」環境では、コーダーが主要な問題がすべて解決されると考えていると、自己満足の行動を引き起こすことさえあります。

Rustはプログラミングのメンターと何ら変わりはないことがわかりました。経験の浅いコーダーと一緒に時間をかけて座り、作業を見直し、潜在的なバグを示し、効率性を指摘し、場合によっては正しくなるまでコンパイルされないようにするシニアエンジニアです。ただし、Rustプログラマーにとっては、自分で理論を学び、ベストプラクティスにコミットする方がはるかに良いです。なぜなら、そのメンターはエプロンのひもを切るだけで、そのままにされたくないからです。

Rustの一般的な脆弱性を今すぐ見つけて修正する準備はできていますか？ チャレンジをプレイしてください。