A3:2017-敏感数据泄露
许多Web应用程序和API都无法正确保护敏感数据，例如：财务数据、医疗数据和PII数据。攻击者可以通过窃取或修改未加密的数据来实施信用卡诈骗、身份盗窃或其他犯罪行为。未加密的敏感数据容易受到破坏，因此，我们需要对敏感数据加密，这些数据包括：传输过程中的数据、存储的数据以及浏览器的交互数据。
应用程序脆弱吗?
首先你需要确认的是哪些数据是敏感数据（包含：传输过程中的数据、存储数据）而需要被加密。例如：密码、信用卡卡号、医疗记录、个人信息应该被加密，特别是隐私法律或条例中规定需要加密的数据，如：欧盟《通用数据保护条例》（GDPR）、 属于“金融数据保护条例”的《支付卡行业数据安全标准》（PIC DSS）。对于这些数据，要确定：
• 在数据传输过程中是否使用明文传输？这和传输协议相关，如：HTTP、SMTP和FTP。外部网络流量非常危险。验证所有的内部通信，如：负载平衡器、Web服务器或后端系统之间的通信。
• 当数据被长期存储时，无论存储在哪里，它们是否都被加密，包含备份数据？
• 无论默认条件还是源代码中，是否还在使用任何旧的或脆弱的加密算法？
• 是否使用默认加密密钥，生成或重复使用脆弱的加密密钥，或者缺少恰当的密钥管理或密钥回转？
• 是否强制加密敏感数据，例如：用户代理（如：浏览器）指令和传输协议是否被加密？
• 用户代理（如：应用程序、邮件客户端）是否未验证服务器端证书的有效性？
如何防止?
对一些需要加密的敏感数据，应该起码做到以下几点：
• 对系统处理、存储或传输的数据分类，并根据分类进行访问控制。
• 熟悉与敏感数据保护相关的法律和条例，并根据每项法规要求保护敏感数据。
• 对于没必要存放的、重要的敏感数据，应当尽快清除，或者通过PCI DSS标记或拦截。未存储的数据不能被窃取。
• 确保存储的所有敏感数据被加密。
• 确保使用了最新的、强大的标准算法或密码、参数、协议和密匙，并且密钥管理到位。
• 确保传输过程中的数据被加密，如：使用TLS。确保数据加密被强制执行，如：使用HTTP严格安全传输协议（HSTS ）。
• 禁止缓存对包含敏感数据的响应。
• 确保使用密码专用算法存储密码，如：Argon2 、 scrypt 、bcrypt 或者PBKDF2 。将工作因素（延迟因素）设置在可接受范围。
• 单独验证每个安全配置项的有效性
攻击案例场景
场景#1：一个应用程序使用自动化的数据加密系统加密信用卡信息，并存储在数据库中。但是，当数据被检索时被自动解密，这就使得SQL注入漏洞能够以明文形式获得所有信用卡卡号。
场景#2：一个网站上对所有网页没有使用或强制使用TLS，或者使用弱加密。攻击者通过监测网络流量（如：不安全的无线网络），将网络连接从HTTPS降级到HTTP，就可以截取请求并窃取用户会话cookie。 之后，攻击者可以复制用户cookie并成功劫持经过认证的用户会话、访问或修改用户个人信息。除此之外，攻击者还可以更改所有传输过程中的数据，例如：转款的接接收者。
场景#3：密码数据库使用未加盐的哈希算法或弱哈希算法去存储每个人的密码。一个文件上传漏洞使黑客能够获取密码文件。所有这些未加盐哈希的密码通过彩虹表暴力破解方式破解。 由简单或快速散列函数生成加盐的哈希，也可以通过GPU破解。
相关技能掌握
web敏感信息泄漏：
信息泄漏是指在正常情况下不能被普通用户访问的敏感信息没有被应用程序所保护，能够直接访问。就web来说这种类型的问题往往会带来巨大的危害，攻击者不仅可以轻松收集用户手机号，姓名等隐私信息，更可以借此攻入企业后台甚至是getshell。通过该实验了解常见的web敏感信息泄漏漏洞原理，掌握常见的web信息泄漏漏洞的利用和漏洞防护。
http://www.hetianlab.com/expc.do?ec=ECID25ad-863a-454c-87b6-e2b09b1f764f
A4:2017-XML外部实体（XXE）
许多较早的或配置错误的XML处理器评估了XML文件中的外部实体引用。攻击者可以利用外部实体窃取使用URI文件处理器的内部文件和共享文件、监听内部扫描端口、执行远程代码和实施拒绝服务攻击。
应用程序脆弱吗?
应用程序和特别是基于XML的Web服务或向下集成，可能在以下
方面容易受到攻击：
• 您的应用程序直接接受XML文件或者接受XML文件上传，特别是来自不受信任源的文件，或者将不受信任的数据插入XML文件，并提交给XML处理器解析。
• 在应用程序或基于Web服务的SOAP中，所有XML处理器都启用了文档类型定义（DTDs）。因为禁用DTD进程的确切机制因处理器而不同。
• 如果为了实现安全性或单点登录（SSO），您的应用程序使用SAML进行身份认证。而SAML使用XML进行身份确认，那么您的应用程序就容易受到XXE攻击。
• 如果您的应用程序使用第1.2版之前的SOAP，并将XML实体传递到SOAP框架，那么它可能受到XXE攻击。
• 存在XXE缺陷的应用程序更容易受到拒绝服务攻击，包括：Billion Laughs 攻击。
如何防止?
开发人员培训是识别和减少XXE缺陷的关键，此外，防止XXE 缺陷还需要：
• 尽可能使用简单的数据格式（如：JSON），避免对敏感数据进行序列化。
• 及时修复或更新应用程序或底层操作系统使用的所有XML处理器和库。同时，通过依赖项检测，将SOAP更新到1.2版本或更高版本。
•在应用程序的所有XML解析器中禁用XML外部实体和DTD进程。
• 在服务器端实施积极的（“白名单”）输入验证、过滤和清理，以防止在XML文档、标题或节点中出现恶意数据。
• 验证XML或XSL文件上传功能是否使用XSD验证或其他类似验证方法来验证上传的XML文件。
• 尽管在许多集成环境中，手动代码审查是大型、复杂应用程序的最佳选择，但是SAST 工具可以检测源代码中的XXE漏洞。如果无法实现这些控制，请考虑使用虚拟修复程序、API安全网关或Web应用程序防火墙（ WAF ）来检测、监控和防止XXE攻击
攻击案例场景
大量XXE缺陷已经被发现并被公开，这些缺陷包括嵌入式设备的XXE缺陷。 XXE缺陷存在于许多意想不到的地方，这些地方包括深嵌套的依赖项。最简单的方法是上传可被接受的恶意XML文件：
场景#1：攻击者尝试从服务端提取数据：
]>
场景#2：攻击者通过将上面的实体行更改为以下内容来探测服务
器的专用网络：
]>
场景#3：攻击者通过恶意文件执行拒绝服务攻击：
]>
相关技能掌握
XXE漏洞分析与实践
实验了解XXE漏洞的基础知识及演示实践。
http://www.hetianlab.com/expc.do?ec=ECIDcb00-c025-4fea-a3f4-93057c24bf78
A5:2017-失效的访问控制
未对通过身份验证的用户实施恰当的访问控制。攻击者可以利用这些缺陷访问未经授权的功能或数据，例如：访问其他用户的帐户、查看敏感文件、修改其他用户的数据、更改访问权限等。
应用程序脆弱吗？
访问控制强制实施策略，使用户无法在其预期的权限之外执行行为。失败的访问控制通常导致未经授权的信息泄露、修改或销毁所有数据、或在用户权限之外执行业务功能。常见的访问控制脆弱点包括：
• 通过修改URL、内部应用程序状态或 HTML 页面绕过访问控制检查，或简单地使用自定义的 API 攻击工具。
• 允许将主键更改为其他用户的记录，例如查看或编辑他人的帐户。
• 特权提升。在不登录的情况下假扮用户，或以用户身份登录时充当管理员。
• 元数据操作，如重放或篡改JWT 访问控制令牌，或作以提升权限的cookie 或隐藏字段。
•CORS配置错误允许未授权的API访问。
• 以未通过身份验证的用户身份强制浏览的通过身份验证时才能看到的页面、或作为标准用户访问具有相关权限的页面、或API没有对POST、PUT和DELETE强制执行访问控制。
如何防止？
访问控制只有在受信服务器端代码或没有服务器的API中有效，这样这样攻击者才无法修改访问控制检查或元数据。
• 除公有资源外，默认情况下拒绝访问。
• 使用一次性的访问控制机制，并在整个应用程序中不断重用它们，包括最小化CORS使用。
• 建立访问控制模型以强制执行所有权记录，而不是接受用户创建、读取、更新或删除的任何记录。
• 域访问控制对每个应用程序都是唯一的，但业务限制要求应由域模型强制执行。
• 禁用Web服务器目录列表，并确保文件元数据（如：git）不存在于 Web的根目录中。
• 记录失败的访问控制，并在适当时向管理员告警（如：重复故障）。
• 对API和控制器的访问进行速率限制，以最大限度地降低自动化攻击工具的危害。
• 当用户注销后，服务器上的JWT令牌应失效。
开发人员和QA人员应包括功能访问控制单元和集成测试人员。
攻击案例场景
场景#1：应用程序在访问帐户信息的 SQL调用中使用了未经验证的数据：
pstmt.setString(1，request.getParameter("acct"));
ResultSet results = pstmt.executeQuery( );
攻击者只需修改浏览器中的“acct”参数即可发送他们想要的任何帐号信息。如果没有正确验证，攻击者可以访问任何用户的帐户。
http://example.com/app/accountInfo?acct=notmyacct
场景#2：攻击者仅强制浏览目标URL。管理员权限是访问管理页面所必需的。
http://example.com/app/getappInfo
http://example.com/app/admin_getappInfo
如果一个未经身份验证的用户可以访问任何页面，那么这是一个缺陷。如果一个非管理员权限的用户可以访问管理页面，那么这同样也是一个缺陷
相关技能掌握
实验:权限绕过漏洞
越权漏洞的成因主要是因为开发人员在对数据进行增、删、改、查询时对客户端请求的数据过分相信而遗漏了权限的判定。通过该实验了解权限绕过漏洞，掌握常见的权限绕过漏洞原理以及漏洞检测利用和漏洞防护。
http://www.hetianlab.com/expc.do?ec=ECIDee9320adea6e062018031511354800001
A6:2017-安全配置错误
安全配置错误是最常见的安全问题，这通常是由于不安全的默认配置、不完整的临时配置、开源云存储、错误的HTTP标头配置以及包含敏感信息的详细错误信息所造成的。因此，我们不仅需要对所有的操作系统、框架、库和应用程序进行安全配置，而且必须及时修补和升级它们。
应用程序脆弱吗？
您的应用程序可能受到攻击，如果应用程序是：
• 应用程序栈堆的任何部分都缺少适当的安全加固，或者云服务的权限配置错误。
• 应用程序启用或安装了不必要的功能（例如：不必要的端口、服务、网页、帐户或权限）。
• 默认帐户的密码仍然可用且没有更改。
• 错误处理机制向用户披露堆栈跟踪或其他大量错误信息。
• 对于更新的系统，禁用或不安全地配置最新的安全功能。
• 应用程序服务器、应用程序框架（如：Struts、Spring、ASP.NET）、库文件、数据库等没有进行安全配置。
• 服务器不发送安全标头或指令，或者未对服务器进行安全配置。
• 您的应用软件已过期或易受攻击（参见A9：2017-使用含有已知漏洞的组件）。
缺少一个体系的、可重复的应用程序安全配置过程，系统将处于高风险中。
如何防止?
应实施安全的安装过程，包括：
• 一个可以快速且易于部署在另一个锁定环境的可重复的加固过程。开发、质量保证和生产环境都应该进行相同配置，并且，在每个环境中使用不同的密码。这个过程应该是自动化的，以尽量减少安装一个新安全环境的耗费。
• 搭建最小化平台，该平台不包含任何不必要的功能、组件、文档和示例。移除或不安装不适用的功能和框架。
• 检查和修复安全配置项来适应最新的安全说明、更新和补丁，并将其作为更新管理过程的一部分，（参见A9：2017-使用含有已知漏洞的组件）。在检查过程中，应特别注意云存储权限（如：S3桶权限）。
• 一个能在组件和用户间提供有效的分离和安全性的分段应用程序架构，包括：分段、容器化和云安全组。
• 向客户端发送安全指令，如：安全标头。
• 在所有环境中能够进行正确安全配置和设置的自动化过程。
攻击案例场景
场景#1：应用程序服务器附带了未从产品服务器中删除的应用程序样例。这些样例应用程序具有已知的安全漏洞，攻击者利用这些漏洞来攻击服务器。如果其中一个应用程序是管理员控制台，并且没有更改默认账户，攻击者就可以通过默认密码登录，从而接管服务器。
场景#2：目录列表在服务器端未被禁用。攻击者发现他们很容易就能列出目录列表。攻击者找到并下载所有已编译的Java类，他们通过反编译来查看代码。然后，攻击者在应用程序中找到一个严重的访问控制漏洞。
场景#3：应用服务器配置允许将详细的错误信（如：堆栈跟踪信息）返回给用户，这可能会暴露敏感信息或潜在的漏洞，如：已知含有漏洞的组件的版本信息。
场景#4：云服务向其他CSP用户提供默认的网络共享权限。这允
许攻击者访问存储在云端的敏感数据。
相关技能掌握
Redis_Crackit入侵事件场景模拟
实验还原Redis Crackit入侵事件的真实场景，了解该事件原理，了解Redis的安全特性以及加固方案。
http://www.hetianlab.com/expc.do?ec=ECID172.19.104.182015111310254200001
获取更多精彩内容可扫码关注我们的微信公众号哦~❤
