docker配置，案例复现

最新推荐文章于 2024-07-19 17:35:15 发布

二氧化蛙

最新推荐文章于 2024-07-19 17:35:15 发布

阅读量89

点赞数

文章标签： docker eureka 容器

本文链接：https://blog.csdn.net/m0_66022305/article/details/132233355

版权

一、docker的安装

1）更新系统软件包：

yum update

2）安装 Docker 的依赖软件包：

yum install -y yum-utils device-mapper-persistent-data lvm2

3）添加 Docker 的官方存储库：

yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo

4）安装 Docker 社区版：

yum install -y docker-ce

5）启动 Docker 服务：

systemctl start docker

6）运行 docker version，查看docker ce是否安装成功：

docker -v

7）查看状态，active为running则启动成功：

systemctl status docker

二、nginx配置漏洞

`1、$uri`导致的CRLF注入漏洞

下面两种情景十分常见：

用户访问http://example.com/aabbcc，自动跳转到https://example.com/aabbcc
用户访问http://example.com/aabbcc，自动跳转到http://www.example.com/aabbcc

第二个场景主要是为了统一用户访问的域名，更加有益于SEO优化。

在跳转的过程中，我们需要保证用户访问的页面不变，所以需要从Nginx获取用户请求的文件路径。查看Nginx文档，可以发现有三个表示uri的变量：

$uri
$document_uri
$request_uri

解释一下，1和2表示的是解码以后的请求路径，不带参数；3表示的是完整的URI（没有解码）。那么，如果运维配置了下列的代码：

location / {
    return 302 https://$host$request_uri;
}

因为$uri是解码以后的请求路径，所以可能就会包含换行符，也就造成了一个CRLF注入漏洞。

这个CRLF注入漏洞可以导致会话固定漏洞、设置Cookie引发的CSRF漏洞或者XSS漏洞。

其中，我们通过注入两个\r\n即可控制HTTP体进行XSS，但因为浏览器认为这是一个301跳转，所以并不会显示我们注入的内容。

当我们正常访问时，nginx重定向后，会在http响应头中出现Location字段

当我们访问ip/%0d%0atest时,响应头会出现test。%0d%0a即 \r\n，也就是换行符，所以在url中加入一个换行符即可将恶意数据写入http响应头。

同理加两个换行符可以将数据写入响应体，例如访问 ip/%0d%0a%0d%0a<script>alert(1)</script>后响应体如下图所示，通过这种注入可实现xss攻击。

<?php
header("Content-Security-Policy: frame-src http://localhost:8081/");
?>

<iframe src="http://localhost:8081/?path=http://www.baidu.com/%0a%0dX-XSS-Protection:0%0a%0d%0a%0d<script>alert(location.href)</script>"></iframe>

如何修复这个CRLF漏洞？正确的做法应该是如下：

location / {
    return 302 https://$host$request_uri;
}

另外，由$uri导致的CRLF注入漏洞不仅可能出现在上述两个场景中，理论上，只要是可以设置HTTP头的场景都会出现这个问题。

2、目录穿越漏洞

这个常见于Nginx做反向代理的情况，动态的部分被proxy_pass传递给后端端口，而静态文件需要Nginx来处理。

假设静态文件存储在/home/目录下，而该目录在url中名字为files，那么就需要用alias设置目录的别名：

www.xianoupeng.com/files

location /files/{
    alias /home/;
}
www.xianoupeng.com/files../

location /files/ {
    alias /home/    
}

此时，访问http://example.com/files/readme.txt，就可以获取/home/readme.txt文件。

但我们注意到，url上/files没有加后缀/，而alias设置的/home/是有后缀/的，这个/就导致我们可以从/home/目录穿越到他的上层目录。

进而我们获得了一个任意文件下载漏洞。

/user/share/nginx/html/config.php 有mysql配置 mysql 用户名和密码

如何解决这个漏洞？

只需要保证location和alias的值都有后缀/或都没有这个后缀。

3、Http Header被覆盖的问题

众所周知，Nginx的配置文件分为Server、Location、If等一些配置块，并且存在包含关系，和编程语言比较类似。如果在外层配置的一些选项，是可以被继承到内层的。

但这里的继承也有一些特性，比如add_header，子块中配置后将会覆盖父块中的add_header添加的所有HTTP头，造成一些安全隐患。

如下列代码，Server块添加了CSP头：

server {
    ...
    add_header Content-Security-Policy "default-src 'self'";
    add_header X-Frame-Options DENY;

    location = /test1 {
        rewrite ^(.*)$ /xss.html break;
    }

    location = /test2 {
        add_header X-Content-Type-Options nosniff;
        rewrite ^(.*)$ /xss.html break;
    }
}

但/test2的location中又添加了X-Content-Type-Options头，导致父块中的add_header全部失效。此时，test2的csp就完全失效了，我们成功触发XSS。

总结

Nginx配置文件造成的漏洞绝不止这三种，解决这类漏洞，最根本的方法是仔细阅读官方文档，文档里说明了很多配置文件错误和正确的用法。最忌去百度网上的一些解决方法，很多错误就是一传十十传百，最后流传开来的。另外，本文开头提到的工具gixy，我们也可以利用起来，网站上线前进行一下扫描，也许就能发现一些可能存在的问题。

二氧化蛙

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
docker配置，案例复现

Nginx配置文件造成的漏洞绝不止这三种，解决这类漏洞，最根本的方法是仔细阅读官方文档，文档里说明了很多配置文件错误和正确的用法。最忌去百度网上的一些解决方法，很多错误就是一传十十传百，最后流传开来的。另外，本文开头提到的工具gixy，我们也可以利用起来，网站上线前进行一下扫描，也许就能发现一些可能存在的问题。
复制链接

扫一扫