Web安全-CSRF跨站请求伪造

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
云数据库 RDS MySQL,高可用系列 2核4GB
简介: Web安全-CSRF跨站请求伪造

Tr0e

于 2019-02-05 19:44:54 发布

阅读量1.2k
收藏 8

点赞数
分类专栏: Web安全
版权

Web安全
专栏收录该内容
48 篇文章169 订阅
订阅专栏
概述

攻击场景
GET

POST

由上面可见,对于CSRF来说,POST、GET请求是没有任何区别的,只不过POST请求方式多了一些代码。

Cookie

所以,安全研究人员在测试CSRF漏洞时,一定要考虑浏览器问题,每个浏览器的Cookie机制都不完全相同,像FireFox也可以发送Cookie。

假设 Http://wwwxxser.com/ 存在CSRF漏洞,用户登录后,Cookie存储在本地,当用户使用Chrome访问 Http://www.shuijiao8.com(带有xxer.com的CSRF POC)后,攻击将会成功,但是如果使用IE,则可能会失败,这样就可以看出浏览器Cookie机制的重要性。

漏洞检测
检测CSRF攻击主要分为两种:手工检测和半自动检测。这里并不是说没有全自动的CSRF检测工具,只是全自动CSRF工具的误报率较大,故不再介绍全自动检测工具。

手工检测

POC测试,即Proof of Concept,是业界流行的针对客户具体应用的验证性测试。

半自动检测

BurpSuite实战
下面使用BurpSuite对某站点进行CSRF漏洞的检测验证。来看看被测的站点,为某新闻编辑发布平台(新增->编辑->保存)如下图:

1、使用BurpSuite捕获提交请求:

2、右键选择 Engagement tools – > Generate CSRF PoC,如下图所示;

3、构造、修改该请求提交的参数,生成测试CSRF的HTML页面(POC),然后在浏览器中访问,如下图所示:

(打钩后下次点击在浏览器中测试则默认复制CSRF HTML)

4、点击copy后,直接在浏览器上的地址栏右键粘贴,回车,访问:

5、点击提交请求:
6、最后,重点是查看刚才提交的信息是否成功被修改了或是成功新增了数据。到平台检查是否成功提交,如下图所示:

【小结】信息被修改,或成功新增表单,则说明可以成功伪造请求进行操作,存在CSRF漏洞。若无被修改/新增或在粘贴地址栏回车时页面出现错误,无法提交,则不存在CSRF漏洞。

漏洞预防
在预防CSRF攻击时,不像其他漏洞那样复杂,你只需要在关键部分增加一些小操作就可以防御CSRF攻击。

二次确认

Token认证

浏览器同源策略
【提前声明】同源策略不能作为防范 CSRF 的方法!!!!!但有必要讲一讲。

同源策略是浏览器的一个安全功能,不同源的客户端脚本在没有明确授权的情况下,不能读写对方资源。所以在域名为xyz.com的站点下的JS脚本采用AJAX读取域名为abc.com的站点里面的文件数据是会被拒绝的。

下表给出了相对http://a.xyz.com/dir/page.html同源检测的示例:

同源策略限制了从同一个源(如果两个页面的 协议、端口(如果有指定)和 域名 都相同,则称这两个页面具有相同的源)加载的文档或脚本如何与来自另一个源的资源进行交互,这是一个用于隔离潜在恶意文件的重要安全机制。

关于同源策略的两个认识误区:

如果你说同源策略就是“限制非同源资源的获取”,这不对,最简单的例子是引用图片、css、js 文件等资源的时候就允许跨域。
如果你说同源策略就是“禁止跨域请求”,这也不对,本质上同源策略并不是浏览器会禁止跨域请求,而是在发出跨域请求后浏览器会拦截服务端的响应,浏览器不允许你继续进行JS操作,这也就是为什么同源策略无法防御CSRF攻击(CSRF攻击只要成功发起请求即可)。
那么问题来了!浏览器的同源策略被 CSRF 占了这么大的便宜,那它真的是一无是处吗?不是!同源策略会限制了 cookie 的命名区域,虽然同源请求会自动带上cookies,但是攻击者无论如何还是无法获取 cookie 的内容本身。

