JAVA实习生面试总结 ———— JAVAWEB篇

JAVA实习生面试总结 ———— JAVAWEB篇 1、JSP和Servlet有什么区别？

• JSP经过编译后就变成了Servlet（JSP的本质就是Servlet，JVM只能识别JAVA的类，不能识别JSP的代码，WEB容器将JSP的代码编译成JVM能够识别的JAVA类）。
• JSP更擅长表现于页面显示，Servlet更擅长于逻辑控制。
• Servlet中没有内置对象，JSP中的内置对象都是必须通过HttpServletRequest对象，HttpServletResponse对象以及HttpServlet对象得到。
• JSP是Servlet的一种简化，使用JSP只需要完成程序员需要输出到客户端的内容，JSP中给的 JAVA脚本如何镶嵌到一个类中，由JSP容器完成。而Servlet则是个完整的JAVA类，这个类的Servlce方法用于生成对客户端的响应。

2、说一下jsp的四种作用域？

• page：代表于一个页面相关的对象和属性。
• request：代表与Web客户端发出的一个请求相关的对象和属性。一个请求可能跨越多个页面，涉及多个Web组件；需要在页面显示的临时数据可以置于此作用域。
• session：代表某个用户与服务器建立的一次会话相关的对象和属性。跟某个用户相关的数据应该放在用户自己的session中。
• application：代表与整个Web应用程序相关的对象和属性，它实质上是跨越整个Web应用程序，包括多个页面、请求和会话的一个全局作用域。

3、请说一下session的工作原理？

session是一个存在于服务器上的类似于一个散列表格式的文件。里面存有我们需要的信息，在我们需要用的时候可以从里面取出来。类似于一个大号的map（服务器端的一个集合），里面的**键（key）**存储的是用户的sessionid，用户向服务器发送请求的时候会带上这个sessionid，这时就可以从中取出对应的值了。

4、session 和 cookie 有什么区别？

cookie 和 Session 的区别？

cookie 的概念：客户端会话技术，服务器端将数据保存到客户端。

Seesion 的概念：服务器端会话技术，在一次会话的多次请求间共享数据，（客户端）将数据保存在服务器端的对象中（HttpSession）。

• 存储位置不同：cookie 存储在客户端浏览器，Session 存储在服务器端。
• 存储容量不同：cookie 存储数据的容量很小（通常为 4KB），对同一个域名下的总 cookie 数量也有限制（20个），而 Session的存储容量较大。
• 安全性不同：cookie 的安全性较低，而 Session 安全性较高。

cookie 和 Session 的生命周期不同：

• 当浏览器关闭后，cookie 数据被销毁。
• 当服务器对象关闭的时候，Session 数据被销毁。或者 Session 对象调用invalidate()主动销毁，也可以设置定时销毁 Session 对象。

cookie 和 Session的使用案例：

cookie：

• 记住上一次访问时间。
• 在不登陆的情况下，完成服务器对客户端的身份识别。
• 存少量的不太敏感的数据。

Session：

• 存储登录验证码
• 用户登录的信息。

5、如果客户端禁止cookie能实现session还能用嘛？

cookie和Session，一般认为是两个独立的东西，Session采用的是在服务器端保持的状态，而cookie采用的是在客户端保持状态的方案。但为什么禁用cookie就不能得到Session呢？

因为Session是用JSESSIONID来确定当前对话所对应的服务器Session，而JSESSIONID是通过cookie来传递的，禁用cookie相当于失去了JSESSIONID，也就得不到服务器端的Session了。

