2016 实习招聘面试经历 - 3

文章写于 2016 年,旧的博客不维护了,一些文章直接迁移到这边来。本文为当时记录的第三篇,记得应该是腾讯音乐的内推一面/二面。后面内推挂了,走的实习招聘。javascript

前端跨域

  • 讲jsonp的原理, 如何实现
  • jsonp的安全性: 当时本身说的是可不能够判断来源,好比请求头,域名.而后面试官说jsonp是get请求,没有origin的.我又猜想用reffer? 嗯,这个对了;
    我还猜想是否是用cookie和session.可是直接的script请求是不能带上这个的.
    面试官让我再想,我就猜可不能够传多一个验证的字段验证身份.对了.后面本身看书发现了这种方法就是token.记录以下:

先介绍CSRF: 跨站请求伪造,cross site requrest forgery.
意思是跨域发出请求,请求是身份认证后的(除了referer不同,cookie是同样的)
原理: 受害者必须依次完成两个步骤:
  1.登陆受信任网站A,并在本地生成Cookie。
  2.在不登出A的状况下,访问危险网站B。
cookie发送:若是是内存cookie,均可以正常发送,若是是本地cookie,须要带有p3p属性.
get请求能够经过img等标签,post请求直接经过form表单提交.html

CSRF攻击是源于WEB的隐式身份验证机制!WEB的身份验证机制虽然能够保证一个请求是来自于某个用户的浏览器,但却没法保证该请求是用户批准发送的!前端

防护:java

  • Cookie Hashing, 全部表单中包含同一个伪随机值,表单提交的时候提交这个cookie(加密后)进行验证
  • 用验证码,能彻底解决,可是用户体验很差
  • One-Time Token, 不一样的表单包含一个不一样的伪随机值.
  • 服务端给一个token,token可能包含时间戳,用户名id,随机字符串
  • 限制Session Cookie的生命周期
  • 检查Referer
  • 对于jsonp,过滤callback函数名,按照 JSON 格式标准输出 Content-Type 及编码( Content-Type : application/json; charset=utf-8 )。

参考: 浅谈CSRF攻击方式jquery

跨域有没有额外的请求? 当时说没有=.= 后来想到又OPTIONS,本身确实遇到过的.
OPTIONS的用途:ios

  1. 获取服务器支持的HTTP请求方法;也是黑客常用的方法。
  2. 用来检查服务器的性能。例如:AJAX进行跨域请求时的预检,须要向另一个域名的资源发送一个HTTP OPTIONS请求头,用以判断实际发送的请求是否安全。

跨域的话,有没有遇到传cookie的问题?没有=.= 怎么解决? 查了一下资料,大概是这几种:面试

  1. 在后端提供一个获取其余域名下的全部cookie的接口,前端拿到cookie直接设置/或者后台返回设置cookie的js代码,前端jsonp加载
  2. 经过script发起一个请求,请求一个后端接口,发送一个加密的key,服务端验证key的合法性,在接口返回中写入登录成功的cookie
  3. sohu的解决方法: 在登录域名passport.sohu.com下登录,经过隐藏的iframe提交登录,返回内容写入成功登录的cookie,此时cookie只有passport,而后前端经过登录成功的标志操做iframe请求,带上cookie.后端检查到成功登录的cookie后返回一段发起多个登录请求的html片断; 这段html会请求一个加密后的17173的登录url,这个连接就包含2中讲的key了,后面就和2同样. 在IE中,须要在响应内容的头部加入P3P.

其实当时若是不太紧张应该是能够想出来的=.= 当时说本身没遇到不会.
参考: 实现跨域cookie共享(转载)shell

移动端相关

$('elementsSetThatCanBeTapped').on('tap', function(e) {
   e.preventDefault();
   e.stopPropagation();
   $(this).off('click');
})
复制代码

看起来是解除了click事件,阻止默认行为和冒泡.我试试看..嗯试了一下真的能够.可是若是能够,不要绑定click事件就行了吧…上面差很少就是这么作了.不过若是有事件委托那不太同样.果真面试的时候脑子不顶用啊哈哈.json

  • 阻止事件冒泡/默认事件怎么作

XSS

问我还有没有了解其余前端安全.说了XSS.Cross Site Scripting.跨站脚本.然而重点不在跨站上.
发生在目标网站中目标用户的浏览器层面上,当用户浏览器渲染整个HTML文档的过程当中出现了不被预期的脚本指令并执行时,XSS发生了.
跨站是由于通常攻击都是获取第三方的脚本资源(script请求).分为三种:反射型,存储型,DOMXSS后端

  • 反射型: XSS代码在url中做为输入提交到服务端,服务端解析后响应并在响应内容中出现这段xss代码,浏览器执行.(get,跳转)
  • 存储型: XSS代码存在服务端,好比留言板
  • DOMXSS: 经过各类输入点/输出点进行攻击(输入:document.cookie/location/url),(输出:docuemnt.write/window.open…)

防护措施:

不要在页面中插入任何不可信数据,除非这些数已经进行了编码 在将不可信数据插入到HTML标签之间时,对这些数据进行HTML Entity编码.编码的有6个: (当时蒙对了4个=.=)

& --> &
< --> &lt;
> --> &gt;
" --> &quot;
' --> &#x27;
/ --> &#x2F;
复制代码

不推荐将单引号( ‘ )编码为 ' 由于它并非标准的HTML标签 须要对斜杠号( / )编码,由于在进行XSS攻击时,斜杠号对于关闭当前HTML标签很是有用

  • 在将不可信数据插入到HTML属性里时,对这些数据进行HTML属性编码 属性必定用引号,属性里的引号就进行编码
  • 在将不可信数据插入到SCRIPT里时,对这些数据进行SCRIPT编码
  • 在将不可信数据插入到Style属性里时,对这些数据进行CSS编码
  • 在将不可信数据插入到HTML URL里时,对这些数据进行URL编码

参考: 防护 XSS 的七条原则

相关文章
相关标签/搜索