CloudQuery 安全系列： Http 与 Https

Posted 2021-07-24 CloudQuery

随着当前大数据时代数据量激增，各种应用互联互通上云后Web安全也成了近几年关注的热点，各种扫描、渗透测试、检测围绕在各个web应用周围，随着云趋势的流行网络层的安全保障就显得格外重要。

CloudQuery作为一款基于Web的数据管控工具，安全一直是CloudQuery关注的重点。所以我们就此开了一个关于CloudQuery Web安全的专题来给大家详细介绍我们是如何搭建自己的安全体系的。

But！我们的产品经理说这个系列更新完全看她心情，如果大家反响热烈的话她还能开一个「DTS」系列——是的，CloudQuery要出DTS了！大家有任何想法可以去官网底部找她的邮箱反馈哈哈！

好的，言归正传，本文我们就开启CloudQuery安全系列第一篇，详细介绍Http和Https两大协议。

Http是什么？

我们都知道Http是当前应用最广泛的网络协议，基于它简捷、快速的特性迅速在互联网应用中推广开来。一个Http请求是由一个请求行、多个请求报头，最后跟随一个空的文本行来终止报头列表组成的。同时随着协议的不断发展，目前已经支持到GET、POST、OPTIONS、HEAD、PUT、DELETE、TRACE请求方式，但由于研究调查发现99%的Http请求都是GET类型，所以本文接下来会针对广为应用的GET方法进行重点探讨。Http带来的便利性是毋庸置疑的，有了Http后，用户可以利用一个浏览器来访问不同的应用系统，脱离桌面端限制后用户操作的便利性得到了大幅提升。

Http协议的主要特点可以概括如下：

• 协议简单。整个链路可以概括为：“ 客户端发起请求 ->服务端响应请求 -> 重新发起新请求 ” ，每一次请求都是独立的行为，这也体现了Http无状态的特点。
• 只需浏览器。Http协议完美支持B/S架构，只要有浏览器就可以工作，用户操作简便。甚至从某种意义上说，APP也可以当作某种特定内容的浏览器。
• 灵活性好。无论是数据传输、视频播放都可以灵活使用。非常适合快速迭代的互联网Web应用。

Http的缺陷分析

总结了Http协议的特点后不难发现，Http是未经过任何加密处理的。通过简单的网络抓包就可以获得请求包中的所有内容，再对包中的内容进行分析就可以得到用户的访问行为。从交互角度来分析，Http作为Web应用的基础协议，其特点就是用户请求->服务器响应，在整个过程中服务器始终处于被动响应状态，不会主动获取用户信息。在这种信息交换的环境下，客户端可以随意篡改请求内容，而服务端却必须对客户端提交的请求进行响应，这也就是Http最核心的问题：

• 信息未加密，链路中容易被获取或截断、劫持
• 请求易被模仿、篡改

Https及其认证方式详解

上文中提到了Http的种种缺点，而Https就是为了解决这三大风险而设计的，从严格意义上来说， Https并不是一个独立的协议，而是工作在SSL协议上的Http协议。

SSL是一种为网络通信提供安全以及数据完整性的安全协议，这也是有效保障用户数据安全的措施。而Https的认证流程根据认证次数可以分为单向认证和双向认证。

单向认证的特点在于只有客户端对服务端进行身份验证，服务端只对提交的加密密钥进行识别处理，并不会对客户端的合法性进行验证，这就存在会受到SSL剥离攻击的隐患，例如SSL Strip工具的原理就是劫持用户的请求，并模拟用户来与目标站点建立Https连接，成功连接后利用已经建立的连接的对称密钥解密服务器返回的Https，将其中的Http再发回客户端。这是由于单向认证中服务器并不对客户端的有效性进行检查造成的。

而双向认证主要是增加了服务器对客户端的合法性校验，这样就可以有效避免刚才提到的SSL剥离攻击。客户端发起的请求中会包含SSL参数，从服务端获取证书，再将该证书提交给CA，CA验证该证书的合法性后通知客户端，客户端根据CA的验证结果来确认目标站点的真实性。此处与单向认证存在两处不同：

• 服务端要求客户端的请求中携带证书并接受用户的公钥
• 客户端与服务端互相利用对方的公钥加密来协商可支持的传输类型和密码方案。

客户端从服务端的返回中得到公钥后再利用公钥对自身产生的密钥进行对称加密，再将加密后的密文发送至服务端；服务端利用私钥解密得到数据后进行系统内部业务逻辑处理。

CloudQuery配置Https

