1.web页面安全

同源策略

web是放开的

默认支持跨网站访问资源，不区分协议，域名 ，端口

• cdn
• 图片资源

同源

• 协议、域名和端口都一样
• 二级域名 也算是域名不一样

同源策略

不同源之间的限制策略

1. dom
   • 通过window.open 或 a标签打开 同源页面才可以互相访问，不同源禁止
   • 解决：可以通过postmessage解决通讯问题
2. web数据
   • cookie indexDB localstorage 在不同源不能互相访问
3. 网络
   • 页面中默认支持引入第三方资源
     • 使用 CSP 服务端决定客户端能否加载哪些资源
   • 限制跨域发起第三方网络请求
     • 使用配置 跨域资源共享（CORS）解决

跨站脚本攻击XSS

cross site Scripting

行为

• 可以窃取用户信息
  • cookie
  • localstorage
• 监听用户行为
  • addListenter
• 通过修改dom伪造 登录窗口 获取用户密码信息
• 生产垃圾浮动广告

恶意脚本注入

1. 存储型
   • 论坛留言 输入带 脚本内容到服务器2.用户访问服务器，页面显示内容是自动加载的注入了 script内容3.script 就可以上传用户当前的一些cookie信息到 黑客的服务器
   • 乌云网2015年bug
2. 反射型
   • 通过url 参数 query 输入，？param=''2. 服务器把解析的param也输出到了页面3. param注入的script 代码就会可以上传用户信息到他的服务器
3. DOM型
   • 用户通过wifi 或者网线访问页面时2.黑客网络劫持，wifi路由劫持，修改了html的内容3.用户访问页面已经是修改过的 包含自动上传用户信息到黑客服务器

解决方案

• 关键字处理
  • 替换为空字符
  • 转码为 <script&gt
• CSP
  • 限制下载第三方资源，防止下载了黑客的恶意脚本
  • 限制客户端不能发起第三方请求，杜绝了访问和上传用户信息给黑客服务器 禁止内联脚本
  • 提供上报机制提醒运维同事及时修复
• httpOnly
  • 设置了 httpOnly后 cookie只能使用在http上，客户端无权是用 document.cookie访问
• 其他
  • 身份确认
    • 手机 验证码
  • 表单优化
    • 输入长度限制

跨站请求伪造 CSRF

cross site request forgery

Gmail 漏洞，

1. 通过用户已经登录的gmail
2. 黑客给一个修改邮件自动转发的连接给用户
3. 用户点击后，由于已经登录的gmail，恶意连接发起get请求 并调用了自动转发邮件到自己邮箱
4. 黑客就可以在gamil登陆页面通过 对用户走忘记密码流程，忘记密码的验证信息会同时发送给用户和攻击者，从而实现盗号

核心思想

引诱用户访问黑客的网站，利用用户已经登录的状态，做非法请求

攻击方式

自动get请求

• 用户访问黑客的在自己服务器写好一个攻击的页面2.通过图片 src 方式 引入url 浏览器会自动加载执行，url直接使用 get接口里把对应的恶意参数放到url里
• 通过标签就可以触发
  • 通过美女图的方式诱惑用户点击
  • 优势：不用维护黑客服务器和代码，单纯直接调用接口
• 缺点：url明文 可能会被识破，不过可以通过转义掩盖

自动post请求

• 用户访问，黑客的在自己服务器写好一个攻击的页面，加载页面会主动发起提交表单的逻辑
• 缺点： 需要维护服务器和写代码页面，同时UI表单代码需要做隐藏处理

特点

不需要注入代码到目标服务器，仅仅是利用服务器的网络和接口的漏洞，加上用户状态进行攻击

解决方案

Cookie的SameSite

setCookie xxx; xxx; SameSite=none

3个状态

• Stirct
  • 最严格，只有同源才会带上cookie
• Lax
  • 从用户网站标签打开黑客网站 会带上cookie
  • 从用户网站 表单通过get 请求，会带上cookie
  • 其他 post 或 img iframe 都会不带cookie
• None
  • 不做限制
    • 前提是设置了Secure 即使用https传输
    • SameSite=None; Secure

服务器验证来源的站点

判断Referer字段是否和服务器一致

从A打开B?sessionId=xx，B上面会带有 Referer：A的信息

• Referer Policy
  • 由于A会在url上带上sessionId=xx 容易暴露安全信息 给黑客
  • 分类 多个组合
    • no-referrer 不显示
    • origin 原始地址 只有协议+域名+端口
    • cross 跨域情况
    • strict 不支持降级
    • downgrade 降级
    • no-referrer-when-downgrade 默认 + 发生降级不显示

判断Origin

只包含协议 域名 和端口 比较安全

业务 token

在对应的业务代码里面 加入临时生成的token，黑客服务器模拟的页面没有设置token，所以发起请求 会被服务器拒绝

其他

• X-XSS-Protection
• X-Frame-Options
• X-Content-Type-Options

2.系统安全

单进程浏览器缺点

缓冲区溢出

