XSS跨站脚本攻击：
答：XSS （Cross-Site Scripting）跨站脚本攻击是一种常见的安全漏洞，恶意攻击者在用户提交的数据中加入一些代码，将代码嵌入到了Web页面中，从而可以盗取用户资料，控制用户行为或者破坏页面结构和样式等。为了和 CSS 区分，这里把攻击的第一个字母改成了 X，于是叫做 XSS。
最简单的就是当我们提交一个查询后弹出一个alert页面，却无论如何都关不掉，这就是发生了XSS跨站脚本攻击。
XSS产生原因：
XSS产生的原因是过于信任客户端的数据，没有做好过滤或者转义等工作。如果客户端上传的数据中插入一些符号以及javascript代码，那么这些数据将会成为应用代码中的一部分了，这样就造成了XSS攻击。
XSS分类：
存储型：攻击者将恶意代码存储到了数据库中，在响应浏览器请求的时候返回恶意代码，并且执行。这种攻击常见于带有用户保存数据的网站功能；
反射型：将恶意代码放在URL中，将参数提交到服务器。服务器解析后响应，在响应结果中存在XSS代码，最终通过浏览器解析执行；
DOM型：取出和执行恶意代码由浏览器端完成，属于前端 JavaScript的安全漏洞。
XSS防御：
对重要的 cookie设置 httpOnly, 防止客户端通过document.cookie读取 cookie；
对输入内容的特定字符进行编码，前端后端都可以对传入的内容进行过滤，去掉带javascript等字段的输入
CSRF跨站请求伪造：
答：CSRF（ Cross-site request forgery）跨站请求伪造，也是一种常见的安全漏洞。XSS相当于是控制了站点内的信任用户，而CSRF则通过伪装成受信任用户的请求来利用受信任的网站。
CSRF举例：
用户登录受信任网站A，并在本地生成登录态Cookie。（如果用户没有登录网站A，那么网站B在获取A网站的信息并且去请求网站A的接口时，会提示登录）在不登出A的情况下，访问恶意网站B，那么网站B得到了网站A的所有信息，然后B网站去请求A网站的接口，伪装成A网站的正常请求为所欲为。
下边以示意图来说明CSRF整个流程：
注意：
CSRF中恶意网站仅仅是伪装成了正常用户，但是其并不可以直接获取到正常用户的登录态cookie等信息。如果不做防御，被攻击网站服务器是无法区分是否是冒用用户，因为当前请求确实带着登录凭证等信息。
CSRF防御：
Referer 头验证：在 HTTP 头中有一个字段叫 Referer，它记录了该 HTTP 请求的来源地址。不靠谱，Referer可以被改变；
Token验证：服务器发送给客户端一个Token，客户端提交的表单中（或者URL上）带着这个Token。如果这个Token 不合法，那么服务器拒绝这个请求。
双重Cookie验证：利用恶意网站无法获取cookie信息，仅可冒用的特点，我们将cookie中的参数取出来，加入到请求参数中，服务端进行校验，如果参数中没有附加额外的cookie中的参数，那么就拒绝请求。
CSRF和XSS的区别有哪些呢？
CSRF攻击需要用户先登录网站A，恶意网站B获取到A网站用户的 cookie；
XSS攻击则不需要登录。
CSRF攻击本质是利用网站A本身的漏洞，去请求网站A的相关接口；
XSS攻击向网站 A 注入恶意代码，然后通过执行恶意代码，篡改了网站A的内容。
SQL注入：
答：SQL注入是指通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器，执行恶意的SQL命令。
SQL注入就是服务端将客户端传入的恶意SQL语句直接进行了执行，这样会导致问题出现。比如说用户在登录的时候，使用了or 1=1来完成身份验证和授权。
SQL注入是一种流行的攻击攻击方法，但是通过一些手段是可以防御该攻击的，常见的防御手段如下：
使用预编译语句，比如MyBatis中的SQL语句使用#号代替$符号。
使用安全的存储过程来防止SQL注入。
对客户端的输入进行数据类型的检查等。
