web安全

朱俊宇
140 阅读7分钟

web安全

CSP

Content Security Policy 内容安全策略 主要目的是为了防止xss攻击,是解决xss的最优解

实质就是白名单制度，开发者明确告诉客户端，哪些外部资源可以加载和执行，等同于提供白名单。它的实现和执行全部由浏览器完成，开发者只需要配置

设置csp的2种方式

1.在响应头中设置 (Ignore X-Frame headers插件可以屏蔽该响应头)

Content-Security-Policy: script-src 'self'; object-src 'none';
style-src cdn.example.org third-party.org; child-src https:

2.设置meta标签

<meta http-equiv="Content-Security-Policy" content="script-src 'self'; object-src 'none'; style-src cdn.example.org third-party.org; child-src https:">
  • 脚本：只信任当前域名
  • <object>标签：不信任任何URL，即不加载任何资源
  • 样式表：只信任cdn.example.org和third-party.org
  • 框架（frame）：必须使用HTTPS协议加载
  • 其他资源：没有限制

CSRF

Cross Site Request Forgery 是一种劫持受信任用户向服务器发送非预期请求的攻击方式

一般是攻击者借助受害者的 Cookie 骗取服务器的信任，在受害者毫不知情的情况下以受害者名义伪造请求发送给受攻击服务器，从而在并未授权的情况下执行在权限保护之下的操作

比如自动提交表单,进行评论等

csrf条件

  1. 目标站点一定要有CSRF漏洞
  2. 用户要登录过目标站点,并且在浏览器上保持有该站点的登录状态
  3. 需要用户打开一个第三方站点,可以是黑客的站点,也可以是一些论坛

csrf防御手段:

  1. 设置cookie的SameSite属性 (samesite还有跟踪分析的作用)

    chrome80以后默认值为Lax,解决办法是set-cookie设为none,开启secure

  2. 在请求头中使用Origin和Referer进行同源检测

    origin在302重定向中不会存在 因为浏览器不想泄漏敏感信息 HTTPS 页面跳转到 HTTP 页面，所有浏览器 Referer 都丢失

  3. 将所有请求都加上验证码
  4. 添加 csrfToken 验证

    把csrfToken放在http请求头中给服务器来验证是不是自己网站的请求 www.cnblogs.com/sablier/p/1…

xss防御(含sql注入)

重要理念：任何用户输入的任何信息，都是不可信的

  1. 用户输入内容做严格长度限制 限制用户输入内容长度，可以减少xss的危害性，长度越短，xss可操作空间越小。
  2. 开启csp(主要手段) Content Security Policy 的规则相对复杂，使用的时候，必须经过严格测试。 csp虽然已经得到较多浏览器支持，但是规则复杂，一不小心把自己的功能给禁用掉了。目前各大型互联网公司在各自服务中应用者少。暂时持观望态度，某些简单场景可以考虑。 Github-csp-journey是先行者之一，但是目前也放弃了该方案。(待准备更规范易用)
  3. 给cookie添加httponly

    httponly主要是为了防止xss攻击,samesite(如果是从第三方站点发起的请求,那么需要浏览器禁止发送某些关键 Cookie数据到服务器)主要是为了防止csrf攻击,csrf token 请求头的origin和refer也可以防止csrf攻击

  4. x-xss-protection 返回html内容的服务器端:http响应头添加x-xss-protection: 1; mode=block 该http头信息已经得到部分浏览器支持，可以对xss做出拦截。
  5. 转码过滤 xss产生的可能性非常多，关键点是要对所有可能存在用户输入的地方做转码过滤。用户输入的地方包括但不限于：重定向、富文本输入、简单输入框、评论框、搜索框、URL地址参数、自定义样式等等。
    1. 服务器防止sql注入攻击转码
    2. 客户端输出文本内容做html标签转义(如url地址参数、评论、搜索等)
    3. 富文本内容做白名单过滤(参考xssjs)

xss总结：

