Java Web 面试题 总结 解析

1.jsp 和 servlet 有什么区别？

答案：JSP（JavaServer Pages）是一种在HTML中嵌入Java代码的技术，适合用于生成动态内容；Servlet是Java编写的服务器端程序，用于处理HTTP请求和响应。
---------------------------------------------------------------------------------------
JSP（Java Server Pages）和Servlet 是 Java Web 开发中常用的两种技术，它们之间有以下区别：
​
视图层和控制层：JSP 主要负责视图层的展示，即 HTML 页面的生成，可以在 JSP 中嵌入 Java 代码；而 Servlet 主要负责处理请求、执行业务逻辑和生成响应，即控制层的实现。
​
技术特点：JSP 基于 HTML，可以方便地进行页面布局和样式设计，同时支持 Java 代码嵌入和标签库扩展；Servlet 是纯 Java 代码，可以更灵活地控制请求和响应的过程，处理复杂的业务逻辑。
​
开发方式：JSP 是将 HTML 和 Java 代码混合在一个文件中，使用标签来嵌入 Java 代码；Servlet 是一个独立的 Java 类，通过继承 HttpServlet 类来实现请求处理。
​
执行过程：JSP 在首次访问时会被编译成 Servlet，并生成对应的 Servlet 类，在后续的请求中直接执行编译后的 Servlet 类；Servlet 每次请求都会创建一个新的线程来处理，每个线程使用单个 Servlet 实例。
​
可复用性：Servlet 是一个独立的 Java 类，可以在不同的 Web 应用程序中复用；JSP 更适合于简单的视图展示，难以在不同的页面中重复使用。
​
综上所述，JSP 和 Servlet 可以说是相辅相成的，JSP 通过封装了 HTML 和嵌入的 Java 代码，提供了方便的页面展示和交互；而 Servlet 可以处理更复杂的请求和逻辑，实现了灵活的控制层。在开发实践中，通常会将二者结合起来，用 JSP 负责页面展示，用 Servlet 负责请求处理和业务逻辑。

2.jsp 有哪些内置对象？作用分别是什么？

答案：JSP有9个内置对象，包括request、response、session、application、out、page、pageContext、config和exception，用于在JSP页面中访问HTTP请求和其他上下文信息。
---------------------------------------------------------------------------------------
JSP（Java Server Pages）中有以下几个内置对象，它们在 JSP 页面中可以直接使用，享有特殊的作用和功能：
​
request（javax.servlet.http.HttpServletRequest）：代表客户端的 HTTP 请求，可以通过该对象获取请求的信息，如请求参数、请求头等。
​
response（javax.servlet.http.HttpServletResponse）：代表服务器对客户端的 HTTP 响应，可以通过该对象设置响应的信息，如设置响应头、写入响应内容等。
​
session（javax.servlet.http.HttpSession）：代表用户的会话，用于在多个请求之间共享数据。可以通过该对象存储和获取用户的相关信息。
​
application（javax.servlet.ServletContext）：代表整个 Web 应用程序的上下文，用于在应用程序中共享数据。可以通过该对象存储和获取全局的配置信息和属性。
​
out（javax.servlet.jsp.JspWriter）：代表用于向客户端输出内容的输出流对象，可以通过该对象发送数据到客户端。
​
config（javax.servlet.ServletConfig）：代表当前 JSP 页面的配置信息，可以通过该对象获取当前 JSP 页面的初始化参数。
​
page（java.lang.Object）：代表当前 JSP 页面本身，使用该对象可以调用一些页面级别的方法和属性。
​
pageContext（javax.servlet.jsp.PageContext）：代表当前 JSP 页面的上下文对象，包含了对其他内置对象的引用，可以通过该对象访问其他内置对象。
​
这些内置对象提供了丰富的功能和便利的操作，可以在 JSP 页面中使用它们实现各种功能，如获取请求参数、设置响应头、操作会话数据等。同时，我们也可以通过 EL 表达式和 JSTL 标签库来更方便地操作这些内置对象。

3.说一下 jsp 的 4 种作用域？

