Java Web
64. 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类，这个类的Service方式用于生成对客户端的响应。
65. jsp 有哪些内置对象？感化离别是什么？
JSP有9个内置对象：
request：封装客户端的恳求，个中包含来自GET或POST恳求的参数；
response：封装办事器对客户端的响应；
pageContext：经由该对象能够获取其他对象；
session：封装用户会话的对象；
application：封装办事器运行情况的对象；
out：输出办事器响应的输出流对象；
config：Web应用的设置对象；
page：JSP页面自己（相当于Java法式中的this）；
exception：封装页面抛出非常的对象。
66. 说一下 jsp 的 4 种感化域？
JSP中的四种感化域包罗page、request、session和application，具体来说：
page代表与一个页面相关的对象和属性。
request代表与Web客户机发出的一个恳求相关的对象和属性。一个恳求或者跨越多个页面，涉及多个Web组件；需要在页面显露的暂时数据能够置于此感化域。
session代表与某个用户与办事器竖立的一次会话相关的对象和属性。跟某个用户相关的数据应该放在用户本身的session中。
application代表与整个Web应用法式相关的对象和属性，它实质上是跨越整个Web应用法式，包罗多个页面、恳求和会话的一个全局感化域。
67. session 和 cookie 有什么区别？
因为HTTP和谈是无状况的和谈，所以办事端需要记录用户的状况时，就需要用某种机制来识具体的用户，这个机制就是Session.典型的场景好比购物车，当你点击下单按钮时，因为HTTP和谈无状况，所以并不知道是哪个用户把持的，所以办事端要为特定的用户建立了特定的Session，用用于标识这个用户，而且跟踪用户，如许才知道购物车里面有几本书。这个Session是留存在办事端的，有一个独一标识。在办事端留存Session的方式好多，内存、数据库、文件都有。集群的时候也要考虑Session的转移，在大型的网站，一样会有专门的Session办事器集群，用来留存用户会话，这个时候 Session 信息都是放在内存的，使用一些缓存办事好比Memcached之类的来放 Session。
思虑一下办事端若何识别特定的客户？这个时候Cookie就登场了。每次HTTP恳求的时候，客户端都邑发送响应的Cookie信息到办事端。实际上大多数的应用都是用 Cookie 来实现Session跟踪的，第一次建立Session的时候，办事端会在HTTP和谈中敷陈客户端，需要在 Cookie 里面记录一个Session ID，今后每次恳求把这个会话ID发送到办事器，我就知道你是谁了。有人问，若是客户端的浏览器禁用了 Cookie 怎么办？一样这种情形下，会使用一种叫做URL重写的手艺来进行会话跟踪，即每次HTTP交互，URL后背都邑被附加上一个诸如 sid=xxxxx 如许的参数，办事端据此来识别用户。
Cookie其实还能够用在一些轻易用户的场景下，设想你某次上岸过一个网站，下次登录的时候不想再次输入账号了，怎么办？这个信息能够写到Cookie里面，接见网站的时候，网站页面的剧本能够读取这个信息，就主动帮你把用户名给填了，可以轻易一下用户。这也是Cookie名称的由来，给用户的一点利益。所以，总结一下：Session是在办事端留存的一个数据构造，用来跟踪用户的状况，这个数据能够留存在集群、数据库、文件中；Cookie是客户端留存用户信息的一种机制，用来记录用户的一些信息，也是实现Session的一种体式。
68. 说一下 session 的工作道理？
其实session是一个存在办事器上的雷同于一个散列表格的文件。里面存有我们需要的信息，在我们需要用的时候能够从里面掏出来。雷同于一个大号的map吧，里面的键存储的是用户的sessionid，用户向办事器发送恳求的时候会带上这个sessionid。这时就能够从中掏出对应的值了。
69. 若是客户端禁止 cookie 能实现 session 还能用吗？
Cookie与 Session，一样认为是两个自力的器材，Session采用的是在办事器端连结状况的方案，而Cookie采用的是在客户端连结状况的方案。但为什么禁用Cookie就不克获得Session呢？因为Session是用Session ID来确定当前对话所对应的办事器Session，而Session ID是经由Cookie来传递的，禁用Cookie相当于失去了Session ID，也就得不到Session了。
假定用户封闭Cookie的情形下使用Session，其实现途径有以下几种：
设置php.ini设置文件中的“session.use_trans_sid = 1”，或许编译时打开打开了“--enable-trans-sid”选项，让PHP主动跨页传递Session ID。
手动经由URL传值、隐藏表单传递Session ID。
用文件、数据库等形式留存Session ID，在跨页过程中手动挪用。
70. spring mvc 和 struts 的区别是什么？阻挡机制的分歧
Struts2是类级其余阻挡，每次恳求就会建立一个Action，和Spring整应时Struts2的ActionBean注入感化域是原型模式prototype，然后经由setter，getter吧request数据注入到属性。Struts2中，一个Action对应一个request，response上下文，在领受参数时，能够经由属性领受，这解说属性参数是让多个方式共享的。Struts2中Action的一个方式能够对应一个url，而其类属性却被所有方式共享，这也就无法用讲解或其他体式标识其所属方式了，只能设计为多例。
SpringMVC是方式级其余阻挡，一个方式对应一个Request上下文，所以方式直接根基上是自力的，独享request，response数据。而每个方式同时又何一个url对应，参数的传递是直接注入到方式中的，是方式所独有的。处理究竟经由ModeMap返回给框架。在Spring整应时，SpringMVC的Controller Bean默认单例模式Singleton，所以默认对所有的恳求，只会建立一个Controller，有应为没有共享的属性，所所以线程平安的，若是要改变默认的感化域，需要添加@Scope讲解点窜。
Struts2有本身的阻挡Interceptor机制，SpringMVC这是用的是自力的Aop体式，如许导致Struts2的设置文件量照样比SpringMVC大。底层框架的分歧
Struts2采用Filter（StrutsPrepareAndExecuteFilter）实现，SpringMVC（DispatcherServlet）则采用Servlet实现。Filter在容器启动之后即初始化；办事住手今后坠毁，晚于Servlet。Servlet在是在挪用时初始化，先于Filter挪用，办事住手后销毁。机能方面
Struts2是类级其余阻挡，每次恳求对应实例一个新的Action，需要加载所有的属性值注入，SpringMVC实现了零设置，因为SpringMVC基于方式的阻挡，有加载一次单例模式bean注入。所以，SpringMVC斥地效率和机能高于Struts2。设置方面
spring MVC和Spring是无缝的。从这个项目的治理和平安上也比Struts2高。
71. 若何避免 sql 注入？
PreparedStatement（简洁又有效的方式）
使用正则表达式过滤传入的参数
字符串过滤
JSP中挪用该函数搜检是否包函不法字符
JSP页面判断代码
72. 什么是 XSS 冲击，若何避免？
XSS冲击又称CSS,全称Cross Site Script （跨站剧本冲击），其道理是冲击者向有XSS破绽的网站中输入恶意的 HTML 代码，当用户浏览该网站时，这段 HTML 代码会主动执行，从而达到冲击的目的。XSS 冲击雷同于 SQL 注入冲击，SQL注入冲击中以SQL语句作为用户输入，从而达到查询/点窜/删除数据的目的，而在xss冲击中，经由插入恶意剧本，实现对用户游览器的掌握，获取用户的一些信息。 XSS是 Web 法式中常见的破绽，XSS 属于被动式且用于客户端的冲击体式。
XSS提防的总体思路是：对输入(和URL参数)进行过滤，对输出进行编码。
73. 什么是 CSRF 冲击，若何避免？
CSRF（Cross-site request forgery）也被称为 one-click attack或许 session riding，中文全称是叫跨站恳求伪造。一样来说，冲击者经由伪造用户的浏览器的恳求，向接见一个用户本身曾经认证接见过的网站发送出去，使方针网站领受并误认为是用户的真实把持而去执行号令。常用于窃取账号、转账、发送子虚新闻等。冲击者行使网站对恳求的验证破绽而实现如许的冲击行为，网站可以确认恳求起原于用户的浏览器，却不克验证恳求是否源于用户的真实意愿下的把持行为。
若何避免：
1. 验证 HTTP Referer 字段
HTTP头中的Referer字段记录了该 HTTP 恳求的起原地址。在平日情形下，接见一个平安受限页面的恳求来自于统一个网站，而若是黑客要对其实施 CSRF
冲击，他一样只能在他本身的网站组织恳求。是以，能够经由验证Referer值来防御CSRF 冲击。
2. 使用验证码要害把持页面加上验证码，后台收到恳求后经由判断验证码能够防御CSRF。但这种方式对用户不太友好。
3. 在恳求地址中添加token并验证
CSRF 冲击之所以可以成功，是因为黑客能够完全伪造用户的恳求，该恳求中所有的用户验证信息都是存在于cookie中，是以黑客能够在不知道这些验证信息的情形下直接行使用户本身的cookie 来经由平安验证。要抵当 CSRF，要害在于在恳求中放入黑客所不克伪造的信息，而且该信息不存在于 cookie 之中。能够在 HTTP 恳求中以参数的形式到场一个随机发生的 token，并在办事器端竖立一个阻挡器来验证这个 token，若是恳求中没有token或许 token 内容不准确，则认为或者是 CSRF 冲击而拒绝该恳求。这种方式要比搜检 Referer 要平安一些，token 能够在用户上岸后发生并放于session之中，然后在每次恳求时把token 从 session 中拿出，与恳求中的 token 进行比对，但这种方式的难点在于若何把 token 以参数的形式到场恳求。
对于 GET 恳求，token 将附在恳求地址之后，如许 URL 就酿成 http://url?csrftoken=tokenvalue。
而对于 POST 恳求来说，要在 form 的最后加上
，如许就把token以参数的形式到场恳求了。
4. 在HTTP 头中自界说属性并验证这种方式也是使用 token 并进行验证，和上一种方式分歧的是，这里并不是把 token 以参数的形式置于 HTTP 恳求之中，而是把它放到 HTTP 头中自界说的属性里。经由 XMLHttpRequest 这个类，能够一次性给所有该类恳求加上 csrftoken 这个 HTTP 头属性，并把 token 值放入个中。如许解决了上种方式在恳求中到场 token 的未便，同时，经由 XMLHttpRequest 恳求的地址不会被记录到浏览器的地址栏，也不消担心 token 会透过 Referer 泄露到其他网站中去。