上述几条策略中，没有银弹，xss防护不能一劳永逸。实际项目需要结合上述几条一起使用，减少xss的可能性，每一条都很重要

  1. csrf token csrf防御已经是各大互联网公司的常规操作。建议服务器端接口请求，做csrf token校验。 类似实现方案有：①json web token(非可回放请求) ②某讯的基于cookie的time33 hash token(可回放请求) 引文，仅供学习：segmentfault.com/a/119000001…

cookie

作用

  1. 会话状态管理（如用户登录状态、购物车、游戏分数或其它需要记录的信息）
  2. 个性化设置（如用户自定义设置、主题等）
  3. 浏览器行为跟踪（如跟踪分析用户行为等）

属性

  • HttpOnly document.cookie 不能访问到,只能作用于服务器 能防止xss攻击
  • Secure 只能通过https协议传输
  • SameSite(跨站请求) 必须要启用secure才能设置,也就是不需要用https传输
    1. Strict 仅允许一方请求携带 Cookie，即浏览器将只发送相同站点请求的 Cookie，即当前网页 URL 与请求目标 URL 完全一致。
    2. Lax 允许部分第三方请求携带 Cookie
    3. None 无论是否跨站都会发送 Cookie 之前默认是 None 的，Chrome80 后默认是 Lax

    默认值由None 改成 Lax ,对一些现有业务影响很大:

跨站&跨域

跨站比跨域的条件宽松,跨站一定跨域,跨域不一定跨站

跨域更严格 (协议 主机名 端口名)

跨站 eTLD+1 (有效顶级域名+二级域名)

常见顶级域名 .com、.co.uk、.github.io www.taobao.com 和 www.baidu.com 是跨站，www.a.taobao.com 和 www.b.taobao.com 是同站，a.github.io 和 b.github.io 是跨站(注意是跨站)

其他安全问题

  1. 数据加密传输 除了全站使用https传输外，还应该对于敏感用户数据，如用户名、密码、手机号、短信验证码等做二次加密传输 包括管理端敏感数据传输也需要加密 敏感数据的字段名称不要直接用username、password这种容易理解的单词，建议混淆一下名字(防止代理人机器分析) 。 邮箱、手机号、用户名等做随机秘钥的对称加密。 密码做MD5类非对称加密后在，再做基于随机秘钥的二次对称加密。
  2. HSTS HTTP Strict Transport Security（通常简称为HSTS）是一个安全功能，它告诉浏览器只能通过HTTPS访问当前资源，而不是HTTP。strict-transport-security: max-age=3600
  3. 点击劫持 强烈建议在不允许第三方iframe加载的页面添加http相应头，X-Frame-Options 值为：x-frame-options: SAMEORIGIN 表示只允许同源网站加载。特别是管理后台的网站，一旦发生点击劫持，被骗取管理员用户名，密码，会非常危险。
  4. 第三方库安全 我们在实际开发项目中会或多或少都会用到一些第三方库，建议通过开发工具自动检测能力去发现旧版本的第三方库的安全问题，即时更近修复。

检测工具、服务、安全组织

1、工具篇

  1. www.zaproxy.org/ (owasp官方安全渗透测试工具)
  2. xss脚本
  3. easyXssPayload构造xss的脚本
  4. 开发工具安全插件 该工具提供方为 snyk.io ,可以在常用的开发工具中，自动检测代码安全问题，非常好用，强烈推荐

2、服务篇

  1. webpagetest.org/ (在线网站性能测试及安全扫描，安全扫描为snyk提供)
  2. observatory.mozilla.org (mozilla在线网站安全扫描，功能比较简单，可以快速扫描)

3、安全组织

  1. The Open Web Application Security Project
  2. www.freebuf.com/

参考链接

阮一峰-Content Security Policy 入门教程

阮一峰-Cookie 的 SameSite 属性

samesite属性-冴羽

跨站与跨域

vue3文档-安全

前端安全-美团技术团队

avatar
文章
阅读
粉丝