2020再谈跨域

Posted 张京

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了2020再谈跨域相关的知识,希望对你有一定的参考价值。

跨域这个话题已经谈了很多年了,怎么现在又要谈这个问题?本来是可以不必再提了的,但是由于Chrome 86版本以后又增加了很多限制,导致我们不得不再次提起。

CORS

对于前端开发来说,跨域通常有两种方式,一种是在服务端修改nginx配置,在response headers里添加CORS设置,另一种是在本地架设代理。我们先谈第一种。

原本在nginx里添加CORS已经是一种常规操作,简单到无以复加:

    location /somewhere/ {
        if ($request_method = OPTIONS) {
            add_header Access-Control-Allow-Origin "$http_origin";
            add_header Access-Control-Allow-Credentials "true";
            add_header Access-Control-Allow-Methods "GET, POST, OPTIONS";
            add_header Access-Control-Allow-Headers "sitessubid,Authorization,Content-Type,Accept,Origin,User-Agent,DNT,Cache-Control,X-Mx-ReqToken,Keep-Alive,X-Requested-With,If-Modified-Since";
            add_header Content-Length 0;
            add_header Content-Type text/plain;
            return 200;
        }
        if ($request_method = POST) {
            add_header Access-Control-Allow-Origin "$http_origin";
            add_header Access-Control-Allow-Credentials "true";
        }
    }

然后我们只要在每个axios或者fetch请求里添加withCredentials就能自动把对应该服务器的cookies随请求一并发送了。

但问题在Chrome 86版本以后,Chrome强制给从服务端下发的每个cookie都增加了一个缺省的SameSite属性,并且强制把这个属性设置为Lax,从而导致我们的withCredentials不起作用,只要是跨域的情况,cookies连取都取不到,更不要提发送了。在这里我不想再详述SameSite的原理,感兴趣的可以去这里了解。

这就需要我们必须从服务端入手,修改nginx下发cookies时的SameSite属性。

SameSite和secure

修改SameSite又分为两种情况:如果你用的是低版本的nginx,可能还不一定能完全解决问题,目前唯一能修改的变通之道是修改cookiepath,使它后面带上SameSite属性,例如这样:

proxy_cookie_path ~(.*) "$1; SameSite=none";

这里实际修改的是cookie里的path值,但由于附加了;,所以浏览器会认为自;以后的是新属性,所以也会接受这个SameSite设定。

但是仅此还不够,Chrome又要求如果SameSite值为none的话,则还必须设置secure属性,也就是要求所有下发cookie的域名必须使用https协议,所以最终修改的结果是:

proxy_cookie_path ~(.*) "$1; SameSite=none; secure";

但这种情况只能解决类似于cookie是以path结尾的情况,如果上游服务器下发cookie时不止有path,并且在path结尾指定了其它的SameSite,那就无能为力了,因为这么修改path之后cookie会变成:

path=/; SameSite=none; secure; SameSite=Lax

浏览器仍然以最后一个SameSite=Lax为准。目前低版本nginx对这个问题无解。

但如果你是nginx 1.19.3及以上,新增了一个属性,可以更好地解决这个问题:

proxy_cookie_flags one samesite=none;

添加secure标志的方法类似,参考官方文档,不赘述。

localhost的https

由上可知,我们可以通过修改nginx的方法来改造跨域cookies的发送。但这时如果你又不想跨域了,还想用本地代理的方式来解决,又会遇到一个问题:因为我们上面在下发cookies的时候,缺省地给每个cookie都带上了secure属性,这就导致我们在使用本地代理的时候反而无法设置cookies,因为我们本地的开发服务器往往使用的是类似于http://localhost:8080这样的地址,它不是https协议,所以无法设置securecookies,那么怎么办呢?

我们只能动手改造我们的本地服务器,使它也支持https协议:

第一步,我们先生成根证书:

openssl genrsa -des3 -out rootCA.key 2048
openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.pem

这时候我们会得到两个文件,一个是rootCA.key,一个是rootCA.pem

我们把pem文件导入系统的钥匙链,并给予它完全的信任,这样以后再由它签发的证书才能被系统认可,否则即使我们用它签发了证书,浏览器一样会拒绝。

第二步,生成localhost证书:

我们先建立一个名为server.csr.cnf的文件:

[req]
default_bits = 2048
prompt = no
default_md = sha256
distinguished_name = dn

[dn]
C=US
ST=RandomState
L=RandomCity
O=RandomOrganization
OU=RandomOrganizationUnit
emailAddress=hello@example.com
CN = localhost

然后执行以下命令生成server.key文件

openssl req -new -sha256 -nodes -out server.csr -newkey rsa:2048 -keyout server.key -config <( cat server.csr.cnf )

再创建一个v3.ext文件:

authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = localhost

然后执行以下命令生成server.crt文件:

openssl x509 -req -in server.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out server.crt -days 500 -sha256 -extfile v3.ext

好了,到此为止,这个server.keyserver.crt文件就是我们真正需要的两个文件,我们把它们引入系统,不同的系统有不同的引入方法,以下例子是react的方法,建立一个.env文件:

SSL_CRT_FILE=server.crt
SSL_KEY_FILE=server.key
HTTPS=true

这时候再启动你的工程,localhost就带有https协议了。


跨域就是这么麻烦,但不论如何麻烦,我们不辞麻烦,也一定要解决它!

以上是关于2020再谈跨域的主要内容,如果未能解决你的问题,请参考以下文章

浅谈跨域的N种方式

浅谈跨域攻击及预防

跨域问题详解

再谈 XSS 攻击

浅谈跨站请求伪造(CSRF)

跨域访问方法介绍--使用片段识别符传值