2022面试精选之常规应用漏洞

题目来源：https://www.yuque.com/feei/sig/application-security

redis漏洞产生原因

(1) redis绑定在 0.0.0.0:6379，且没有进行添加防火墙规则避免其他非信任来源 ip 访问等相关安全策略，直接暴露在公网；

(2) 没有设置密码认证（一般为空），可以免密码远程登录redis服务。

(3) root 身份运行redis

redis利用方法

·能够回连且权限够的话，写crontab利用计划任务执行命令反弹shell

·开启22端口且权限够大的情况下，通过写公钥到服务器获得系统权限

·知道物理路径且web目录有写权限写webshell

·redis 4.x之后,主从复制getshell

原理：利用一个可以发起网络请求的服务，当作跳板来攻击其他服务。

SSRF漏洞一般位于远程图片加载、图片或文章收藏功能、URL分享、通过URL在线翻译、转码等功能点处

1、 分享：通过url地址分享网页内容

2、 转码：通过URL地址把原地址的网页内容调优使其适合手机屏幕浏览

3、 在线翻译：通过URL地址翻译对应文本的内容

4、 图片加载与下载：通过URL地址加载或下载图片

5、 图片、文章收藏功能

1）CURL支持协议

2）利用file协议读取文件

3）利用dict协议查看端口开放

4）利用gopher协议反弹shell

使用@：http://[email protected] = 10.10.10.10

IP地址转换成十进制、八进制：127.0.0.1 = 2130706433

使用短地址：http://10.10.116.11 = http://t.cn/RwbLKDx

端口绕过：ip后面加一个端口

xip.io：10.0.0.1.xip.io = 10.0.0.1

通过js跳转..

利用DNS解析

利用句号（127。0。0。1）

利用[::]（http://[::]:80/）；

利用短地址（http://dwz.cn/11SMa）；

协议（Dict://、SFTP://、TFTP://、LDAP://、Gopher://）

1、过滤返回信息，验证远程服务器对请求的响应是比较容易的方法；

2、统一错误信息，避免用户可以根据错误信息来判断远端服务器的端口状态；

3、限制请求的端口为http常用的端口，比如，80,443,8080,8090；

4、黑名单内网ip。避免应用被用来获取获取内网数据，攻击内网；

5、禁用不需要的协议。仅允许http和https请求；

6、使用正则对参数进行效验，防止畸形请求绕过黑名单。

7、禁止30x跳转

PHP支持的协议

·file:// — Accessing local filesystem·http:// — Accessing HTTP(s) URLs·ftp:// — Accessing FTP(s) URLs·php:// — Accessing various I/O streams·zlib:// — Compression Streams·data:// — Data (RFC 2397)·glob:// — Find pathnames matching pattern·phar:// — PHP Archive·ssh2:// — Secure Shell 2·rar:// — RAR·ogg:// — Audio streams·expect:// — Process Interaction Streams

Java支持的协议·file·ftp·gopher·http·https·jar·mailto·netdoc

gbk编码 %df使用mysql_set_charset(GBK)指定字符集

在请求中添加一个攻击者不知道的参数（且该参数浏览器不会自动发送），让服务端可以区别出请求是否经过用户的同意。

这样用户知道该参数，发送请求的时候，携带 cookie 和该参数；而攻击者不知道该参数，浏览器发送请求时，只自动携带了 cookie。服务端即可通过校验该参数，来判断操作是否是用户真实想进行的。

这个参数，就被称为 csrf token。

HTTP request Header: 将 token 添加在 header 中发送，它具有一个天然的优势，可以利用浏览器的同源策略：csrf token header 相当于一个自定义 header，在跨域请求时，携带自定义 header，会触发预检请求，若预检请求不通过，正式请求就不会发送。

双重提交（Double Submit Cookie）

在请求到达服务端后，服务端不需要再从数据库/缓存中读取对应的值来跟 csrf token 比对。只需要跟请求中的 csrf cookie 比对即可。这个 cookie 就是服务端当初签发出去的 token 参数。只要它们相等，就证明请求是经过用户同意发送的，因为攻击者无法读取这个 cookie 值，也就无法将这个值作为 token 参数，添加到请求中发送，而用户是知道的（用户可以读取 csrf token cookie）。 我们可以使用加密签名的方式： 将用户的 session token 作为明文，使用服务端的密钥进行加密签名，将面名后的秘文作为 csrf token value 发送给客户端。使用 session token 作为明文有 2 个好处：即保证了 csrf token 跟 user 绑定，又保证了 csrf token 的随机且唯一。即： csrf_token = HMAC(session_token, application_secret)

