“保存SQLQueryStructure(也称作SQL注入)失败”在CWE/SANS2月16号出版的排名前25位最危险编程错误清单上位列第二。原因是：SQL注入式攻击对企业用户构成了巨大的潜在威胁。这是因为一旦SQL注入式攻击成功，就会导致黑客侵入你的网络，访问和毁坏数据并控制计算机。
SQL注入是什么？
SQL注入式攻击的原理非常简单。当一款应用软件进行用户数据输出时，就为恶意用户入侵制造了机会，从而导致输入是作为SQL序列出现而不是数据。
举例来说，想象这样一行代码：
SELECT*FROMUsersWHEREUsername=’$username’ANDPassword=’$password
设计这行代码是要显示”用户”框中用户名和密码的记录。使用网络界面的话，在提示输入用户名和密码的时候，恶意用户可能会键入：
1′or’1′=’1
1′or’1′=’1
然后产生这些的序列：
SELECT*FROMUsersWHEREUsername=’1′OR’1′=’1′ANDPassword=’1′OR’1′=’1′
这样黑客就将整个OR条件成功的注入了验证流程。更糟糕的是，条件’1′=’1′总是正确的，因此这种SQL序列通常会导致黑客规避了验证流程。
使用诸如”；”的字符会在现有序列的末尾另外产生一行序列，作为现有序列注释的一部分，黑客可能会删除整个表格或者更改包含的数据。黑客甚至能掌控基础的操作系统环境，从而控制整个计算机，将计算机沦为供其驱使的肉鸡来攻击网络中的其他计算机。概括来说SLQ注入式攻击的结果包括：机密数据泄露，数据完整性的损失，数据丢失，危及整个网络。
如何防御SQL注入式攻击？
最重要的措施就是数据清理和验证。数据清理通常会涉及任何通过某项功能运行的提交数据(比如MySQL的mysql_real_escape_string()功能)来保证任何存在风险的字符(比如”‘”)不会传递到数据的SQL序列。
验证有略微的不同。数据验证是要确保提交的数据以希望的格式出现。在最基本的层面上，这包括确保电子邮件地址包含”@”标识，提交的数据长度不能超出规定的最大长度。验证经常会以两种形式出现：通过风险黑名单或多余的字符和通过在指定情况下才能使用的字符的白名单，这更多会涉及编程人员的工作。虽然验证通常是在用户方面发生的行为，但黑客可能会修改或绕过验证，因此对服务器上的数据加以验证也很重要。
但是数据清理和验证还远远不够。以下是帮助用户阻止或缓解SQL注入式攻击的十种方法：
1.不要相信任何人：假设所提交的用户数据都是存在问题的，对所有数据加以验证和清洁。
2.不要使用可能被规避的动态SQL：无论何时都尽可能采用备好的报表，参数化的查询或者存储的流程。