HTTP/1.1 200 OK
Date: Sun, 24 Apr 2016 12:43:39 GMT
Server: Apache
Access-Control-Allow-Origin: http://www.acceptmeplease.com
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: application/xml
Content-Length: 423
1
2
3
4
5
6
7
8
受到同源策略的影响,同时我们也可以通过一些方法来达到跨域资源的共享,在返回服务器的信息头部会加上 Access-Control-Allow-Origin,浏览器看到这个字段的值与当前的源匹配,就会解锁跨域限制。

DVWA
【简介】

DVWA是一款渗透测试的演练系统,在圈子里是很出名的。如果你需要入门,并且找不到合适的靶机,那我就推荐你用DVWA。

DVWA(Damn Vulnerable Web Application)是一个用来进行安全脆弱性鉴定的PHP/MySQL Web应用,旨在为安全专业人员测试自己的专业技能和工具提供合法的环境,帮助web开发者更好的理解web应用安全防范的过程。

【DVWA的十大模块】

DVWA共有十个模块,分别是:

(1)Brute Force(暴力(破解))
(2)Command Injection(命令行注入)
(3)CSRF(跨站请求伪造)
(4)File Inclusion(文件包含)
(5)File Upload(文件上传)
(6)Insecure CAPTCHA (不安全的验证码)
(7)SQL Injection(SQL注入)
(8)SQL Injection(Blind)(SQL盲注)
(9)XSS(Reflected)(反射型跨站脚本)
(10)XSS(Stored)(存储型跨站脚本)

需要注意的是,DVWA 1.9的代码分为四种安全别:Low,Medium,High,Impossible。我们可以通过比较四种级别的代码,接触到一些PHP代码审计的内容。

【DVWA的漏洞列表】

DVMA正如他的名字一样是一个包含了很多漏洞的应用系统。DVWA的漏洞包括了OWASP oepen web application security project的web 10大漏洞。DVWA里面具体包括如下这些漏洞:

(1)暴力破解漏洞通过brute force登录页面进入到该漏洞的测试位置。这个漏洞是用来测试暴力破解工具和展示不安全的弱密码。
(2)命令执行漏洞在存在风险的系统上执行命令。
(3)CSRF伪造跨站请求漏洞,允许攻击者去修改应用的管理员密码。
(4)SQL注入,DVWA包括盲注和错误型注入两种SQL注入漏洞类型。
(5)不安全的文件上传漏洞,允许攻击者上传恶意的文件到web服务器上
(6)XSS跨站脚本漏洞,允许攻击者注入他们自己的脚本到web服务器上。DVWA系统里面包含了反射性XSS和存储型XSS两种类型。
(7)文件包含漏洞,允许进行本地文件包含执行和远程文件包含执行。
(8)验证码绕过。

【DVWA的搭建】

1、下载phpStudy http://phpstudy.php.cn/
phpStudy是集成了Apache和MySql的集成环境,下载好安装phpStudy。

2、运行时若显示缺少VC运行库:
32位的VC9:http://www.microsoft.com/zh-CN/download/details.aspx?id=5582
64位的VC9:http://www.microsoft.com/zh-CN/download/details.aspx?id=15336

3、安装好后运行 http://127.0.0.1:8088/ 看是否可以出现“hello word"界面(需要修改默认端口80改为8088)

4、下载DVWA http://www.dvwa.co.uk/ 下载后解压,放到phpStudy的WWW目录之下。

5、配置一下相关文件首先最好先配置一下phpStudy的数据库密码。修改后将DVWA/confing下的config.inc.php.dist修改为config.inc.php,找到其中的把原来的db_password改为刚设置的。

6、修改成功后访问 http://127.0.0.1:8088/DVWA/index.php 然后创建数据库。创建好了若没有问题便会自动跳转至登陆界面,默认账号/密码:admin/password。

参考教程:
(1)https://www.cnblogs.com/ECJTUACM-873284962/p/7784508.html
(2)https://blog.csdn.net/biobby/article/details/81213894
(3)如果遇到无法连接数据库的情况,解决方案:https://blog.csdn.net/qq_41631096/article/details/83301865