CloudQuery平台支持用户便捷、快速接入Https，部署后默认使用Http协议，需要切换Https协议时只需用户布置一个支持Https协议的反向代理服务器即可。接入Https后CloudQuery前端会自动发起Https或wss请求。本章将以教程的形式带领各位配置Https，该配置教程使用本地的证书和域名，实际证书请使用自己申请的证书和域名。

实现方式如下图，nginx Https 代理服务器需要用户自行添加配置。

• 生成证书（如果已经申请到证书可跳过本步）

sudo mkdir /tmp/ssl
# 创建了有效期100年，加密强度为RSA2048的SSL密钥key和X509证书文件。
sudo openssl req -x509 -nodes -days 36500 -newkey rsa:2048 -keyout /tmp/ssl/nginx.key -out /tmp/ssl/nginx.crt
# 执行上面的命令后，需要在Common Name选项中填入域名，示例使用 *.cqcommunity.club

• 创建 nginx 配置文件

touch /tmp/ssl/nginx.conf

• 编辑 /tmp/nginx.conf 文件内容（请将#注释中的替换为实际配置）

worker_processes 1;
events{
worker_connections 1024;
}
http{
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
gzip on;
gzip_min_length 1k;
gzip_comp_level 5;
gzip_types text/plain application/javascript application/x-javascript test/javascript text/css text/xml;
gzip_disable "MSIE [1-6]\\.";
gzip_vary on;
server {
        listen       80;
        server_name  www.cqcommunity.club;
        rewrite ^ https://$http_host$request_uri? permanent;    # force redirect http to https
    #return 301 https://$http_host$request_uri;
    }


server {
        listen 443 ssl;
    charset utf-8;
    ssl_certificate /etc/nginx/ssl/nginx.crt; # 这里填自己的证书
    ssl_certificate_key /etc/nginx/ssl/nginx.key; # 这里填自己的证书
    keepalive_timeout   70;
    server_name www.cqcommunity.club;  # 这里填自己的域名
    server_tokens off;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:HIGH:!aNULL:!MD5:!RC4:!DHE;
    access_log      /var/log/nginx/wiki.xby1993.net.access.log;
    error_log       /var/log/nginx/wiki.xby1993.net.error.log;
    location / {
                proxy_set_header Host $host;
                proxy_set_header Cookie $http_cookie;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_pass http://172.17.0.1:9898;  #这里的地址通过容器访问宿主机的ip ,9898是cloudquery使用的端口
                proxy_set_header X-Forwarded-Proto $scheme;
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "upgrade";
        }
    }
 include servers/*;
}

• 启动&配置 nginx 镜像

# 下载 nginx 镜像
docker pull nginx
# 启动 nginx 并监听 80 和 443 端口
docker run --name cloudquery_https_nginx -p 80:80 -p 443:443 -d nginx
# 容器内部创建文件夹,用来存放证书文件
docker exec -t cloudquery_https_nginx sh -c 'mkdir /etc/nginx/ssl'
# 将刚才生成的证书文件复制到容器内部
docker cp /tmp/ssl/nginx.key cloudquery_https_nginx:/etc/nginx/ssl/
docker cp /tmp/ssl/nginx.crt cloudquery_https_nginx:/etc/nginx/ssl/
docker cp /tmp/ssl/nginx.conf cloudquery_https_nginx:/etc/nginx/ssl/
# 重启容器
docker restart cloudquery_https_nginx

• 修改客户端 hosts

# 如果你使用的备案过的域名,则不必添加这个配置
sudo sh -c "echo '${ip} www.cqcommunity.club' >> /etc/hosts"

至此配置完毕，请尝试浏览器访问 https://www.cqcommunity.club/login 页面。请求结构如图：

从图中我们不难看出部署反向代理器后由客户端（浏览器）在外网环境发起Https请求时会先请求至反向代理服务器，再由该代理服务器转发至内网环境，内网环境下一般不存在请求伪造以及劫持情况，此时以Http协议再向CloudQuery所在服务器进行会话请求。Https方式不仅提高了外网环境下的会话安全性，保证用户数据安全想的同时也在一定程度上保护了服务端，让恶意攻击和伪装数据的成本大大提高。

至此就是本文对Http和Https的介绍，以及Https在CloudQuery中的应用。可以看出，Https重点解决的是传输过程中的安全问题，可以用来保障客户端的传输数据安全，虽然并不会直接提升Web站点的安全性，但在一定程度上解决了传输过程中的截断、泄漏等问题。

下一篇我们从XSS攻击的角度来进行注入攻击的防护，有缘再见。

官网地址：https://cloudquery.club/