Web 开发安全与最佳实践：MVC、会话管理与常见攻击防御

• 仅在错误页面（isErrorPage=true）中使用
• 包含异常信息

这些内置对象极大地便利了 HTTP 请求的处理过程。例如：

• 使用 request 获取用户的请求内容
• 使用 session 获取会话的状态信息
• 使用 out 发送 HTML 给客户端

JSP 和 Servlet 比较

JSP（JavaServer Pages）和 Servlet 都是 JavaWeb 开发中常用的技术，主要用于生成动态网页内容。虽然它们的目标相似，但在使用方式和适用场景上有明显区别。

1. 语法和易用性

JSP

• 基于 HTML，允许在 HTML 中嵌入 Java 代码
• 支持表达式语言（EL）和 JSTL，简化了数据访问和常见操作
• 更适合于生成和展示视图（View）

Servlet

• 纯 Java 代码
• 在生成 HTML 时相对繁琐
• 更适合处理复杂的业务逻辑

2. 编译方式

JSP

• 首次请求时编译
• 代码变更后自动重新编译，无需重启服务器

Servlet

• 服务器启动或首次请求时编译
• 编译一次后不再重新编译，代码更改需重启服务器

3. 主要用途

JSP

• 生成和展示视图（HTML 页面）
• 适合处理简单的展示逻辑

Servlet

• 处理业务逻辑
• 处理表单提交、数据库查询等后端操作

4. 在 MVC 模式中的应用

在实际开发中，JSP 和 Servlet 通常结合使用，实现 MVC（Model-View-Controller）设计模式：

• Controller：Servlet 处理用户请求，执行业务逻辑
• Model：POJO（Plain Old Java Object）实现，存储应用层数据
• View：JSP 展示数据给用户

这种组合充分发挥了两者的优势，提高了代码的可维护性和可扩展性。

Session 和 Cookie 比较

Session 和 Cookie 都是用于存储用户信息的重要 Web 技术，但它们在多个方面有显著差异。

1. 存储位置

• Session: 存储在服务器端，每个用户有唯一的 session。
• Cookie: 存储在客户端（浏览器），通过 HTTP 响应头部设置。

2. 存储容量

• Cookie: 容量小，通常不超过 4KB。
• Session: 理论上没有限制，但过多可能占用大量服务器内存。

3. 数据类型

• Cookie: 只能存储字符串，特殊字符需编码。
• Session: 可存储任何数据类型（如字符串、数字、对象等）。

4. 生命周期

• Cookie:
  • 可设置明确的过期时间。
  • 无过期时间设置时，仅在当前浏览器会话有效。
• Session:
  • 由服务器控制，通常设置一个失效时间。
  • 用户长时间无活动时，服务器可能自动删除。

5. 安全性

• Cookie: 存储在客户端，安全性较低，可能被窃取或修改。
• Session: 存储在服务器，用户无法直接访问，安全性较高。

6. 应用场景

• Cookie: 适合存储少量、安全要求不高的数据。
• Session: 适合存储大量、安全性要求高的数据。

7. 性能影响

• Cookie: 每次 HTTP 请求都会携带，可能影响网络传输效率。
• Session: 不影响网络传输，但可能增加服务器负载。

选择建议

• 需要存储大量数据且安全性要求高：使用 Session。
• 只需存储小部分数据且安全性要求不高：使用 Cookie。
• 考虑结合使用：Cookie 存储 Session ID，Session 存储具体数据。

单点登录：Cookie 被禁用时的解决方案

单点登录（Single Sign-On, SSO）是一种允许用户通过一次身份验证即可访问多个相关系统或服务的方法。传统上，SSO 依赖 Cookie 来追踪用户的会话状态。然而，当 Cookie 被禁用时，我们需要采用替代方案。以下是几种可行的解决方法，每种都有其优缺点：

1. URL 重写

原理： 在 URL 中附加会话标识符（如 SessionID）。

优点：

• 简单易实现
• 不依赖客户端存储

缺点：

• 安全风险：SessionID 可能被截获或泄露
• URL 变得冗长且不美观
• 可能影响 SEO

使用场景： 适用于安全要求不高的内部系统

2. 隐藏表单字段

原理： 在 HTML 表单中添加隐藏字段存储会话信息。

优点：

• 相对安全，不直接暴露在 URL 中
• 实现简单

缺点：

• 仅适用于基于表单的交互
• 无法处理非表单请求（如 AJAX）

