【Linux系列】脚本中的if else

在开始今天的分享之前，我想先推荐一篇非常精彩的文章。

文章就是《渗透测试文件包含漏洞原理与验证(1)——文件包含概述》

链接是：点击这里。

这篇文章详细解释了文件包含漏洞的原理，以及如何在实际的Web应用程序中发现和验证这类漏洞。它提到，文件包含漏洞通常发生在PHP等脚本语言中，当开发者在引入文件时没有对文件名进行充分的校验，就可能导致意外的文件泄露或恶意代码注入。

文章还介绍了几种PHP中的文件包含函数，包括include()、include_once()、require()和require_once()，以及它们在找不到文件时的不同行为。此外，文章还探讨了利用文件包含漏洞的条件，比如函数通过动态变量引入文件，以及用户能够控制这个动态变量。

通过一些实际的示例，文章展示了如何通过修改文件扩展名来绕过某些安全限制，以及如何通过修改URL参数来实现文件包含攻击。

这篇文章不仅提供了丰富的技术细节，还强调了合法合规的重要性。它提醒我们，所有的渗透测试活动都应该在获得明确授权的情况下进行，并且要遵守相关法律法规。

如果你对Web安全感兴趣，或者想要提高你的Web应用程序的安全性，我强烈推荐你阅读这篇文章。它不仅能够提供实用的技术知识，还能帮助你更好地理解安全领域的法律和道德规范。让我们一起在合法合规的前提下，探索和提升Web安全吧！

一.脚本概述

docker_build.sh 是一个用于构建 Docker 镜像的 Bash 脚本，它根据不同的参数 $param 来执行不同的构建流程。这个脚本体现了条件判断、目录切换、版本控制和 Docker 命令的结合使用，是 Docker 构建流程中一个典型的实践案例。

# 执行 docker_build.sh 脚本
if [ "$param" == "test-flex-flow" ]; then
    cd $CODE_PATH/api
    docker build -f Dockerfile  -t  ${IMAGE}:${IMAGE_TAG} .
else
    cd $CODE_PATH
    git pull
    current_branch=$(git rev-parse --abbrev-ref HEAD)
    if [ "$param" == "test-test" ]; then
        read -p "是否重新构建前端包？(y/n)" reply
        if [ "$reply" = "y" ]; then
            # 前端构建
            chmod +x ./frontend_build.sh
            sh ./frontend_build.sh
        fi
    fi
    sh docker_build.sh $IMAGE_TAG
fi

二.脚本功能解析

1.条件判断

脚本首先通过一个 if 语句来判断参数 $param 的值。这个参数决定了脚本的执行流程，是脚本的核心逻辑之一。

• 如果 $param 等于 test-flex-flow，则脚本会切换到 $CODE_PATH/api 目录，并使用当前目录下的 Dockerfile 来构建一个带有标签 ${IMAGE}:${IMAGE_TAG} 的 Docker 镜像。
• 如果 $param 不等于 test-flex-flow，则脚本会执行另一套流程，包括拉取最新的代码、判断当前分支、以及根据 $param 的值来决定是否重新构建前端包。

这种条件判断的设计使得脚本能够根据不同的构建需求灵活地执行不同的任务，提高了脚本的可用性和灵活性。

2.目录切换与版本控制

脚本中使用了 cd 命令来切换工作目录，这是构建过程中常见的操作，因为不同的构建任务可能需要在不同的目录下执行。例如，构建 API 服务时可能需要切换到 API 服务的代码目录，而构建前端服务时则可能需要切换到前端代码目录。

此外，脚本还涉及到版本控制的操作，如 git pull 和 git rev-parse --abbrev-ref HEAD。这些命令用于确保代码是最新的，并且能够识别当前的工作分支。这对于持续集成/持续部署（CI/CD）流程来说至关重要，因为它们确保了构建的代码是最新的，并且能够追溯到具体的代码版本。

3.Docker 构建命令

脚本中的核心命令是 docker build，它用于根据 Dockerfile 构建 Docker 镜像。这个命令的参数 -f 指定了 Dockerfile 的位置，-t 参数用于指定构建出的镜像的标签，最后的 . 表示构建上下文是当前目录。

4.前端构建

在脚本的另一部分，如果 $param 等于 test-test，则会提示用户是否需要重新构建前端包。如果用户输入 y，则会执行 frontend_build.sh 脚本来构建前端代码。这个步骤体现了前后端分离的开发模式，其中前端代码需要单独构建并打包。

三.脚本的优化与改进

虽然脚本已经能够满足基本的构建需求，但仍有一些地方可以进行优化和改进。

1.参数化

脚本中的 $IMAGE 和 $IMAGE_TAG 变量没有在脚本中定义，这可能会导致脚本在执行时出现错误。为了提高脚本的健壮性，可以在脚本开始处定义这些变量，或者通过外部传入参数的方式来提供这些值。

2.错误处理

脚本中缺少对命令执行结果的检查。在实际使用中，如果某个命令执行失败，脚本应该能够捕获错误并给出提示，而不是继续执行后续的命令。可以通过检查命令的退出状态码来实现这一点。

3.日志记录

在构建过程中，记录日志是非常重要的。脚本可以添加日志记录的功能，将构建过程中的关键信息记录下来，便于问题追踪和性能分析。

4.并行构建

如果构建任务较多，可以考虑实现并行构建来提高构建效率。Docker 支持并行构建，可以通过修改脚本来实现这一点。