加密与安全配置问题
加密和安全配置是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版本问题
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泄露
代码仓库可能泄露敏感信息。如果开发人员不小心将敏感信息提交到代码仓库，这些信息就会暴露给所有有权限访问仓库的人。
假设在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）、自动化测试方法，以及漏洞报告的编写技巧。这些能力，是每一个想要精进渗透测试技能的同学都离不开的“必修课”。