使用场景： 适合以表单为主的传统 Web 应用

3. Web Storage (localStorage/sessionStorage)

原理： 利用 HTML5 的 Web Storage API 在客户端存储会话信息。

优点：

• 数据持久性（localStorage）或会话期间持久（sessionStorage）
• 较大的存储容量
• 不随 HTTP 请求自动发送，可控制数据传输

缺点：

• 需要 JavaScript 支持
• 潜在的 XSS 安全风险

使用场景： 适合现代 Web 应用，特别是单页应用（SPA）

4. 基于令牌的认证（如 JWT）

原理： 服务器生成包含用户身份信息的令牌，客户端存储并在每次请求中包含该令牌。

优点：

• 无状态，利于扩展
• 跨域支持好
• 可包含丰富的用户信息
• 安全性高（如果正确实现）

缺点：

• 实现相对复杂
• 令牌管理（如刷新、撤销）需要额外考虑

使用场景： 适合需要高安全性和可扩展性的现代 Web 应用和 API

选择建议

• 对于安全性要求高的应用，避免使用 URL 重写
• 如果是基于 HTML5 的现代应用，优先考虑 Web Storage 或基于令牌的方法
• 对于需要高度安全性和可扩展性的系统，推荐使用 JWT 等基于令牌的认证方式
• 在可能的情况下，组合使用多种方法以提高兼容性和安全性

记住，无论选择哪种方法，都要充分考虑安全性，并在实现过程中遵循最佳实践。

Web 应用中会话（Session）的删除

在 Web 应用中，会话（Session）可能因以下几个因素而被删除：

1. 会话超时

大多数框架都允许设置超时时间。如果特定会话在这段时间内未访问服务器，它将自动被删除。

• 示例：在 Java Servlet 中，可以通过配置 web.xml 文件中的来设置超时时间。

2. 手动删除

应用程序代码可以显式地删除会话。

• 示例：在 Java Servlet 中，可以使用 HttpSession.invalidate() 方法来删除会话。

3. 服务器重启

• 默认情况：服务器重启时，所有内存中的会话都会被删除。
• 例外情况：某些服务器可以将会话持久化到磁盘，并在重启后恢复它们。

4. 浏览器关闭

• 对于基于 cookie 的会话（最常见的实现），会话 cookie 通常在浏览器关闭时被删除。
• 这并不会立即删除服务器端的会话，除非设置了会话超时或服务器采取了行动。

5. 服务器特定行为

会话管理由 Web 服务器处理，不同服务器之间可能存在差异：

• 有些服务器定期进行超时检查并删除过期会话。
• 其他服务器可能在接收请求时检查会话超时。

最佳实践

1. 根据应用程序的安全需求设置适当的超时时间。
2. 实现手动注销功能，以便用户完成操作后能主动使会话失效。
3. 考虑使用安全的、HTTPOnly 的 cookie 来存储会话 ID，以增强安全性。
4. 了解您所使用的特定服务器的会话管理策略。

注意：具体行为可能因 Web 服务器、应用程序框架和配置设置而异。

Tomcat 创建 Servlet 实例的过程

Tomcat 作为一个实现 Servlet 规范的 Web 容器，负责创建和管理 Servlet 对象的生命周期。以下是 Tomcat 创建和管理 Servlet 实例的详细过程：

1. 加载 Servlet 类

当 Tomcat 接收到一个请求并需要创建特定 Servlet 类时：

• 调用类加载器 (ClassLoader) 加载指定的类
• 如果类已被加载，则跳过此步骤

2. 实例化 Servlet 类

• Tomcat 使用 Java 反射机制的 Class.newInstance() 方法创建 Servlet 实例
• 此方法调用 Servlet 类的无参构造方法
• 注意：如果类没有无参构造方法或构造方法不可访问（如私有），将抛出异常

3. 初始化 Servlet 对象

• Tomcat 调用 Servlet 实例的 init(ServletConfig config) 方法
• 传入 ServletConfig 对象，包含初始化参数
• 此步骤允许 Servlet 执行任何必要的设置操作

4. 处理请求（调用服务方法）

• 初始化完成后，Tomcat 调用 Servlet 的 service() 方法处理请求
• service() 方法通常接收两个参数：
  • HttpServletRequest 实例：表示客户端请求
  • HttpServletResponse 实例：表示服务器响应

5. Servlet 生命周期管理

• Servlet 实例通常是单例的，每个 Servlet 类只创建一个实例
• 在多线程环境中，每个客户端请求由一个独立线程处理
• 开发者需确保 Servlet 的线程安全性

