重放攻打

  • 攻击者通过某种伎俩获取到申请的报文，并将报文从新发送到浏览器

  • 防备伎俩

    • 无论何时，只容许提交一次报文，每次申请带上一个随机数，当服务器接管到申请时，判断之前是否有收到雷同的申请，有的话则认为是重放，拒绝请求，但这种办法有个毛病，就是是数据库须要记录大量的历史申请（随机数）
    • 一段时间内，只容许解决一次申请，每个报文带上工夫戳，个别申请的达到耗时约60s，所以服务器比照以后工夫，如果距离大于60s，则认为是重放，这个办法的毛病是，客户端和服务器零碎工夫须要放弃同步，并且如果是1分钟内达到的申请是无奈限度重放的
    • 申请增加间断的流水号，每次申请都会减少一，当接管到不间断的流水号时，对应的申请就有重放的嫌疑，这样无需记录大量的随机数，但因为流水号很容易被伪造，所以一遍不必这种形式
    • 个别采纳随机数和工夫戳相结合的形式，60s内达到的申请，比照随机数，如果统一就认为是重放，60s外达到的申请间接认为是重放，且能够革除记录的随机数

  • 除了重放攻打，有可能客户端的疾速点击也会反复发送申请，在服务端能够用下面的办法解决，客户端能够应用节流和防抖限度

    • 防抖，间断反复多个动作，只对最初一个动作响应
    • 节流，一个工夫距离内，只容许一个动作失效

XSS（跨站脚本攻打）

  • XSS攻打的原理就是，利用网页自身的破绽，例如会从网页链接中读取信息，并拼接到html文本中，通过这种形式，向网页植入歹意脚本，泄露用户信息，如能够通过XSS获取用户cookie

  • 攻打模式一：

    • 网页拼接，网页接管输出文本或从链接获取参数后，间接展现在页面上，则攻击者可通过结构<script>标签伪造输出，让页面执行脚本
    • 防备办法，对获取到的输出进行本义，浏览器不会执行本义后的输出

  • 攻打模式二：

    • 页面上某a标签，从链接中会获取参数，拼接到href前面，攻击者通过结构javascript:XXX，因为本义并不会解决"javascript"这种字符串，当点击a标签时，恶意代码被执行
    • 防备办法，页面外部保留一组黑名单，当获取到的参数带有某特定字符串时，回绝应用这个参数

  • xss攻打分类：

    • 贮存型：结构的恶意代码提交到数据库，通过数据库返回给浏览器执行
    • 反射型：拜访的时候就在url上带有恶意代码，服务器读取url参数把他拼接到html上，返回浏览器被执行
    • DOM型：html自身会读取输出或url参数，拼接到html上时执行了恶意代码

  • 防备：

    • 输出过滤，前后端都对承受的参数进行过滤以及本义，但有个毛病，某些失常输出的字符也会被本义导致后续应用或展现时有误
    • 通过dom操作进行前端的渲染，应用innerText（不要应用或审慎应用innerHTML），setAttribute这种api，能够避免恶意代码被拼接，vue的模板机制和react的jsx就是利用的这个办法防止xss，但这种形式仍然无奈防止onload事件的插入，以及利用href的xss
    • 针对href的xss输出，须要留神防止应用.innerHTML、.outerHTML、document.write()以及vue和react的v-html/dangerouslySetInnerHTML

    • CSP（content security policy）

      • 启用CSP能够禁止加载外域代码，或只容许执行受信赖的域名下的代码
      • 禁止提交申请到不受信的服务器
      • 禁止执行内联脚本
      • 上报异样信息以供剖析
    • HTTP-only Cookie：在cookie中设置httponly，则cookie无奈被js脚本获取到
    • 验证码，针对敏感操作，须要验证码能力放行

CSRF（跨站申请伪造）

  • Cross-site request forgery
  • 攻击者诱导用户进入第三方网站，在第三方网址中，通过img或href等标签的src属性，向被攻打网站发送跨站申请，若此时用户曾经获取了被攻打网站的登录受权，跨站申请就有可能带上用户的cookie，从而绕过后盾的验证，导致攻打申请被后盾执行
  • 失常来讲，因为浏览器自身带有同源限度，js无奈间接对不同域名下的资源进行操作，但img或script标签不受同源策略的限度，所以存在CSRF的可能

  • 攻打类型：

    • GET类型，通过src属性发动申请
    • POST类型，须要结构form，进行提交，同时因为form提交会产生页面跳转，个别为了不让用户辨认到提交，会有一个iframe装着
    <form action="http://bank.example/withdraw" method=POST>    <input type="hidden" name="account" value="xiaoming" />    <input type="hidden" name="amount" value="10000" />    <input type="hidden" name="for" value="hacker" /></form><script> document.forms[0].submit(); </script>
    • 链接类型，申请写在a标签的href在中，诱使用户点击，从而发出请求

  • 防备策略：

    • 同源检测：利用申请头的Origin和Referer，能够在meta或csp中设置referer policy，管制申请是否带referer

      • 但referer是有可能被批改的，并不是齐全平安
      • 同时因为SEO（搜索引擎优化）的需要，申请页面（html）的申请是会须要被容许的，如果这个页面自身会触发某些get申请，就很可能被攻打
      • 另外如果，页面自身容许输出评论等，也可能被发动攻打

    • CSRF Token：结构一个攻击者无奈获取的token，在申请时带着这个token拜访服务器，不能放在cookie中，而是作为报文body的一部分

      • 关上页面时，拜访服务器，返回一个token，通过js遍历，把token带在a标签和form标签中，然而这种办法无奈解决由js发动的申请，或后续动静生成的dom元素，针对这两种状况，须要手动增加token，而后服务器承受申请时验证token
      • 通常该token由客户id，随机数以及工夫戳生成，并加密，服务器验证时会比照有效性
      • 然而这种验证须要额定贮存token，对服务器而言是额定的累赘

    • 双重cookie验证：利用无奈跨域获取cookie的限度，在拜访页面时往cookie增加一个csrfcookie的随机数，后续发动申请时，页面获取该cookie，并设置到申请参数里，后续验证，服务器只须要验证cookie中的值和申请里的参数是否统一即可

      • 这种办法无需存储额定的数据，间接比照cookie即可
      • 但前提是不存在xss破绽，不然还是有可能泄露cookie，或者被批改cookie，从而利用伪造的cookie发动申请，造成用户损失

    • samesite cookie：新的提案

      • Set-Cookie: xxx; Samesite=Strict，则该cookie除了从本身网站下发动申请，其余包含新页面关上，或不同域名下的异步申请，都不会带上cookie
      • Set-Cookie: xxx; Samesite=Lax，当这个申请是从本身网站下发动的申请，或者关上了新页面，如从百度关上某个页面，同时他是个get申请，那么容许带上cookie
      • 但这种计划有个毛病，不反对子域，即启用了samesite后，子域无奈应用父域的cookie