ユーザー入力を信頼できないことは、よく知られている真実です。これらの入力は、フィルタリングせずに使用すると、セキュリティ上の問題になる可能性さえあります。XSS および SQL インジェクションは、フィルタリングされていないユーザー入力 (またはユーザーが変更できる入力) を使用することで発生する可能性がある問題です。
このような問題を回避するには、外部リソースの影響を受ける可能性のあるすべての文字列を制御する必要があります。Perl は、'Taint-mode' でこれをサポートしています。
私が知っている問題はすべて、操作された文字列が原因です。外部の影響によって操作される int や float などに起因するセキュリティ問題の例を知っていますか? それとも、このデータ型は安全であると想定できますか?
最終的に、変換するかどうかにかかわらず、すべての値は文字列としてプログラムに渡されます。この理由だけでなく、すべてが潜在的に有害であると見なされるべきです。
たとえば、数字フィールドに数字以外の文字を入力すると、解析エラーが発生する可能性があります。予期しない場所にゼロを入れると、ゼロ除算エラーが発生する可能性があります。予想よりもはるかに大きな値を入力したり、予想外の場合に負の値を入力したり、その他のさまざまなことを行ったりすると、何らかのエラーが発生する可能性があります。また、システム エラーによって必要以上の情報が漏えいする可能性も十分にあります。たとえば、ASP.NET アプリケーションでは、カスタム エラーがオンになっていない場合、データベース接続情報、物理パス情報、またはサイトが使用するサード パーツ ライブラリに関する情報が、既定のエラー メッセージで漏えいする可能性があります。
文字列はおそらく他の値よりも問題になる可能性が高くなりますが、すべてのユーザー入力は潜在的に有害なものとして扱う必要があります。
いいえ、外部ソースからの番号を受け入れることでセキュリティ上の問題が発生する可能性があります。外部ソースが、(たとえば) 処理する必要のある配列内の多数の要素を提供する場合、やみくもに信頼されている多数の要素は、スローダウンまたはメモリの枯渇を引き起こすのに十分なメモリを割り当てることにより、サービス拒否を引き起こす可能性があります。逆に、小さすぎる数値を受け入れて、記憶域を割り当てたよりも多くの要素をやみくもに読み続けると、スタックまたはヒープの上書きが発生する可能性があります。
安全かどうかはデータ型ではなく、これを決定するのはその下のコードです。
とは言うものの、文字列は通常、バッファー オーバーランまたは基になるインタープリター (SQL またはスクリプト言語) に対するインジェクション スタイルの攻撃のいずれかによって問題を引き起こします。明らかに、数値型の変数からこの種の問題は発生しません。
発生する可能性があるのは、サービス拒否攻撃のようなものに役立つ可能性のある悪い外部値に関連するバグです。