6. Servlet 销毁

• 当 Servlet 不再需要或者服务器关闭时，Tomcat 调用 Servlet 的 destroy() 方法
• 此方法用于释放资源，执行清理操作

注意事项

1. 反射机制：newInstance() 方法是 Java 反射 API 的一部分，允许在运行时动态创建对象
2. 线程安全：由于 Servlet 是单例的，在多线程环境中需要特别注意线程安全问题
3. 性能考虑：Servlet 的单例特性有助于提高性能，但也带来了线程安全的挑战
4. 错误处理：在整个过程中，Tomcat 需要妥善处理可能出现的异常，如类加载失败、实例化错误等

通过这个过程，Tomcat 能够灵活地管理 Servlet 的生命周期，实现了 Servlet 容器的核心功能。

SQL 注入攻击及其防范措施

SQL 注入是一种常见且危险的网络攻击方式。攻击者通过在用户输入中插入恶意 SQL 代码，试图操纵数据库查询，从而获取敏感信息或篡改数据。为有效预防 SQL 注入攻击，可采取以下关键措施：

1. 使用预编译语句（Prepared Statements）
   • 原理：在执行 SQL 语句前，先确定查询结构，再传入参数。
   • 优势：参数不会被解释为 SQL 代码，有效防止注入。
   • 实现：如在 Java 中使用 PreparedStatement 类。
2. 采用参数化查询
   • 与预编译语句类似，确保用户输入被视为数据而非代码。
   • 适用于各种编程语言和数据库系统。
3. 严格的用户输入验证
   • 对所有用户输入进行过滤和验证。
   • 例如：限制用户名只能包含字母和数字。
   • 拒绝或转义潜在危险的字符。
4. 实施最小权限原则
   • 严格控制数据库访问权限。
   • 只赋予用户完成必要操作的最小权限。
   • 即使发生注入，也可限制潜在危害。

通过综合应用这些方法，可以显著降低 SQL 注入攻击的风险。需要注意的是，安全措施应该是多层次的，不应仅依赖单一防御手段。持续的安全意识和定期的代码审查同样重要，有助于及时发现和修复潜在漏洞。

XSS 攻击与防御简介

XSS 攻击

XSS（跨站脚本攻击）是一种在网页上注入恶意脚本的攻击方式，使得这些脚本可以在其他用户的浏览器上运行。当用户访问含有恶意脚本的网页时，这些脚本会在用户的浏览器中执行，从而进行恶意操作，如：

• 获取用户信息
• 篡改网页内容
• 执行未经授权的操作

防止 XSS 的方法

1. 转义用户输入：对所有用户提供的数据进行转义处理，确保浏览器将其解析为纯文本，而不会执行为脚本。
2. 内容安全策略（CSP）：CSP 是一种浏览器的安全机制，可以有效限制浏览器资源的运行和加载。例如，限制网页只能运行和加载来自同一域名的脚本，可以有效防止 XSS。
3. 输入验证：对用户提交的信息进行校验，当发现含有可能引起 XSS 注入的内容时拒绝处理。
4. 使用 HTTP-only Cookies：使用 HTTP-only 标志来修饰含有敏感信息的 cookie，可以防止 cookie 内容被 JavaScript 获取或修改。
5. 避免使用不安全的 JS 代码：某些 JS 方法（如 innerHTML）存在安全隐患，应尽量避免使用。

为了有效防御 XSS 攻击，最好结合使用上述多种方法，构建多层防御机制。定期的安全审计和更新也是保持网站安全的重要措施。

CSRF

CSRF(跨站请求伪造) 是一种网络安全攻击，利用用户在受信任网站上的已认证身份，执行未经授权的操作。攻击过程如下:

1. 攻击者构造一个恶意网站或链接。
2. 诱导目标用户点击该链接或访问恶意网站。
3. 如果用户当前已登录目标网站，其身份认证信息 (如 cookies) 会随请求自动发送。
4. 攻击者利用这些认证信息，以用户的身份向目标网站发送伪造请求。
5. 目标网站无法分辨这些请求是否由真实用户发起，从而执行了未经授权的操作。

CSRF 攻击的危险在于，它能绕过身份认证，在用户不知情的情况下执行各种操作，如修改账户信息、进行交易等。为防范 CSRF 攻击，网站需要实施额外的安全措施，如使用 anti-CSRF 令牌、验证 Referer 头等。