1、前言
本文主要介绍WEB客户端一些漏洞类型,漏洞产生的原因、有哪些危害、可能产生漏洞的场景,如何防范。后面会有对应的文章对应具体漏洞类型展开详细说明,提供靶场实战演练,主要用于理解挖掘漏洞的思路。
2、Web如何管理用户状态
Web应用程序大部分使用HTTP协议传输数据,而HTTP协议是一种无状态的协议,每个请求都是相互独立的,服务器无法识别两个请求是否来自同一个客户端。为了解决这个问题,Cookie技术应运而生。Cookie是由Netscape公司于1994年提出的,最初用于记录用户在网站上的登录状态。
Cookie只解决了识别客户端的问题,无法解决服务器区分不同请求来自同一个用户还是不同用户,所以就出现Session机制。Session是一种在服务器端维护状态的机制,用于在不同HTTP请求之间保持特定用户或客户端的状态信息。它的出现主要是为了解决HTTP协议的无状态性问题,实现用户状态的持久化和管理。
一般情况下,常用的做法是将Session与Cookie结合使用。使用Cookie存储Session ID,通过Session ID关联服务器端的Session数据,从而兼顾了安全性和客户端传输效率。
Cookie和Session的主要区别:
特性 | Cookie | Session |
---|---|---|
存储位置 | 存储在客户端 | 存储在服务器端 |
安全性 | 相对较低,容易被篡改 | 相对较高,服务器端存储,客户端无法修改 |
存储容量 | 有限制,一般每个Cookie大小不能超过4KB | 理论上无限制,受服务器配置和内存限制 |
隐私保护 | 需要注意隐私泄露风险 | 相对更好的隐私保护,数据存储在服务器端 |
跨域问题 | 可以设置Domain属性实现跨域共享 | 仅适用于同一站点,不会发送给其他域 |
跨标签和窗口共享 | 可以共享,同一域名下的不同标签页和窗口共享 | 不共享,每个标签页/窗口都会创建新的Session |
服务器负担 | 对服务器负担较小,客户端负责存储和传输 | 对服务器负担较大,需要维护Session池和管理机制 |
传输方式 | 通过HTTP请求头传输 | 通过Cookie或URL传输Session ID |
适用场景 | 适用于保存少量不敏感数据,如用户偏好设置 | 适用于保存较多或敏感数据,如用户登录状态等 |
3、同源策略
同源策略(Same-Origin Policy,SOP)是一种基本的Web安全策略,它是浏览器实施的一种安全机制,旨在阻止不同源(来源)的网页间交互,以保护用户信息安全和防止恶意攻击。
同源的定义: 两个URL的协议、域名、端口都相同,则认为这两个URL同源。
代码语言:javascript复制# 同源
http://example.com/page1 和 http://example.com/page2
# 不同源-----域名不同
http://example.com/page1 和 http://example2.com/page1
4、恶意网站拦截
恶意网站拦截工作原理:一般都是浏览器周期性的从服务器获取一份最新恶意网址的黑名单,如果用户上网时访问的网址存在于黑名单中,浏览器就会弹出一个警告页面。
常见的恶意网址分为两类:挂马网站和钓鱼网站。前者通常包含有恶意的脚本如Javascript 或 Flash,通过利用浏览器的漏洞, 包括一些插件, 执行 shellcode,在用户电脑植入木马。后者通过模仿知名网站的相似页面来欺骗用户。
5、Web安全-OWASP TOP10
Open Web Application Security Project开放式Web应用程序安全项目(OWASP)是一个非营利组织,不附属于任何企业或财团。因此,由OWASP提供和开发的所有设施和文件都不受商业因素的影响。OWASP官方网站是 OWASP Foundation, the Open Source Foundation for Application Security | OWASP Foundation ,可以在该网站上找到有关OWASP项目、资源、安全指南等丰富的信息。
6、访问控制崩溃
通过身份验证的用户,可以访问其他用户的相关信息,没有实施恰当的访问权限,攻击者可以利用这个漏洞去查看未授权的功能和数据,就是常说的越权漏洞。比如访问用户的账户、敏感文件、获取和正常用户相同的权限等。常见攻击方式有
- 通过修改URL、内部应用程序状态或HTML页面绕过访问控制检查,或简单地使用自定义的API攻击工具。
- 允许将主键更改为其他用户的记录,例如查看或编辑他人的帐户。
- 特权提升:在不登录的情况下假扮用户,或以用户身份登录时充当理员。
- 以未通过身份验证的用户身份强制浏览的通过身份验证时才能看到的页面、或作为标准用户访问具有相关权限的页面、或API没有对POST、PUT和DELETE强制执行访问控制。
7、敏感数据暴露
敏感数据暴露指敏感信息在未经授权或安全措施不足的情况下,被泄露、访问、公开或传输到未受信任的人或系统。这可能导致隐私泄露、数据泄露、安全漏洞等严重后果。
可能产生原因
- 用户个人信息收集后存储分散,业务使用中管理不规范 ,在查询详情接口没有做加密处理直接全部返回
- 信息安全意识参差不齐,可能存在违规使用、随意下载用户个人信息的行为
- 网站的配置信息泄露
如何防范
- 使用自己搭建的git服务管理代码,不放到公网上
- 谨慎使用第三方云服务,不要把工作相关的存放到云端
- 禁止使用工作邮箱注册非工作相关网站
8、注入
注入是指web应用程序对用户输入数据的合法性没有判断或过滤不严,攻击者可以在web应用程序中事先定义好的查询语句的结尾上添加额外的执行语句,在管理员不知情的情况下实现非法操作,以此来实现欺骗数据库服务器执行非授权的任意查询,从而进一步得到相应的数据信息。
SQL注入是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串,最终达到欺骗服务器执行恶意SQL命令目的的入侵行为。产生的原因:
- 不正确的输入验证和过滤:用户输入没有做适当的验证和过滤,直接用于构建SQL查询。如果用户输入中包含SQL代码,攻击者可以利用这些输入执行恶意的SQL语句。
- 拼接SQL语句:将用户输入直接拼接到SQL查询中,而不是使用参数化查询或预处理语句,导致SQL语句结构被破坏,允许攻击者执行任意SQL操作。
- 过度信任外部输入:应用程序过度信任外部输入,包括来自用户、AP的输入。攻击者可能恶意篡改这些输入,注入恶意SQL语句。
8.1、举例:登录输入框
假设登录查询语句如下:
代码语言:javascript复制select * from table where name='XX' and pawword='YY'
只要用户名和密码匹配,就可以登录成功。如果有人在User ID 文本框输入了这样一行代码:
代码语言:javascript复制Admin' or 1=1 #
那么整个语句就变成了:
代码语言:javascript复制Select * from table where name='Admin' or 1=1 # and password='YY'
只要表名是对的,这条语句就永真,任意账号都可以直接登录。
9、不安全的设计
在开发软件时,在关键身份验证、访问控制、业务逻辑和关键流部位没有进行安全的设计。由于开发过程中的设计缺陷,可能导致注入、文件上传等漏洞被利用。
常见的漏洞利用:支付逻辑、密码找回、验证码暴力破解/ 重复使用/ 客户端回显/ 绕过/ 自动识别等。
9.1、支付逻辑
所有涉及购买、支付等方面的功能处就有可能存在支付漏洞,挖掘:寻找网站的支付系统、或兑换系统,抓包判断有没有敏感信息可以修改。【注意:实际验证过程中,一定要有授权】
可能漏洞利用的场景:修改支付价格、状态,修改购买数量、优惠卷、积分,多重替换支付,无限制试用等。
10、安全配置不当
通常是由于不安全的默认配置、不完整的临时配置、开源云 存储、错误的 HTTP标头配置以及包含敏感信息的详细错误信息造成的。
可能出现的风险点:
- 应用程序启用或者安装了不必要的安全功能
- 默认账户名和密码没有修改
- 应用软件已过期或出了新版本未更新
- 应用程序服务器,应用程序框架等未进行安全配置。
- 错误处理机制披露大量敏感信息
- 对于更新的系统,禁用或不安全地配置安全功能。
11、认证崩溃
通过错误使用应用程序的身份认证和会话管理功能,攻击者能够破译密码、密钥或会话令牌, 或者利用其它开发缺陷来暂时性或永久性冒充其他用户的身份。
可能出现的风险点
- 允许暴力破解破解密码或者账号。
- 允许默认的、弱的或众所周知的密码,例如:admin/admin
- 使用明文、加密或弱散例密码。
- 缺少或失效的多因素身份验证。
- 暴露URL中的会话ID(例如URL重写)。
- 旧密码泄露
- 会话ID使用时间过长
常见防范措施
- 在可能的情况下,实现多因素身份验证,以防止自动、凭证填充 暴力破解和被盗凭据再利用攻击。
- 检查弱口令,模拟爆破操作。
- 限制或逐渐延迟失败的登录尝试,记录所有失败信息,并暴力破解或其他攻击被检测时提醒管理员。
- 会话状态管理,组合使用Session与Cookie。会话ID不要在URL中,注意设置它的时效性。
12、服务端请求伪造
服务端请求伪造(Server-Side Request Forgery,SSRF)是指攻击者能够从易受攻击的Web应用程序发送精心设计的请求的对其他网站进行攻击。一般SSRF攻击的目标是从外网无法访问的内部系统。
产生原因一般是由于服务端提供了从其他服务器应用获取数据的功能,但没有对目标地址做过滤与限制。SSRF就是利用存在缺陷的web应用作为代理去攻击远程和本地的服务器。也就是说,对于为服务器提供服务的其他应用没有对访问进行限制,如果构造好访问包,那就有可能利用目标服务对他的其他服务器应用进行调用。
(图片来源网络)
SSRF常见危害
- 1.可以对服务器所在内网、本地进行端口扫描,获取一些服务的信息等
- 2.目标网站本地敏感数据的读取
- 3.内外网主机应用程序漏洞的利用
- 4.内外网Web站点漏洞的利用
预防SSRF漏洞包括:
- 严格验证和过滤用户输入:确保用户输入不包含恶意URL或特殊协议。
- 限制URL的范围和协议:对允许的URL进行白名单验证,限制协议、域名或IP范围。
- 避免从用户输入中获取URL:避免直接从用户输入中获取URL,比如通过程序按一定规则拼接获取。
- 实施访问控制:确保服务器只能访问受信任的资源,并限制对敏感资源的访问