7.网络编程-安全

引言

Session

JWT (JSON Web Token)

网络攻击

CSRF

DDoS

其他常见网络攻击类型及应对措施

引言

Session、Cookie 和 JWT 都是Web开发中用于实现用户状态管理和身份验证的技术。它们各自有不同的特点和应用场景：

Session

Session 是一种服务器端的机制，用于在一次完整的系列操作（如用户的一次网站访问）中保持特定用户的状态信息。具体实现通常包括以下步骤：

创建Session：当用户首次访问网站并进行身份验证（如登录）时，服务器为该用户创建一个唯一的Session ID，并将相关用户状态信息（如用户ID、权限等）存储在服务器端的内存、数据库或文件系统中。
传递Session ID：服务器通过HTTP响应向客户端（通常是浏览器）发送一个名为Set-Cookie的头，其中包含Session ID。浏览器接收到后，将其保存在本地的Cookie中。
维持会话：后续用户请求时，浏览器会自动在请求头中附带上与Session ID对应的Cookie。服务器通过解析请求头中的Cookie，获取Session ID，然后根据该ID从服务器端的存储中查找并恢复用户状态，从而识别和维护用户会话。

优点：

用户状态信息存储在服务器端，相对安全，不易被客户端篡改。
可以存储较复杂和敏感的数据，如用户权限、购物车内容等。

缺点：

依赖服务器端存储，随着用户数量增加，服务器端存储和管理Session的成本可能会增加。
需要处理Session过期、失效等问题，以防止Session固定攻击等安全风险。

Cookie 是浏览器和服务器之间进行会话管理的一种机制。它由服务器在HTTP响应中通过Set-Cookie头设置，浏览器将Cookie保存在本地，并在后续请求中自动附带到请求头的Cookie字段中。

作用：

存储少量用户相关信息，如用户偏好、购物车内容、Session ID等。
维护用户会话，如通过存储Session ID实现Session管理。

特点：

存储在客户端（浏览器），大小有限制（通常为4KB），且易被客户端篡改（除非使用HttpOnly、Secure等属性加强安全性）。
有生命周期（Expires/Max-Age属性）和作用域（Domain、Path属性）限制。
可以设置为HttpOnly防止JavaScript访问，设置为Secure要求仅在HTTPS连接中传输，以及SameSite属性防止跨站请求伪造（CSRF）。

JWT (JSON Web Token)

JWT (JSON Web Token) 是一种开放标准（RFC 7519），定义了一种紧凑的、自包含的方式在各方之间安全地传输信息作为JSON对象。JWT通常用于用户身份验证，但它也可以用于信息交换。

一个JWT包含三部分：Header（头部）、Payload（载荷）和Signature（签名）。Header和Payload都是Base64编码的JSON对象，Signature则是通过对Header和Payload使用密钥（secret）进行哈希运算生成的，用于验证JWT的完整性和真实性。

工作流程：

生成JWT：服务器在用户成功登录后，根据用户信息生成一个JWT，包含用户ID、过期时间等信息，并使用密钥进行签名。
传输JWT：服务器通过HTTP响应（如Bearer Token方式）将JWT发送给客户端（通常是浏览器），客户端将其保存在内存或localStorage中。
使用JWT：后续请求中，客户端在请求头（如Authorization头）中携带JWT。服务器接收到后，验证JWT的签名和有效性，通过解析Payload中的信息识别用户身份并进行授权。

优点：

状态less（无状态）：服务器无需存储Session信息，减轻了服务器端压力。
自包含：所有必要的用户信息都在JWT中，易于传递（如跨域请求）。
安全性：通过数字签名保证数据完整性和真实性。

缺点：

数据量有限：由于JWT通常放在Authorization头中，大小不宜过大。
无法主动注销：一旦JWT发放，除非设置较短的有效期，否则无法在服务器端主动使JWT失效，需依赖客户端不再使用或清除已发放的JWT。

总结来说，Session、Cookie和JWT各有优缺点，适用于不同的场景。Session适用于需要在服务器端存储复杂用户状态且对安全性要求较高的场景，Cookie常用于存储小量用户信息和维持会话，而JWT则在需要实现无状态、跨域认证、移动端友好等场景下更为合适。实际应用中，根据业务需求和安全考虑，可能结合使用这些技术。

