Rust ist zum fünften Mal die beliebteste Programmiersprache. Ist es unser neuer Sicherheitsretter?
ここ数年、世界中のソフトウェアエンジニアは、プログラミングのためのRustに飽き足らないようです。Mozilla が開発したこの比較的新しいシステムプログラミング言語は、Stack Overflow コミュニティの心を掴みました。
プログラミング言語Rustは、一般的に使用されている言語から既知の要素や関数的な要素を取り入れ、パフォーマンスと安全性を導入しながら、複雑さを排除する異なる哲学に基づいて作業しています。学習が必要なため、多くの開発者はあまり使う機会がなく、Stack Overflowで調査した人のわずか5.1%が普通に使っているに過ぎない。しかし、それはさておき、この言語がエキサイティングであること、そしてCやC++といった従来の言語に比べてセキュリティの面で非常に強力であることは否定できない。しかし、今はまだ、理論的なレベルで開発者の関心を集めている段階です。
Rust は、メモリの安全性と、一般的なメモリ管理の問題と結びついたセキュリティバグの撲滅を最優先するプログラミング言語であることは、重要なポイントです。Rust は、メモリ安全性と、一般的なメモリ管理の問題と結びついたセキュリティバグの撲滅を優先するプログラミング言語であるということが重要です。これは大きな問題ですが（そして間違いなく、少なからぬ AppSec チームの頭痛の種になっています）、私たちが直面する安全なコーディングの課題は、これだけではありません。
Rustは何を防ぐのでしょうか？そして、私たちは、セキュリティ環境のどこに、まださらされているのでしょうか？最新のプログラミングユニコーンを紐解いてみましょう。
メモリセーフな最新システムプログラミングの新境地
Mozilla の研究開発チームは、いくつかの素晴らしいプロジェクトに取り組んでおり、オープンソースの先駆者として Rust プログラミングに投資することも例外ではありません。その紹介ビデオでは、彼らの哲学を知ることができます。重要なテーマは非常に明確で、ソフトウェアセキュリティに対する現在のアプローチには欠陥があり、Rust はその問題の多くを解決するために設計されています。
最近のEasyJet社のように、私たちは毎日のように大規模なデータ漏洩に直面しているので、この言葉はあまりにも単純に思えます。C++のような言語は何十年も前から存在しています。C++のような言語は何十年も前から存在していますが、開発者が安全なコーディングのベストプラクティスを実践できるまでに習得するには十分な時間がありませんでした。なぜRustがそうでなければならないのでしょうか。これまでにも新しい言語は登場してきましたが、一般的な脆弱性を根絶する方法が見つかったわけでも、書かれたコードがコンパイル時に魔法のように完璧になるわけでもありません。
コンセプトはシンプルですが、複雑な問題を解決するのはシンプルな答えであることがあります。Rustは、あらゆる意味で、メモリセーフなシステムプログラミングの革命であり、多くの点でその約束を果たしています......そして、発見されなければ大きな問題を引き起こす可能性のあるエラーを導入しがちな開発者のベーコンを確実に救っています。Java、C、C++、そしてKotlinやGolangのような新しい言語であっても、セキュリティを意識しない開発者にはかなり厳しいものがあります。これらの言語では、組み込まれた警告や、コンパイルされたばかりの素晴らしい機能にセキュリティグレムリンが潜んでいることを示す特別な兆候はありません。
では、もっと掘り下げてみましょう。
ラストの安全性の理由は？
通常、開発者は機能を構築し、機能的でユーザーフレンドリーであることを保証することを第一の目標としており、おそらく履歴書に誇れるものでもあるでしょう。開発者が素晴らしいソフトウェアを作り、それを出荷し、次の大きなプロジェクトに移ることは全く普通のことです。この時点で、セキュリティチームが脆弱性をチェックし、もし見つかった場合は、「完成した」アプリケーションがホットフィックスを求めてチームに戻ってくるかもしれません。問題が単純な場合もあれば、開発者が修正できる範囲を完全に逸脱している場合もあります。
問題は、表面的にはセキュリティバグが全く明らかになっていないことであり、スキャン、テスト、手動によるコードレビューがバグを拾えなかった場合、攻撃者はそのわずかな機会を利用してバグを悪用する可能性があります。
Rustでは、多くの脆弱性がコードに混入するのを未然に防ぐことを目指しています。構文エラーや、SDLCの過程で生産上の問題を引き起こすメモリ安全性のバグがある場合は、単純にコンパイルされません。これは、ソフトウェアがどのように実行されても、無効なメモリへのアクセスがないことを保証する、設計上のメモリセーフプログラミングです。セキュリティバグの70％がメモリ管理関連の問題であることを考えると、これは大変なことです。
サビはフラグを立てて防ぎます。
- バッファオーバーフロー
- 無料になってから使う
- ダブルフリー
- Null ポインタの脱参照
- 初期化されていないメモリの使用
RustのコードスニペットをC++と比較すると、どちらかがデフォルトで安全であることが明らかになります。バッファオーバーフローのバグの例を見てみましょう。
#include <iostream></iostream>
#include <string.h></string.h>
int main( void ) {
char a[3] = "12";
char b[4]= "123";
strcpy(a, b); // buffer overflow as len of b is greater than a
std::cout << a << "; " << b << std::endl;
}
対。
pub fn main() {
let mut a: [char; 2] = [1, 2];
let b: [char; 3] = [1, 2, 3];
a.copy_from_slice(&b);
}
Rustはバッファオーバーフローを防ぐために、実行時にはセキュリティ警告を出し、copy_from_slice関数に到達した時点でパニックを起こしますが、コンパイル時には起こりません。
その意味では、「左から始める」言語の一つであると言えます。エラーがハイライトされ、メモリ関連のセキュリティバグを発生させないための正しいコードの書き方を開発者に強制的に教えてくれるので、納期に間に合うかどうかは、コーダーが注意を払い、修正し、デリバリーパスに忠実であるかどうかにかかっています。
この言語のアプローチは単純に見えますが、この強力なロジックで動作させるのは信じられないほどの偉業であり、その道を歩んでいるのです。Rustは、セキュリティの観点からすると、大きな飛躍と言えます。Dropboxのような企業は、大規模な企業規模での利用を開拓しており、これは素晴らしいことです。しかし、より安全な未来を阻んでいるのが採用の問題であるという結論に達する前に、もっと考慮すべきことがあるのです。
ラストのおさらい
Rustでプログラミングすると、見た目以上にバグが発生しやすいという小さな（まあ、大きな）問題がいくつかあります。Rustは、OWASPのトップ10の脆弱性を修正することはできず、違反や遅延、安全でないコーディング技術の一般的な文化を引き起こし続けています。また、天使と悪魔の戦い、あるいはより広く知られているように、安全なRustと安全でないRustの戦いもあります。
。
公式ドキュメントでも説明されているように、Safe RustはRustの「真の」形であり、Unsafe Rustは、他の言語の何かとの統合が必要な場合など、時には必要となるものの、「絶対に安全ではない」と判断された機能を含んでいます。しかし、Unsafe Rustであっても、追加できる機能は限られている。Unsafe Rustでは、安全でないブロックの中で、以下のようなことが可能です。
- 生のポインターを脱参照する
- 安全でない関数の呼び出し（C関数、コンパイラの組込み関数、ローアローケータを含む
- 安全でない特性の実装
- スタティックを変異させる
- ユニオンのフィールドにアクセスします。
いわゆる「安全でない」モードであっても、Rustプログラミングの超能力の1つである「ボローチェッカー」は依然として機能します。一般に、静的コード解析によって、メモリ問題や並列計算の衝突、その他多くのバグを防ぎます。この解析は、安全でないブロックでもチェックを行います。特定の状況下でコンパイラが指導に入らずに安全でない構造を書くには、より多くの作業が必要になるだけなのです。
しかし、これは深刻な設定ミスやセキュリティ脆弱性につながるブラックホール、すなわち未定義の動作を引き起こす可能性があります。Rustでのプログラミングは、CやC++と比較して、（安全でない使い方であっても）脆弱性の可能性をかなり低く抑えることができますが、未定義の振る舞いを呼び出すことはリスクになり得ます。
これで、開発者主導のセキュアコーディングに頼ることは終わりでしょうか？
以前、Rustはよく知られた言語の部品を含んでいると言いましたが、覚えていますか？Rustの主なセキュリティ上の脆弱性の1つは、よく知られた言語、つまりC言語のコンポーネントを含んでいることです。
Rustは今でも「安全なプログラミング言語」ですが、やはりユーザーを導入することで物事がうまくいかなくなることがあります。開発者は、エラーを出さずに実行できるように調整することができます（より多くの機能が使えるようになるため、魅力的な提案です）。基本的に、安全な状態であっても、開発者は好きなだけ「安全でない」ことができます。
Rustの成果はスキャンツールに似ています。すべての脆弱性、すべての攻撃ベクトル、すべての問題をスキャンするスイスアーミーSAST/DAST/RAST/IASTツールがないように、Rustもそうではありません。Rustを使用しても、いくつかの脆弱性は、非常に簡単に導入される可能性があります。
安全でないRustを実行したときの未定義の動作は、整数オーバーフローの問題を引き起こす可能性があります。また、一般的に、安全な設定であっても、セキュリティの設定ミスやビジネスロジック、既知の脆弱性を持つコンポーネントの使用などのヒューマンエラーを防ぐことはできません。これらの問題は、パッチを当てずに放置すると非常に大きな脅威となります。また、真のRustのような「安全だと思われている」環境では、重大な問題がすべて拾われるとコーダーが信じている場合、自己満足的な行動をとる可能性もあります。
Rustは、プログラミングのメンターと同じように、経験の浅いコーダーと一緒に時間をかけて、彼らの仕事を見直し、バグの可能性を示し、効率性を指摘し、場合によっては、正しいものになるまでコンパイルしないようにする上級エンジニアのことです。しかし、Rustプログラマーにとっては、自分自身で理論を学び、ベストプラクティスに取り組む方がはるかに良いのです。なぜなら、メンターがエプロンの紐を切ってしまうかもしれないし、あなたがぶら下がったままになるのは嫌だからです。
今すぐRustの一般的な脆弱性を見つけて修正する準備はできましたか？ チャレンジしてみてください。
Rust integriert bekannte und funktionale Elemente aus häufig verwendeten Sprachen und arbeitet nach einer anderen Philosophie, die Komplexität beseitigt und gleichzeitig Leistung und Sicherheit einführt.
Matias Madou, Ph.D. セキュリティ専門家、研究者、CTO兼共同設立者（Secure Code Warrior ）。Ghent大学でアプリケーションセキュリティの博士号を取得し、静的解析ソリューションに焦点を当てた。その後、米国Fortify社に入社し、開発者が安全なコードを書くことを支援せずに、コードの問題を検出するだけでは不十分であることに気づきました。開発者を支援し、セキュリティの負担を軽減し、お客様の期待を上回る製品を開発することを志すようになった。Team Awesomeの一員としてデスクワークをしていないときは、RSA Conference、BlackHat、DefConなどのカンファレンスでプレゼンテーションをするのが好きである。
Secure Code Warrior 、ソフトウェア開発サイクル全体を通じてコードの安全性を確保し、サイバーセキュリティを最優先とする文化を構築するため、貴社をSecure Code Warrior 。アプリセキュリティ管理者、開発者、CISO、あるいはセキュリティに関わるあらゆる立場の方々に対し、当社が貴社のビジネスにおける不安全なコードに関連するリスクの低減を支援します。
デモを予約する
Matias Madou, Ph.D. セキュリティ専門家、研究者、CTO兼共同設立者（Secure Code Warrior ）。Ghent大学でアプリケーションセキュリティの博士号を取得し、静的解析ソリューションに焦点を当てた。その後、米国Fortify社に入社し、開発者が安全なコードを書くことを支援せずに、コードの問題を検出するだけでは不十分であることに気づきました。開発者を支援し、セキュリティの負担を軽減し、お客様の期待を上回る製品を開発することを志すようになった。Team Awesomeの一員としてデスクワークをしていないときは、RSA Conference、BlackHat、DefConなどのカンファレンスでプレゼンテーションをするのが好きである。
マティアスは、15年以上のソフトウェアセキュリティの実務経験を持つ研究者・開発者です。フォーティファイ・ソフトウェア社や自身の会社（Sensei Security）などでソリューションを開発してきました。キャリアの中で、Matiasは、商用製品につながる複数のアプリケーションセキュリティ研究プロジェクトを主導し、10件以上の特許を取得しています。また、RSAカンファレンス、Black Hat、DefCon、BSIMM、OWASP AppSec、BruConなどの世界的なカンファレンスで定期的に講演を行っているほか、高度なアプリケーションセキュリティトレーニング（courses ）の講師も務めています。
Matiasはゲント大学でコンピュータ工学の博士号を取得し、アプリケーションの内部構造を隠すためのプログラム難読化によるアプリケーションセキュリティを研究しました。
ここ数年、世界中のソフトウェアエンジニアは、プログラミングのためのRustに飽き足らないようです。Mozilla が開発したこの比較的新しいシステムプログラミング言語は、Stack Overflow コミュニティの心を掴みました。
プログラミング言語Rustは、一般的に使用されている言語から既知の要素や関数的な要素を取り入れ、パフォーマンスと安全性を導入しながら、複雑さを排除する異なる哲学に基づいて作業しています。学習が必要なため、多くの開発者はあまり使う機会がなく、Stack Overflowで調査した人のわずか5.1%が普通に使っているに過ぎない。しかし、それはさておき、この言語がエキサイティングであること、そしてCやC++といった従来の言語に比べてセキュリティの面で非常に強力であることは否定できない。しかし、今はまだ、理論的なレベルで開発者の関心を集めている段階です。
Rust は、メモリの安全性と、一般的なメモリ管理の問題と結びついたセキュリティバグの撲滅を最優先するプログラミング言語であることは、重要なポイントです。Rust は、メモリ安全性と、一般的なメモリ管理の問題と結びついたセキュリティバグの撲滅を優先するプログラミング言語であるということが重要です。これは大きな問題ですが（そして間違いなく、少なからぬ AppSec チームの頭痛の種になっています）、私たちが直面する安全なコーディングの課題は、これだけではありません。
Rustは何を防ぐのでしょうか？そして、私たちは、セキュリティ環境のどこに、まださらされているのでしょうか？最新のプログラミングユニコーンを紐解いてみましょう。
メモリセーフな最新システムプログラミングの新境地
Mozilla の研究開発チームは、いくつかの素晴らしいプロジェクトに取り組んでおり、オープンソースの先駆者として Rust プログラミングに投資することも例外ではありません。その紹介ビデオでは、彼らの哲学を知ることができます。重要なテーマは非常に明確で、ソフトウェアセキュリティに対する現在のアプローチには欠陥があり、Rust はその問題の多くを解決するために設計されています。
最近のEasyJet社のように、私たちは毎日のように大規模なデータ漏洩に直面しているので、この言葉はあまりにも単純に思えます。C++のような言語は何十年も前から存在しています。C++のような言語は何十年も前から存在していますが、開発者が安全なコーディングのベストプラクティスを実践できるまでに習得するには十分な時間がありませんでした。なぜRustがそうでなければならないのでしょうか。これまでにも新しい言語は登場してきましたが、一般的な脆弱性を根絶する方法が見つかったわけでも、書かれたコードがコンパイル時に魔法のように完璧になるわけでもありません。
コンセプトはシンプルですが、複雑な問題を解決するのはシンプルな答えであることがあります。Rustは、あらゆる意味で、メモリセーフなシステムプログラミングの革命であり、多くの点でその約束を果たしています......そして、発見されなければ大きな問題を引き起こす可能性のあるエラーを導入しがちな開発者のベーコンを確実に救っています。Java、C、C++、そしてKotlinやGolangのような新しい言語であっても、セキュリティを意識しない開発者にはかなり厳しいものがあります。これらの言語では、組み込まれた警告や、コンパイルされたばかりの素晴らしい機能にセキュリティグレムリンが潜んでいることを示す特別な兆候はありません。
では、もっと掘り下げてみましょう。
ラストの安全性の理由は？
通常、開発者は機能を構築し、機能的でユーザーフレンドリーであることを保証することを第一の目標としており、おそらく履歴書に誇れるものでもあるでしょう。開発者が素晴らしいソフトウェアを作り、それを出荷し、次の大きなプロジェクトに移ることは全く普通のことです。この時点で、セキュリティチームが脆弱性をチェックし、もし見つかった場合は、「完成した」アプリケーションがホットフィックスを求めてチームに戻ってくるかもしれません。問題が単純な場合もあれば、開発者が修正できる範囲を完全に逸脱している場合もあります。
問題は、表面的にはセキュリティバグが全く明らかになっていないことであり、スキャン、テスト、手動によるコードレビューがバグを拾えなかった場合、攻撃者はそのわずかな機会を利用してバグを悪用する可能性があります。
Rustでは、多くの脆弱性がコードに混入するのを未然に防ぐことを目指しています。構文エラーや、SDLCの過程で生産上の問題を引き起こすメモリ安全性のバグがある場合は、単純にコンパイルされません。これは、ソフトウェアがどのように実行されても、無効なメモリへのアクセスがないことを保証する、設計上のメモリセーフプログラミングです。セキュリティバグの70％がメモリ管理関連の問題であることを考えると、これは大変なことです。
サビはフラグを立てて防ぎます。
- バッファオーバーフロー
- 無料になってから使う
- ダブルフリー
- Null ポインタの脱参照
- 初期化されていないメモリの使用
RustのコードスニペットをC++と比較すると、どちらかがデフォルトで安全であることが明らかになります。バッファオーバーフローのバグの例を見てみましょう。
#include <iostream></iostream>
#include <string.h></string.h>
int main( void ) {
char a[3] = "12";
char b[4]= "123";
strcpy(a, b); // buffer overflow as len of b is greater than a
std::cout << a << "; " << b << std::endl;
}
対。
pub fn main() {
let mut a: [char; 2] = [1, 2];
let b: [char; 3] = [1, 2, 3];
a.copy_from_slice(&b);
}
Rustはバッファオーバーフローを防ぐために、実行時にはセキュリティ警告を出し、copy_from_slice関数に到達した時点でパニックを起こしますが、コンパイル時には起こりません。
その意味では、「左から始める」言語の一つであると言えます。エラーがハイライトされ、メモリ関連のセキュリティバグを発生させないための正しいコードの書き方を開発者に強制的に教えてくれるので、納期に間に合うかどうかは、コーダーが注意を払い、修正し、デリバリーパスに忠実であるかどうかにかかっています。
この言語のアプローチは単純に見えますが、この強力なロジックで動作させるのは信じられないほどの偉業であり、その道を歩んでいるのです。Rustは、セキュリティの観点からすると、大きな飛躍と言えます。Dropboxのような企業は、大規模な企業規模での利用を開拓しており、これは素晴らしいことです。しかし、より安全な未来を阻んでいるのが採用の問題であるという結論に達する前に、もっと考慮すべきことがあるのです。
ラストのおさらい
Rustでプログラミングすると、見た目以上にバグが発生しやすいという小さな（まあ、大きな）問題がいくつかあります。Rustは、OWASPのトップ10の脆弱性を修正することはできず、違反や遅延、安全でないコーディング技術の一般的な文化を引き起こし続けています。また、天使と悪魔の戦い、あるいはより広く知られているように、安全なRustと安全でないRustの戦いもあります。
。
公式ドキュメントでも説明されているように、Safe RustはRustの「真の」形であり、Unsafe Rustは、他の言語の何かとの統合が必要な場合など、時には必要となるものの、「絶対に安全ではない」と判断された機能を含んでいます。しかし、Unsafe Rustであっても、追加できる機能は限られている。Unsafe Rustでは、安全でないブロックの中で、以下のようなことが可能です。
- 生のポインターを脱参照する
- 安全でない関数の呼び出し（C関数、コンパイラの組込み関数、ローアローケータを含む
- 安全でない特性の実装
- スタティックを変異させる
- ユニオンのフィールドにアクセスします。
いわゆる「安全でない」モードであっても、Rustプログラミングの超能力の1つである「ボローチェッカー」は依然として機能します。一般に、静的コード解析によって、メモリ問題や並列計算の衝突、その他多くのバグを防ぎます。この解析は、安全でないブロックでもチェックを行います。特定の状況下でコンパイラが指導に入らずに安全でない構造を書くには、より多くの作業が必要になるだけなのです。
しかし、これは深刻な設定ミスやセキュリティ脆弱性につながるブラックホール、すなわち未定義の動作を引き起こす可能性があります。Rustでのプログラミングは、CやC++と比較して、（安全でない使い方であっても）脆弱性の可能性をかなり低く抑えることができますが、未定義の振る舞いを呼び出すことはリスクになり得ます。
これで、開発者主導のセキュアコーディングに頼ることは終わりでしょうか？
以前、Rustはよく知られた言語の部品を含んでいると言いましたが、覚えていますか？Rustの主なセキュリティ上の脆弱性の1つは、よく知られた言語、つまりC言語のコンポーネントを含んでいることです。
Rustは今でも「安全なプログラミング言語」ですが、やはりユーザーを導入することで物事がうまくいかなくなることがあります。開発者は、エラーを出さずに実行できるように調整することができます（より多くの機能が使えるようになるため、魅力的な提案です）。基本的に、安全な状態であっても、開発者は好きなだけ「安全でない」ことができます。
Rustの成果はスキャンツールに似ています。すべての脆弱性、すべての攻撃ベクトル、すべての問題をスキャンするスイスアーミーSAST/DAST/RAST/IASTツールがないように、Rustもそうではありません。Rustを使用しても、いくつかの脆弱性は、非常に簡単に導入される可能性があります。
安全でないRustを実行したときの未定義の動作は、整数オーバーフローの問題を引き起こす可能性があります。また、一般的に、安全な設定であっても、セキュリティの設定ミスやビジネスロジック、既知の脆弱性を持つコンポーネントの使用などのヒューマンエラーを防ぐことはできません。これらの問題は、パッチを当てずに放置すると非常に大きな脅威となります。また、真のRustのような「安全だと思われている」環境では、重大な問題がすべて拾われるとコーダーが信じている場合、自己満足的な行動をとる可能性もあります。
Rustは、プログラミングのメンターと同じように、経験の浅いコーダーと一緒に時間をかけて、彼らの仕事を見直し、バグの可能性を示し、効率性を指摘し、場合によっては、正しいものになるまでコンパイルしないようにする上級エンジニアのことです。しかし、Rustプログラマーにとっては、自分自身で理論を学び、ベストプラクティスに取り組む方がはるかに良いのです。なぜなら、メンターがエプロンの紐を切ってしまうかもしれないし、あなたがぶら下がったままになるのは嫌だからです。
今すぐRustの一般的な脆弱性を見つけて修正する準備はできましたか？ チャレンジしてみてください。
ここ数年、世界中のソフトウェアエンジニアは、プログラミングのためのRustに飽き足らないようです。Mozilla が開発したこの比較的新しいシステムプログラミング言語は、Stack Overflow コミュニティの心を掴みました。
プログラミング言語Rustは、一般的に使用されている言語から既知の要素や関数的な要素を取り入れ、パフォーマンスと安全性を導入しながら、複雑さを排除する異なる哲学に基づいて作業しています。学習が必要なため、多くの開発者はあまり使う機会がなく、Stack Overflowで調査した人のわずか5.1%が普通に使っているに過ぎない。しかし、それはさておき、この言語がエキサイティングであること、そしてCやC++といった従来の言語に比べてセキュリティの面で非常に強力であることは否定できない。しかし、今はまだ、理論的なレベルで開発者の関心を集めている段階です。
Rust は、メモリの安全性と、一般的なメモリ管理の問題と結びついたセキュリティバグの撲滅を最優先するプログラミング言語であることは、重要なポイントです。Rust は、メモリ安全性と、一般的なメモリ管理の問題と結びついたセキュリティバグの撲滅を優先するプログラミング言語であるということが重要です。これは大きな問題ですが（そして間違いなく、少なからぬ AppSec チームの頭痛の種になっています）、私たちが直面する安全なコーディングの課題は、これだけではありません。
Rustは何を防ぐのでしょうか？そして、私たちは、セキュリティ環境のどこに、まださらされているのでしょうか？最新のプログラミングユニコーンを紐解いてみましょう。
メモリセーフな最新システムプログラミングの新境地
Mozilla の研究開発チームは、いくつかの素晴らしいプロジェクトに取り組んでおり、オープンソースの先駆者として Rust プログラミングに投資することも例外ではありません。その紹介ビデオでは、彼らの哲学を知ることができます。重要なテーマは非常に明確で、ソフトウェアセキュリティに対する現在のアプローチには欠陥があり、Rust はその問題の多くを解決するために設計されています。
最近のEasyJet社のように、私たちは毎日のように大規模なデータ漏洩に直面しているので、この言葉はあまりにも単純に思えます。C++のような言語は何十年も前から存在しています。C++のような言語は何十年も前から存在していますが、開発者が安全なコーディングのベストプラクティスを実践できるまでに習得するには十分な時間がありませんでした。なぜRustがそうでなければならないのでしょうか。これまでにも新しい言語は登場してきましたが、一般的な脆弱性を根絶する方法が見つかったわけでも、書かれたコードがコンパイル時に魔法のように完璧になるわけでもありません。
コンセプトはシンプルですが、複雑な問題を解決するのはシンプルな答えであることがあります。Rustは、あらゆる意味で、メモリセーフなシステムプログラミングの革命であり、多くの点でその約束を果たしています......そして、発見されなければ大きな問題を引き起こす可能性のあるエラーを導入しがちな開発者のベーコンを確実に救っています。Java、C、C++、そしてKotlinやGolangのような新しい言語であっても、セキュリティを意識しない開発者にはかなり厳しいものがあります。これらの言語では、組み込まれた警告や、コンパイルされたばかりの素晴らしい機能にセキュリティグレムリンが潜んでいることを示す特別な兆候はありません。
では、もっと掘り下げてみましょう。
ラストの安全性の理由は？
通常、開発者は機能を構築し、機能的でユーザーフレンドリーであることを保証することを第一の目標としており、おそらく履歴書に誇れるものでもあるでしょう。開発者が素晴らしいソフトウェアを作り、それを出荷し、次の大きなプロジェクトに移ることは全く普通のことです。この時点で、セキュリティチームが脆弱性をチェックし、もし見つかった場合は、「完成した」アプリケーションがホットフィックスを求めてチームに戻ってくるかもしれません。問題が単純な場合もあれば、開発者が修正できる範囲を完全に逸脱している場合もあります。
問題は、表面的にはセキュリティバグが全く明らかになっていないことであり、スキャン、テスト、手動によるコードレビューがバグを拾えなかった場合、攻撃者はそのわずかな機会を利用してバグを悪用する可能性があります。
Rustでは、多くの脆弱性がコードに混入するのを未然に防ぐことを目指しています。構文エラーや、SDLCの過程で生産上の問題を引き起こすメモリ安全性のバグがある場合は、単純にコンパイルされません。これは、ソフトウェアがどのように実行されても、無効なメモリへのアクセスがないことを保証する、設計上のメモリセーフプログラミングです。セキュリティバグの70％がメモリ管理関連の問題であることを考えると、これは大変なことです。
サビはフラグを立てて防ぎます。
- バッファオーバーフロー
- 無料になってから使う
- ダブルフリー
- Null ポインタの脱参照
- 初期化されていないメモリの使用
RustのコードスニペットをC++と比較すると、どちらかがデフォルトで安全であることが明らかになります。バッファオーバーフローのバグの例を見てみましょう。
#include <iostream></iostream>
#include <string.h></string.h>
int main( void ) {
char a[3] = "12";
char b[4]= "123";
strcpy(a, b); // buffer overflow as len of b is greater than a
std::cout << a << "; " << b << std::endl;
}
対。
pub fn main() {
let mut a: [char; 2] = [1, 2];
let b: [char; 3] = [1, 2, 3];
a.copy_from_slice(&b);
}
Rustはバッファオーバーフローを防ぐために、実行時にはセキュリティ警告を出し、copy_from_slice関数に到達した時点でパニックを起こしますが、コンパイル時には起こりません。
その意味では、「左から始める」言語の一つであると言えます。エラーがハイライトされ、メモリ関連のセキュリティバグを発生させないための正しいコードの書き方を開発者に強制的に教えてくれるので、納期に間に合うかどうかは、コーダーが注意を払い、修正し、デリバリーパスに忠実であるかどうかにかかっています。
この言語のアプローチは単純に見えますが、この強力なロジックで動作させるのは信じられないほどの偉業であり、その道を歩んでいるのです。Rustは、セキュリティの観点からすると、大きな飛躍と言えます。Dropboxのような企業は、大規模な企業規模での利用を開拓しており、これは素晴らしいことです。しかし、より安全な未来を阻んでいるのが採用の問題であるという結論に達する前に、もっと考慮すべきことがあるのです。
ラストのおさらい
Rustでプログラミングすると、見た目以上にバグが発生しやすいという小さな（まあ、大きな）問題がいくつかあります。Rustは、OWASPのトップ10の脆弱性を修正することはできず、違反や遅延、安全でないコーディング技術の一般的な文化を引き起こし続けています。また、天使と悪魔の戦い、あるいはより広く知られているように、安全なRustと安全でないRustの戦いもあります。
。
公式ドキュメントでも説明されているように、Safe RustはRustの「真の」形であり、Unsafe Rustは、他の言語の何かとの統合が必要な場合など、時には必要となるものの、「絶対に安全ではない」と判断された機能を含んでいます。しかし、Unsafe Rustであっても、追加できる機能は限られている。Unsafe Rustでは、安全でないブロックの中で、以下のようなことが可能です。
- 生のポインターを脱参照する
- 安全でない関数の呼び出し（C関数、コンパイラの組込み関数、ローアローケータを含む
- 安全でない特性の実装
- スタティックを変異させる
- ユニオンのフィールドにアクセスします。
いわゆる「安全でない」モードであっても、Rustプログラミングの超能力の1つである「ボローチェッカー」は依然として機能します。一般に、静的コード解析によって、メモリ問題や並列計算の衝突、その他多くのバグを防ぎます。この解析は、安全でないブロックでもチェックを行います。特定の状況下でコンパイラが指導に入らずに安全でない構造を書くには、より多くの作業が必要になるだけなのです。
しかし、これは深刻な設定ミスやセキュリティ脆弱性につながるブラックホール、すなわち未定義の動作を引き起こす可能性があります。Rustでのプログラミングは、CやC++と比較して、（安全でない使い方であっても）脆弱性の可能性をかなり低く抑えることができますが、未定義の振る舞いを呼び出すことはリスクになり得ます。
これで、開発者主導のセキュアコーディングに頼ることは終わりでしょうか？
以前、Rustはよく知られた言語の部品を含んでいると言いましたが、覚えていますか？Rustの主なセキュリティ上の脆弱性の1つは、よく知られた言語、つまりC言語のコンポーネントを含んでいることです。
Rustは今でも「安全なプログラミング言語」ですが、やはりユーザーを導入することで物事がうまくいかなくなることがあります。開発者は、エラーを出さずに実行できるように調整することができます（より多くの機能が使えるようになるため、魅力的な提案です）。基本的に、安全な状態であっても、開発者は好きなだけ「安全でない」ことができます。
Rustの成果はスキャンツールに似ています。すべての脆弱性、すべての攻撃ベクトル、すべての問題をスキャンするスイスアーミーSAST/DAST/RAST/IASTツールがないように、Rustもそうではありません。Rustを使用しても、いくつかの脆弱性は、非常に簡単に導入される可能性があります。
安全でないRustを実行したときの未定義の動作は、整数オーバーフローの問題を引き起こす可能性があります。また、一般的に、安全な設定であっても、セキュリティの設定ミスやビジネスロジック、既知の脆弱性を持つコンポーネントの使用などのヒューマンエラーを防ぐことはできません。これらの問題は、パッチを当てずに放置すると非常に大きな脅威となります。また、真のRustのような「安全だと思われている」環境では、重大な問題がすべて拾われるとコーダーが信じている場合、自己満足的な行動をとる可能性もあります。
Rustは、プログラミングのメンターと同じように、経験の浅いコーダーと一緒に時間をかけて、彼らの仕事を見直し、バグの可能性を示し、効率性を指摘し、場合によっては、正しいものになるまでコンパイルしないようにする上級エンジニアのことです。しかし、Rustプログラマーにとっては、自分自身で理論を学び、ベストプラクティスに取り組む方がはるかに良いのです。なぜなら、メンターがエプロンの紐を切ってしまうかもしれないし、あなたがぶら下がったままになるのは嫌だからです。
今すぐRustの一般的な脆弱性を見つけて修正する準備はできましたか？ チャレンジしてみてください。
以下のリンクをクリックして、このリソースのPDFをダウンロードしてください。
Secure Code Warrior 、ソフトウェア開発サイクル全体を通じてコードの安全性を確保し、サイバーセキュリティを最優先とする文化を構築するため、貴社をSecure Code Warrior 。アプリセキュリティ管理者、開発者、CISO、あるいはセキュリティに関わるあらゆる立場の方々に対し、当社が貴社のビジネスにおける不安全なコードに関連するリスクの低減を支援します。
レポートを見るデモを予約する
Matias Madou, Ph.D. セキュリティ専門家、研究者、CTO兼共同設立者（Secure Code Warrior ）。Ghent大学でアプリケーションセキュリティの博士号を取得し、静的解析ソリューションに焦点を当てた。その後、米国Fortify社に入社し、開発者が安全なコードを書くことを支援せずに、コードの問題を検出するだけでは不十分であることに気づきました。開発者を支援し、セキュリティの負担を軽減し、お客様の期待を上回る製品を開発することを志すようになった。Team Awesomeの一員としてデスクワークをしていないときは、RSA Conference、BlackHat、DefConなどのカンファレンスでプレゼンテーションをするのが好きである。
マティアスは、15年以上のソフトウェアセキュリティの実務経験を持つ研究者・開発者です。フォーティファイ・ソフトウェア社や自身の会社（Sensei Security）などでソリューションを開発してきました。キャリアの中で、Matiasは、商用製品につながる複数のアプリケーションセキュリティ研究プロジェクトを主導し、10件以上の特許を取得しています。また、RSAカンファレンス、Black Hat、DefCon、BSIMM、OWASP AppSec、BruConなどの世界的なカンファレンスで定期的に講演を行っているほか、高度なアプリケーションセキュリティトレーニング（courses ）の講師も務めています。
Matiasはゲント大学でコンピュータ工学の博士号を取得し、アプリケーションの内部構造を隠すためのプログラム難読化によるアプリケーションセキュリティを研究しました。
ここ数年、世界中のソフトウェアエンジニアは、プログラミングのためのRustに飽き足らないようです。Mozilla が開発したこの比較的新しいシステムプログラミング言語は、Stack Overflow コミュニティの心を掴みました。
プログラミング言語Rustは、一般的に使用されている言語から既知の要素や関数的な要素を取り入れ、パフォーマンスと安全性を導入しながら、複雑さを排除する異なる哲学に基づいて作業しています。学習が必要なため、多くの開発者はあまり使う機会がなく、Stack Overflowで調査した人のわずか5.1%が普通に使っているに過ぎない。しかし、それはさておき、この言語がエキサイティングであること、そしてCやC++といった従来の言語に比べてセキュリティの面で非常に強力であることは否定できない。しかし、今はまだ、理論的なレベルで開発者の関心を集めている段階です。
Rust は、メモリの安全性と、一般的なメモリ管理の問題と結びついたセキュリティバグの撲滅を最優先するプログラミング言語であることは、重要なポイントです。Rust は、メモリ安全性と、一般的なメモリ管理の問題と結びついたセキュリティバグの撲滅を優先するプログラミング言語であるということが重要です。これは大きな問題ですが（そして間違いなく、少なからぬ AppSec チームの頭痛の種になっています）、私たちが直面する安全なコーディングの課題は、これだけではありません。
Rustは何を防ぐのでしょうか？そして、私たちは、セキュリティ環境のどこに、まださらされているのでしょうか？最新のプログラミングユニコーンを紐解いてみましょう。
メモリセーフな最新システムプログラミングの新境地
Mozilla の研究開発チームは、いくつかの素晴らしいプロジェクトに取り組んでおり、オープンソースの先駆者として Rust プログラミングに投資することも例外ではありません。その紹介ビデオでは、彼らの哲学を知ることができます。重要なテーマは非常に明確で、ソフトウェアセキュリティに対する現在のアプローチには欠陥があり、Rust はその問題の多くを解決するために設計されています。
最近のEasyJet社のように、私たちは毎日のように大規模なデータ漏洩に直面しているので、この言葉はあまりにも単純に思えます。C++のような言語は何十年も前から存在しています。C++のような言語は何十年も前から存在していますが、開発者が安全なコーディングのベストプラクティスを実践できるまでに習得するには十分な時間がありませんでした。なぜRustがそうでなければならないのでしょうか。これまでにも新しい言語は登場してきましたが、一般的な脆弱性を根絶する方法が見つかったわけでも、書かれたコードがコンパイル時に魔法のように完璧になるわけでもありません。
コンセプトはシンプルですが、複雑な問題を解決するのはシンプルな答えであることがあります。Rustは、あらゆる意味で、メモリセーフなシステムプログラミングの革命であり、多くの点でその約束を果たしています......そして、発見されなければ大きな問題を引き起こす可能性のあるエラーを導入しがちな開発者のベーコンを確実に救っています。Java、C、C++、そしてKotlinやGolangのような新しい言語であっても、セキュリティを意識しない開発者にはかなり厳しいものがあります。これらの言語では、組み込まれた警告や、コンパイルされたばかりの素晴らしい機能にセキュリティグレムリンが潜んでいることを示す特別な兆候はありません。
では、もっと掘り下げてみましょう。
ラストの安全性の理由は？
通常、開発者は機能を構築し、機能的でユーザーフレンドリーであることを保証することを第一の目標としており、おそらく履歴書に誇れるものでもあるでしょう。開発者が素晴らしいソフトウェアを作り、それを出荷し、次の大きなプロジェクトに移ることは全く普通のことです。この時点で、セキュリティチームが脆弱性をチェックし、もし見つかった場合は、「完成した」アプリケーションがホットフィックスを求めてチームに戻ってくるかもしれません。問題が単純な場合もあれば、開発者が修正できる範囲を完全に逸脱している場合もあります。
問題は、表面的にはセキュリティバグが全く明らかになっていないことであり、スキャン、テスト、手動によるコードレビューがバグを拾えなかった場合、攻撃者はそのわずかな機会を利用してバグを悪用する可能性があります。
Rustでは、多くの脆弱性がコードに混入するのを未然に防ぐことを目指しています。構文エラーや、SDLCの過程で生産上の問題を引き起こすメモリ安全性のバグがある場合は、単純にコンパイルされません。これは、ソフトウェアがどのように実行されても、無効なメモリへのアクセスがないことを保証する、設計上のメモリセーフプログラミングです。セキュリティバグの70％がメモリ管理関連の問題であることを考えると、これは大変なことです。
サビはフラグを立てて防ぎます。
- バッファオーバーフロー
- 無料になってから使う
- ダブルフリー
- Null ポインタの脱参照
- 初期化されていないメモリの使用
RustのコードスニペットをC++と比較すると、どちらかがデフォルトで安全であることが明らかになります。バッファオーバーフローのバグの例を見てみましょう。
#include <iostream></iostream>
#include <string.h></string.h>
int main( void ) {
char a[3] = "12";
char b[4]= "123";
strcpy(a, b); // buffer overflow as len of b is greater than a
std::cout << a << "; " << b << std::endl;
}
対。
pub fn main() {
let mut a: [char; 2] = [1, 2];
let b: [char; 3] = [1, 2, 3];
a.copy_from_slice(&b);
}
Rustはバッファオーバーフローを防ぐために、実行時にはセキュリティ警告を出し、copy_from_slice関数に到達した時点でパニックを起こしますが、コンパイル時には起こりません。
その意味では、「左から始める」言語の一つであると言えます。エラーがハイライトされ、メモリ関連のセキュリティバグを発生させないための正しいコードの書き方を開発者に強制的に教えてくれるので、納期に間に合うかどうかは、コーダーが注意を払い、修正し、デリバリーパスに忠実であるかどうかにかかっています。
この言語のアプローチは単純に見えますが、この強力なロジックで動作させるのは信じられないほどの偉業であり、その道を歩んでいるのです。Rustは、セキュリティの観点からすると、大きな飛躍と言えます。Dropboxのような企業は、大規模な企業規模での利用を開拓しており、これは素晴らしいことです。しかし、より安全な未来を阻んでいるのが採用の問題であるという結論に達する前に、もっと考慮すべきことがあるのです。
ラストのおさらい
Rustでプログラミングすると、見た目以上にバグが発生しやすいという小さな（まあ、大きな）問題がいくつかあります。Rustは、OWASPのトップ10の脆弱性を修正することはできず、違反や遅延、安全でないコーディング技術の一般的な文化を引き起こし続けています。また、天使と悪魔の戦い、あるいはより広く知られているように、安全なRustと安全でないRustの戦いもあります。
。
公式ドキュメントでも説明されているように、Safe RustはRustの「真の」形であり、Unsafe Rustは、他の言語の何かとの統合が必要な場合など、時には必要となるものの、「絶対に安全ではない」と判断された機能を含んでいます。しかし、Unsafe Rustであっても、追加できる機能は限られている。Unsafe Rustでは、安全でないブロックの中で、以下のようなことが可能です。
- 生のポインターを脱参照する
- 安全でない関数の呼び出し（C関数、コンパイラの組込み関数、ローアローケータを含む
- 安全でない特性の実装
- スタティックを変異させる
- ユニオンのフィールドにアクセスします。
いわゆる「安全でない」モードであっても、Rustプログラミングの超能力の1つである「ボローチェッカー」は依然として機能します。一般に、静的コード解析によって、メモリ問題や並列計算の衝突、その他多くのバグを防ぎます。この解析は、安全でないブロックでもチェックを行います。特定の状況下でコンパイラが指導に入らずに安全でない構造を書くには、より多くの作業が必要になるだけなのです。
しかし、これは深刻な設定ミスやセキュリティ脆弱性につながるブラックホール、すなわち未定義の動作を引き起こす可能性があります。Rustでのプログラミングは、CやC++と比較して、（安全でない使い方であっても）脆弱性の可能性をかなり低く抑えることができますが、未定義の振る舞いを呼び出すことはリスクになり得ます。
これで、開発者主導のセキュアコーディングに頼ることは終わりでしょうか？
以前、Rustはよく知られた言語の部品を含んでいると言いましたが、覚えていますか？Rustの主なセキュリティ上の脆弱性の1つは、よく知られた言語、つまりC言語のコンポーネントを含んでいることです。
Rustは今でも「安全なプログラミング言語」ですが、やはりユーザーを導入することで物事がうまくいかなくなることがあります。開発者は、エラーを出さずに実行できるように調整することができます（より多くの機能が使えるようになるため、魅力的な提案です）。基本的に、安全な状態であっても、開発者は好きなだけ「安全でない」ことができます。
Rustの成果はスキャンツールに似ています。すべての脆弱性、すべての攻撃ベクトル、すべての問題をスキャンするスイスアーミーSAST/DAST/RAST/IASTツールがないように、Rustもそうではありません。Rustを使用しても、いくつかの脆弱性は、非常に簡単に導入される可能性があります。
安全でないRustを実行したときの未定義の動作は、整数オーバーフローの問題を引き起こす可能性があります。また、一般的に、安全な設定であっても、セキュリティの設定ミスやビジネスロジック、既知の脆弱性を持つコンポーネントの使用などのヒューマンエラーを防ぐことはできません。これらの問題は、パッチを当てずに放置すると非常に大きな脅威となります。また、真のRustのような「安全だと思われている」環境では、重大な問題がすべて拾われるとコーダーが信じている場合、自己満足的な行動をとる可能性もあります。
Rustは、プログラミングのメンターと同じように、経験の浅いコーダーと一緒に時間をかけて、彼らの仕事を見直し、バグの可能性を示し、効率性を指摘し、場合によっては、正しいものになるまでコンパイルしないようにする上級エンジニアのことです。しかし、Rustプログラマーにとっては、自分自身で理論を学び、ベストプラクティスに取り組む方がはるかに良いのです。なぜなら、メンターがエプロンの紐を切ってしまうかもしれないし、あなたがぶら下がったままになるのは嫌だからです。
今すぐRustの一般的な脆弱性を見つけて修正する準備はできましたか？ チャレンジしてみてください。
目次
Matias Madou, Ph.D. セキュリティ専門家、研究者、CTO兼共同設立者（Secure Code Warrior ）。Ghent大学でアプリケーションセキュリティの博士号を取得し、静的解析ソリューションに焦点を当てた。その後、米国Fortify社に入社し、開発者が安全なコードを書くことを支援せずに、コードの問題を検出するだけでは不十分であることに気づきました。開発者を支援し、セキュリティの負担を軽減し、お客様の期待を上回る製品を開発することを志すようになった。Team Awesomeの一員としてデスクワークをしていないときは、RSA Conference、BlackHat、DefConなどのカンファレンスでプレゼンテーションをするのが好きである。
Secure Code Warrior 、ソフトウェア開発サイクル全体を通じてコードの安全性を確保し、サイバーセキュリティを最優先とする文化を構築するため、貴社をSecure Code Warrior 。アプリセキュリティ管理者、開発者、CISO、あるいはセキュリティに関わるあらゆる立場の方々に対し、当社が貴社のビジネスにおける不安全なコードに関連するリスクの低減を支援します。
デモを予約するダウンロード
%20(1).avif)
.avif)