两个内核

• 浏览器内核
  • 浏览器主进程
  • 网络进程
  • GPU进程
  • 包含cookie localstorage 下载 网络请求，都是固定逻辑，相对安全
• 渲染内核
  • 渲染进程
  • 包含 html css js 解析 与 执行 ，恶意代码容易写入，存在漏洞
  • 需要使用安全沙箱隔离
• 内核之间通过IPC通讯

安全沙箱

• 在沙箱里无法访问或操作系统数据
• 安全沙箱最小单位是 进程
• 浏览器默认认为 网络请求的资源都是不安全的前提
• 渲染进程执行js 都会封闭在安全沙箱，如果要访问更高权限，需要通过IPC通知 浏览器内核处理
• 包含的操作
  • 持久化
  • 网络请求
  • 用户交互
    1. 系统一般通过窗口句柄绘图，渲染进程把渲染图片发送给浏览器内核再显示到屏幕
    2. 系统输入时间发送给浏览器内核，内核根据调度情况再依次执行

站点隔离

• 相同的协议+ 根域名 放在同一个渲染进程
• 早期以一个页签一个进程，缺点：当内嵌iframe，iframe里的域名就可以和当前共用同一个进程
• 处理器架构A级漏洞
  • spectre幽灵
  • meltdown熔毁
  • 这两个漏洞黑客可以直接入侵到进程内部，所以所有的进程应该互相隔离

3.网络安全

http不安全

• 明文
• 篡改
• 伪造

https

是在http和tcp之间进入的ssl/tls安全层 进行加解密

对称加密

1. 浏览器请求 解密套件列表+ 客户端随机数
2. 服务端接收 并返回支持的加密套件+服务端随机数
3. 客户端 根据加密套件 + 客户端随机数 + 服务端随机数 生成秘钥进行加密
4. 服务端 根据加密套件 + 客户端随机数 + 服务端随机数 生成秘钥进行解密

缺点: 客户端和服务端随机数都是明文的

非对称加密

• A秘钥加密，只能B秘钥解密
• B秘钥加密，只能A秘钥解密
• 加密的叫公钥
• 解密的叫私钥
• 流程
  1. 浏览器发送加密套件列表 给服务器
  2. 服务选择加密套件，返回 加密套件+公钥给客户端
  3. 客户端公钥加密发送数据
  4. 服务器通过私钥进行解密
• 缺点
  • 非对称执行效率低
  • 无法确认服务端的身份

对称加密+非对称加密

核心：使用非对称加密传输秘钥，对称加密传输数据

1. 客户端发送 对称加密套件列表 + 非对称加密列表 + 客户端随机数
2. 服务端 记录客户端随机数， 选择 对称加密套件+非对称加密套件+ 生成服务端随机数 + 公钥 返回
3. 浏览器保存 公钥，使用公钥对 合并随机数 （服务器随机数+ 客户端随机数 ）进行加密 生成 premaster
4. 服务端 使用私钥对 加密后的合并随机数 进行解密，解密成功，返回解密成功信息
5. 客户端 比较服务端解密后的信息，和自己原来的合并随机数是否一致，一致则确认身份
6. 客户端 使用 合成随机数+加密后合成随机数 进行对称加密 发送服务器
7. 服务端 使用 合成随机数+加密后合成随机数 进行对称解密

对称加密+非对称加密+ 数字证书

• 在对称加密+非对称加密的解决方案中，把返回公钥改成 数字证书
• 通过数字证书确保服务器的身份

CA

定义

• Certificate Authority
• 服务器被黑客入侵后，可以把dns绑定ip转到自己的服务器
• CA可以通过权威机构颁发证书，确认当前服务器是否靠谱

数字证书 Digital Certificate

• 组织信息
• 有效时间
• 证书序列号
• 公钥
• CA信息
• 签名
  1. CA使用Hash函数对明文信息生成摘要
  2. CA使用私钥对信息摘要加密

浏览器验证数字证书过程

1. 先验证证书有效期
2. 验证是否被吊销
3. 是否合法CA颁发
   1. 浏览器接受到 服务器数字证书 和 CA的数字证书
      • 有些服务器没有保存CA数字证书，需要自己另外去下载CA
      • 会拖慢首次打开的请求速度
   2. 使用CA的Hash对明文信息生成摘要
   3. 利用CA的公钥 对签名进行解密
   4. 判断解密的摘要和自己生成的摘要是否一致，一样证明有效

数字证书申请过程

1. 申请服务器提交 自己公钥+ 基本信息
2. 审核
3. hash生成信息摘要
4. CA服务器用私钥加密
5. 生成数字签名
6. 数字签名+服务器基本信息 + 申请服务器公钥 = 数字证书

CA的上级CA如何确认身份

数字证书链

• 根 CA(Root CAs)
• 中间CA(Intermediates CAs)
  • 中间CA可以包含多个其他中间CA
• 依次从当前往上验证到根证书
• 通过WebTrust 认证可以是根CA ，并且会内置在个大操作系统中