CSRF(Cross-site request forgery),跨站请求伪造,简写 CSRF/XSRF。

指利用受害者尚未失效的身份认证信息(cookie、会话等),诱骗其点击恶意链接或者访问包含攻击代码的页面,在受害人不知情的情况下以受害者的身份向(身份认证信息所对应的)服务器发送请求,从而完成非法操作(如转账、改密等)。

LOW
首先我们把安全级别设置为Low级别,然后服务器端源代码如下:

<?php
if( isset( $_GET[ 'Change' ] ) ) {
// Get input
$pass_new = $_GET[ 'password_new' ];
$pass_conf = $_GET[ 'password_conf' ];

 // Do the passwords match? 
 if( $pass_new == $pass_conf ) { 
     // They do! 
     $pass_new = ((isset($GLOBALS["___mysqli_ston"]) && is_object($GLOBALS["___mysqli_ston"])) ? mysqli_real_escape_string($GLOBALS["___mysqli_ston"],  $pass_new ) : ((trigger_error("[MySQLConverterToo] Fix the mysql_escape_string() call! This code does not work.", E_USER_ERROR)) ? "" : "")); 
     $pass_new = md5( $pass_new ); 

     // Update the database 
     $insert = "UPDATE `users` SET password = '$pass_new' WHERE user = '" . dvwaCurrentUser() . "';"; 
     $result = mysqli_query($GLOBALS["___mysqli_ston"],  $insert ) or die( '<pre>' . ((is_object($GLOBALS["___mysqli_ston"])) ? mysqli_error($GLOBALS["___mysqli_ston"]) : (($___mysqli_res = mysqli_connect_error()) ? $___mysqli_res : false)) . '</pre>' ); 

     // Feedback for the user 
    echo "<pre>Password Changed.</pre>"; 
} 
else { 
    // Issue with passwords matching 
    echo "<pre>Passwords did not match.</pre>"; 
} 

((is_null($___mysqli_res = mysqli_close($GLOBALS["___mysqli_ston"]))) ? false : $___mysqli_res); 

}
?>

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
附:以上代码的查看方式为:在DVWA的安装目录下打开相应的网页资源文件。

从系统源码可以看到,服务器收到修改密码的请求后,会检查参数password_new与password_conf是否相同,如果相同,就会修改密码,并没有任何的防CSRF机制。即:

DVWA系统的Low级别的CSRF漏洞,无需确认原始密码,只需要用户在cookie还有效的时间内在相同的浏览器访问我们给定的URL,就可以实现CSRF攻击,修改用户密码,所以这里存在CSRF漏洞。

【漏洞利用】

注意:成功修改密码后,URL发生了变化。
【低级攻击】

所以,我们可以直接通过构造链接,诱导用户点击以下链接即可实现密码更改:

http://127.0.0.1:8088/DVWA/vulnerabilities/csrf/?password_new=123456&password_conf=123456&Change=Change#

但是这样很拙劣……一眼就可以看出来,而且会跳转到提示密码更改成功的页面。在做渗透测试的时候可以用,但是实际的攻击中一般情况下是不会攻击成功的。

【进阶攻击】

那么咱们怎样才能诱导用户点击这个URL呢?我们已经可以预测所有参数,现在需要去构造请求。生成 text.html 文件(编写POC文件),搭建在攻击者的服务器上(127.0.0.1):


404 ERROR!


Files Not Found.


1
2
3
4
5
6
7
存储位置为:D:\SoftWare\PhpStudy\PHPTutorial\WWW\DVWA\vulnerabilities\csrf

