注入攻击（一）

应用在何时容易受到攻击：

1，用户支持的数据没有经过应用程序的验证，过滤或净化；

2，恶意数据直接被解释器用于动态的查询或非参数化的调用，而无需上下文感知的转义；

3，在ORM搜索参数中使用了恶意数据，这样搜索就会预估出包含敏感或所有记录的数据；

一些常见的注入包括SQL、OS命令、ORM、LDAP和表达式语言（EL）或OGEL注入。所有解释器的概念是相同的，组织可以将SAST和DAST工具添加CI/CD过程中，以便于在生产部署之前对现有或新检查的怠慢进行注入问题的预警，手动和自动源代码检查是、检测您是否容易受到注入攻击的最好方法，紧随其后的是对所有参数、字段、头、cookie、JSON和XML数据输入的彻底的DAST扫描。

如何预防

防止注入漏洞需要将数据与命令语句、查询语句分隔开。
1，最佳选择是使用安全的API，安全避免使用解释器，或提供参数化界面的接口，或迁移到ORM或实体框架；

2，注意：当参数化时，存储过程仍然可以引入SQL注入，如果PL/SQL或T-SQL将查询和数据连接在一起，或者执行带有立即执行或exec（）的恶意数据；

3，使用正面的或“白名单“的具有恰当的规范化的输入验证方法同样会有助于防止注入攻击，但这不是一个完整的防御，yin w诶许多应用程序在输入中需要特殊字符，例如文本区域或移动应用程序的API；

4，对于任何剩余的动态查询，可以使用该解释器的特定转义语法转义特殊字符，OWASP的Java Encode和类似的库提供了这样的转义例程。注意：SQL结构，比如表名、列名等无法转义，因此用户提供的结构名是非常危险的，这是编写软件中的一个常见问题；

5，在查询中是使用LIMIT和其他SQL控件，以防止在sql注入时大量地公开记录。

攻击例子：

脆弱性的sql语句：

String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") +"'“;

框架应用的盲目信任
例如:Hibernate查询语言(HQL)：

Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") +"'");

在这两个案例中，攻击者在浏览器中将“id”参数的值修改 成’ or’1’=’1。例如:
http://example.com/app/accountView?id=’ or ‘1’=’1 这样查询语句的意义就变成了从accounts表中返回所有的记录。更危险的攻击可能导致数据被篡改甚至是存储过程被 调用。