Cross-Site Request Forgery (CSRF) Attack Lab网安实验
3.1 Task 1: Observing HTTP Request.
使用F12
打开网络元素,观察发送的GET和POST报文
3.2 Task 2: CSRF Attack using GET Request
在/var/www/CSRF/Attacker/
目录下建立index.html
文件并写入JS的恶意代码。index.html是作为www.csrflabattacker.com
网站服务器默认打开的文件,打开后将默认编译其中代码,通过img的特性自动发送报文。
需要root权限才能修改
我们打开网络抓包,并访问www.csrflabattacker.com
网站,可以看到由该网站向www.csrflabelgg.com
发送了add?friend=43
的报文,43为Boby的Elgg网站账户id号。
可以看到在Alice访问www.csrflabattacker.com
后相当于发送了添加Boby为好友的报文给服务器,与Boby成功成为好友
3.3 Task 3: CSRF Attack using POST Request
使用POST发送报文,需要先将各个参数加入到变量中,参考实验文档的格式
同样登录www.csrflabattacker.com
恶意网站,在执行恶意代码后自动跳转回用户首页,可以发现用户的姓名与简介已经被修改了
Question 1: Boby does not knowAlice’s Elgg password, so he cannot log into Alice’s account to get the information. Please describe how Boby can solve this problem.
Answer 1:由于网站设计者的问题以及实验需要,发送报文不检查该报文是否为有发送该报文权限的用户,Boby只需要获得Alice的账户id即可盗用Alice权限发出修改指令
Question 2: If Boby would like to launch the attack to anybody who visits his malicious web page. In this case, he does not know who is visiting the web page beforehand. Can he still launch the CSRF attack to modify the victim’s Elgg profile? Please explain.
Answer 2: 不能,因为发送修改的报文需要id号(这里是Alice的id=42),如果要攻击其他用户,需要先获取其id并修改攻击的报文
3.4 Task 4: Implementing a countermeasure for Elgg
进入/var/www/CSRF/Elgg/vendor/elgg/elgg/engine/classes/Elgg/
目录内对ActionsService.php
进行修改,找到函数gatekeeper
并注释掉第一行的return true
,之后重复之前的攻击,可以发现攻击失败,Alice的主页没有被修改。
总结
不去管理服务器内部实现,我们只关注于向服务器发送的报文,可以发现简单的参数传递如果没有密钥的参与将会极大降低安全性