1. 项目概述为什么我们需要一份自己的安全自检清单干了这么多年运维和开发我见过太多因为“没想到”而引发的安全事件。服务器被挂马、数据库被拖库、用户信息泄露……很多时候问题就出在一些看似不起眼的环节上。我们总把目光聚焦在防火墙、WAF这些“大门”上却忘了检查后院的窗户有没有关严。这个项目就是要把这些容易被忽略的“窗户”都找出来整理成一份可执行、可复用的安全自检清单。这份清单不是一份面面俱到的安全规范而是一个从实战出发的检查工具。它覆盖了从底层服务器系统权限到上层Web应用配置再到移动端APP安全的多个层面。核心目标很简单让你能定期比如每季度或每次重大更新后花上几个小时对照清单逐项检查快速发现潜在风险把安全从“被动响应”变成“主动防御”。无论你是个人站长、创业团队的技术负责人还是大厂里负责某块业务的同学手头有这么一份清单心里都会踏实很多。2. 清单设计思路构建分层纵深防御检查体系安全防御不能只靠单点必须建立纵深。这份自检清单的设计正是基于“纵深防御”的思想从外到内、从基础设施到应用逻辑层层设防。每一层都有其独特的风险点和检查项相互补充避免出现短板。2.1 核心原则最小权限与默认安全在展开具体检查项之前必须理解两个基石性原则。“最小权限原则”要求系统中的每个程序、每个用户、每个进程都只拥有完成其任务所必需的最小权限。比如一个用来备份数据库的脚本就不应该拥有删除整个数据库的权限。“默认安全原则”则要求系统的默认配置应该是安全的。比如新安装的数据库不应该允许空密码登录新开启的服务不应该对所有IP开放。我们设计检查项时所有条目都围绕着这两个原则展开。检查的目的就是确保当前配置符合最小权限并纠正那些不安全的默认项。例如检查服务器上是否有不必要的sudo权限用户就是在贯彻最小权限检查Web服务器是否默认关闭了目录浏览就是在确保默认安全。2.2 检查范围界定四层核心防线基于常见的技术栈和攻击面我将清单划分为四个主要检查层面这基本覆盖了一个典型互联网产品从后端到前端的核心链路系统与基础设施层这是最底层包括服务器操作系统、网络配置、中间件如Nginx, MySQL, Redis的基础安全配置。攻击者常通过漏洞扫描、弱口令爆破等方式从这里突破。Web应用层这是业务逻辑的核心包括网站本身的代码安全、会话管理、访问控制、输入输出处理等。SQL注入、XSS、CSRF等常见Web漏洞都发生在这里。数据与用户权限层聚焦于业务数据的安全和用户权限体系的健壮性。涉及数据库安全配置、用户数据的存储与传输、角色权限的校验逻辑等。权限绕过和敏感数据泄露是主要风险。移动客户端层对于有APP的产品客户端本身也是一个攻击面。包括APP的代码混淆、通信安全、本地数据存储、权限申请等。反编译、中间人攻击、本地数据窃取是常见威胁。这四层并非完全独立例如Web应用层的漏洞可能导致数据层失守而移动客户端的配置不当又可能将风险引向服务器。清单的设计考虑了这种联动性在检查时会提示关联风险。3. 系统与基础设施层自检详解这是防御的第一道墙如果这里千疮百孔上层的防御再坚固也形同虚设。检查要细致到“令人发指”的程度。3.1 操作系统权限与账户安全服务器系统的账户和权限管理是根本。首先使用cat /etc/passwd和cat /etc/shadow需root查看所有系统账户。重点检查非登录账户像www-data,nginx,mysql这类服务账户其登录shell应为/usr/sbin/nologin或/bin/false禁止其通过SSH登录。空密码账户绝对不允许存在。可以用awk -F: ($2 \\) {print $1} /etc/shadow来检查。UID为0的账户除了root不应该有其他账户的UID为0。使用awk -F: ($3 0) {print $1} /etc/passwd检查。sudo权限执行visudo或查看/etc/sudoers文件确保只有必要的运维人员账户被授予sudo权限并且最好限制其能执行的命令范围。例如可以配置只允许特定用户重启某个服务而不是所有命令。实操心得我习惯创建一个独立的运维组如ops将需要sudo权限的用户加入该组然后在sudoers文件中配置%ops ALL(ALL) ALL。这样比单独配置每个用户更清晰。同时强烈建议为所有sudo用户配置SSH密钥登录并禁用密码双因子认证更好。接下来是文件系统权限检查。关键目录的权限必须严格/etc/,/bin,/sbin,/usr/bin等系统目录权限不应过松。通常目录应为755文件为644或更严格。Web根目录这是重灾区。你的网站代码目录如/var/www/html绝对不应该被配置为777权限。推荐权限设置为目录755文件644。上传目录如图片、附件可以单独设置为755并由Web服务进程用户如www-data拥有确保Web进程有写权限但其他用户没有。使用find命令查找全局可写文件find / -type f -perm -ow ! -path /proc/* ! -path /sys/* 2/dev/null以及SUID/SGID文件find / -type f \( -perm -4000 -o -perm -2000 \) 2/dev/null审查这些特殊权限的文件是否必要。3.2 网络服务与端口暴露“看不见的端口才是最安全的端口。” 使用netstat -tunlp或ss -tunlp查看所有监听端口。每一行你都要问自己这个服务为什么开着它必须对所有IP0.0.0.0开放吗数据库服务MySQL、PostgreSQL、Redis、MongoDB等严禁将监听地址绑定在0.0.0.0。它们应该只监听127.0.0.1或内网IP。通过公网访问必须使用SSH隧道或配置在VPN之后。检查MySQL的my.cnf中的bind-addressRedis的redis.conf中的bind 127.0.0.1。Memcached/Elasticsearch这些服务历史上曾因暴露公网导致严重漏洞。务必检查其绑定IP。SSH服务编辑/etc/ssh/sshd_config。Port 22考虑更改为非标准端口减少自动化扫描。PermitRootLogin no必须禁止root直接登录。先用普通用户登录再su或sudo。PasswordAuthentication no强烈建议禁用密码认证只使用公钥认证。这能从根本上杜绝暴力破解。AllowUsers或AllowGroups使用白名单机制只允许特定的用户或组登录。防火墙配置是最后的关卡。无论你用iptables、firewalld还是云服务商的安全组规则都必须遵循最小化原则。只开放必要的端口如HTTP 80, HTTPS 443, 修改后的SSH端口并且对源IP进行限制如只允许办公网IP访问SSH和管理后台。定期审查规则清理掉那些早已不再使用的旧规则。3.3 中间件基础安全配置以最常用的Nginx和MySQL为例。Nginx隐藏版本号在配置文件中加入server_tokens off;避免泄露软件版本信息给攻击者提供便利。禁用不必要的HTTP方法在server块中限制只允许GET, POST, HEAD等必要方法。if ($request_method !~ ^(GET|HEAD|POST)$ ) { return 405; }正确配置SSL/TLS禁用老旧不安全的协议SSLv2, SSLv3和加密套件。可以使用Mozilla的SSL配置生成器获取推荐配置。确保使用强证书并开启HSTSHTTP Strict Transport Security。限制客户端请求大小设置client_max_body_size防止巨大的请求体导致拒绝服务。MySQL运行mysql_secure_installation脚本进行基础加固。检查用户权限登录MySQL执行SELECT user, host FROM mysql.user;。确保没有host为%的匿名用户或测试用户。每个用户都应从特定的IP或主机名连接。审查数据库权限使用SHOW GRANTS FOR usernamehost;查看每个用户的权限。遵循最小权限原则Web应用使用的数据库用户通常只需要SELECT, INSERT, UPDATE, DELETE等数据操作权限而不需要FILE, PROCESS, SUPER等管理权限。日志审计考虑开启通用查询日志或慢查询日志用于审计注意磁盘空间但生产环境慎用对性能有影响。4. Web应用层自检详解这一层与业务代码紧密相关是防御的核心战场。很多检查需要开发与运维协同进行。4.1 安全头信息Security Headers配置HTTP安全头是浏览器的一道重要防线正确配置能有效缓解多种前端攻击。你可以使用在线工具如 securityheaders.com或浏览器开发者工具的Network面板检查响应头。Content-Security-Policy这是对抗XSS的利器。它告诉浏览器只允许加载来自哪些源的脚本、样式、图片等。一个相对严格的策略示例Content-Security-Policy: default-src self; script-src self https://trusted.cdn.com; style-src self unsafe-inline; img-src self data: https://*.example.com; font-src self; connect-src self; frame-ancestors none;这表示默认只允许同源脚本只允许同源和指定的CDN图片允许同源、data协议和特定域名。frame-ancestors none等同于下面的X-Frame-Options DENY。配置CSP需要谨慎建议先从report-only模式开始观察控制台报告再逐步推行。X-Frame-Options防止你的页面被嵌套在iframe中用于对抗点击劫持。设置为DENY完全禁止或SAMEORIGIN只允许同源页面嵌套。X-Content-Type-Options设置为nosniff阻止浏览器对响应内容类型进行MIME嗅探强制按照Content-Type头声明的类型来解析可以防止一些基于类型混淆的攻击。Referrer-Policy控制Referrer信息的发送保护用户隐私。可以根据需要设置为strict-origin-when-cross-origin跨域时只发送源不发送路径或no-referrer。Strict-Transport-Security即HSTS告诉浏览器在未来一段时间内通过max-age指定只能通过HTTPS访问该域名。includeSubDomains和preload指令可以进一步增强安全。注意事项安全头的配置位置很重要。对于Nginx通常在server块或全局http块中配置。对于Apache在.htaccess或虚拟主机配置中使用Header set指令。对于运行在反向代理后的应用如Tomcat、Node.js必须在代理服务器Nginx上配置而不是后端应用因为后端应用返回的头可能被代理覆盖或修改。4.2 会话管理与访问控制会话是用户身份的凭证这里出问题就是身份伪造。会话ID的生成与存储确保会话ID是足够长且随机的通常由框架保证。切勿在URL中传递会话ID这会导致日志泄露。Cookie中存储的会话ID必须标记为HttpOnly防止JavaScript窃取和Secure仅通过HTTPS传输。在支持SameSite的浏览器中设置为Strict或Lax可以有效防御CSRF。会话超时设置合理的会话空闲超时和绝对超时。用户注销后必须在服务端立即销毁会话。访问控制这是业务逻辑安全的重中之重。必须进行“服务端权限校验”。前端隐藏一个按钮很容易但关键是要在后端每个API接口、每个业务操作前都校验当前登录用户是否有权执行此操作。例如删除文章时不仅要传文章ID后端还必须校验该文章的作者是否是当前用户。永远不要相信客户端传来的任何用于权限判断的标识。敏感操作日志与二次认证对于修改密码、转账、删除重要数据等操作必须记录详细的操作日志谁、何时、做了什么。对于极高风险操作应引入二次认证如邮箱/短信验证码、TOTP动态令牌等。4.3 输入验证与输出编码这是防御注入攻击SQL注入、命令注入和跨站脚本XSS的基石。输入验证在数据进入业务逻辑的第一时间进行“白名单”验证。比如一个手机号字段就只允许数字和特定的国家代码符号一个选择状态的字段就只允许“开启”、“关闭”等预定义值。对于复杂内容如富文本可以使用专门的净化库如PHP的HTMLPurifierPython的bleach。参数化查询这是杜绝SQL注入的唯一正确方法。无论是使用ORM框架还是直接写SQL都必须使用参数化查询或预编译语句让数据库区分代码和数据。绝对不要用字符串拼接的方式构造SQL。输出编码数据在输出到不同上下文时必须进行相应的编码。输出到HTML正文进行HTML实体编码如变成lt;。输出到HTML属性同样进行HTML实体编码并且属性值要用引号包裹。输出到JavaScript进行JavaScript Unicode转义。输出到URL参数进行URL编码。 现代前端框架如React, Vue大多在默认情况下提供了基础的XSS防护但开发者仍需保持警惕特别是在使用dangerouslySetInnerHTML或v-html时。5. 数据与用户权限层自检这一层关注数据的“静”态安全和权限的“动”态流转。5.1 用户数据存储与传输安全密码存储必须使用强哈希算法。不要再使用MD5、SHA1甚至加盐的MD5也不安全。应该使用专门为密码设计的、计算缓慢的算法如bcrypt、Argon2、PBKDF2。这些算法内置了盐值salt和成本因子work factor能有效抵御彩虹表攻击和暴力破解。以Node.js的bcrypt为例const bcrypt require(bcrypt); const saltRounds 12; // 成本因子值越大越安全但也越慢 const hash await bcrypt.hash(plainPassword, saltRounds); // 验证 const match await bcrypt.compare(plainPassword, hash);敏感信息加密用户的身份证号、银行卡号等个人敏感信息如果业务上必须存储应在数据库层面进行加密。可以使用数据库提供的透明加密功能如MySQL的InnoDB表空间加密或者在应用层使用AES等对称加密算法加密后存储。密钥管理是关键绝不能硬编码在代码或配置文件中应使用专门的密钥管理服务KMS或至少在环境变量中配置。数据传输全站HTTPS是必须的。检查是否有任何遗漏的HTTP链接或接口。确保HTTP到HTTPS的301/302重定向正确无误。对于API接口特别是移动端APP使用的API除了HTTPS还应考虑使用签名机制来防止请求被篡改重放。5.2 权限模型与越权检查权限漏洞越权是最高发的逻辑漏洞之一分为水平越权访问同级别其他用户的数据和垂直越权低权限用户执行高权限操作。清晰的权限模型设计系统时就要有清晰的RBAC基于角色的访问控制或ABAC基于属性的访问控制模型。定义好角色如用户、管理员、运营和权限如“查看文章”、“删除文章”、“管理用户”。服务端校验全覆盖这是本层检查的核心。你需要像攻击者一样思考遍历所有涉及对象访问的API。例如GET /api/user/orders返回当前用户的订单。后端是否校验了登录态返回前是否过滤了其他用户的订单GET /api/order/123查看订单123详情。后端是否校验了订单123属于当前用户POST /api/admin/deleteUser删除用户。后端是否校验了调用者拥有“管理用户”的权限是否只是靠前端隐藏了这个按钮PUT /api/article/456修改文章456。后端是否校验了文章作者是当前用户或者当前用户是编辑/管理员检查方法代码审计是关键。审查所有Controller/Action/Route处理函数在操作资源前寻找权限校验代码。如果没有这就是一个高危漏洞。同时进行渗透测试使用两个不同的测试账户如A和B尝试用A的凭证去访问、修改、删除B的资源。5.3 数据库安全进阶除了前面提到的基础配置还需关注数据备份与恢复备份是否加密备份文件存储的权限是否严格不应被Web用户读取恢复流程是否经过测试审计日志是否开启了数据库的审计功能记录所有敏感操作如全表删除、权限变更日志是否被妥善保存和分析连接池与错误信息应用连接数据库是否使用了连接池数据库错误信息是否被直接返回给前端用户应配置应用只返回通用的错误信息详细的错误日志记录在服务端。6. 移动端APP自检要点移动端APP运行在不可控的用户环境中面临独特的风险。6.1 客户端代码与数据安全代码混淆与加固发布正式包前必须对代码进行混淆ProGuard for Android, 代码混淆 for iOS和加固增加反编译和逆向工程的难度。对于Android还要注意AndroidManifest.xml中的debuggable标志应为false。敏感信息硬编码绝对不要在代码中硬编码API密钥、加密密钥、数据库密码等。这些信息应通过安全的渠道如构建时从环境变量注入获取或设计为需要从服务端动态获取。本地数据存储检查存储在本地SharedPreferences, UserDefaults, 本地数据库文件的数据。用户的认证令牌Token是否安全存储Android应使用EncryptedSharedPreferencesiOS应使用Keychain。是否缓存了过多的敏感用户数据如完整聊天记录、个人资料缓存是否有有效的清理机制数据库文件如SQLite是否加密可以使用Room with Encryption for Android, SQLCipher等方案。6.2 通信安全与权限管理证书锁定为了防止中间人攻击APP可以实现证书锁定。这意味着APP只信任特定的服务器证书或公钥而不是设备系统信任的所有根证书。Android可以使用Network Security ConfigurationiOS可以使用NSURLSession的delegate进行证书校验。注意证书锁定会增加运维复杂性证书更新需要发版需权衡利弊。更通用的做法是开启双向TLS验证或使用SSL Pinning公钥锁定。API请求安全确保所有网络请求都使用HTTPS。对重要的请求如登录、支付进行签名防篡改。Token应定期刷新并在失效后引导用户重新登录。APP权限遵循最小权限原则。检查AndroidManifest.xml和iOS的Info.plist中声明的权限是否都是业务必需的。对于运行时权限Android 6.0/iOS应在真正需要时才向用户申请并做好被拒绝后的降级处理逻辑。6.3 更新与反篡改安全更新机制APP的更新是否通过官方应用商店或安全的渠道进行是否有机制防止攻击者推送恶意更新包可以考虑对更新包进行签名验证。完整性校验APP启动时是否可以对自己关键文件的完整性进行校验如签名校验以防止被植入恶意代码或篡改虽然完全防止逆向很难但这可以阻挡大部分低水平篡改。环境检测对于金融类等高安全要求APP可以考虑检测设备是否已越狱/ROOT是否运行在模拟器中是否安装了Xposed/框架等并根据策略决定是否限制部分功能或直接退出。7. 自动化检查与持续监控手动检查清单固然重要但将其自动化才能持续有效。7.1 利用工具进行自动化扫描基础设施扫描使用像Lynis、OpenVAS这样的开源安全扫描工具对服务器进行自动化审计。它们能检查系统配置、软件版本、权限设置等并给出详细的加固建议。Web漏洞扫描使用OWASP ZAP、Burp Suite社区版也可用等动态应用安全测试工具对网站进行自动化爬取和漏洞扫描可以发现XSS、SQL注入、敏感信息泄露等问题。可以将这些工具集成到CI/CD流水线中在新版本发布前自动扫描。依赖组件扫描使用OWASP Dependency-Check、GitHub Dependabot、Snyk等工具检查项目依赖的第三方库是否存在已知的安全漏洞CVE。这是防御供应链攻击的关键。代码静态分析使用SonarQube、Fortify、Checkmarx等工具对源代码进行静态分析发现潜在的安全编码问题如硬编码密码、不安全的随机数生成等。7.2 建立持续监控与响应流程检查不是一劳永逸的安全状态是动态变化的。日志集中与分析将服务器日志、应用日志、数据库日志、防火墙日志等集中收集到ELKElasticsearch, Logstash, Kibana或类似平台。建立异常检测规则例如短时间内大量登录失败、访问了不存在的敏感路径、执行了异常SQL语句等。文件完整性监控使用AIDE、Tripwire等工具对系统关键文件如/etc/passwd,/usr/bin/, Web目录建立哈希值基线定期检查文件是否被篡改。入侵检测系统部署基于主机的HIDS如Wazuh、OSSEC或基于网络的NIDS如Suricata、Zeek实时监控可疑活动。应急响应计划光发现问题不够还要能快速响应。团队是否有一份明确的应急响应计划遇到入侵事件时第一步该做什么隔离、取证、通知联系人是谁如何修复和恢复定期进行演练。这份自检清单的内容看起来很多但你可以将其拆解融入到日常开发和运维的流程中。例如将安全头检查、依赖扫描作为CI/CD的一环将服务器基线检查写成Ansible/SaltStack剧本定期自动执行将权限校验代码审查作为代码合并的必要步骤。安全是一个过程而不是一个产品。这份清单就是你启动这个过程的扳手。从现在开始选一个你最担心的系统对照清单检查一遍你可能会发现一些让你后背发凉的问题。别担心发现问题是解决问题的第一步。
)
