2016 實習招聘面試經歷 - 3

文章寫於 2016 年，舊的博客不維護了，一些文章直接遷移到這邊來。本文爲當時記錄的第三篇，記得應該是騰訊音樂的內推一面/二面。後面內推掛了，走的實習招聘。

前端跨域

• 講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表單提交.

CSRF攻擊是源於WEB的隱式身份驗證機制！WEB的身份驗證機制雖然能夠保證一個請求是來自於某個用戶的瀏覽器，但卻沒法保證該請求是用戶批准發送的！

防護：

• 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攻擊方式

跨域有沒有額外的請求? 當時說沒有=.= 後來想到又OPTIONS,本身確實遇到過的.
OPTIONS的用途:

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共享(轉載)

移動端相關

• tap的實現原理,解決什麼問題(300ms是系統爲了檢測是否是雙擊)
• 一個元素保留了tap事件和click事件,怎麼阻止click事件的觸發 參考StackOverlow: Prevent click event after handling jQuery Mobile tap event on iOS

$('elementsSetThatCanBeTapped').on('tap', function(e) {
   e.preventDefault();
   e.stopPropagation();
   $(this).off('click');
})
複製代碼

看起來是解除了click事件,阻止默認行爲和冒泡.我試試看..嗯試了一下真的能夠.可是若是能夠,不要綁定click事件就行了吧…上面差很少就是這麼作了.不過若是有事件委託那不太同樣.果真面試的時候腦子不頂用啊哈哈.

• 阻止事件冒泡/默認事件怎麼作

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 的七條原則