Posts

个人觉得不错的文章： https://www.cnblogs.com/sup3rman/p/16051163.html https://blog.csdn.net/wahaha__zhou_/article/details/147429499 jwt(json web token) jwt格式: header.payload.signature 其中header和payload部分都是base64编码的json对象，签名部分是二进制编码的 头部包含令牌本身的元数据，payload包含用户的实际“声明” jwt签名：证明内容没有被篡改，可验证 签名 = 算法( 私钥, Base64Url(Header) + "." + Base64Url(Payload) 概念 主要作用 你可以理解成 JWT Token 的整体标准/形式 “令牌” JWS 对数据进行签名（算法(私钥，header+payload)） “防篡改 + 验证身份” JWE 对数据进行加密（加密payload） “防止别人看到内容” JWK 描述密钥的 JSON 格式 “密钥的 JSON 身份证” 字段 含义 kty Key Type，密钥类型 kid Key ID，密钥编号 use 密钥用途 alg 推荐/指定算法 n RSA 公钥参数 e RSA 公钥参数 x EC/OKP 等密钥参数 d 私钥参数，非常敏感 header字段： kid 密钥标识符，告诉服务器选择哪把密钥来进行验证jwt签名，这里就可能存在sql注入的手段，让服务器去查找密钥完成sql注入 alg 签名算法 porswigger靶场 less1 服务器在使用jwt里面的sub做身份验证，但是没有验证签名是否与header+paylaod是否匹配，可以直接bp抓包登录后更改掉payload部分sub身份 ...

arp协议 设备之间的通信是靠MAC地址，ARP（地址解析协议） 的作用就是：根据IP地址，找到对应的MAC地址。 主机A（192.168.1.10）想给主机B（192.168.1.20）发数据 A只知道B的IP，不知道B的MAC A广播一个ARP请求：“谁是192.168.1.20？请告诉我你的MAC地址” B收到后单播回复：“我是，我的MAC是 XX:XX:XX:XX:XX:XX” A把这个对应关系存入ARP缓存表，之后就直接用MAC通信了 关键问题在于：ARP协议没有任何认证机制。设备收到ARP回复时，会无条件相信并更新自己的缓存，即使自己根本没发过请求。 攻击者利用这个信任漏洞，发送伪造的ARP响应，把错误的IP-MAC对应关系塞进目标的ARP缓存里。 典型场景（中间人攻击）： 正常情况： 受害者(192.168.1.10) → 网关(192.168.1.1) ARP欺骗后： 受害者认为：网关(192.168.1.1) 的MAC = 攻击者的MAC 网关认为： 受害者(192.168.1.10) 的MAC = 攻击者的MAC 受害者 → 攻击者 → 网关 （数据全部经过攻击者中转） 攻击者分别向受害者和网关发送伪造ARP包： 对受害者说：“我是网关，我的MAC是攻击者MAC” 对网关说：“我是受害者，我的MAC是攻击者MAC” 这样双方的数据都会先发给攻击者，攻击者可以窃听、篡改、转发，这就是典型的中间人攻击（MITM）。 现在我以vmware为例开始演示我的kali攻击机实施arp断网攻击我的另一台centos虚拟机，同一网段 均为nat模式，均能正常上网 kali网ip： eth0 UP 192.168.159.128/24 fe80::20c:29ff:fe69:62cd/64 centos网ip： 192.168.159.136 查看当前网段的网关 ip route 单项攻击 只欺骗靶机，但是不影响网关 sudo arpspoof -i eth0 -t target 网关ip sudo arpspoof -i eth0 -t 192.168.159.136 192.168.159.2 目标机器视角： 直接搜索网页一直转，网ip，mac地址都在，结束攻击之后正常恢复上网 欺骗全网段所有主机，容易被发现 sudo arpspoof -i eth0 网关ip sudo arpspoof -i eth0 192.168.159.2 双向欺骗 ...

