@@ -35,41 +35,44 @@ XSS 是实现 CSRF 的诸多途径中的一条,但绝对不是唯一的一条。
3535又叫“跨站请求伪造”。可以这么理解 CSRF 攻击:攻击者盗用了你的身份,以你的
3636名义发送恶意请求。CSRF 能够做的事情包括:以你名义发送邮件,发消息,盗取你的账
3737号,甚至于购买商品,虚拟货币转账......造成的问题包括:个人隐私泄露以及财产安全。
38- 下图简单阐述了 CSRF 攻击的思想:
38+ 下图简单阐述了 CSRF 攻击的思想: < br >
3939![ 03_1_2] ( /data/images/Java应届生面试突击/计算机网络/03_1_2.png )
4040
41- 1 . 用户 C 打开浏览器,访问受信任网站 A,输入用户名和密码请求登录网站 A;
41+ 1 . 用户 C 打开浏览器,访问受信任网站 A,输入用户名和密码请求登录网站 A; < br >
42422.在用户信息通过验证后,网站 A 产生 Cookie 信息并返回给浏览器,此时用户登录网
43- 站 A 成功,可以正常发送请求到网站 A;
44- 3 . 用户未退出网站 A 之前,在同一浏览器中,打开一个 TAB 页访问网站 B;
43+ 站 A 成功,可以正常发送请求到网站 A; < br >
44+ 3 . 用户未退出网站 A 之前,在同一浏览器中,打开一个 TAB 页访问网站 B; < br >
45454 . 网站 B 接收到用户请求后,返回一些攻击性代码,并发出一个请求要求访问第三方
46- 站点 A;
46+ 站点 A; < br >
47475 . 浏览器在接收到这些攻击性代码后,根据网站 B 的请求,在用户不知情的情况下携
4848带 Cookie 信息,向网站 A 发出请求。网站 A 并不知道该请求其实是由 B 发起的,所以会根
49- 据用户 C 的 Cookie 信息以 C 的权限处理该请求,导致来自网站 B 的恶意代码被执行。
49+ 据用户 C 的 Cookie 信息以 C 的权限处理该请求,导致来自网站 B 的恶意代码被执行。 < br >
5050
51- 从上图可以看出,要完成一次 CSRF 攻击,受害者必须依次完成两个步骤:
52- 1 . 登录受信任网站 A,并在本地生成 Cookie。
53- 2 . 在不退出 A 的情况下,访问危险网站 B。
51+ 从上图可以看出,要完成一次 CSRF 攻击,受害者必须依次完成两个步骤: < br >
52+ 1 . 登录受信任网站 A,并在本地生成 Cookie。 < br >
53+ 2 . 在不退出 A 的情况下,访问危险网站 B。 < br >
5454
5555##### 示例:
56- 银行网站 A,它以 GET 请求来完成银行转账的操作,如:
57- http://www.mybank.com/Transfer.php?toBankId=11&money=1000
56+ 银行网站 A,它以 GET 请求来完成银行转账的操作,如: < br >
57+ http://www.mybank.com/Transfer.php?toBankId=11&money=1000 < br >
5858危险网站 B,它里面有一段 HTML 的代码如下:
5959``` html
6060<img src =http://www.mybank.com/Transfer.php?toBankId =11&money =1000 >
6161```
62+ &ensp ;&ensp ;&ensp ;&ensp ;
6263 首先,你登录了银行网站 A,然后访问危险网站 B,噢,这时你会发现你的银行账户
63- 少了 1000 块。
64+ 少了 1000 块。 <br >
65+ &ensp ;&ensp ;&ensp ;&ensp ;
6466 为什么会这样呢?原因是银行网站 A 违反了 HTTP 规范,使用 GET 请求更新资源。
6567在访问危险网站 B 的之前,你已经登录了银行网站 A,而 B 中的<img >以 GET 的方式请求
6668第三方资源(这里的第三方就是指银行网站了,原本这是一个合法的请求,但这里被不法
6769分子利用了),所以你的浏览器会带上你的银行网站 A 的 Cookie 发出 Get 请求,去获取资
6870源“http://www.mybank.com/Transfer.php?toBankId=11&money=1000”,结果银行网站
6971服务器收到请求后,认为这是一个更新资源操作(转账操作),所以就立刻进行转账操作。
72+
7073##### 防御方法:
7174 3.1. CSRF 攻击是有条件的,当用户访问恶意链接时,认证的 cookie 仍然有效,所以
72- 当用户关闭页面时要及时清除认证 cookie。
75+ 当用户关闭页面时要及时清除认证 cookie。 < br >
7376 3.2. 在客户端页面增加伪随机数。在所有 POST 方法提交的数据中提供一个不可预测
7477的参数,比如一个随机数或者一个根据时间计算的 HASH 值,并且在 Cookie 中也同样保
7578存这个参数值(保证 2 者数值的一致)。把这个参数嵌入标签保存在 FORM 表单中,当浏
@@ -79,47 +82,50 @@ http://www.mybank.com/Transfer.php?toBankId=11&money=1000
7982的 POST 请求。
8083``` php
8184<?php
82- //构造加密的 Cookie 信息
83- $value = “DefenseSCRF”;
84- setcookie(”cookie”, $value, time()+3600);
85+ //构造加密的 Cookie 信息
86+ $value = “DefenseSCRF”;
87+ setcookie(”cookie”, $value, time()+3600);
8588?>
89+
8690在表单里增加 Hash 值,以认证这确实是用户发送的请求。
91+
8792<?php
88- $hash = md5($_COOKIE['cookie']);
93+ $hash = md5($_COOKIE['cookie']);
8994?>
95+
9096<form method =”POST” action =”transfer.php” >
91- <input type =”text” name =”toBankId” >
92- <input type =”text” name =”money” >
93- <input type =”hidden” name =”hash” value =” <? =$hash;? >”>
94- <input type =”submit” name =”submit” value =”Submit” >
97+ <input type =”text” name =”toBankId” >
98+ <input type =”text” name =”money” >
99+ <input type =”hidden” name =”hash” value =” <? =$hash;? >”>
100+ <input type =”submit” name =”submit” value =”Submit” >
95101</form >
102+
96103然后在服务器端进行 Hash 值验证
104+
97105<?php
98- if(isset($_POST['check'])) {
99- $hash = md5($_COOKIE['cookie']);
100- if($_POST['check'] == $hash) {
101- doJob();
102- } else {
103- //...
104- }
105- } else {
106- //...
107- }
106+ if(isset($_POST['check'])) {
107+ $hash = md5($_COOKIE['cookie']);
108+ if($_POST['check'] == $hash) {
109+ doJob();
110+ } else {
111+ //...
112+ }
113+ } else {
114+ //...
115+ }
108116?>
117+
109118```
1101193.3.图片验证码
111120
112121##### 4.SQL 注入攻击
113122见《数据库部分》。 <br >
114-
115123&ensp ;&ensp ;&ensp ;&ensp ;
116124 https 怎么做到安全的。https 的实现过程(工作原理)。HTTPS 如何加密, HTTPS 加
117125密算法 SSL。 网络安全协议 SSL 协议及完整交互过程。解释 https (先公私钥加密,再
118126对称加密) 为什么不直接公私钥。MD5 加盐。怎么对传输的数据加密。对称加密和非对称
119127加密( 公钥加密 )。RSA 算法的机制(-> 加密通信连接建立的过程) 。
120128
121-
122-
123129### <a name =" 2 " >2. 怎么确保数据传输过程中的安全性?</a >
124130
125131#### 1.数据加密:
0 commit comments