答案：JSP的四种作用域分别是page（页面）、request（请求）、session（会话）和application（应用程序），用于在不同范围内存储和共享数据。
---------------------------------------------------------------------------------------
在 JSP（Java Server Pages）中，作用域指的是在页面中存储和访问数据的范围。根据作用域的范围不同，JSP 中的作用域可以分为以下四种：
​
pageScope：代表当前页面的作用域，即当前 JSP 页面中所有的 Java 变量。这个作用域是默认的作用域，当未指定作用域时，就会作为当前变量的作用域。
​
requestScope：代表一次 HTTP 请求的作用域，即在一次请求过程中将数据保存到 request 对象中，可以在请求处理的整个过程中使用。通过 request 对象可以共享数据给下一个页面或者下一个 Servlet。
​
sessionScope：代表一个用户会话的作用域，即在一个会话周期中都可以使用的数据，可以用于在不同页面间共享数据。可以通过 HttpSession 来实现会话作用域。
​
applicationScope：代表整个 Web 应用程序的作用域，即在整个应用程序中都可以使用的数据，可以用于在不同用户间共享数据。可以通过 ServletContext 对象来实现全局作用域。
​
这四种作用域的作用范围不同，可以根据具体应用场景来选择使用，以满足不同的需求。在代码中通过 JSP 内置对象（page、request、session、application）来引用这些作用域中的数据，例如，可以使用 
pageScope.xxx、{requestScope.xxx}、sessionScope.xxx、{applicationScope.xxx} 来获取对应作用域中的变量值。

4.session 和 cookie 有什么区别？

答案：Session是在服务器端维护的一种状态信息，保存在服务器内存中；Cookie是在客户端维护 的一种状态信息，保存在客户端的浏览器中。
---------------------------------------------------------------------------------------
Session 和 Cookie 是在 Web 开发中用于跟踪用户状态和存储用户数据的两种常用机制，它们之间有以下区别：
​
存储位置：Session 数据存储在服务器端，通过在客户端浏览器上存储一个 session ID 来进行跟踪；Cookie 数据存储在客户端浏览器上，以文本文件的形式存储在客户端。
​
安全性：Session 相对于 Cookie 较为安全，因为 Session 数据存储在服务器端，客户端只保存一个 session ID，而非敏感数据存储在服务器端，减少了数据泄露风险；Cookie 数据存储在客户端浏览器上，容易受到 XSS（跨站脚本攻击）和 CSRF（跨站请求伪造）等攻击。
​
存储容量：Cookie 的存储容量较小，一般限制在几 KB 到几十 KB 之间；Session 存储容量相对较大，可以达到几十 MB 到几 GB，受服务器配置和硬件资源限制。
​
生命周期：Cookie 具有设定的过期时间，在过期之前一直有效；Session 在用户关闭浏览器或长时间无活动时会过期，或者可以设置 Session 的超时时间。
​
可跨域访问：Cookie 可以设置为跨域访问，即一个域下的网页可以访问其他域下的 Cookie 数据；Session 默认情况下不支持跨域访问，只在当前域内有效。
​
使用方式：开发者可以通过在服务器端代码中使用语言提供的 Session 对象来操作 Session 数据；而对于 Cookie，可以通过在服务器端设置 Cookie 响应头，或通过 JavaScript 在客户端操作 Cookie。
​
综上所述，Session 和 Cookie 都是用于在 Web 开发中存储和跟踪用户数据的机制，但它们的存储位置、安全性、存储容量、生命周期、可跨域访问和使用方式等方面存在一些差异。在实际应用中，根据具体需求和安全考虑，选择合适的机制来管理用户状态和数据。

5.说一下 session 的工作原理？