参考资料：逻辑漏洞框架 - CSDN 逻辑漏洞是指程序在某功能设计不严谨，在前后端/对用户输入没进行严谨过滤 portswigger靶场 Excessive trust in client-side controls 抓包看到客户端会发送一个带有price的检验包发送给服务器告诉服务器这个东西多少钱，我们直接改包价格  改包成功，服务器信任客户发送的price High-level logic vulnerability 第二关我们再去先试一下，抓包添加商品没有看到price参数，我尝试了添加一个price参数在末尾，没改成价格，但是也没有报错 应该是后端会去校验商品价格，这个不通，然后之前发现的这个商品的quantity可以更改值为负数，相应的结算金额也变成了负数，但是提交负数订单时错的，总金额必须得大于0，尝试去购买商品让金额达到0<x<100 直接购买成功，这个不是不检验quantity参数，导致负数产生 Inconsistent security controls 权限逻辑漏洞 进去没有账号，需要自己在emali.client去注册一个账户，找了一圈没有发现什么有用的东西 根据提示使用burpsuite 自带的discover content对网站做一个目录扫描 扫描发现/admin目录，提示只能有DontWannaCry 这个用户访问，根据提示把邮箱地址改为 @dontwannacry.com格式 原来dontwannacry是个公司，注册会验证一次邮箱，但是后续更改email并不会验证，这个就是逻辑漏洞 登录进去就会多了admin管理页面 Flawed enforcement of business rules 这一关就是要使用优惠券，新用户减了5块还是不够啊，尝试抓包重放都不能重复使用 但是发现下面有个注册， 有签到券，然后发现这两个券可以交替无限使用 Low-level logic flaw 总金额溢出 根据提示发现这一关我们抓包到的添加商品到cart里面一次请求最多99，100就是非法数值 根据提示去intruder模块去fuzz测试总金额溢出，当fuzz次数多的时候总金额溢出就会变成负数， 32bit的整形溢出 -2,147,483,648到2,147,483,647 然后结合商品组合出总金额溢出到0-100就合适 Inconsistent handling of exceptional input 这一关是一个垂直越权 根据提示，对网站做一个目录扫描，找到/admin界面 跟之前那关一样的提示，应该是要注册邮箱的时候加上dontwannacry这个域名 尝试了下，之前是注册了之后可以随便更改邮箱地址的逻辑漏洞，这一关限制了更改邮箱地址 这一关逻辑大概是，注册需要是自己的邮箱后缀，才能收到激活邮件，后缀必须是@dontwannacry.com才能进入admin管理员界面 ...

