2

最近公開されたRailsS​​QLインジェクションの脆弱性に関して大きな懸念があります。私はセキュリティの扱いに精通していないので、神経質になっています。MongoDBはこの種の攻撃の影響を受けにくいと聞いています。

これは、MongoDBに恒久的に移行する正当な理由ですか？

4

3 に答える 3

4

いいえ。SQLデータベースがSQLインジェクション攻撃に対して脆弱であるという理由だけで、MongoDBに移行する理由はありません。

MongoDBは、特定のユースケース、特にスキーマのないコレクションが必要な場合に最適です。

リレーショナルデータを保存する必要がある場合は、リレーショナルDBの方がはるかに便利です。

つまり、SQLインジェクションが怖い場合は、入力をサニタイズする方法を学びましょう。MongoDBに移動しないでください。

新たに発見された脆弱性は、すべての人に影響を与えるわけではありません。詳細については、こちらをお読みください。

于 2013-01-18T20:52:42.080 に答える
2

SQL！= NoSQL

SQLを使用するリレーショナルデータベースは、NoSQLの機能ごとの置き換えではありません。問題のドメインによっては、アーキテクチャや設計の決定を異なる場合がありますが、設計目標とパフォーマンス特性が大きく異なるため、スペアパーツのように単純に交換することはできません。

すべてのソフトウェアにはリスクがあります

ソフトウェアのセキュリティは大きなトピックであり、SOの質問の範囲をはるかに超えています。ただし、広く使用されていてすぐにパッチが適用される製品から、理解できない製品に切り替えることは、本質的に適切なリスク管理のトレードオフではありません。

実際、あなたが言及している脆弱性は、その後パッチが適用されたRailsの脆弱性です。将来、MVCまたはOSスタックのさまざまな部分を対象とする他のRubyまたはRailsの脆弱性（または実際にはネットワークまたはOSの脆弱性）がないという保証はありません。したがって、SQLをこのストーリーの本質的な悪役として描くことで、リスク管理の観点から何が得られると思うかはわかりません。

于 2013-01-18T20:59:37.187 に答える
2

SQLインジェクションは、何十年にもわたって知られており、よく理解されている問題です。あなたがそれらに固執するとき、SQLインジェクションを完全に不可能にするコーディング慣行があります：

  • クエリに入れる前に、エスケープ関数を介してすべての変数を実行します
  • プリペアドステートメントを使用する
  • ストアドプロシージャを使用する

これらのプラクティスの少なくとも1つを常に使用してください。そうすれば、SQLインジェクションを恐れる必要はありません。

一方、MongoDBはかなり新しいテクノロジーです。脆弱なアプリケーションにつながる最も一般的な初心者のミスの種類はまだわかっていません。たぶん、誰もが気付かずに今やっているSQLインジェクションと同じくらい悪いことがあるでしょう。たぶん、エクスプロイトはすでにブラックハットハッカーの間で循環しています。知るか？

また、CodeGnomeが指摘しているように、MongoDBはSQLデータベースのドロップイン代替品ではありません。それは完全に異なる哲学を持っています。このあたりのすべてのMongoDB質問の83％は、MongoDBをリレーショナルデータベースであるかのように使用しようとし、なぜそれが機能しないのか疑問に思う人々によって尋ねられます。

于 2013-01-18T21:10:28.463 に答える