答案：当客户端发送请求时，服务器为每个客户端创建一个唯一的Session ID，将Session ID保存 在Cookie中或通过URL重写传递给客户端。服务器通过Session ID来查找对应的Session对象，从 而维护客户端会话状态。
---------------------------------------------------------------------------------------
Session 的工作原理如下：
​
客户端发起请求：当客户端（通常是浏览器）向服务器发送请求时，服务器会为该客户端创建一个唯一的 Session ID，并将该 Session ID 作为响应的一部分返回给客户端。
​
Session ID 的保存：服务器可以通过多种方式将 Session ID 发送到客户端进行保存。最常见的方式是通过 Cookie，在响应中设置一个名为 “JSESSIONID” 的 Cookie，并将 Session ID 作为 Cookie 的值。客户端的浏览器会自动在后续的请求中携带该 Cookie。
​
服务器端存储 Session 数据：服务器端会在内存或磁盘中维护一个数据结构（通常是散列表或哈希表），用于存储 Session 数据。通过 Session ID 可以将该数据与特定的客户端关联起来。
​
客户端请求中的 Session ID：每次客户端发送请求时，会自动携带之前保存的 Session ID，可以通过 Cookie，URL 重写或隐藏表单字段等方式传递。
​
服务器端获取 Session 数据：服务器接收到请求后，会解析请求中的 Session ID，并根据该 ID 从存储的 Session 数据中检索和恢复之前保存的数据。
​
读写 Session 数据：在服务器端处理请求的过程中，可以读取和修改 Session 数据。服务器可以根据需要在会话期间持续更新和维护 Session 数据。
​
Session 过期和销毁：Session 有一个有效期，可以定义在服务器端。当会话超时或客户端主动关闭浏览器时，Session 可能会过期或被销毁。服务器可以在会话管理中监视会话状态，并处理过期和销毁的会话。
​
通过以上步骤，Session 可以实现在服务器和客户端之间存储和共享用户状态和数据。它提供了一种有状态的解决方案，使得在 Web 应用程序中跟踪和管理用户会话变得容易和有效。

6.如果客户端禁止 cookie 能实现 session 还能用吗？

答案：如果客户端禁止了Cookie，仍然可以通过URL重写的方式传递Session ID来实现Session功 能。
---------------------------------------------------------------------------------------
如果客户端禁止了 Cookie，Session 仍然可以实现，但需要使用其他机制来传递和管理 Session ID。
​
以下是一些替代方法：
​
URL 重写（URL Rewriting）：在每个生成的链接中附加 Session ID 参数，例如 http://example.com/page?sessionId=abc123。服务器端通过解析 URL 参数来获取 Session ID，并根据该 ID 检索和恢复相应的 Session 数据。这种方式可确保即使禁用了 Cookie，Session 仍然可以正常工作。但需要注意，URL 重写可能会导致安全风险，因为 Session ID 可能会出现在浏览器的地址栏和日志中。
​
隐藏表单字段（Hidden Form Fields）：在每个表单中增加一个隐藏字段，用于存储 Session ID。服务器端接收到请求后，从隐藏字段中提取 Session ID，并检索和恢复相应的 Session 数据。需要确保每个需要传递 Session ID 的表单都包含隐藏字段。这种方式也能够绕过 Cookie 禁用的限制，但需要修改现有的表单并确保所有相关表单都包含隐藏字段。
​
请注意，禁用 Cookie 会导致更复杂的会话管理和更高的安全风险。使用其他方式传递 Session ID（如URL 重写或隐藏表单字段）可能会引入一些额外的开发和维护成本。因此，如果可能，通常建议客户端启用 Cookie 来支持 Session 功能。

7.spring mvc 和 struts 的区别是什么？