总结就是一句话：JSESSIONID就是在cookie里面，禁用了cookie就得不到JSESSIONID，就拿不到Session`

解决方案：

• 先判断当前的Web组件是否启动Session，假如没有，直接返回参数url。
• 再判断客户端浏览器是否支持cookie，假如支持，直接返回参数url；假如不支持，就在参数url中假如JSESSIONID信息，然后返回修改后的url。

6、forward 和 redirect 的区别？

• forward 请求转发是一次请求，redirect 重定向是两次请求；
• 重定向的第二个请求一定是GET请求；
• 请求转发的目标只能是本应用中的资源，重定向的目标可以是其他应用。
• 请求转发后浏览器地址栏不会有变化，而重定向会有变化，因为重定向是两个请求。
• 请求转发对Servlet01和Servlet02的请求方法是相同的，即要么都是GET，要么都是POST，因为请求转发是一个请求；

7、什么是CSS攻击，如何避免？

CSS攻击，即跨站脚本攻击（Cross Site scripting），它是web程序中最常见的漏洞。

原理：

攻击者往web页面里面插入恶意的HTML代码（Javascript、CSS、Hyml标签等），当某个用户浏览器该页面的时候，嵌入其中的HTML代码会被执行，从而达到恶意攻击用户的目的。如盗取用户cookie执行一系列操作，破坏页面结构，重定向到其他网站。

案例：恶意的在某个网站的登录页面加入HTML代码（Javascript、Css、Html标签等），当用户输入账号密码登录后，这段恶意的HTML代码会被执行，从而获取用户的账号密码信息。

预防思路：

• web页面中可由用户输入的地方，对输入的数据转义、过滤处理。
• 后台输出页面的时候，也需要对输出内容进行转义、过滤处理（因为攻击者可能其他方式吧恶意脚本写入数据库）。
• 前端对html标签属性、css属性赋值的地方进行校验。

8、什么是CSRF攻击，如何避免？

CSRF：Cross Site Request Forgery（跨站点请求伪造）。

CSRF攻击者在用户已经登录目标网站之后，诱使用户访问一个攻击页面，利用目标网站对用户的信任，以用户身份在攻击页面对目标网站发起伪造用户操作的请求，达到攻击目的。

案例：就好比用户A，在自己电脑上通过自己的账号密码登录了B网站（登录用户身份识标识被XX网站信任），当A在浏览网页的时候，不经意间打开了钓鱼网站X，这时候X就可借着B网站对用户A的信任标识，以用户A的身份去访问B网站，并对其进行攻击！

预防方法：

• 添加并验证token
• 添加自定义http请求头
• 使用post请求
• 敏感操作添加验证码

9、说下原生JDBC操作数据库流程？

• 第一步：Class.forName()加载数据库连接驱动
• 第二步：DriverManager.getConnection()获取连接对象
• 第三步：根据SQL获取sql会话对象，有两种方式：Statement、PrepareStatement
• 第四步：执行SQL处理结果集，执行SQL前如果有参数值就设置参数值setXXX()
• 第五步：关闭结果集，关闭会话，关闭连接。

10、如何避免SQL注入？

• 预编译SQL（使用PrepareStatement），参数化查询方式，避免SQL拼接。
• 校验参数的数据格式是否合法（恶意使用正则或者特殊字符的判断）。
• 对进入数据库的特殊字符进行转义处理，或者编码转换。

11、单点登录的三种实现方式

单点登录SSO（Single Sign On）说的简单点就是在一个多系统共存的环境下，用户在一处登录后，就不用再其他系统中登录，也就是用户的一次登录能得到其他所有系统的信任。单点登录再大型网站里面使用得非常频繁，例如像阿里巴巴这样得网站，在网站得背后是成百上千的子系统，用户一次操作或者交易可能涉及到几十个子系统的协作，如果每个子系统都需要用户认证，不仅用户会疯掉，各子系统也会认为这种重复认证授权的逻辑搞疯掉。实现单点登录说到底就是要解决如何产生和存储那个信任，再就算其他系统如何验证这个信任的有效性，因此要点也就以下两个：

• 存储信任
• 验证信任

11.1、以cookie作为凭证媒介

最简单的单点登录实现方式，是使用cookie作为媒介，存放用户凭证。

用户登录父应用之后，应用返回一个加密的cookie，当用户访问子应用的时候，携带上这个cookie，授权应用解密cookie并进行校验，校验通过则登录当前用户。

不难发现以上方式把信任存储再客户端的cookie中，这种方式很容易令人疑惑：

• cookie不安全
• 不能跨域实现免登录

对于第一个问题，通过加密cookie可以保证安全性，当然这是再源代码不泄露的前提下。如果cookie的加密算法泄漏，攻击者通过伪造cookie信任标识，从而产生上面所说的CSRF攻击。

11.2、通过JSONP实现

对于跨域问题，可以使用JSONP实现。

用户在父应用中登录后，跟Session匹配的cookie会存到客户端中，跟Session 匹配的cookie会存放到客户端中，当用户需要登录子应用的时候，授权应用访问提供的JSONP接口，并在请求中带上父应用域名下的cookie，父应用接收到请求，验证用户的登录状态，返回加密的信息，子应用通过解析返回来的加密信息来验证用户，如果通过验证则登录用户。

这种方式虽然能解决跨域问题，但是安全性其实跟把信任存储到cookie是差不多的。如果一旦cookie的解密算法泄露了，攻击者可以在本地建立了一个实现了登录接口的假冒父应用，通过绑定host来把子应用发起的请求指向本地的假冒父应用，并做出回应。

因为攻击者完全可以按照加密算法来伪造响应请求，子应用接收到这个响应之后一样可以通过验证，并且登录特定用户。

11.3、通过页面重定向的方式

最后一种介绍的方式，是通过父应用和子应用来回重定向中进行通信，实现信息的安全传递。父应用提高一个GET方式的登录接口，用户通过子应用重定向连接的方式访问这个接口，如果用户还没有登录，则返回一个登录的页面，用户输入账号密码进行登录。如果用户已经登录了，则生成加密的Token，并且重定向到子应用提供的验证Token的接口，通过解密和校验之后，子应用登录当前用户。

中进行通信，实现信息的安全传递。父应用提高一个GET方式的登录接口，用户通过子应用重定向连接的方式访问这个接口，如果用户还没有登录，则返回一个登录的页面，用户输入账号密码进行登录。如果用户已经登录了，则生成加密的Token，并且重定向到子应用提供的验证Token的接口，通过解密和校验之后，子应用登录当前用户。