靶机配置 host-only，kali是NAT，host-only双网卡 检查kali的eth1是否有网ip， sudo dhclient eth1 kali网ip：192.168.65.128/24 信息收集 nmap 存活探测 靶机网ip:192.168.65.132 靶机做一个默认脚本扫描，服务探测，端口扫描 └─$ nmap 192.168.65.132 -sC -sV -p- -min-rate 2222 -r Starting Nmap 7.98 ( https://nmap.org ) at 2026-07-31 09:58 +0800 Nmap scan report for 192.168.65.132 Host is up (0.0017s latency). Not shown: 39528 closed tcp ports (reset), 26003 filtered tcp ports (no-response) PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 4.7p1 Debian 8ubuntu1.2 (protocol 2.0) | ssh-hostkey: | 1024 9b:ad:4f:f2:1e:c5:f2:39:14:b9:d3:a0:0b:e8:41:71 (DSA) |_ 2048 85:40:c6:d5:41:26:05:34:ad:f8:6e:f2:a7:6b:4f:0e (RSA) 80/tcp open http Apache httpd 2.2.8 ((Ubuntu) PHP/5.2.4-2ubuntu5.6 with Suhosin-Patch) |_http-title: Site doesn't have a title (text/html). |_http-server-header: Apache/2.2.8 (Ubuntu) PHP/5.2.4-2ubuntu5.6 with Suhosin-Patch 139/tcp open netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP) 445/tcp open netbios-ssn Samba smbd 3.0.28a (workgroup: WORKGROUP) MAC Address: 00:0C:29:71:CA:7D (VMware) Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel Host script results: | smb-os-discovery: | OS: Unix (Samba 3.0.28a) | Computer name: Kioptrix4 | NetBIOS computer name: | Domain name: localdomain | FQDN: Kioptrix4.localdomain |_ System time: 2026-07-31T06:00:24-04:00 |_clock-skew: mean: 10h00m51s, deviation: 2h49m43s, median: 8h00m50s | smb-security-mode: | account_used: guest | authentication_level: user | challenge_response: supported |_ message_signing: disabled (dangerous, but default) |_smb2-time: Protocol negotiation failed (SMB2) |_nbstat: NetBIOS name: KIOPTRIX4, NetBIOS user: <unknown>, NetBIOS MAC: <unknown> (unknown) Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 42.32 seconds 漏洞发现 网页首页是一个登录界面，尝试sql注入，这里看到了有sql语法报错，应该是有注入点的 ...

靶机，攻击机配置 kali：NAT网卡模式，网卡2设置成host-only模式， level3靶机：hos-only模式 信息收集 查看kali网卡二的ip网段：192.168.65.128/24 nmap 扫描网段存活主机 靶机ip：192.168.65.131 现在做一个默认脚本扫描，端口服务探测 └─$ nmap 192.168.65.131 -sC -sV -p- Starting Nmap 7.98 ( https://nmap.org ) at 2026-07-23 17:09 +0800 Nmap scan report for 192.168.65.131 Host is up (0.0022s latency). Not shown: 65533 closed tcp ports (reset) PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 4.7p1 Debian 8ubuntu1.2 (protocol 2.0) | ssh-hostkey: | 1024 30:e3:f6:dc:2e:22:5d:17:ac:46:02:39:ad:71:cb:49 (DSA) |_ 2048 9a:82:e6:96:e4:7e:d6:a6:d7:45:44:cb:19:aa:ec:dd (RSA) 80/tcp open http Apache httpd 2.2.8 ((Ubuntu) PHP/5.2.4-2ubuntu5.6 with Suhosin-Patch) |_http-title: Ligoat Security - Got Goat? Security ... | http-cookie-flags: | /: | PHPSESSID: |_ httponly flag not set |_http-server-header: Apache/2.2.8 (Ubuntu) PHP/5.2.4-2ubuntu5.6 with Suhosin-Patch MAC Address: 00:0C:29:AA:37:66 (VMware) Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 13.17 seconds 访问web服务，看到80端口有一个登录界面 ...

这一篇是基于上一篇Escalate-Linux渗透测试的笔记，上一篇通过找到.script.sh这个可写文件并且是在shell文件的suid root程序来运行提权脚本实现提权 本篇是基于NFS/SMB文件共享链路实现攻击提权 查询NFS共享文件配置 cat /etc/exports /srv/homes hostname1(rw,sync,no_subtree_check) hostname2(ro,sync,no_subtree_check) 解读;/srv/homes目录可以被远程主机访问 名为hostname1的主机拥有rw权限，而且这个NFS文件共享是no_subtree_tree（不检查访问共享目录时是否是子目录）的， 关键配置就是/home/user5 *(rw,no_root_squash) 允许所有主机访问而且都是rw权限，关闭了root_squash防护，这个东西是客户端以主机root权限访问这个共享文件还是root权限 这里就是我们的入手点 查询Samba文件共享配置 这里看到samba文件共享路径是/home/%U/linux_share 使用kali主机访问samba共享目录 被拒绝 回去尝试NFS共享文件 漏洞利用 回到shell去访问这个NFS文件共享 看到这个script文件权限是-rwsr-这个文件是一个SUID root程序,而且ls文件还是可控的rws文件 user6 / | home | user5 strings script strings script /lib64/ld-linux-x86-64.so.2 F7>S: libc.so.6 setuid system __cxa_finalize setgid __libc_start_main GLIBC_2.2.5 _ITM_deregisterTMCloneTable __gmon_start__ _ITM_registerTMCloneTable =y =W =Z AWAVI AUATL []A\A]A^A_ ;*3$" GCC: (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0 crtstuff.c deregister_tm_clones __do_global_dtors_aux completed.7696 __do_global_dtors_aux_fini_array_entry frame_dummy __frame_dummy_init_array_entry script.c __FRAME_END__ __init_array_end _DYNAMIC __init_array_start __GNU_EH_FRAME_HDR _GLOBAL_OFFSET_TABLE_ __libc_csu_fini _ITM_deregisterTMCloneTable _edata system@@GLIBC_2.2.5 __libc_start_main@@GLIBC_2.2.5 __data_start __gmon_start__ __dso_handle _IO_stdin_used __libc_csu_init __bss_start main setgid@@GLIBC_2.2.5 __TMC_END__ _ITM_registerTMCloneTable setuid@@GLIBC_2.2.5 __cxa_finalize@@GLIBC_2.2.5 .symtab .strtab .shstrtab .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt.got .text .fini .rodata .eh_frame_hdr .eh_frame .init_array .fini_array .dynamic .data .bss .comment 当前ls文件真实内容: ...

信息收集 1.主机存活探测 sudo nmap -sn 192.168.159.0/24 ## 扫描出来目标主机应该是192.168.159.133 2.端口服务,默认脚本扫描探测 └─$ nmap 192.168.159.133 -sV -sC -min-rate 2222 -r Starting Nmap 7.98 ( https://nmap.org ) at 2026-07-01 11:57 +0800 Nmap scan report for 192.168.159.133 Host is up (0.000086s latency). Not shown: 995 closed tcp ports (reset) PORT STATE SERVICE VERSION 80/tcp open http Apache httpd 2.4.29 ((Ubuntu)) |_http-title: Apache2 Ubuntu Default Page: It works |_http-server-header: Apache/2.4.29 (Ubuntu) 111/tcp open rpcbind 2-4 (RPC #100000) | rpcinfo: | program version port/proto service | 100000 2,3,4 111/tcp rpcbind | 100000 2,3,4 111/udp rpcbind | 100000 3,4 111/tcp6 rpcbind | 100000 3,4 111/udp6 rpcbind | 100003 3 2049/udp nfs | 100003 3 2049/udp6 nfs | 100003 3,4 2049/tcp nfs | 100003 3,4 2049/tcp6 nfs | 100005 1,2,3 33443/tcp6 mountd | 100005 1,2,3 34643/tcp mountd | 100005 1,2,3 38995/udp mountd | 100005 1,2,3 47250/udp6 mountd | 100021 1,3,4 32908/udp nlockmgr | 100021 1,3,4 41249/tcp6 nlockmgr | 100021 1,3,4 46353/tcp nlockmgr | 100021 1,3,4 52118/udp6 nlockmgr | 100227 3 2049/tcp nfs_acl | 100227 3 2049/tcp6 nfs_acl | 100227 3 2049/udp nfs_acl |_ 100227 3 2049/udp6 nfs_acl 139/tcp open netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP) 445/tcp open netbios-ssn Samba smbd 4.7.6-Ubuntu (workgroup: WORKGROUP) 2049/tcp open nfs 3-4 (RPC #100003) MAC Address: 00:0C:29:DD:64:D7 (VMware) Service Info: Host: LINUX Host script results: | smb2-security-mode: | 3.1.1: |_ Message signing enabled but not required |_nbstat: NetBIOS name: LINUX, NetBIOS user: <unknown>, NetBIOS MAC: <unknown> (unknown) | smb-security-mode: | account_used: guest | authentication_level: user | challenge_response: supported |_ message_signing: disabled (dangerous, but default) | smb2-time: | date: 2026-07-01T03:57:52 |_ start_date: N/A | smb-os-discovery: | OS: Windows 6.1 (Samba 4.7.6-Ubuntu) | Computer name: osboxes | NetBIOS computer name: LINUX\x00 | Domain name: \x00 | FQDN: osboxes |_ System time: 2026-06-30T23:57:52-04:00 |_clock-skew: mean: 1h19m59s, deviation: 2h18m33s, median: 0s Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 12.29 seconds 扫描结果主要是smba/nfs文件共享这方面的，80端口并没有什么用处，对网站做一个目录扫描 ...

kali网卡ip 192.168.159.128/24 信息收集 发现主机 直接扫描192.168.159.0/24网段发现目标ip是192.168.159.135 端口扫描，服务探测，版本 └─$ nmap 192.168.159.135 -sV -sC -p- Starting Nmap 7.98 ( https://nmap.org ) at 2026-06-29 19:32 +0800 Stats: 0:00:25 elapsed; 0 hosts completed (1 up), 1 undergoing Service Scan Service scan Timing: About 28.57% done; ETC: 19:32 (0:00:15 remaining) Stats: 0:00:30 elapsed; 0 hosts completed (1 up), 1 undergoing Service Scan Service scan Timing: About 71.43% done; ETC: 19:32 (0:00:04 remaining) Nmap scan report for 192.168.159.135 Host is up (0.00028s latency). Not shown: 65528 closed tcp ports (reset) PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 3.9p1 (protocol 1.99) | ssh-hostkey: | 1024 8f:3e:8b:1e:58:63:fe:cf:27:a3:18:09:3b:52:cf:72 (RSA1) | 1024 34:6b:45:3d:ba:ce:ca:b2:53:55:ef:1e:43:70:38:36 (DSA) |_ 1024 68:4d:8c:bb:b6:5a:bd:79:71:b8:71:47:ea:00:42:61 (RSA) |_sshv1: Server supports SSHv1 80/tcp open http Apache httpd 2.0.52 ((CentOS)) |_http-title: Site doesn't have a title (text/html; charset=UTF-8). |_http-server-header: Apache/2.0.52 (CentOS) 111/tcp open rpcbind 2 (RPC #100000) | rpcinfo: | program version port/proto service | 100000 2 111/tcp rpcbind | 100000 2 111/udp rpcbind | 100024 1 786/udp status |_ 100024 1 789/tcp status 443/tcp open ssl/http Apache httpd 2.0.52 ((CentOS)) |_http-server-header: Apache/2.0.52 (CentOS) | ssl-cert: Subject: commonName=localhost.localdomain/organizationName=SomeOrganization/stateOrProvinceName=SomeState/countryName=-- | Not valid before: 2009-10-08T00:10:47 |_Not valid after: 2010-10-08T00:10:47 | sslv2: | SSLv2 supported | ciphers: | SSL2_RC4_64_WITH_MD5 | SSL2_RC2_128_CBC_WITH_MD5 | SSL2_RC4_128_EXPORT40_WITH_MD5 | SSL2_DES_64_CBC_WITH_MD5 | SSL2_RC4_128_WITH_MD5 | SSL2_RC2_128_CBC_EXPORT40_WITH_MD5 |_ SSL2_DES_192_EDE3_CBC_WITH_MD5 |_http-title: Site doesn't have a title (text/html; charset=UTF-8). |_ssl-date: 2026-06-29T08:23:47+00:00; -3h08m58s from scanner time. 631/tcp open ipp CUPS 1.1 | http-methods: |_ Potentially risky methods: PUT |_http-server-header: CUPS/1.1 |_http-title: 403 Forbidden 789/tcp open status 1 (RPC #100024) 3306/tcp open mysql MySQL (unauthorized) MAC Address: 00:0C:29:25:CE:9C (VMware) Host script results: |_clock-skew: -3h08m58s Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 33.91 seconds ## 默认脚本去做的版本探测， 现在去访问web页面，发现是一个登陆页面，简单试了一下，应该是有sql注入点的，现在做一个扫描网站目录扫描 ...

信息收集 ip -br a nmap 192.168.159.0/24 -sn -min-rate 2222 -r mkdir nmap_results nmap 192.168.159.134 -p- -min-rate 2222 -r -PN -oA nmap_results/port_scan ##到这就能扫出来一些开放的端口服务 ls nmap_results/ cat nmap_results/port_scan.nmap | grep open ## 方便去做指纹探测 nmap 192.168.159.134 -p 22,80,111,139,443,1024,65529 -sV -sC --version-all -oA nmap_results/server_info ## 服务版本系统扫描 扫出来的结果： Starting Nmap 7.98 ( https://nmap.org ) at 2026-06-16 22:01 +0800 Nmap scan report for 192.168.159.134 Host is up (0.00060s latency). PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 2.9p2 (protocol 1.99) | ssh-hostkey: | 1024 b8:74:6c:db:fd:8b:e6:66:e9:2a:2b:df:5e:6f:64:86 (RSA1) | 1024 8f:8e:5b:81:ed:21:ab:c1:80:e1:57:a3:3c:85:c4:71 (DSA) |_ 1024 ed:4e:a9:4a:06:14:ff:15:14:ce:da:3a:80:db:e2:81 (RSA) |_sshv1: Server supports SSHv1 80/tcp open http Apache httpd 1.3.20 ((Unix) (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b) | http-methods: |_ Potentially risky methods: TRACE |_http-server-header: Apache/1.3.20 (Unix) (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b |_http-title: Test Page for the Apache Web Server on Red Hat Linux 111/tcp open rpcbind 2 (RPC #100000) | rpcinfo: | program version port/proto service | 100000 2 111/tcp rpcbind | 100000 2 111/udp rpcbind | 100024 1 1024/tcp status |_ 100024 1 1024/udp status 139/tcp open netbios-ssn Samba smbd (workgroup: 4MYGROUP) 443/tcp open ssl/https Apache/1.3.20 (Unix) (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b |_ssl-date: 2026-06-16T14:03:23+00:00; +1m52s from scanner time. |_http-title: 400 Bad Request | ssl-cert: Subject: commonName=localhost.localdomain/organizationName=SomeOrganization/stateOrProvinceName=SomeState/countryName=-- | Not valid before: 2009-09-26T09:32:06 |_Not valid after: 2010-09-26T09:32:06 |_http-server-header: Apache/1.3.20 (Unix) (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b | sslv2: | SSLv2 supported | ciphers: | SSL2_RC2_128_CBC_EXPORT40_WITH_MD5 | SSL2_RC4_128_WITH_MD5 | SSL2_RC2_128_CBC_WITH_MD5 | SSL2_DES_192_EDE3_CBC_WITH_MD5 | SSL2_RC4_128_EXPORT40_WITH_MD5 | SSL2_DES_64_CBC_WITH_MD5 |_ SSL2_RC4_64_WITH_MD5 1024/tcp open status 1 (RPC #100024) 65529/tcp closed unknown MAC Address: 00:0C:29:73:A5:97 (VMware) Host script results: |_clock-skew: 1m51s |_nbstat: NetBIOS name: KIOPTRIX, NetBIOS user: <unknown>, NetBIOS MAC: <unknown> (unknown) |_smb2-time: Protocol negotiation failed (SMB2) Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 22.55 seconds 🔥 1️⃣ HTTP（80端口）——最重要入口 Apache 1.3.20 mod_ssl 2.8.4 OpenSSL 0.9.6b ...

csrf（跨站请求伪造） 简单来说就是攻击者通过恶意B网站盗用A网站受信用户的cookie伪造恶意请求发送回A网站，达到一些操作目的 真实原理（CSRF 的逻辑）： 受害者访问恶意网站 ➔ 恶意网站返回一个暗藏杀机的 HTML 表单 ➔ 受害者的浏览器默默执行了这个表单，直接向目标网站发送了一个请求 ➔ 浏览器在发请求时，自动把目标网站的 Cookie 带上了 ➔ 目标网站一看有合法的 Cookie，就执行了操作。 csrf可分为get型，post型 portswigger之csrf通关 无防御措施的 CSRF 漏洞（构建csrf攻击） 这一关一来给了我们一个user登录，进去之后能看到更改邮件地址的功能， 这一关的题意是使用csrf攻击来更改查看者的电子邮件地址并将其上传到漏洞利用服务器的 HTML。 思路：要更改查看者的邮箱地址，我们需要先登录上查看者的账号，但是不知道密码，但是通过抓包发现这个网页的数据包带了cookie，所以可以通过bp的csrfpoc来构造恶意网站，达到能借用cookie更改其邮箱地址的操作 针对csrf常见的防御措施 csrf令牌 CSRF令牌是由服务器端应用程序生成并与客户端共享的唯一、秘密且不可预测的值。当客户端发出执行敏感操作（例如提交表单）的请求时，必须包含正确的CSRF令牌。否则，服务器将拒绝执行请求的操作。 将 CSRF 令牌共享给客户端的常用方法是将其作为隐藏参数包含在 HTML 表单中 csrf令牌验证中的常见缺陷 1.csrf令牌的验证方式取决于请求方法：有些应用程序在使用 POST 方法请求时会正确验证令牌，但使用 GET 方法时会跳过验证。 2.CSRF令牌的验证取决于令牌是否存在：有些应用程序在令牌存在时会正确验证令牌，但如果缺少令牌则会跳过验证。 在这种情况下，攻击者可以移除包含令牌的整个参数（而不仅仅是其值），从而绕过验证并发起 CSRF 攻击： 3.CSRF令牌与用户会话无关：某些应用程序不会验证令牌是否与发出请求的用户属于同一会话。相反，这些应用程序维护一个全局令牌池，其中包含其颁发的所有令牌，并接受池中出现的任何令牌。 在这种情况下，攻击者可以使用自己的帐户登录应用程序，获取有效令牌，然后将该令牌提供给受害用户进行 CSRF 攻击。相当于是去拿一个未使用过的token值取伪造请求 4.csrf令牌与非会话的cookie相关联：服务器把 CSRF 令牌绑定到了一个“单独的 cookie”上，但没有把它绑定到“当前登录会话”上，所以攻击者可以拿自己的 token+cookie 组合，借受害者的登录状态完成操作。 实验：CSRF，其中令牌证取决于请求方法 根据提示，我们发现这个csrf令牌验证在post请求里面必须要通过在能发送请求，但是我们把它切换到get请求，更高csrf令牌发现验证通过了，此时就可以去改邮件地址了， 能成功更改邮箱地址，说明这里是csrf漏洞点， 实验：CSRF，其中令牌验证依赖于令牌是否存在 这一关根据提示，csrf令牌检查，有时候缺少令牌会直接跳过验证，所以删掉csrf令牌参数就能直接绕过 实验：CSRF 攻击，其中令牌与用户会话无关 经过多次抓包实验发现，这个cookie值不变，但是每一次更改地址的token都在变化 所以这里我们需要先去拿一个未使用过的csrf令牌，拿到这个的思路就是去抓包在进入账户的收看response响应里面的csrf令牌 rOZzkjkvAJHL5libEv6lj2qeFxPFDCxf这个就是未使用的 ...