网络攻击

CSRF

CSRF (Cross-Site Request Forgery): CSRF是一种网络攻击手段，攻击者通过诱使用户在其当前已登录的可信网站之外的环境中（如恶意网站或电子邮件中的链接）触发一个操作，利用用户的浏览器向目标网站发起一个未经授权的请求。由于用户浏览器与目标网站之间已有有效的会话（例如通过Cookie维持的Session），该请求会被目标网站视为合法用户的操作，并可能导致账户信息修改、资金转账、数据删除等后果。

解决CSRF攻击的方法:

使用CSRF Tokens: 在每个敏感操作请求中包含一个一次性或短期有效的随机Token（通常称为CSRF Token），服务器端在接收到请求时验证这个Token的存在性和正确性。这个Token通常在用户登录后生成，并作为隐藏字段包含在表单中，或通过HTTP-only Cookie发送给客户端，客户端在发起请求时必须将其回传。
检查Referer或Origin Header: 服务器端检查请求的Referer或Origin头，确保请求来源于预期的域名。但这不是一个可靠的防护手段，因为某些浏览器或网络环境可能不发送或允许伪造这些头。
使用双重提交验证: 要求用户除了提交正常表单数据外，还需要完成额外的验证，如输入一个从Cookie中获得的验证码。
限制跨域请求: 对于仅接受JSON API的接口，可以设置CORS策略，仅允许特定源发起请求，防止跨域的CSRF攻击。

DDoS

DDoS (Distributed Denial of Service): DDoS攻击是一种网络攻击形式，攻击者通过控制大量（分布式的）设备（如僵尸网络）同时向目标系统发送大量请求，意图耗尽其处理能力、带宽或其它系统资源，导致目标服务无法正常响应合法用户的请求。

解决DDoS攻击的策略:

网络层防护:
- 防火墙与入侵检测系统 (IDS/IPS): 过滤异常流量，阻止已知攻击模式。
- 带宽扩容与流量清洗: 增加网络带宽以承受更大的流量冲击，并使用专门的DDoS防护服务或设备对恶意流量进行清洗，仅允许正常流量到达服务器。
- IP黑名单与速率限制: 对频繁发送异常请求的IP地址进行临时或永久封禁，或限制单个IP的请求速率。
应用层防护:
- 资源优化与负载均衡: 提高服务器处理效率，合理分配请求，避免单一节点过载。
- 验证码或二次验证: 对可疑请求引入人机验证，增加攻击成本。
- CDN服务: 利用内容分发网络分散流量，缓解直接对源站的压力。
云服务商防护服务:
- 许多云服务商提供DDoS防护服务，能够实时监测并自动缓解大规模攻击。

其他常见网络攻击类型及应对措施

XSS (Cross-Site Scripting):
- 输入验证与输出转义: 对用户提交的所有数据进行严格验证，确保其符合预期格式；在输出到HTML页面时，对特殊字符进行转义或使用安全上下文（如HTML属性使用data-*属性、内容使用textContent而非innerHTML）。
- 内容安全策略 (CSP): 设置浏览器的CSP头，限制脚本、样式、图片等资源的加载来源，防止恶意内容注入。
SQL Injection:
- 参数化查询: 使用预编译的参数化查询语句，确保用户输入的数据始终被视为数据而非指令。
- ORM工具: 使用支持自动参数化的ORM框架，避免手动拼接SQL语句。
Clickjacking:
- X-Frame-Options: 设置响应头，禁止网站内容在iframe中嵌套显示，防止点击劫持。
Man-in-the-Middle (MitM):
- 启用HTTPS: 强制使用SSL/TLS加密所有通信，防止中间人窃取或篡改数据。
- 证书pinning: 确保应用程序只接受特定的服务器证书，即使中间人持有有效CA签发的证书也无法进行伪装。
Brute Force Attacks:
- 账户锁定与登录尝试限制: 对连续失败的登录尝试进行限制，如达到一定次数后暂时锁定账户或增加登录延迟。
- 强密码策略: 要求用户设置包含字母、数字、符号的复杂密码，降低暴力破解成功率。