OWASPTOP10漏洞详解以及防护⽅案
OWASP TOP 10 漏洞详解以及防护⽅案
OWASP介绍
官⽹：
OWASP TOP10 指出了 WEB 应⽤⾯临最⼤风险的 10 类问题，是⽬前 WEB 应⽤安全⽅⾯最权威的项⽬。
OWASP 是⼀个开源的、⾮盈利全球性安全组织，致⼒于应⽤软件的安全研究。OWASP 的使命是应⽤软件更加安全，使企业和组织能够对应⽤安全风险作出更清晰的决策。⽬前OWASP 全球拥有 140 个分会近四万名员，共同推动了安全标准、安全测试⼯具、安全指导⼿册等应⽤安全技术的发展。
OWASP TOP 10
A1：2017 注⼊
A2：2017 失效的⾝份认证
A3：2017 敏感数据泄露
A4：2017 XML外部实体
A5：2017 失效的访问控制
A6：2017 安全配置错误
A7：2017 跨站请求脚本（XSS）
A8：2013 跨站请求伪造（CSRF）
A8：2017 不安全的反序列化
A9：2017 使⽤含有已知漏洞的组件
A10：2017 不⾜的⽇志记录和监控
A1 2017注⼊injection
注⼊：⽤户的输⼊被当成命令/代码执⾏或者解析了
将不受信⽤的数据作为命令或查询的⼀部分发送到解析器时，会产⽣诸如SQL注⼊、NoSQL注⼊、OS注⼊（操作系统命令）和LDAP（）注⼊的注⼊缺陷。攻击者的恶意数据可以诱使解析器在没有适当授权的情况下执⾏⾮预期命令或访问数据。
⽤户的输⼊并⾮固定位置，可能存在于：
输⼊框
搜索栏
提交表单
URL链接
所有的GET/POST请求的请求头和请求包头
留⾔
评论
⼏乎任何数据源都有可能成为注⼊载体，只要是能被发出的数据位置
可被执⾏的代码：
SQL
LDAP
Xpath or NoSQL
系统命令
XML语⾔
SMTP包头
表达式语句
ORM查询语句
危害：该代码能做什么即是危害
注⼊的分类
通常的注⼊有sql注⼊和命令注⼊
SQL注⼊攻击
动态页⾯有时会通过脚本引擎将⽤户输⼊的参数按照预先设定的规则构造成SQL语句来进⾏数据库操作。SQL注⼊攻击指的是通过构造特殊的输⼊作为参数传⼊Web应⽤程序，改变原有的SQL语句的语义来执⾏攻击者所要的操作，其主要原因是程序没有采取必要的措施避免⽤户输⼊内容改变原有SQL 语句的语义。
SQL注⼊的危害：
绕过登陆验证：使⽤万能密码登陆⽹站后台等
获取敏感数据：获取⽹站管理员账号、密码等
⽂件系统操作：列⽬录、读取或写⼊⽂件等
注册表操作：读取、写⼊、删除注册表等
执⾏系统命令：远程执⾏命令
参考链接：
防护⽅案
1、关闭 SQL 错误回显
2、前端输⼊字符⽩名单验证（长度、类型等）
3、对输⼊的特殊字符使⽤转义处理
4、SQL 操作使⽤ PreParedStatement
5、SQL 服务运⾏于专门的账号，并且使⽤最⼩权限
6、限制 SQL 服务的远程访问，只开放给特定开发⼈员
7、代码审计，最有效的检测应⽤程序的注⼊风险的⽅法之⼀
8、使⽤成熟的 waf
命令注⼊攻击
WEB应⽤代码中，有时会允许接收⽤户输⼊⼀段代码，之后在web应⽤服务器上执⾏这段代码并将结果返回给⽤户，如果这段代码没有进⾏限制，⽤户就可能执⾏恶意代码。
防护⽅案
1、⽩名单效验命令参数
2、单引号禁⽌命令解析功能
A2 2017 失效的⾝份认证
通过错误使⽤应⽤程序的⾝份认证和会话管理功能，攻击者能够破译密码、密钥或会话令牌，或者暂时或永久的冒充其他⽤户的⾝份。
危害：
这些漏洞可能导致部分甚⾄全部账户遭受攻击，⼀旦攻击成功，攻击者就能执⾏合法的任何操作
防护⽅案
1、使⽤内置的会话管理功能
2、通过认证的问候
3、使⽤单⼀的⼊⼝点
4、确保在⼀开始登录SSL保护的⽹页
A3 2017 敏感数据泄露
⼀般我们的敏感信息包括密码、财务数据、医疗数据等，由于web应⽤或者API未加密或不正确的保护敏感数据，这些数据极易遭到攻击者利⽤，攻击者可能使⽤这些数据来进⾏⼀些犯罪⾏为，因此，未加密的信息极易遭到破坏和利⽤，我们应该加强对敏感数据的保护，web应⽤应该在传输过程中数据、存储的数据以及和浏览器的交互时的数据进⾏加密，保证数据安全。
实例场景
⼀个应⽤程序使⽤⾃动化的数据加密系统加密信⽤卡信息，并存储在数据库中。但是，当数据被检索时被⾃动解密，这就使得SQL注⼊漏洞能够以明⽂形式获取所有信⽤卡卡号⼀个⽹站上对所有⽹页没有使⽤或强制使⽤TLS，或者使⽤弱加密。攻击者通过检测⽹络流量（如：不安全的⽆线⽹络），将⽹络连接从HTTPS降到HTTP，就可以截取请求并窃取⽤户会话cookie。之后攻击者可以复制⽤户cookie并成功劫持经过认证的⽤户会话、访问或修改⽤户个⼈信息。除此之外，攻击者还可以更改所有传输过程中
的数据，例如：转款的接受者
密码数据库使⽤未加盐的哈希算法或弱哈希算法去存储每个⼈的密码，⼀个⽂件上传漏洞能使⿊客获取密码⽂件。所有这些未加盐的哈希密码通过彩虹表暴⼒破解⽅式破解，由简单或快速散列函数⽣成加盐的哈希也可以通过GPU破解
防护⽅案
1、对于 github 泄露，定期对仓库扫描
2、对于应⽤⽹站⽬录定期扫描
3、使⽤强壮的⽹络协议与算法
4、注重对敏感数据的保护
A4 2017 XML外部实体（XXE）
XXE 全称为XML External Entity attack 即XML(可扩展标记语⾔) 外部实体注⼊攻击，早期或配置错误的XML处理器评估了XML⽂件外部实体引⽤，攻击者可以利⽤这个漏洞窃取URI(统⼀资源标识符)⽂件处理器的内部⽂件和共享⽂件、监听内部扫描端⼝、执⾏远程代码和实施拒绝服务攻击。
攻击⽅式
当应⽤程序解析 XML⽂件时包含了对外部实体的引⽤，攻击者传递恶意包含 XML 代码的⽂件，读取指定的服务器资源。
漏洞原因
XML 协议⽂档本⾝的设计特性，可以引⼊外部的资源；定义 XML ⽂件时使⽤的外部实体引⼊功能
漏洞影响
读取服务器敏感资料，如、/etc/password
读取应⽤程序源码
防护⽅案
1、关闭 DTD (Data Type Definition)
2、禁⽌外部实体引⼊
2.1 使⽤开发语⾔提供的禁⽤外部实体的⽅法
PHP：
libxml_disable_entity_loader(true);
其他语⾔:
3、过滤⽤户提交的XML数据
关键词
system
file://
public
expect
...
A5 2017 ⽆效的访问控制（业务逻辑漏洞）
失效的访问控制就是越权访问漏洞
未对通过⾝份验证的⽤户实施恰当的访问控制。攻击者可以利⽤这些缺陷访问未经授权的功能或数据，例如：访问其他⽤户的账户、查看敏感⽂件、修改其他⽤户数据、更改访问权限等
垂直越权：
低权限⽤户可以访问更⾼权限才能访问的页⾯
⽔平越权：
同级别权限⽤户的权限控制失效，攻击者可以从普通⽤户A的权限提升到普通⽤户B的权限访问应⽤程序
防护⽅案
1、对参数的⽩名单过滤
2、对权限的控制管理重新设计与限制
3、限制下载⽂件的类型
A6：2017 安全配置错误
安全配置错误是⽐较常见的漏洞，由于操作者的不当配置(默认配置，临时配置，开源云存储，http标头配置，以及包含敏感信息的详细错误)，导致攻击者可以利⽤这些配置获取到更⾼的权限，安全配置错误可以发⽣在各个层⾯，包含平台、web服务器、应⽤服务器、数据库、架构和代码。
如 python 开发中对于 Django 框架在⽣产环境启⽤了 Debug 模式
可能受到攻击的应⽤程序：
缺少适当的安全加固、云服务的权限配置错误
应⽤程序启⽤或安装了不必要的功能（端⼝、服务、⽹页、账户或权限等）
默认账户的密码仍然没有更改
错误处理机制向⽤户披露堆栈跟踪或其他⼤量错误信息
对于更新的系统，禁⽤或不安全地配置最新的安全功能
应⽤程序服务器、应⽤程序框架（如：Struts、Spring、ASP.NET）、库⽂件、数据库等没有进⾏安全
配置
服务器不发送安全标头或指令，或未对服务器进⾏安全配置
应⽤软件已过期或易受攻击
漏洞影响
可让攻击者获取到敏感数据、提升权限，如未修改应⽤程序配置的默认密码，未删除应⽤程序安装程序⽬录⽂件等
防护⽅案
⼀个可以快速且易于部署在另⼀个锁定环境的可重复的加固过程。开发、质量保证和⽣产环境都应该进⾏相同配置，并且在每个环境中使⽤不同的密码。这个过程应该是⾃动化的，以尽量减少安装⼀个新安全环境的耗费
搭建最⼩化平台，该平台不包含任何不必要的功能、组件、⽂档和⽰例。移除或不安装不适⽤的功能和框架
检查和修复安全配置项来适应最新的安全说明、更新和补丁，并将其作为更新管理过程的⼀部分，在检查过程中应特别注意云存储权限（如：S3桶权限）
⼀个能在组件和⽤户间提供有效的分离和安全性的分段应⽤程序架构，包括：分段、容器化和云安全组
向客户端发送安全指令，如：安全标头
在所有环境中能够进⾏正确安全配置和设置⾃动化过程
A7：2017 跨站脚本（XSS）
当应⽤程序的新⽹页中包含不受信任的、未经恰当验证、转义的数据或可以使⽤HTML、JavaScript的浏览器API更新的现有⽹页时，就会出现xss漏洞，跨站脚本攻击是最普遍的web应⽤安全漏洞，甚⾄在某些安全平台都存在xss漏洞。xss会执⾏攻击者在浏览器中执⾏的脚本，并劫持⽤户会话，破坏⽹站或⽤户重定向到恶意站点，使⽤xss还可以执⾏拒绝服务攻击。
存在三种XSS类型，通常针对⽤户的浏览器：
反射式XSS：应⽤程序或API包括未经验证和未转义的⽤户输⼊，作为HTML输出的⼀部分。⼀个成功的攻击可以让攻击者在受害者的浏览器执⾏任意的HTML和JavaScript。通常，⽤户将需要与指向攻击者控制页⾯的某些恶意链接进⾏交互，如恶意漏洞⽹站，⼴告等
存储式XSS：你的应⽤或API将未净化的⽤户输⼊存储下来了，并在后期在其他⽤户或者管理员的页⾯展⽰出来。存储型XSS⼀般被认为是⾼危或严重的风险
基于DOM的XSS：会动态的将攻击者可控的内容加⼊页⾯的JavaScript框架、单页⾯程序或API存在这种类型的漏洞。理想的来说，你应该避免将攻击者可控的数据发送给不安全的JavaScript API
典型的XSS攻击可导致盗取session、账户、绕过MFA、DIV替换、对⽤户浏览器的攻击（如：恶意软件下载、键盘记录）
防护⽅案
XSS 过滤器的作⽤是过滤⽤户（浏览器客户端）提交的有害信息，从⽽达到防范XSS 攻击的效果。
1、输⼊过滤
输⼊验证
对⽤户提交的信息进⾏“有效性”验证。
仅接受指定长度
仅包含合法字符
仅接收指定范围
特殊的格式，例如，email 、IP 地址。
数据消毒xml实体解析xpath注入
过滤或净化掉有害的输⼊
$code = str_replace('script','',$xsscode);
2、输出编码
HTML 编码是HTML 实体编码。
$code = htmlspecialchars($xsscode);
3、⿊⽩名单策略
不管是采⽤输⼊过滤还是输出编码，都是针对信息进⾏⿊、⽩名单式的过滤。
⿊名单，⾮允许的内容
⽩名单，允许的内容
4、防御DOM 型XSS
避免客户端⽂档重写，重定向或其他敏感操作。
A8 2017 不安全的反序列化
不安全的反序列化可以导致、、注⼊攻击或特权升级攻击
对反序列化的利⽤是有点困难的。因为在不更改或调整底层可被利⽤代码的情况下，现场的反序列化漏洞很难被使⽤
可能的两种主要攻击类型：
如果应⽤中存在可以在反序列化过程中或者之后被改变⾏为的类，则攻击者可以通过改变应⽤逻辑或者实现远程代码执⾏攻击。我们将其称为对象和数据结构攻击
典型的数据篡改攻击，如访问控制相关的攻击，其中使⽤了现有的数据结构，但内容发⽣了变化
防护⽅案
1、对数据对象签名，并作完整检查
2、数据对象中的数据做严格的类型检查，限制⼀部分恶意攻击
3、隔离反序列化操作环境
A9 2017 使⽤含有已知漏洞的组件
组件（库、框架和其他软件模块）拥有和应⽤程序相同的权限。如果应⽤程序中含有已知漏洞的组件被攻击者利⽤，可能会造成严重的数据丢失或服务器接管。同时，使⽤含有已知漏洞的组件的应⽤程序和API可能会破坏应⽤程序防御、造成各种攻击并产⽣严重影响
对于⼀些漏洞很容易到其利⽤程序，但对其他的漏洞则需要定制开发
这种安全漏洞普遍存在。基于组件开发的模式使得多数开发团队根本不了解其应⽤或API中使⽤的组件，更谈不上及时更新这些组件了
经常爆出漏洞的组件：
Weblogic
Strust-2
防护⽅案
1、及时更新、修复组件漏洞
2、移除不再使⽤的依赖组件
A10 2017 ⽇志记录和监控不⾜
对于⽇志记录的监控不⾜，以及事件响应缺失或⽆效的集成，使得攻击者攻击系统、应⽤、盗取数据等操作⽆法被发现和追查。让其能够进⼀步攻击系统、保持持续性的或攻击更多的系统，以及对数据的不当操作。
防护⽅案
1、启⽤⽇志监控、告警机制
2、启⽤异地监控，C/S架构的监制机制
3、尽可能的完整记录所有⽇志
A11 2013 跨站请求伪造（CSRF）
它强制终端⽤户在当前对其进⾏⾝份验证后（登陆 cookie session）的Web 应⽤程序上执⾏，⾮本意操作的攻击。 CSRF 攻击的重点在于更改状态的请求，⽽不是盗取数据，因为攻击者⽆法查看伪造请求的响应。
借助于社⼯的⼀些帮助，例如，通过电⼦邮件或聊天发送链接，攻击者可以诱骗⽤户执⾏攻击者选择的操作。
如果受害者是普通⽤户，则成功的CSRF 攻击可以强制⽤户执⾏更改状态的请求，例如转移资⾦、修改密码等操作。
如果受害者是管理账户，CSRF 攻击会危及整个Web 应⽤程序.
关键点
⽤户没有退出登陆
CSRF 是⼀种欺骗受害者提交恶意请求的攻击。它继承了受害者的⾝份和特权，代表受害者执⾏⾮本意 的、恶意的操作。
对于⼤多数站点，浏览器请求会⾃动发送与站点关联的所有凭据，例如⽤户的会话Cookie，IP 地址， Windows 域凭据等。因此，如果⽤户已对当前站点进⾏了⾝份验证，则该站点没有办法区分⼀个请求 是受害者发送的合法请求还是攻击者伪造受害者⾝份发送的⾮法请求。
⽬标
CSRF 的⽬标是更改⽤户账户的状态，攻击者利⽤CSRF 发送的请求都是更改状态的请求，⽐如，转账、更改密码，购买商品等等。
CSRF 的场景中，攻击者是没有办法获得服务器的响应。
防护⽅案
⽆效的防御
使⽤秘密的Cookie
仅接收POST 请求（get请求容易泄露消息）
多步交易（有可能被恶意攻击者预测）
URL 重写（⽤户⾝份信息会暴露在url中）
HTTPS （所有安全机制的前提）
有效的防御
验证Referer 字段
添加Token 验证，可以参考dvwa csrf最⾼级别
⼀串随机字符串每次客户端请求，服务器都会刷新token 服务器创建了⼀个token值，存储在服务器中并下发到浏览器下次浏览器请求，需要提交该token值，服务器根据浏览器提交的token 与服务器中存储的token进⾏对⽐，如果⼆者⼀致说明请求是正常。如果⼆者不⼀致说明请求可能来⾃恶意的攻击者 token的设计，在php中通常利⽤session机制
⼆次验证
在关键操作之前，再输⼊密码或者验证码。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。