当服务端收到请求后，从缓存/数据库/cookie 中获取原来的加密明文 session_token，使用服务端的密钥再进行一次加密签名，比对签名后的结果 和 请求中携带的 csrf token 参数是否相等，若相等，则： csrf token 是服务端签发的

签名的内容没有被篡改，即该 token 就是当前用户的。

(1)CORS全称是"跨域资源共享"（Cross-origin resource sharing）,Origin源未严格，从而造成跨域问题,允许浏览器向跨源服务器，发出XMLHttpRequest请求

(2)Origin为*的时候，使用curl测试CORS，

curl -H “Origin: https://evil.com” -I

CRLF 指的是回车符(CR，ASCII 13，\r，%0d) 和换行符(LF，ASCII 10，\n，%0a)。

CRLF注入漏洞的本质和XSS有点相似，攻击者将恶意数据发送给易受攻击的Web应用程序，Web应用程序将恶意数据输出在HTTP响应头中。（XSS一般输出在主体中）

所以CRLF注入漏洞的检测也和XSS漏洞的检测差不多。通过修改HTTP参数或URL，注入恶意的CRLF，查看构造的恶意数据是否在响应头中输出。

(1)利用问号绕过限制 http://www.aaa.com/acb?Url=http://login.aaa.com http://www.aaa.com/acb?Url=http://test.com?login.aaa.com

(2)利用反斜杠和正斜杠绕过限制 http://www.aaa.com/acb?Url=http://login.aaa.com/ http://www.aaa.com/acb?Url=http://test.com/login.aaa.com http://www.aaa.com/acb?Url=http://test.com\login.aaa.com http://test.com.login.aaa.com

(3)利用@绕过URL限制 http://www.aaa.com/acb?Url=http://[email protected]

(4)白名单缺陷绕过限制 testxxx.com

(5)多重跳转的问题导致可绕过URL限制 (6)可信站点（baidu.com）302跳转绕过限制 (7)利用#号绕过 https://www.baidu.com/#login.aaa.com

XSS持久化依赖于储存型XSS漏洞，当发现有存储型XSS漏洞时，会尝试插入一段JS代码用于窃取cookie，配合hook可以实现更多操作。持久化一般采用无感记录，如登录记录，cookie记录等，并发送到指定接收端。

1.fastjson-1.2.24

(fastjson接受的JSON可以通过艾特type字段来指定该JSON应当还原成何种类型的对象，在反序列化的时候方便操作)

2.fastjson-1.248以下

(checkAutoType中使用TypeUtils.getClassFromMapping(typeName)去获取class不为空，从而绕过了黑名单检测)

3.fastjson-1.2.60以下

(在此版本以下，字符串中包含\x转义字符时可以造成dos漏洞)

1.2.70及以上版本，目前暂未被披露存在高危的漏洞利用链。

当autotype开启时，参数中使用“@type”字段，可以指定任意的类，fastjson将反序列化为指定的对象。

官方维护了一份常见危险类型的黑名单，但众所周知，黑名单的机制很难覆盖全面。如果有攻击者找到黑名单以外的危险类型，依然会产生严重危害。 方案一：开启safemode 适用于完全不需要autoType的应用。开启时，会强制关闭autoType。

优点：最安全的方案，完全禁用autoType，新的版本再爆出反序列化漏洞时，极大概率不需要再升级也能免疫。

不足：仅适用于完全不需要autoType的应用。

方案二：配置一个autoType白名单。

优点：相对安全，可以避免一些恶意类的传入，前提是白名单范围要尽量缩小。新的版本再爆出反序列化漏洞时，大概率不需要再升级也能免疫。

不足：情况复杂的业务，梳理有哪些数据是需要用到autoType反序列化的，整理出白名单需要一定时间。

方案三：autoType黑名单

优点：整改成本低，处理速度快。

不足：安全性不如前两种方案，短期内可作为临时方案，缓解外部漏洞探测。有极低的概率会对已有业务产生影响（反序列化的内容里包含java.net.前缀类型对象的情况）。