安全漏洞大揭秘：手把手教你轻松防止SQL注入( 二 ) 安全漏洞大揭秘：手把手教你轻松防止SQ

Select message from user where email = ‘Smith1234@mail.com’ or ‘1’=’1’;添加看似无害的内容（例如“or 1=1”）会更改查询的逻辑，并可能通过返回表中称为“用户”的所有行来泄漏数据。在这种情况下，向您显示表中每个用户的消息。严重的隐私问题，在某些司法管辖区或环境中也可能存在法律问题，例如GDPR ， HIPAA或CCPA 。
上面的查询以以下意外输出结束：
HelloPassword 1234How are youDon’t tell anyoneWassupSQL注入的工作方式SQL注入（和其他类型的注入漏洞）的基本要点是在SQL查询字符串中使用来自应用程序外部的未经检查的数据，例如用户输入文本。 CWE 89的描述：“SQL命令中使用的特殊元素的不适当中和（SQL注入）”更精确地定义了以下内容：
“在用户可控制的输入中没有充分删除或引用SQL语法的情况下，生成的SQL查询可能导致这些输入被解释为SQL而不是普通用户数据。这可用于更改查询逻辑以绕过安全性检查，或用于插入修改后端数据库的其他语句，可能包括执行系统命令。 ”
CWE数据库中的相同条目（CWE 89）提供了此攻击的另一个简单示例。假设应用程序代表用户“wiley”进行查询，并且用户以包含SQL指令的方式构造输入，例如：
name'; DELETE FROM items; --如果此应用程序不对此输入进行任何有效性检查，则会构造如下查询：
SELECT * FROM items WHERE owner = 'wiley' AND itemname = 'name';DELETE FROM items;--'如果此攻击成功，它将删除表项中的所有数据，从而对数据库造成破坏。任何有效的SQL命令都可能以这种方式执行。这是写/修改攻击的示例，其目的是破坏数据库或插入不需要的信息。前面的示例（“or 1=1”）是读取攻击，其目的是数据泄漏。
数据库服务器的许多实现都接受分号作为命令分隔符，这使得这种SQL注入非常危险。尾部的“–”表示文本的其余部分为注释，从而迫使SQL解释器忽略尾部的引号，否则将导致语法错误。欺骗组合查询字符串的方法有多种。有时以开发人员无法想象的方式。
防止SQL注入的缓解措施开发人员应实施几种缓解措施。首先，安全立场应考虑所有来自不受信任的应用程序外部的数据。以下是典型的缓解策略：

将准备好的语句与参数化查询一起使用。
使用存储过程。
白名单输入验证。
转义所有提供的输入。

这些在OWASP速查表的SQL注入中有更详细的描述。
测试SQL注入
一种典型的安全性方法是，在集成软件运行时，作为常规质量检查操作的一部分，执行各种类型的安全性测试。不幸的是，功能测试不会尝试将漏洞利用插入用户输入字段中，因为大多数测试人员并不认为自己是坏演员。
除了传统上他们没有时间或方向的事实之外。手动测试注入类型漏洞也很困难，因为它需要尝试许多不同的输入组合。这是开始进行模糊测试或模糊测试的地方。它会创建随机，意外和无效的数据作为被测应用程序的输入。模糊测试是渗透测试的一部分，因为目标是通过公开的界面公开安全漏洞。
渗透测试
渗透性测试（以及扩展性的模糊测试）是有益的，因为它可以发现贯穿整个过程的安全性问题并揭示重要的安全性问题。但是，像所有动态测试一样，它完全取决于测试，代码和API覆盖的数量，以完全测试所有可能的排列和组合。渗透测试取决于功能测试的完整性，通常在用户界面级别进行。因此，请务必通过API测试和SAST支持渗透测试，以确保您的工作透彻。
API测试
API测试通过消除对脆弱且耗时的UI测试的依赖，有助于向左移动功能和安全性测试。 API层是许多应用程序功能所驻留的地方，并且测试在此级别进行更改时更具弹性，并且更易于自动化和维护。