c - 取得は役に立ちましたか?

Question

私には、特に C プログラミング言語を学んでいる人々は、getsstdin からデータを読み込むために関数をまだ使用しているようです。C11標準から^1つ削除されましたが、 cppreferenceの免責事項には次のように記載されています。

gets() 関数は境界チェックを実行しないため、この関数はバッファ オーバーフロー攻撃に対して非常に脆弱です。安全に使用することはできません (標準入力に表示される内容を制限する環境でプログラムを実行しない限り)。このため、この関数は C99 標準の 3 番目の正誤表で非推奨になり、C11 標準では完全に削除されました。fgets() と gets_s() は、推奨される代替品です。

gets() を使用しないでください。

ただし、これは、より現代的なプログラミング哲学を思いついた新しい問題ではないようです。それは常に壊れていて、プログラムがクラッシュする原因となっていました。「標準入力に表示できるものを制限する環境」が何を意味するのかわかりません。

それで、それは過去に役に立ちましたか？または、それが C の以前の標準および標準化前のバージョンに追加された理由は何ですか?

---

⁽¹⁾ _{... または少なくとも、読み取る最大長を示す追加のパラメーターを持つように変更されました。しかし、私は古い署名について尋ねており、ポインタしか受け取っていません。}

Answer 1

はい、それは有用であると同時に「バッファオーバーフロー攻撃に対して非常に脆弱」でした。

それは常に壊れており、プログラムがクラッシュする原因となっていました。「標準入力に表示できるものを制限する環境」が何を意味するのかわかりません。

いいえ、getsプログラムがクラッシュすることはありませんでした。これは主にセキュリティの問題です。ここでバッファオーバーフロー攻撃について読むことができます

次の質問も参照してください: gets 関数が非常に危険なため、使用すべきではないのはなぜですか?

Answer 2

Cの黎明期の名残を見ると、歴史的背景を考えなければなりません。

C 言語は 70 年代に設計されました。当時、ネットワーク化されたシステムは例外であり、セキュリティは今日ほど重要視されていませんでした。システムが信頼できないサードパーティのデータで動作することはめったにありませんでした。そして、彼らがそうしていたとしても、それほど大きなリスクとは考えられていませんでした. 情報技術はまだ黎明期にありました。コンピューター システムがどれほど機密性が高いか、誰も認識していませんでした。

一方、CPU 時間は貴重でした。プログラムは可能な限り効率的である必要がありました。

これが、C 標準ライブラリのほとんどの関数が境界チェックを行わない理由です。パフォーマンスは、セキュリティよりもはるかに優先されました。セキュリティが必要な場合、データをプログラムに供給する前に検証する必要がありました。

しかし、今日の 21 世紀では、すべてのコンピューター システムが相互接続され、すべてのコンピューター システムが、信頼されていない、または未知の発信元からの情報を常に処理しています。

Answer 3

発明されたときgets、信頼できないソースからの大量の入力を受け入れることができる必要のあるプログラムはほとんどありませんでした。gets協力するユーザーからの限られた入力には十分です。このユーザーは、各行にあまり入力しないことで、「表示できるものを制限する環境」を提供します。「y/n」プロンプトに数百バイトのデータを入力しないように、端末に座っているユーザーを大いに期待することができます。彼らがあなたのプログラムに大きなファイルをパイプした場合、あなたのプログラムがそのために設計されていなかったとき、まあ、彼らは悪い結果を得ました。

任意の入力を処理する必要があったプログラムは、を使用しませんでしgetsた。

現在、悪意のある入力は実際には一般的であり、攻撃者がバッファオーバーフローを簡単に有利に利用できるようにするツールと手法が存在するため、より大きな被害をもたらします。よく訓練されたユーザーがプロンプトで入力するのはニッチなケースです。さらに、悪意のある入力のアカウンティングは、攻撃を意図していない予期しない入力に対してソフトウェアが堅牢であることを保証するための優れた手法として広く使用されています。ほとんどすべてのプログラムは、任意の入力を処理することが期待されています。したがってgets、明らかに不十分です。

Answer 4

Gets は今でもプロトタイプ作成に役立ちます。プログラムをクラッシュさせようとするのではなく、目の前の問題を解決することを志向するプログラマーにとって、書くのは速く、期待される結果をもたらします。