IT行业的安全就像锁住你的房子或汽车一样，它不能阻止坏人，但如果它足够好，他们可能会转移到更容易的目标。- Paul Herbka
我们完全同意。确保你的网络应用程序的安全是至关重要的。因此，我们在这里为您提供最新的OWASP十大安全威胁，请您留意。
OWASP代表开放网络应用安全项目--一个开放的社区，致力于使组织能够开发、购买和维护可以信任的应用程序和API。
我们赞同OWASP的思想，鼓励企业摆脱渗透和打补丁的心态，并支持Contrast Securities的Jeff Williams在2009年OWASP AppSec DC主题演讲中所说的："我们永远不会以黑客的方式获得安全--这需要企业文化的改变"，以正确解决应用安全问题。因此，这篇文章不仅是针对应用安全社区的，而且也是为了向开发者伸出援手。
OWASP Top 10 - 2017提到了以下安全威胁：
- 注入
- 破解认证
- 敏感数据暴露
- XML外部实体(XEE)
- 破损的访问控制
- 安全配置错误
- 跨站脚本(XSS)
- 不安全的反序列化
- 使用已知有漏洞的组件
- 记录和监控不足
这是即将发表的许多文章中的一篇，旨在详细介绍这些威胁。今天我们先来看看代码注入。
注入是对任何Web应用程序最古老和最危险的攻击之一。在这种攻击中，攻击者只是发送恶意数据，以使应用程序处理它并做一些它不应该做的事情。注入缺陷是非常普遍的，特别是在传统的代码中。其核心原因是。用户提供的数据没有经过应用程序的验证、过滤或净化。
其他一些潜在的原因包括：
-
在解释器中直接使用动态查询。
-
直接在解释器中使用非参数化的调用，而没有实现上下文感知的转义（简称自动转义）。在这里阅读更多关于转义所有用户提供的输入的信息。
-
在对象关系映射（ORM）搜索参数中使用敌意数据以提取额外的敏感记录。
-
敌意数据被直接使用或串联，这样的SQL或命令在动态查询、命令或存储过程中同时包含结构和敌意数据。
下面是OWASP的例子，一个SQL查询消耗了不信任的数据：
String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";
当攻击者在他们的浏览器中修改'id'参数值来发送：' or '1'='1 ，这个查询就会被利用。比如说。 http://example.com/app/accountView?id=' or '1'='1 这可以导致数据库表返回所有的行。
为了保证你的应用程序免受注入攻击，这里有一些OWASP的技术建议需要注意：
防止注入需要将数据与命令和查询分开。
-
首选是使用安全的API，完全避免使用解释器或提供一个参数化的接口，或迁移到使用对象关系映射工具（ORMs）。***注意：*即使在参数化的情况下，如果PL/SQL或T-SQL将查询和数据连接起来，或用EXECUTE IMMEDIATE或
exec()执行敌对数据，存储过程仍然可以引入SQL注入。 -
使用积极的或 "白名单 "的服务器端输入验证。这不是一个完整的防御措施，因为许多应用程序需要特殊字符，如文本区域或移动应用程序的API。
-
对于任何残留的动态查询，使用该解释器的特定转义语法转义特殊字符。***注意：*SQL结构，如表名、列名等不能被转义，因此用户提供的结构名是危险的。这是报告编写软件中的一个常见问题。
-
在查询中使用
LIMIT和其他SQL控制，以防止在SQL注入的情况下大量泄露记录。
代码注入可能是非常致命的，因为它可能导致数据丢失或损坏、缺乏责任感、拒绝访问或有时可能导致主机完全被接管。
