在交通银行的前端系统中，如何处理敏感数据（如银行卡号、密码）的传输和存储？请说明前端和后端的安全措施，以及如何避免XSS、CSRF等攻击？
交通银行前端开发工程师难度：中等
答案
1) 【一句话结论】在交通银行前端系统中，敏感数据通过HTTPS加密传输，前端不存储敏感数据，后端通过KMS管理密钥并使用AES-256加密存储；前端通过输入过滤、CSP防御XSS，通过CSRF Token、SameSite Cookie、Referer检查防御CSRF，同时配置HSTS预加载增强传输安全。
2) 【原理/概念讲解】老师口吻解释关键点：
- HTTPS与传输安全：采用SSL/TLS证书（由CA颁发，定期更新），配置HSTS（HTTP Strict Transport Security），强制客户端使用HTTPS，防止中间人攻击。类比：银行与用户之间的“加密隧道”，证书像银行的身份证明，HSTS像强制用户只走安全通道。
- 密钥管理（KMS集成）：后端使用云服务（如AWS KMS或阿里云KMS）管理加密密钥，密钥轮换周期（如每90天轮换一次），避免密钥泄露风险。前端通过API从KMS获取临时密钥，加密数据后发送，后端解密时使用KMS的密钥。
- 敏感数据存储：后端对银行卡号等敏感数据用AES-256加密（密钥256位，符合NIST FIPS 140-2标准，攻击复杂度极高），存储密文，解密时再解密。类比：银行将现金存入保险柜，用高安全级别的密码锁，只有授权人员能打开。
- XSS防御：前端对用户输入进行严格过滤（检查输入是否包含
<script>标签），对输出内容进行HTML转义（如<→<），部署CSP（Content Security Policy），限制页面加载的资源（如script-src 'self'，只允许加载银行域名的脚本），防止恶意脚本执行。 - CSRF防御：每个请求携带CSRF Token（通过Cookie传递，设置
HttpOnly、Secure、SameSite=Strict），后端验证Token有效性；对敏感操作（如转账）增加Referer检查，确保请求来自合法页面，防止伪造请求。
3) 【对比与适用场景】
| 加密算法 | 密钥长度 | 安全性依据 | 适用场景 |
|---|---|---|---|
| AES-128 | 128位 | NIST FIPS 140-2，攻击复杂度较低 | 非核心敏感数据 |
| AES-256 | 256位 | NIST FIPS 140-2，攻击复杂度极高（需2^128次尝试） | 核心敏感数据（如银行卡号） |
4) 【示例】
前端发送加密数据（假设使用KMS生成密钥）：
// 获取KMS临时密钥
const getKmsKey = async () => {
const response = await fetch('/api/getKmsKey', {
method: 'POST',
headers: { 'Authorization': 'Bearer token' }
});
const { keyId, encryptedKey } = await response.json();
const key = await window.crypto.subtle.decrypt(
{ name: 'AES-GCM', iv: new TextEncoder().encode('iv') },
await window.crypto.subtle.importKey(
'jwk',
JSON.parse(encryptedKey),
{ name: 'AES-GCM', length: 256 },
false,
['decrypt']
),
new TextEncoder().encode('iv')
);
return key;
};
// 加密银行卡号
const encryptCard = async (cardNumber) => {
const key = await getKmsKey();
const iv = new TextEncoder().encode('iv');
const encrypted = await window.crypto.subtle.encrypt(
{ name: 'AES-GCM', iv },
key,
new TextEncoder().encode(cardNumber)
);
return btoa(String.fromCharCode(...new Uint8Array(encrypted)));
};
// 发送加密数据
const sendEncryptedData = async (cardNumber) => {
const encrypted = await encryptCard(cardNumber);
await fetch('/api/submitBankCard', {
method: 'POST',
headers: { 'Content-Type': 'application/json', 'Authorization': 'Bearer token' },
body: JSON.stringify({ encryptedBankCard: encrypted })
});
};
后端解密（使用KMS的密钥）：
from cryptography.fernet import Fernet
from cryptography.hazmat.primitives import serialization
from cryptography.hazmat.primitives.asymmetric import rsa, padding
from cryptography.hazmat.primitives import hashes
import boto3
kms_client = boto3.client('kms')
key_id = 'arn:aws:kms:region:account-id:key/...'
# 获取KMS密钥
response = kms_client.generate_data_key(KeyId=key_id, KeySpec='AES_256')
encryption_key = response['CiphertextBlob']
decryption_key = response['Plaintext']
# 解密数据
cipher_suite = Fernet(decryption_key)
encrypted_data = request.json['encryptedBankCard']
decrypted_data = cipher_suite.decrypt(encrypted_data.encode()).decode()
db.save({'bank_card': decrypted_data})
5) 【面试口播版答案】（约90秒）
“面试官您好，针对敏感数据传输和存储，以及XSS、CSRF防护，我的思路是：首先，传输层面，我们采用HTTPS协议，并配置HSTS预加载，强制客户端只通过安全通道通信，防止中间人攻击。前端不存储任何敏感数据（如银行卡号、密码），因为前端环境存在被攻击风险。后端通过KMS（密钥管理系统）管理加密密钥，定期（如每90天）轮换密钥，确保密钥安全。对敏感数据（如银行卡号）使用AES-256加密存储，密钥256位，符合NIST FIPS 140-2标准，攻击复杂度极高。然后，针对XSS攻击，前端对用户输入进行严格过滤（检查输入是否包含<script>标签），对输出内容进行HTML转义（如<→<），同时部署内容安全策略（CSP），限制页面加载的资源（如只允许加载银行域名的脚本），防止恶意脚本执行。对于CSRF攻击，我们在每个请求中携带一个唯一的CSRF Token（通过Cookie传递，设置HttpOnly、Secure、SameSite=Strict属性），后端验证Token有效性；对敏感操作（如转账）增加Referer检查，确保请求来自合法页面。通过这些措施，从传输、存储到防御，全方位保护敏感数据安全。”
6) 【追问清单】
- 问：HTTPS证书管理具体如何做？比如是否使用预加载HSTS？
回答要点：使用CA颁发的SSL/TLS证书，定期更新（如一年），并配置HSTS预加载，确保客户端首次访问后强制使用HTTPS。 - 问：密钥轮换周期和KMS集成的具体步骤？
回答要点：密钥每90天轮换一次，通过KMS生成新密钥，前端和后端更新密钥，避免密钥泄露风险。 - 问：AES-256加密算法的安全性依据是什么？为什么256位密钥足够？
回答要点：AES-256符合NIST FIPS 140-2标准，256位密钥的攻击复杂度为2^128次尝试，在当前计算能力下无法破解，确保数据安全。 - 问：CSRF Token的生成位置？比如放在Cookie还是请求头？
回答要点：通常放在Cookie（设置HttpOnly、Secure、SameSite属性），或请求头（如X-CSRF-Token），后端验证时检查Token是否匹配。 - 问：前端如何处理用户输入的敏感数据，比如输入时实时加密？
回答要点：前端使用加密库（如crypto-js）结合KMS临时密钥，对输入的银行卡号实时加密，提交加密后数据，避免明文传输。
7) 【常见坑/雷区】
- 前端存储敏感数据：如将银行卡号存入localStorage/cookie，导致设备被窃取后数据泄露。
- 未使用HSTS预加载：导致客户端首次访问时可能走HTTP，被中间人攻击。
- 密钥管理不当：密钥未轮换，或直接硬编码，导致密钥泄露。
- XSS防御不充分：只做输入过滤，未对输出编码；或CSP配置不当，允许加载外部脚本。
- CSRF Token管理不当：Token生成不唯一，或未验证有效性，导致伪造请求成功。
- 忽略Referer检查：敏感操作未验证请求来源，导致CSRF攻击。