问题描述
将全文索引的使用公开给内部用户和可能的公共用户是否有任何已知的危险？
假设查询参数化正确，用户是否可以滥用输入来触发 sql 注入或拒绝服务攻击？
{{1}}
这个问题的触发因素是用户可以指定的输入种类繁多，而且不同的 sql 服务器具有不同的查询语法，如果指定的查询无效，至少有一些 (MysqL) 会返回语法错误。
- 'FORMSOF(INFLECTIONAL，模型 NEAR 飞机)'
- 'NEAR((term1,term2),5) AND term3'
- 'NEAR((term1,5) OR NEAR((term3,term4),2,TRUE)'
- '+join +(>left
- '电动 INPATH (/purchaSEOrder/items/item/comment)'
解决方法
在谈论 SQL 注入时，风险在于有人可以通过将 SQL 添加到数据参数来将 SQL 关键字引入查询本身。
这就是为什么分离数据和查询是绝对关键的。这通常通过使用占位符值来实现，如：
SELECT * FROM content_table WHERE MATCH(Title,Subtitle,Body) AGAINST (?);
就搜索而言，您通常需要注意两个层面：
- 使用原始 SQL 关键字来表达查询条件的 SQL 层，例如
WHERE x=? AND y=? - 您在字符串中表达条件的搜索层，例如
WHERE CONTAINS(?)具有绑定数据参数'"computer software" NEAR hardware)'
请注意，第二种形式的语法包含在字符串中，因此如果您表明自己没有 SQL 注入的风险，但最终可能会收到很多由不良用户引起的语法错误您需要处理的输入。
在第一种情况下，如果您需要编写查询条件，则需要遵循通常的规则：
- 不允许：
- 在查询中包含未知字段。
- 在查询中包含未知运算符。
- 尽可能严格地将查询和数据分开。
您可能需要将请求的数据解析为可以重组为 SQL 查询的组件。这可能会变得很混乱，尤其是当您在搜索内容方面有很大的自由度时，因此请尝试使其尽可能简单和可测试。
如果您有单元测试，请包含一个故意敌对并试图将无效或注入类型数据引入查询的测试。确保正确包含数据。
注意：如果您使用占位符值调用存储过程，但该存储过程使用串联组合 SQL 语句，您仍然处于危险之中，因此您需要绝对确定您将数据与查询分开.如果您的查询中引入了零 个用户数据，则不存在 SQL 注入的风险。