加密和安全配置是Web应用安全的基础。但如果使用不当,反而可能带来安全问题。错误使用加密算法、TLS配置缺陷、敏感信息泄露等,都是常见的问题。

加密算法的选择很重要。使用弱加密算法,即使实现正确,也可能被破解。
假设一个系统使用MD5来存储密码哈希:
|$password_hash = md5($password);
MD5已经被破解,攻击者可以使用彩虹表快速破解密码。更严重的是,如果系统没有加盐,相同密码的hash相同,攻击者就可以通过对比hash值来判断密码是否相同。
测试弱密码的MD5值:
|import hashlib # 常见密码的MD5 common_passwords = ['123456', 'password', 'admin', '12345678'] for pwd in common_passwords: md5_hash = hashlib.md5(pwd.encode()).hexdigest() print(f"{pwd}: {md5_hash}") # 可以在线MD5数据库查询 # 如:https://www.md5online.org/
类似地,SHA1也已经被破解,不应该用于签名。DES的密钥长度太短,不安全。RC4有已知漏洞,不应该使用。
即使使用强加密算法,如果密钥管理不当,也可能导致密钥泄露。
假设一个系统的配置文件,密钥硬编码在代码中:
|$secret_key = 'my_secret_key_123';
如果代码泄露(比如提交到GitHub),密钥也会泄露。即使代码不泄露,如果密钥强度弱(太短或可预测),攻击者也可能通过暴力破解来获取密钥。
另一个问题是密钥复用。如果多个系统使用相同的密钥,一旦某个系统的密钥泄露,其他系统也会受到影响。
密钥存储也很重要。如果密钥存储在不安全的地方(如配置文件、环境变量、日志文件),就可能被读取。所以密钥应该存储在安全的地方,比如环境变量、数据库、文件系统等。
即使使用强算法,如果实现错误,也可能导致问题。
假设一个系统使用AES加密,但使用ECB模式。ECB模式的问题是:相同的明文块会产生相同的密文块,攻击者可以通过分析密文模式来推断明文内容。正确的做法是使用CBC或GCM模式,它们使用初始化向量(IV)来确保相同明文产生不同密文。
IV重用也可能导致问题。如果每次加密都使用相同的IV,攻击者就可以通过分析密文来推断明文。正确的做法是每次加密都使用随机IV。 填充攻击也同样值得注意。如果填充处理不当,攻击者可能通过分析填充错误来推断明文内容。

TLS版本的选择很重要。使用不安全的TLS版本,即使配置正确,也可能被攻击。
SSL 2.0和3.0已经被废弃,不应该使用。TLS 1.0和1.1有已知漏洞,应该禁用。建议使用TLS 1.2或更高版本。
测试TLS配置可以使用工具:
|# 使用sslscan sslscan example.com # 使用testssl.sh testssl.sh example.com
即使使用安全的TLS版本,如果使用弱密码套件,也可能被攻击。
使用RC4的套件、使用MD5的套件、密钥长度小于128位的套件等,都不安全。建议使用强密码套件,如AES-256-GCM。
测试密码套件可以使用nmap:
|# 使用nmap nmap --script ssl-enum-ciphers -p 443 example.com

代码仓库可能泄露敏感信息。如果开发人员不小心将敏感信息提交到代码仓库,这些信息就会暴露给所有有权限访问仓库的人。
假设在GitHub上搜索目标公司,可能发现数据库配置文件,包含生产环境密码、API密钥和Secret、内部系统地址等信息。
发现这类问题的方法包括:GitHub搜索(可以用site:github.com example.com password、site:github.com example.com api_key、site:github.com example.com secret等搜索),使用工具(如truffleHog扫描Git仓库中的敏感信息,git-secrets防止提交敏感信息)。
配置文件可能泄露敏感信息。如果配置文件可以被直接访问,攻击者就可以获取配置信息。
假设一个系统的.env文件可以访问:
|GET /.env
文件内容可能包含:
|DB_HOST=internal-db.example.com DB_USER=admin DB_PASS=secret_password_123 API_KEY=sk_live_abc123def456
这样攻击者就成功获取了数据库密码和API密钥。
发现这类问题的方法包括:目录扫描(可以用dirsearch -u https://example.com -e env,php,config扫描),常见路径(包括/.env、/config.php、/web.config、/.git/config等)。
日志文件可能泄露敏感信息。如果日志文件可以被访问,攻击者就可以获取日志中的信息。
假设一个系统的日志文件可以访问:
|GET /logs/access.log
日志内容可能包含用户登录请求(包含密码)、API调用(包含token)、错误信息(包含数据库结构)等敏感信息。
错误信息可能泄露敏感信息。如果系统在错误时返回详细信息,攻击者就可以利用这些信息。
假设一个系统在错误时返回详细信息:
|{ "error": "SQL syntax error", "query": "SELECT * FROM users WHERE id = '1' AND password = 'admin'", "file": "/var/www/html/login.php", "line": 42, "stack": [...] }
这些信息泄露了SQL查询结构、文件路径、代码结构等,攻击者可以利用这些信息进行进一步攻击。
本部分我们一起探讨了加密和安全配置中的各种常见问题。加密和安全配置虽然是保障系统安全的基础,但一旦疏忽(比如使用了不安全的算法、密钥管理不规范、实现有疏漏),反而很容易给攻击者留下漏洞。同时,像TLS配置不当(协议版本、密码套件、证书问题)、敏感信息泄漏(代码托管平台上的密钥、配置文件、日志内容、错误信息等)也经常成为安全隐患的根源。
这些风险,既可能因为图省事、疏忽配置产生,也可能因为对细节关注不够而被忽视。其实只要我们养成良好的习惯,比如定期检查使用的加密算法和密钥存储方式,定期体检TLS配置、安全地处理日志和错误信息,并且多用一些扫描工具、关注细节,很多问题都能在早期被发现和避免。
接下来我们将进入更加实用的内容,比如介绍各种常用的安全测试工具(如 Burp Suite)、自动化测试方法,以及漏洞报告的编写技巧。这些能力,是每一个想要精进渗透测试技能的同学都离不开的“必修课”。