答案：Spring MVC和Struts都是Java Web开发框架，但Spring MVC更加灵活、模块化，支持依赖 注入和AOP；而Struts是基于MVC模式的框架，较老，相对来说更加限制。
---------------------------------------------------------------------------------------
Spring MVC 和 Struts 是两个常用的 Java Web 框架，它们之间存在以下区别：
​
架构：Spring MVC 是基于 Spring 框架的一部分，它使用了控制反转（IoC）和依赖注入（DI）的思想，使得应用程序的组件解耦并更易于测试和维护；而 Struts 是一个独立的框架，它采用了经典的 Model-View-Controller（MVC）设计模式。
​
配置方式：Spring MVC 的配置灵活且可扩展，通常使用 XML 或基于注解的方式进行配置；Struts 使用 XML 配置文件进行配置，对于大型应用程序，Struts 配置文件可能会变得复杂。
​
控制器的处理方式：Spring MVC 中的控制器可以是 POJO（Plain Old Java Object），可以通过注解或基于接口的方式进行处理；Struts 中的控制器是一个基于继承的 Action 类，需要继承 Struts 提供的基类，进行方法的覆写。
​
数据绑定：Spring MVC 提供了多样化的数据绑定方式，可以直接绑定表单数据到 POJO 对象，支持数据格式转换和校验；Struts 也提供了数据绑定的机制，但相对来说比较简单，需要手动编写表单数据到 Java 对象的转换逻辑。
​
拦截器和过滤器：Spring MVC 使用拦截器（Interceptor）来实现对请求的预处理和后处理，通过拦截器可以方便地进行跨越业务逻辑和功能模块的处理；Struts 使用过滤器（Filter）进行请求的前置处理和后置处理，过滤器是对请求的全局处理。
​
集成其他技术：由于 Spring MVC 是 Spring 框架的一部分，可以方便地集成 Spring 的其他功能模块，如事务管理、安全性、AOP 等；Struts 也可以集成其他框架和技术，但集成程度相对来说没有 Spring MVC 那么深入。
​
社区和生态系统：Spring MVC 是 Spring 框架的核心组件之一，有着广泛的应用和活跃的社区支持，拥有丰富的第三方库和插件，而 Struts 的社区相对较小，生态系统可能相对较少。
​
综上所述，Spring MVC 和 Struts 在架构、配置方式、控制器处理、数据绑定、拦截器和过滤器、集成其他技术以及社区和生态系统等方面存在一些区别。对于选择哪个框架，可以根据项目需求、团队技术栈和个人喜好来进行评估和选择。

8.如何避免 SQL 注入？

答案：可以使用预编译语句、参数化查询、ORM框架等方式来避免SQL注入，不要直接将用户输入的数据拼接到SQL语句中。
---------------------------------------------------------------------------------------
要避免 SQL 注入，可以采取以下措施：
​
使用参数化的 SQL 语句：不要将用户提供的数据直接插入 SQL 语句中，而是使用参数化 SQL 语句并将用户输入的数据作为参数传递给 SQL 查询。参数化 SQL 语句可以防止 SQL 注入攻击，因为参数化 SQL 语句在执行前会先将参数数据类型化，并对特殊字符进行转义和处理，从而避免 SQL 注入攻击。
​
对用户输入数据进行验证和过滤：对于用户输入的数据，应该进行前端和后端的验证和过滤，确保数据的合法性和正确性。可以通过一些正则表达式或其他过滤技术实现对数据的检查和处理。例如，在用户名处输入条件判断限制掉特殊字符。
​
不要使用动态拼接 SQL 语句：不要将 SQL 动态构建为字符串拼接，因为这种方式容易出现意外的语法错误，并对 SQL 注入攻击形成安全隐患。可以使用 ORM 框架来操作数据库，并使用框架提供的 ORM 接口或语句来保证 SQL 查询的安全。
​
合理设置数据库访问权限：只给予程序所需的最小化的数据库访问权限，限制每个用户或角色对数据库的操作范围，有效地降低 SQL 注入攻击的风险。
​
更新数据库软件和补丁：及时更新数据库软件和安全补丁，确保数据库软件的安全性，并保持软件的最新状态，从而能够有效地保护数据库免受 SQL 注入攻击的威胁。
​
总之，避免 SQL 注入攻击需要开发人员在编写程序时注重代码安全，从多个方面加强对 SQL 查询的安全性控制，确保程序的可靠性和安全性。

9.什么是 XSS 攻击，如何避免？

