本文主要介绍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 |
适用场景 | 适用于保存少量不敏感数据,如用户偏好设置 | 适用于保存较多或敏感数据,如用户登录状态等 |
同源策略(Same-Origin Policy,SOP)是一种基本的Web安全策略,它是浏览器实施的一种安全机制,旨在阻止不同源(来源)的网页间交互,以保护用户信息安全和防止恶意攻击。
同源的定义: 两个URL的协议、域名、端口都相同,则认为这两个URL同源。
# 同源
http://example.com/page1 和 http://example.com/page2
# 不同源-----域名不同
http://example.com/page1 和 http://example2.com/page1
恶意网站拦截工作原理:一般都是浏览器周期性的从服务器获取一份最新恶意网址的黑名单,如果用户上网时访问的网址存在于黑名单中,浏览器就会弹出一个警告页面。
常见的恶意网址分为两类:挂马网站和钓鱼网站。前者通常包含有恶意的脚本如Javascript 或 Flash,通过利用浏览器的漏洞, 包括一些插件, 执行 shellcode,在用户电脑植入木马。后者通过模仿知名网站的相似页面来欺骗用户。
Open Web Application Security Project开放式Web应用程序安全项目(OWASP)是一个非营利组织,不附属于任何企业或财团。因此,由OWASP提供和开发的所有设施和文件都不受商业因素的影响。OWASP官方网站是 OWASP Foundation, the Open Source Foundation for Application Security | OWASP Foundation ,可以在该网站上找到有关OWASP项目、资源、安全指南等丰富的信息。
通过身份验证的用户,可以访问其他用户的相关信息,没有实施恰当的访问权限,攻击者可以利用这个漏洞去查看未授权的功能和数据,就是常说的越权漏洞。比如访问用户的账户、敏感文件、获取和正常用户相同的权限等。常见攻击方式有
敏感数据暴露指敏感信息在未经授权或安全措施不足的情况下,被泄露、访问、公开或传输到未受信任的人或系统。这可能导致隐私泄露、数据泄露、安全漏洞等严重后果。
可能产生原因
如何防范
注入是指web应用程序对用户输入数据的合法性没有判断或过滤不严,攻击者可以在web应用程序中事先定义好的查询语句的结尾上添加额外的执行语句,在管理员不知情的情况下实现非法操作,以此来实现欺骗数据库服务器执行非授权的任意查询,从而进一步得到相应的数据信息。
SQL注入是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串,最终达到欺骗服务器执行恶意SQL命令目的的入侵行为。产生的原因:
假设登录查询语句如下:
select * from table where name='XX' and pawword='YY'
只要用户名和密码匹配,就可以登录成功。如果有人在User ID 文本框输入了这样一行代码:
Admin' or 1=1 #
那么整个语句就变成了:
Select * from table where name='Admin' or 1=1 # and password='YY'
只要表名是对的,这条语句就永真,任意账号都可以直接登录。
在开发软件时,在关键身份验证、访问控制、业务逻辑和关键流部位没有进行安全的设计。由于开发过程中的设计缺陷,可能导致注入、文件上传等漏洞被利用。
常见的漏洞利用:支付逻辑、密码找回、验证码暴力破解/ 重复使用/ 客户端回显/ 绕过/ 自动识别等。
所有涉及购买、支付等方面的功能处就有可能存在支付漏洞,挖掘:寻找网站的支付系统、或兑换系统,抓包判断有没有敏感信息可以修改。【注意:实际验证过程中,一定要有授权】
可能漏洞利用的场景:修改支付价格、状态,修改购买数量、优惠卷、积分,多重替换支付,无限制试用等。
通常是由于不安全的默认配置、不完整的临时配置、开源云 存储、错误的 HTTP标头配置以及包含敏感信息的详细错误信息造成的。
可能出现的风险点:
通过错误使用应用程序的身份认证和会话管理功能,攻击者能够破译密码、密钥或会话令牌, 或者利用其它开发缺陷来暂时性或永久性冒充其他用户的身份。
可能出现的风险点
常见防范措施
服务端请求伪造(Server-Side Request Forgery,SSRF)是指攻击者能够从易受攻击的Web应用程序发送精心设计的请求的对其他网站进行攻击。一般SSRF攻击的目标是从外网无法访问的内部系统。
产生原因一般是由于服务端提供了从其他服务器应用获取数据的功能,但没有对目标地址做过滤与限制。SSRF就是利用存在缺陷的web应用作为代理去攻击远程和本地的服务器。也就是说,对于为服务器提供服务的其他应用没有对访问进行限制,如果构造好访问包,那就有可能利用目标服务对他的其他服务器应用进行调用。
(图片来源网络)
SSRF常见危害
预防SSRF漏洞包括: