2022面试精选之常规应用漏洞 - 网安 - 专业的网络安全产业、社区、知识平台

今天分享一篇文章，涉及Redis未授权、SSRF漏洞、宽字节注入、JSONP劫持、CORS、CRLF注入等技能，并详细讲述了其原理和漏洞利用等。

常规应用漏洞

Redis未授权访问漏洞如何入侵利用

redis漏洞产生原因

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

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

(3) root 身份运行redis

redis利用方法

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

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

(3) 知道物理路径且web目录有写权限写webshell (4) redis 4.x之后,主从复制getshell

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

SSRF漏洞原理、利用方式及修复方案？Java和PHP的SSRF区别

SSRF漏洞原理

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

SSRF漏洞位置

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

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

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

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

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

(5) 图片、文章收藏功能

SSRF漏洞利用

(1) CURL支持协议

(2) 利用file协议读取文件

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

(4) 利用gopher协议反弹shell

SSRF漏洞利用绕过

(1)使用@：http://A.com@10.10.10.10 = 10.10.10.10

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

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

(4)端口绕过：ip后面加一个端口

(5xip.io：10.0.0.1.xip.io = 10.0.0.1

(6)通过js跳转..

(7)利用DNS解析

(8)利用句号（127。0。0。1）

(9)利用[::]（http://[::]:80/）；

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

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

SSRF漏洞修复方式

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

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

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

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

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

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

(7) 禁止30x跳转

Java和PHP的SSRF区别

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)指定字符集

简述JSONP的业务意义，JSONP劫持利用方式及修复方案？如何设计落地一个CSRF Token？

如何设计落地一个CSRF Token

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

这样用户知道该参数，发送请求的时候，携带 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 就是当前用户的。

CORS原理、利用及修复？

原理、利用、修复

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

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

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

CRLF注入原理

原理

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

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

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

URL白名单如何绕过？

绕过方式

(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://login.aaa.com@test.com

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

(5)多重跳转的问题导致可绕过URL限制

(6)可信站点（baidu.com）302跳转绕过限制

(7)利用#号绕过

https://www.baidu.com/#login.aaa.com

XSS持久化如何实现？

XSS持久化

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

Fastjson常见漏洞原理？如何彻底解决Fastjson漏洞？

Fastjson漏洞原理

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将反序列化为指定的对象。

官方维护了一份常见危险类型的黑名单，但众所周知，黑名单的机制很难覆盖全面。如果有攻击者找到黑名单以外的危险类型，依然会产生严重危害。

解决Fastjson漏洞

方案一：开启safemode 适用于完全不需要autoType的应用。开启时，会强制关闭autoType。

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

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

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

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

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

方案三：autoType黑名单

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

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