然后访问诱骗用户点击这个页面的链接(http://127.0.0.1:8088/DVWA/vulnerabilities/csrf/test.html):
用户会看到一个类似404的错误页面,但是用户却不知道自己的密码已经悄悄被人修改了!!!

Medium
首先我们把安全级别设置为Medium级别。查看服务器端源代码:

<?php
if( isset( $_GET[ 'Change' ] ) ) {
// Checks to see where the request came from
if( stripos( $_SERVER[ 'HTTP_REFERER' ] ,$_SERVER[ 'SERVER_NAME' ]) !== false ) {
// Get input
$pass_new = $_GET[ 'password_new' ];
$pass_conf = $_GET[ 'password_conf' ];
// Do the passwords match?
if( $pass_new == $pass_conf ) {
// They do!
$pass_new = ((isset($GLOBALS["_mysqli_ston"]) && isobject($GLOBALS["mysqli_ston"])) ? mysqli_real_escape_string($GLOBALS["_mysqli_ston"], $pass_new ) : ((trigger_error("[MySQLConverterToo] Fix the mysql_escape_string() call! This code does not work.", E_USER_ERROR)) ? "" : ""));
$pass_new = md5( $pass_new );
// Update the database
$insert = "UPDATE users SET password = '$pass_new' WHERE user = '" . dvwaCurrentUser() . "';";
$result = mysqliquery($GLOBALS["
mysqli_ston"], $insert ) or die( '

' . ((is_object($GLOBALS["_mysqli_ston"])) ? mysqlierror($GLOBALS["mysqli_ston"]) : (($_mysqli_res = mysqli_connecterror()) ? $mysqli_res : false)) . '
' );
// Feedback for the user
echo "
Password Changed.
";
}
else {
// Issue with passwords matching
echo "
Passwords did not match.
";
}
}
else {
// Didn't come from a trusted source
echo "
That request didn't look correct.
";
}
((is_null($ _mysqli_res = mysqliclose($GLOBALS["mysqli_ston"]))) ? false : $___mysqli_res);
}

?>

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
通过对源代码进行分析,我们可以知道Medium端主要的防御措施是通过if( eregi( $_SERVER[ 'SERVER_NAME' ], $_SERVER[ 'HTTP_REFERER' ] ) )的ersgi( )函数来检查 HTTP_REFERER(http包头的Referer参数的值,表示来源地址)中是否包含SERVER_NAME(http包头的Host参数,及要访问的主机名,这里是127.0.0.1:8088),希望通过这种机制抵御CSRF攻击。

由于我们前面构造的网页(test.html)就是在本机上,所以其Referer中就已经包含了DVWA平台的主机号。那如果是在另外的地方搭建的网页,我们也可以进行绕过,比如我们可以将构造的文件的名字更改为对方主机名即可,比如127.0.0.1:8088.html。

High
我们同样以正常用户的操作先进行一遍操作,发现密码修改后,URL中新增了一个参数即user_token参数:

http://127.0.0.1:8088/DVWA/vulnerabilities/csrf/?password_new=password&password_conf=password&Change=Change&user_token=7abdd97210f40fbf763ffee206c26b9b#

我们来看下服务器端源代码:

<?php

if( isset( $_GET[ 'Change' ] ) ) {
// Check Anti-CSRF token
checkToken( $_REQUEST[ 'user_token' ], $_SESSION[ 'session_token' ], 'index.php' );

// Get input
$pass_new  = $_GET[ 'password_new' ];
$pass_conf = $_GET[ 'password_conf' ];

// Do the passwords match?
if( $pass_new == $pass_conf ) {
    // They do!
    $pass_new = ((isset($GLOBALS["___mysqli_ston"]) && is_object($GLOBALS["___mysqli_ston"])) ? mysqli_real_escape_string($GLOBALS["___mysqli_ston"],  $pass_new ) : ((trigger_error("[MySQLConverterToo] Fix the mysql_escape_string() call! This code does not work.", E_USER_ERROR)) ? "" : ""));
    $pass_new = md5( $pass_new );

    // Update the database
    $insert = "UPDATE `users` SET password = '$pass_new' WHERE user = '" . dvwaCurrentUser() . "';";
    $result = mysqli_query($GLOBALS["___mysqli_ston"],  $insert ) or die( '<pre>' . ((is_object($GLOBALS["___mysqli_ston"])) ? mysqli_error($GLOBALS["___mysqli_ston"]) : (($___mysqli_res = mysqli_connect_error()) ? $___mysqli_res : false)) . '</pre>' );

    // Feedback for the user
    $html .= "<pre>Password Changed.</pre>";
}
else {
    // Issue with passwords matching
    $html .= "<pre>Passwords did not match.</pre>";
}

((is_null($___mysqli_res = mysqli_close($GLOBALS["___mysqli_ston"]))) ? false : $___mysqli_res);

}

// Generate Anti-CSRF token
generateSessionToken();

?>

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
通过源代码分析我们可以看到:

该模块中加入了Anti-CSRF token来防范CSRF攻击,同时每次随机生成了一个token,当用户提交的时候,在服务器端比对一下token值是否正确,不正确就丢弃掉,正确就验证通过。

【漏洞利用】

这个安全等级,自己主要是利用了DVWA的XSS漏洞和CSRF漏洞共同完成的:

(1)我们找到DVWA的XSS模块,通过XSS漏洞获取浏览器cookie:

(2)返回DVWA的CSRF模块,向输入框中输入任意你想要修改的密码,通过BrupSuite进行拦截,获取数据包并把数据包发送到Repeater模块:
(3)把通过XSS漏洞获取的cookie直接粘贴到这个数据包中,通过brupSuite对数据包进行篡改,发送,修改密码:
至此,密码更改成功!

Impossible
把安全级别设置为Impossible级别。查看源代码:

<?php

if( isset( $_GET[ 'Change' ] ) ) {
// Check Anti-CSRF token
checkToken( $_REQUEST[ 'user_token' ], $_SESSION[ 'session_token' ], 'index.php' );

// Get input
$pass_curr = $_GET[ 'password_current' ];
$pass_new  = $_GET[ 'password_new' ];
$pass_conf = $_GET[ 'password_conf' ];

// Sanitise current password input
$pass_curr = stripslashes( $pass_curr );
$pass_curr = ((isset($GLOBALS["___mysqli_ston"]) && is_object($GLOBALS["___mysqli_ston"])) ? mysqli_real_escape_string($GLOBALS["___mysqli_ston"],  $pass_curr ) : ((trigger_error("[MySQLConverterToo] Fix the mysql_escape_string() call! This code does not work.", E_USER_ERROR)) ? "" : ""));
$pass_curr = md5( $pass_curr );

// Check that the current password is correct
$data = $db->prepare( 'SELECT password FROM users WHERE user = (:user) AND password = (:password) LIMIT 1;' );
$data->bindParam( ':user', dvwaCurrentUser(), PDO::PARAM_STR );
$data->bindParam( ':password', $pass_curr, PDO::PARAM_STR );
$data->execute();

// Do both new passwords match and does the current password match the user?
if( ( $pass_new == $pass_conf ) && ( $data->rowCount() == 1 ) ) {
    // It does!
    $pass_new = stripslashes( $pass_new );
    $pass_new = ((isset($GLOBALS["___mysqli_ston"]) && is_object($GLOBALS["___mysqli_ston"])) ? mysqli_real_escape_string($GLOBALS["___mysqli_ston"],  $pass_new ) : ((trigger_error("[MySQLConverterToo] Fix the mysql_escape_string() call! This code does not work.", E_USER_ERROR)) ? "" : ""));
    $pass_new = md5( $pass_new );

    // Update database with new password
    $data = $db->prepare( 'UPDATE users SET password = (:password) WHERE user = (:user);' );
    $data->bindParam( ':password', $pass_new, PDO::PARAM_STR );
    $data->bindParam( ':user', dvwaCurrentUser(), PDO::PARAM_STR );
    $data->execute();

    // Feedback for the user
    $html .= "<pre>Password Changed.</pre>";
}
else {
    // Issue with passwords matching
    $html .= "<pre>Passwords did not match or current password incorrect.</pre>";
}

}

// Generate Anti-CSRF token
generateSessionToken();

?>

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
通过源代码分析我们可以看到:Impossiable端代码添加了一个输入原来密码的操作,这样我们一开始不知道密码的情况下是不可能修改密码的,所以有效的防御了CSRF攻击。
————————————————

                        版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。

原文链接:https://blog.csdn.net/weixin_39190897/article/details/86766298

相关实践学习
如何在云端创建MySQL数据库
开始实验后,系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助 &nbsp; &nbsp; 相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
相关文章
|
17天前
|
前端开发 开发者
WEB自定义页面请求响应
Web组件支持在应用拦截到页面请求后自定义响应请求能力。开发者通过onInterceptRequest()接口来实现自定义资源请求响应 。自定义请求能力可以用于开发者自定义Web页面响应、自定义文件资源响应等场景。
22 0
|
3月前
|
Web App开发 安全 JavaScript
【Azure 应用服务】App Service 通过配置web.config来添加请求返回的响应头(Response Header)
【Azure 应用服务】App Service 通过配置web.config来添加请求返回的响应头(Response Header)
|
3月前
|
缓存 运维 网络协议
一台新PC进行Web页面请求的历程:技术深度剖析
【8月更文挑战第24天】在当今数字化时代,当我们轻轻点击浏览器上的一个链接,背后其实经历了一场复杂而精妙的交互过程。本文将带您深入探索,从一台全新PC的角度出发,揭秘Web页面请求的全过程,展现这背后隐藏的技术奥秘。
33 0
|
3月前
|
API
【Azure API 管理】在 Azure API 管理中使用 OAuth 2.0 授权和 Azure AD 保护 Web API 后端,在请求中携带Token访问后报401的错误
【Azure API 管理】在 Azure API 管理中使用 OAuth 2.0 授权和 Azure AD 保护 Web API 后端,在请求中携带Token访问后报401的错误
|
6月前
|
JavaScript 安全 前端开发
js开发:请解释什么是XSS攻击和CSRF攻击,并说明如何防范这些攻击。
XSS和CSRF是两种常见的Web安全威胁。XSS攻击通过注入恶意脚本盗取用户信息或控制账户,防范措施包括输入验证、内容编码、HTTPOnly Cookie和CSP。CSRF攻击则诱使用户执行未经授权操作,防范手段有CSRF Tokens、双重验证、Referer检查和SameSite Cookie属性。开发者应采取这些防御措施并定期进行安全审计以增强应用安全性。
124 0
|
6月前
|
缓存 安全 JavaScript
前端安全:Vue应用中防范XSS和CSRF攻击
【4月更文挑战第23天】本文探讨了在Vue应用中防范XSS和CSRF攻击的重要性。XSS攻击通过注入恶意脚本威胁用户数据,而CSRF则利用用户身份发起非授权请求。防范措施包括:对输入内容转义、使用CSP、选择安全的库;采用Anti-CSRF令牌、同源策略和POST请求对抗CSRF;并实施代码审查、更新依赖及教育团队成员。通过这些实践,可提升Vue应用的安全性,抵御潜在攻击。
929 0
|
6天前
|
存储 Web App开发 安全
如何防范 CSRF 攻击
CSRF(跨站请求伪造)攻击是一种常见的安全威胁。防范措施包括:使用Anti-CSRF Token、检查HTTP Referer、限制Cookie作用域、采用双重提交Cookie机制等,确保请求的合法性与安全性。
|
6天前
|
网络安全 数据安全/隐私保护
什么是 CSRF 攻击
CSRF(跨站请求伪造)攻击是指攻击者诱导用户点击恶意链接或提交表单,利用用户已登录的身份在目标网站上执行非授权操作,如转账、修改密码等。这种攻击通常通过嵌入恶意代码或链接实现。
|
14天前
|
安全 前端开发 Java
Web安全进阶:XSS与CSRF攻击防御策略深度解析
【10月更文挑战第26天】Web安全是现代软件开发的重要领域,本文深入探讨了XSS和CSRF两种常见攻击的原理及防御策略。针对XSS,介绍了输入验证与转义、使用CSP、WAF、HTTP-only Cookie和代码审查等方法。对于CSRF,提出了启用CSRF保护、设置CSRF Token、使用HTTPS、二次验证和用户教育等措施。通过这些策略,开发者可以构建更安全的Web应用。
49 4
|
13天前
|
安全 Go PHP
Web安全进阶:XSS与CSRF攻击防御策略深度解析
【10月更文挑战第27天】本文深入解析了Web安全中的XSS和CSRF攻击防御策略。针对XSS,介绍了输入验证与净化、内容安全策略(CSP)和HTTP头部安全配置;针对CSRF,提出了使用CSRF令牌、验证HTTP请求头、限制同源策略和双重提交Cookie等方法,帮助开发者有效保护网站和用户数据安全。
41 2

热门文章

最新文章