Nginx uses "logical AND" to configure origin restrictions and fix CORS cross-domain vulnerabilities

1.Vulnerability Report

• Vulnerability name: CORS cross-domain
• Vulnerability level: medium risk
• Vulnerability proof: Origin can be successfully accessed from any domain name without any restrictions.
• Vulnerability hazards: Due to the existence of the same-origin policy, client scripts from different sources cannot access the resources of the target site. If the target site is not properly configured and there are no strict restrictions on the domain of the request source, any source can be accessed. Regarding the issue of CORS cross-domain vulnerabilities, CORS vulnerabilities are generally used to steal sensitive user data. If the user clicks to trigger a page, the data will be stolen.
• Solution: The fix is ​​to properly configure CORS and determine whether the Origin is legal. Specifically, the request header should not be configured Access-Control-Allow-Originas *or null.

2. Vulnerability recurrence

The way to reproduce is to specify the Origin request header in Header to see if the request can be successful.

curl -H 'Origin:http://aaa.bbb' http://10.14.32.138:80

It was found that the request could indeed be successful and the repair started.

3.Nginx repair

3.1 Add request header

location /myProject/api/ {
    add_header 'Access-Control-Allow-Origin' 'http://10.14.32.138:80' always;
    add_header 'Access-Control-Allow-Credentials' 'false'  always;

    include      proxy_params;
    proxy_pass   http://localhost:8081/;
    access_log   /tmp/httplogs/uat-mobileapi-access.log main;
    error_log    /tmp/httplogs/uat-mobileapi-error.log;
}

After adding it, I submitted it for retest and found that even if the request header configuration is added, it can still be accessed normally when the origin is another domain name.

3.2 Configure origin restrictions

It is further fixed by adding origin restrictions. When accessing from other domain names, a 403 status code will be returned directly.

location /myProject/api/ {
    if ($http_origin !~* "(www.test.com|10.14.32.138)" ) {
        return 403;
    }

    add_header 'Access-Control-Allow-Origin' 'http://10.14.32.138:80' always;
    add_header 'Access-Control-Allow-Credentials' 'false'  always;

    include      proxy_params;
    proxy_pass   http://localhost:8081/;
    access_log   /tmp/httplogs/uat-mobileapi-access.log main;
    error_log    /tmp/httplogs/uat-mobileapi-error.log;
}

After configuration, I found that although cross-domain requests were restricted, requests on the page could not be accessed.

The investigation found that the Origin request header was not passed when making requests on the page, so a 403 status code was also returned.

2.3 Adjust origin restrictions

You need to change the Origin restriction to allow normal access if the Origin is empty.

location /myProject/api/ {
    set $allow_cors 0;
    # 判断不为空
    if ($http_origin) {
        set $allow_cors 1;
    }
    # 判断不在白名单内
    if ($http_origin !~* "(www.test.com|10.14.32.138)" ) {
        set $allow_cors "${allow_cors}1";
    }
    # 判断不为空 且 不在白名单内，返回403
    if ($allow_cors = "11") {
        return 403;
    }

    add_header 'Access-Control-Allow-Origin' 'http://10.14.32.138:80' always;
    add_header 'Access-Control-Allow-Credentials' 'false'  always;

    include      proxy_params;
    proxy_pass   http://localhost:8081/;
    access_log   /tmp/httplogs/uat-mobileapi-access.log main;
    error_log    /tmp/httplogs/uat-mobileapi-error.log;
}

After configuration, the retest passed and the page can be accessed normally.

Finished, finishing with flowers~

Reference address:

1. Nginx configures origin to restrict cross-domain requests (to cope with equal protection), https://blog.csdn.net/qq_20236937/article/details/128640137

2.Nginx: If the header does not exist or is wrong, the request is rejected, https://www.it1352.com/1679888.html

3.NGINX implements AND and OR multiple judgments in IF statements, https://blog.51cto.com/qiangsh/1967549