nodejsのSQLインジェクションから身を守る最善の方法

Question

これはセットアップです。

nodejsサーバーにプロシージャのパラメータを送信するajaxを使用してPOSTを送信しています。この特定のケースでは、ユーザー名とコード。

このPOSTは、これら2つのパラメータを使用するプロシージャを実行するWebサービスにrequest.getを呼び出します。

フロントエンドユーザーが自分のWebサービスのURL、私のrequest.get URLまたは私のプロシージャ名を見ることができないが、彼はまだパラメータは（ユーザー名、コード）送信されて見ることができます

app.post('url/:username/:code', function(req,res,next){ 

var procedure = 'EXECUTE procedureName'+req.params.code; 

    request.get('myWslink/myService.asmx/service? 
    callback=&userName='+req.params.username+'&procedureName='+procedure, function(){}); 
}); 

例えば

と彼がすることができますこれらのパラメータを変更して、彼が実行するはずのプロシージャを実行できるようにします。

また、POSTリクエストを複数回呼び出すこともできます。挿入プロシージャの場合は、複数の迷惑メールをデータベースに埋め込むこともできます。

これらの悪用から身を守るにはどうすればよいでしょうか？

Answer 1

ここにいくつかの提案があります：

この程度のメタプログラミングはしないでください。各手順のためにあなたのアプリケーションに別々のルートを作って、それらのコードをあなた自身で注入してください。これにより、ユーザーの入力を検証して、渡されるガーベジ・データではないことを確認するだけでなく、DBがガーベッジで満たされていないことを確実にするための特定のルートのレート制限も行うことができます。

許可された「コード」のホワイトリストアレイを作成し、whitelist.instanceOf(procedure) != -1がこれを確認して、ルート単位の入力検証を行わないようにすることもできます。

手順を手動で組み込んでも問題はあります。既存のコードでは、外部サービスへの呼び出しによって、procedureNameの前に 'req.params.username'パラメータが配置されます。ほとんどのHTTP解析フレームワークでは、まずパラメータが最初に提供されます。このコードを見て、最初に試した攻撃の1つは、ユーザ名に '&procedureName=something_i_shouldnt_be_able_to_call' を注入することです。これは、私が提出したものが代わりに使用される間、あなたが含むプロシージャ名属性が無視される原因になります。文字列の補間の前にユーザー入力ベースのparamsを最後に置き、文字列補間の前にユーザー入力をURIエンコーディングするか、または "qs"という名前のオブジェクトとしてクエリー文字列を含めることでこれを防ぐことができます

これはSQLを作成するかどうかインジェクションの脆弱性は、Webサービスが引数を解析してプロシージャを実行する方法に完全に依存します。最適なケースは、サービスURIが各パラメータをデコードし、それらを引数としてPDOまたはプリペアドステートメントのいずれかに渡すことです。私の推測では、それが呼び出されている方法を考えると、PDOを使用しているということです。

私がここで示唆しているのは、ユーザ入力の各パラメータをURIエンコードし、単に文字列を補間するのではなく、上記のようにリクエストオプションに渡されるqsオブジェクトを使用することです。これを済ませたら、以下の手順のいずれかまたはすべてを実行して、検証に役立てることができます。

1. ユーザ入力に一重引用符を手動で入力するようにしてください。
2. SQLインジェクションをテストする特定のルートでsqlmapのようなツールを実行します。これは、SQLインジェクション技術の深い知識を必要とせずに、かなり堅牢なテストを提供します。
3. 経験豊富なnode.jsセキュリティ専門家によるアプリケーションセキュリティ評価をスケジュールします。繰り返しに

（私はliftsecurity.ioで利用可能です） - 別々のルートを作成し、そのデータを自分で挿入し、URIはさらに処理する前に、すべてのユーザー入力を符号化し、そして使用 - あなたのプロシージャのコードを与えるために、ユーザーを信用してはいけません文字列補間の代わりに{qs:{name:value}}のような要求オプションオブジェクト。

これらの保護機能を使用すると、ここではストアドプロシージャを使用しているように見えるかもしれません。ただし、Webサービスのドキュメントでその確認を確認できない限り、そのことを確認する唯一の方法は、私が上で提案した方法の1つです。

希望すると便利です。

Answer 2

SQLインジェクションを防止するために、Webサービス上の入力データをエスケープすることができます。 データベース内の複数の偽のエントリを避けるために、各投稿リクエストに一意のトークンを追加して、Webサービス上のトークンを確認することができます。トークンが正当なものである場合は挿入を許可し、挿入しない場合は許可します。 あなたはウェブサービスを使用していますので、確認のためにこれらのトークンをデータベースに保管しなければならないと思います。