答案：XSS（Cross-Site Scripting）攻击是指攻击者通过在网页中插入恶意脚本，从而窃取用户信 息。可以避免XSS攻击的方法包括对用户输入进行合适的转义、过滤和验证。
---------------------------------------------------------------------------------------
XSS（Cross-site scripting）攻击，也称为跨站脚本攻击，是一种常见的网络安全攻击，是指攻击者通过在受害者的 Web 页面中注入恶意脚本，从而在受害者的浏览器中进行各种恶意操作，如窃取用户的 Cookie、密码、银行账户等重要信息，或利用受害者的浏览器发送恶意请求等。
​
为了避免 XSS 攻击，可以采取以下措施：
​
对输入和输出进行过滤和转义：对于用户输入的数据，应该在客户端和服务端进行过滤和转义，限制不合法的字符输入，并将合法字符转义成 HTML 实体，以防止恶意脚本被注入到 Web 页面中。可以使用一些现成的安全框架或过滤器来进行过滤和转义。
​
设置 HTTP 头信息：通过设置 HTTP 头信息，可以防止 XSS 攻击的一些形式，例如，可以设置 HTTP Header 的 Content-Security-Policy（CSP）来限制执行 JavaScript 的来源或脚本类型，并通过设置 HTTP Only Cookie 来限制客户端 Cookie 的访问，从而避免 Cookie 被窃取。
​
不信任任何用户输入数据：不要信任来自用户的任何输入数据，无论是表单字段、URL 参数、HTTP 头信息等，都需要在服务端进行验证和过滤，不要将数据直接输出到 Web 页面上。
​
更新和维护软件：及时更新软件并修复安全漏洞，例如，经常更新浏览器、操作系统、Web 服务器的软件版本，并定期对代码进行安全审计和漏洞扫描，从而能够有效地减少 XSS 攻击的风险。
​
总之，为了避免 XSS 攻击，需要注意对输入和输出进行过滤和转义、设置 HTTP 头信息、不信任任何用户输入数据以及更新和维护软件等措施，以防止 XSS 攻击对 Web 应用程序造成危害。

10.什么是 CSRF 攻击，如何避免？

答案：CSRF（Cross-Site Request Forgery）攻击是指攻击者通过欺骗用户在未经授权的情况下执 行操作。可以通过使用验证码、检查Referer头、使用Token验证等方式来避免CSRF攻击。
---------------------------------------------------------------------------------------
CSRF（Cross-Site Request Forgery）攻击，也称为跨站请求伪造攻击，是一种常见的网络安全攻击，攻击者通过诱使用户在受信任网站上执行恶意操作，从而在用户的身份验证状态下执行未经授权的操作，如修改密码、发布消息等。
​
为了避免 CSRF 攻击，可以采取以下措施：
​
使用随机令牌：在用户执行敏感操作时，可以为每个请求生成一个随机的令牌（CSRF Token），将其与请求一起发送，并在服务器端进行验证。这样，即使恶意网站伪造请求，但由于缺乏有效的令牌，请求将被服务器拒绝。
​
检查来源头：服务器可以检查请求中的来源头（Referer Header），验证请求的来源是否合法。虽然来源头可以被伪造，但在一定程度上可以增加攻击的难度。
​
设置 SameSite 属性：设置 Cookie 的 SameSite 属性为Strict或Lax，以限制跨站点的 Cookie 传递，从而降低 CSRF 攻击的成功率。
​
验证身份和权限：在敏感操作执行前，要求用户重新进行身份验证，例如输入密码、OTP 等。并且，应该对敏感操作进行严格的权限验证，确保只有授权用户可以执行。
​
使用验证码：在需要进行敏感操作之前，可以要求用户通过验证码验证，这可以有效阻止被自动化脚本发起的 CSRF 攻击。
​
更新和维护软件：经常更新Web应用程序和框架的软件版本，并及时修复安全漏洞，以减少受到 CSRF 攻击的风险。
​
审查代码：定期进行代码审计，识别潜在的 CSRF 漏洞，特别是检查是否存在缺乏身份验证或权限验证的敏感操作。
​
总之，为了避免 CSRF 攻击，应使用随机令牌、检查来源头、设置 SameSite 属性、验证身份和权限、使用验证码、更新和维护软件以及审查代码等措施，加强对用户请求的验证与防护，以防止 CSRF 攻击对 Web 应用程序造成危害。