When your talent
When you can not afford to hang on ambition
Then you should stop learning
Code audit online learning experiment, while CE are practical operation, while finishing notes later when convenient to look for quick reference.
table of Contents
CSRF vulnerability audit
Summary:
CSRF (Cross-site request forgery) cross-site request forgery, also known as "One Click Attack" or Session Riding, often abbreviated as CSRF or XSRF, is a malicious use of the site. Although it sounds like a cross-site scripting (XSS), but it is very different from XSS, XSS trusted users in the use of the site, while CSRF is disguised by a trusted user's request to use from trusted sites. Compared with XSS attacks, CSRF attacks are often not very popular (and therefore their resources to guard against is quite rare) and difficult to defend, it is considered more dangerous than XSS
Cross-site request attacks, simply put, it is the attacker through some technical means to deceive the user's browser to access a website they have certified and perform some action (such as e-mail, messaging, and even operations such as property transfers and the purchase of goods ). Because the browser has been certified, so the site is accessed think is the real user to perform operations away. This takes advantage of a vulnerability in the web user authentication: simple authentication can only guarantee requests sent from a user's browser, but can not guarantee that the request itself is sent by the user voluntarily
CSRF and XSS difference:
• XSS: XSS Vulnerability - construction payload-- sent to the victims - victims click to open - an attacker to obtain the victim's cookie-- attacker uses cookie complete attack victims
• CSRF: CSRF Vulnerability - construction payload-- sent to the victims - victims click to open - code execution victims - victims of the attack is completed (unknowingly)
CSRF attacks Process:
The figure can be seen, to complete a CSRF attack, the victim must complete two steps in sequence:
-
Login trusted site A, and generates Cookie locally
-
Without exit of A, B visit dangerous websites
Hypothesis: "If I do not satisfy more than one of the two conditions, I would not be CSRF attacks."
Yes, it does, but you can not guarantee that the situation will not occur:
-
You can not guarantee that you log on a web site, the page will not open a tab and visit another site.
-
You can not guarantee that after you close your browser, your local Cookie expire immediately, your last session has ended.
So CSRF is a difficult defense, a great and dangerous loophole
CSRF vulnerabilities examples
When we open or visit a Web site when the browser and server storage site will generate a session (cookies), when the session is not over, you can use your authority to operate the site. However, the attacker is to use this feature, allow victims to trigger the form or structure of our statement, then the purpose of the attacker wants to achieve
File contains the following files adduser.php, catuser.php, index.html, login.php, user.txt, WebB.php
Code below, the value of the variable $ XssReflex acquisition variable (a string value) named input of the get variable transmission mode, and then directly through echo () function output, the middle note is not any user input filter
index.html
-
<!DOCTYPE html>
-
<html>
-
<head>
<meta charset="utf-8">
-
< Title >
CSRF presentation
</ title >
-
</head>
-
<body>
-
<form name="LoginForm" method="post" action="login.php" onSubmit="return InputCheck(this)">
-
<p>
-
<label for="username" class="label">用户名:
</label>
-
<input id="username" name="username" type="text" class="input" />
-
<p/>
-
<p>
-
<label for="password" class="label">密 码:
</label>
-
<input id="password" name="password" type="password" class="input" />
-
<p/>
-
<p>
-
<input type="submit" name="submit" value=" 确 定 " class="left" />
-
</p>
-
</form>
-
</body>
-
</html>
login.php
-
<?php
-
header(
"Content-Type: text/html;charset=utf-8");
-
session_start();
-
$csrf_token = md5(uniqid());
-
$_SESSION[
'csrf_token'] = $csrf_token;
-
-
if($_GET[
'action'] ==
"logout") {
-
unset($_SESSION[
'username']);
-
echo
'logout success! Click here <a href="index.html"> Login </a> '
;
-
exit;
-
}
-
if(!
isset($_POST[
'submit'])){
-
Exit
(
"unauthorized access!"
);
-
}
-
$username = $_POST[
'username'];
-
$password = $_POST[
'password'];
-
if($username ==
'admin' && $password ==
'admin') {
-
$_SESSION[
'username'] = $username;
-
$_SESSION[
'password'] = $password;
-
echo
$ username,
'Welcome! <br /> successful login the following functions: <br /> <a href="adduser.php"> 1. Add a user </a> '
;
-
echo
'<a href="catuser.php"> 2. Check a user </a>'
;
-
echo
'<a href="login.php?action=logout"> 3. Login Logout </a> a'
;
-
-
-
-
}
else {
-
Exit
(
'! Login failed here <a href="index.html"> return </a>'
);
-
}
-
-
?>
adduser.php
-
<?php
-
header(
"Content-Type: text/html;charset=utf-8");
-
session_start();
-
if($_SESSION[
'username'] !=
'admin') {
-
Echo
'Error!'
;
-
header(
"Location:index.html");
-
exit;
-
}
-
-
$log=fopen(
"user.txt",
"a");
-
-
fwrite($log,
'username：ce'.
"\r\n");
-
fwrite($log,
'password：ce'.
"\r\n");
-
echo
'<br />';
-
fclose($log);
-
// echo '<a href="login.php"> Return </a> <br/>';
-
-
-
?>
catuser.php
-
<?php
-
header(
"Content-Type: text/html;charset=utf-8");
-
session_start();
-
if($_SESSION[
'username'] !=
'admin') {
-
Echo
'Error!'
;
-
header(
"Location:index.html");
-
exit;
-
}
-
-
if(file_exists(
"user.txt"))
-
{
-
$read= fopen(
"user.txt",
'r');
-
while(!feof($read))
-
{
-
echo fgets($read).
"</br>";
-
}
-
fclose($read);
-
}
-
-
?>
WebB.php
-
<!DOCTYPE html>
-
<html>
-
<head><meta charset=
"utf-8">
-
<title>Hack</title>
-
</head>
-
<body>
-
<a href=
"http://localhost/csrf/adduser.php">恶意链接</a>
-
</body>
-
</html>
Finally, create an empty user.txt
Consider the difference in principle CSRF attacks and XSS attacks, comparing the learning will be more easily understood.
Analog Site Admin pages, user name, password areadmin
Login success page:
Generally speaking background administrator has to add user functionality, so click Add user after successful login (here for the convenience of presentation, did not allow administrators to customize the account name, password function, but add a default account (ce) and password (ce), after the success of the page does not echo, but actually has been added successfully, we click on "View 2. user" button to see whether to add a default account (ce) and password (ce)
This time next record if we just add the user's web address, regardless of whether the user is which, simply go to this address will be able to add users?
To test this idea, then we click log off (clear cookie information):
Try to add the user's page address before the browser input: localhost/csrf/adduser.phptry to add users directly
But it did not succeed, the page automatically jump to the login page, why?
Because adduser.php page requires authentication session information to perform the operation.
So some people think: "Since we ourselves can not successfully access this page, in the case of whether the administrators are not aware of, to deceive his visit this page it?." Once again, we use the admin user login, and create a new tab. Then continue to visit the Web site administrator to assume that B (may be legitimate sites on different servers), enter the url in new tab
Page B exist above the prior written attacker malicious links, and induce us to click on (such as connections made picture):
Check again when the user has found the background on the user unwittingly added:
这就是一次利用CSRF漏洞添加后台的实例， 只要用户（受害者）点击该链接，就完成了一次CSRF攻击，虽然用户可能本身并没有执行该操作的意图
CSRF 漏洞防御
在服务器端防御CSRF攻击主要有四种策略：
- 验证HTTP Referer 字段
根据HTTP协议，在HTTP头中有一个字段叫Referer，它记录了该HTTP请求的来源地址
在通常情况下，访问一个安全受限页面的请求必须来自于同一个网站
比如某银行的转账是通过用户访问http://bank.test/test?page=10&userID=101&money=10000页面完成，用户必须先登录bank.test，然后通过点击页面上的按钮来触发转账事件
当用户提交请求时，该转账请求的Referer值就会是转账按钮所在页面的URL(本例中，通常是以bank. test域名开头的地址)
而如果攻击者要对银行网站实施CSRF攻击，他只能在自己的网站构造请求，当用户通过攻击者的网站发送请求到银行时，该请求的Referer是指向攻击者的网站。因此，要防御CSRF攻击，银行网站只需要对于每一个转账请求验证其Referer值，如果是以bank. test开头的域名，则说明该请求是来自银行网站自己的请求，是合法的。如果Referer是其他网站的话，就有可能是CSRF攻击，则拒绝该请求
- 在请求地址中添加token并验证
CSRF攻击之所以能够成功，是因为攻击者可以伪造用户的请求，该请求中所有的用户验证信息都存在于Cookie中，因此攻击者可以在不知道这些验证信息的情况下直接利用用户自己的Cookie来通过安全验证
由此可知，抵御CSRF攻击的关键在于：在请求中放入攻击者所不能伪造的信息，并且该信息不存在于Cookie之中
鉴于此，系统开发者可以在HTTP请求中以参数的形式加入一个随机产生的token，并在服务器端建立一个拦截器来验证这个token，如果请求中没有token或者token内容不正确，则认为可能是CSRF攻击而拒绝该请求
- 在HTTP头中自定义属性并验证
自定义属性的方法也是使用token并进行验证，和前一种方法不同的是，这里并不是把token以参数的形式置于HTTP请求之中，而是把它放到HTTP头中自定义的属性里
通过XMLHttpRequest这个类，可以一次性给所有该类请求加上csrftoken这个HTTP头属性，并把token值放入其中。这样解决了前一种方法在请求中加入token的不便，同时，通过这个类请求的地址不会被记录到浏览器的地址栏，也不用担心token会通过Referer泄露到其他网站
- 添加验证码并验证
我不需要自由，只想背着她的梦
一步步向前走，她给的永远不重