保护自己免受nodejs中的sql注入的最好方法
这是设置。
我使用ajax发送一个POST，在这里我将过程的参数发送到nodejs服务器。 在这个特定的情况下，用户名和代码。
此POST将request.get调用到执行使用这两个参数的过程的Web服务。
例如
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(){}); }); 前端用户无法看到我的web服务url，我的request.get url或我的过程名称，但他仍然可以看到正在发送的参数（用户名，代码），他可以更改这些参数，使他执行一个他不应该执行的过程。
他也可以多次调用一个POST请求，如果是一个插入过程，用一堆垃圾填充数据库。
保护自己免受这些攻击的最好办法是什么？
这里有几点build议：
不要在这个程度上进行元编程。 为每个程序在你的申请单独路线，然后自己注入这些“代码”。 这将允许你做一些事情，比如validation用户input以确保它不是垃圾数据被传入，以及限制特定的路由以确保数据库没有被垃圾填满。
您也可以创build一个允许的“代码”的白名单数组，并确保whitelist.instanceOf(procedure) != -1但这不会让你做每个路由inputvalidation。
即使您手动包含该程序，仍然存在问题。 在您现有的代码中，调用外部服务时会在“procedureName”之前放置“req.params.username”参数。 对于大多数HTTPparsing框架来说，参数是先到先得的。 在看到这个代码之后，我会尝试的第一个攻击之一就是将'&procedureName=something_i_shouldnt_be_able_to_call'注入到我的用户名中。 这会导致你包含的procedureName属性被忽略，而我提交的那个将被用来代替。 您可以通过在string插值之前放置基于用户input的参数和URI编码用户input，或者将查询string作为名为“qs”的对象传递给请求的options参数来防止这种情况。
这是否会造成SQL注入漏洞完全取决于Web服务如何parsing参数并执行过程。 最佳情况是服务URI解码每个参数，然后将这些参数作为parameter passing给PDO或准备好的语句。 我的猜测是，它正在使用PDO，给定了被调用的方式。
所以我在这里最后会build议的是对每个用户input提供的参数进行URI编码，并使用上面提到的传递给请求选项的qs对象，而不仅仅是插入string。 完成之后，您可以采取以下任何或所有步骤来帮助validation：
- 尝试执行诸如手动向用户input中注入单引号的操作。
- 在特定的路由上运行像sqlmap这样的工具来testingSQL注入。 这将给你一个相当强大的testing，而不需要深入的SQL注入技术的知识。
- 与经验丰富的node.js安全专业人员安排应用程序安全评估。 （我可以在liftsecurity.io上find ）
重申 – 不要相信用户给你的程序代码 – 分别制作路由并自己插入这些数据，在进一步处理之前对所有的用户input进行URI编码，并使用请求选项对象： {qs:{name:value}}而不是string插值。
有了这些保护，你可能会很好，因为它似乎在这里使用存储过程。 除非您可以在Web服务的文档中find对此的确认，否则唯一可以确定的方法是通过我上面build议的方法之一。
希望这可以帮助！
为了防止sql注入，你可以逃避web服务上的input数据。 并为了避免在数据库中的多个虚假条目，您可以添加一个唯一的标记与每个发布请求，并validation您的web服务上的标记，如果标记是合法的，则允许插入，如果不是，则避免插入。 您正在使用Web服务，因为我认为您必须将这些令牌保留在数据库中进行validation。