MVC模式

MVC（Model-View-Controller）是一种广泛使用的软件设计模式，用于简化应用程序的开发过程。它通过分离数据访问、用户界面和业务逻辑，使得应用程序的结构更加清晰。

MVC的组成部分

1. Model（模型）

定义：代表应用程序的数据和业务逻辑。职责：

与数据库进行交互处理数据的逻辑操作在JavaWeb中的实现：

使用POJO（Plain Old Java Object）类，通常与数据库表一一对应DAO（Data Access Object）负责数据库交互Service层实现业务逻辑可使用ORM（Object-Relational Mapping）框架如Hibernate来简化数据库操作

2. View（视图）

定义：负责将模型的数据呈现给用户。职责：展示数据，提供用户界面。在JavaWeb中的实现：

常用JSP（JavaServer Pages）也可使用现代模板引擎如Thymeleaf

3. Controller（控制器）

定义：处理用户请求，协调模型和视图。职责：

接收用户输入调用模型的业务逻辑更新视图在JavaWeb中的实现：

传统方式使用Servlet在Spring框架中使用@Controller注解的类

JSP内置对象

JSP提供了几个内置对象，极大地简化了Web开发过程。以下是主要内置对象的概述：

request (HttpServletRequest)

传递客户端发送给服务端的请求包含参数、URL、头信息等response (HttpServletResponse)

承载服务端向客户端发送的响应可设置响应头、状态码等pageContext (PageContext)

提供对其他内置对象的访问包含页面范围的方法，如属性的获取、设置和删除session (HttpSession)

存储会话期间的状态信息application (ServletContext)

在整个应用程序范围内共享数据out (JspWriter)

向客户端发送HTML内容config (ServletConfig)

包含初始化Servlet的参数page (Object)

表示当前Servlet对象exception (Throwable)

仅在错误页面（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文件中的<session-config>来设置超时时间。

2. 手动删除

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

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

3. 服务器重启

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

4. 浏览器关闭

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

5. 服务器特定行为

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

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

最佳实践

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

注意：具体行为可能因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()方法此方法用于释放资源，执行清理操作

注意事项

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

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

SQL注入攻击及其防范措施

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

使用预编译语句（Prepared Statements）

原理：在执行SQL语句前，先确定查询结构，再传入参数。优势：参数不会被解释为SQL代码，有效防止注入。实现：如在Java中使用PreparedStatement类。采用参数化查询

与预编译语句类似，确保用户输入被视为数据而非代码。适用于各种编程语言和数据库系统。严格的用户输入验证

对所有用户输入进行过滤和验证。例如：限制用户名只能包含字母和数字。拒绝或转义潜在危险的字符。实施最小权限原则

严格控制数据库访问权限。只赋予用户完成必要操作的最小权限。即使发生注入，也可限制潜在危害。

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

XSS攻击与防御简介

XSS攻击

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

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

防止XSS的方法

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

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

CSRF

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

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

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