web前端面試題合輯(四)

Ajax/ ES6/Http/安全等知識

  • Ajax是什麼? 如何創建一個Ajax
    • Ajax的全稱:Asynchronous Javascript And XML
    • Ajax是一種用於創建快速動態網頁的技術, 異步的JavaScriptXML

    所謂異步,在這裏簡單地解釋就是:向服務器發送請求的時候,我們不必等待結果,而是可以同時做其他的事情,等到有了結果它自己會根據設定進行後續操作,與此同時,頁面是不會發生整頁刷新的,提高了用戶體驗。

    • 創建
      (1)創建XMLHttpRequest對象,也就是創建一個異步調用對象
      (2)創建一個新的HTTP請求,並指定該HTTP請求的方法、URL及驗證信息
      (3)設置響應HTTP請求狀態變化的函數
      (4)發送HTTP請求
      (5)獲取異步調用返回的數據
      (6)使用JavaScriptDOM實現局部刷新
  • 手寫一個ajax
function creatXhr() {
      var xhr;
      if(window.XMLHttpRequest){ //code for IE7+,Firefox,Chrome,Opera,Safari
          xhr = new XMLHttpRequest();
      } else {
          xhr = new ActiveXObject("Microsoft.XMLHttp");
      }
      return xhr;
  }
  let xhr = creatXhr();
  xhr.onreadystatechange = function () {
      if(xhr.readyState == 4){
        if((xhr.status >= 200 && xhr.status < 300) || xhr.status === 304){
            alert(xhr.responseText);
        }else {
          alert("Request was unsuccessful:" + xhr.status)
        }
        
      } 
  }
  xhr.open('POST',url,true);
  xhr.setRequestHeader("Content-Type","application/x-www-form-urlencoded");//請求
  xhr.send();
  • Ajax的優缺點
    • 優點:
      1.減輕服務器的負擔,Ajax一般只從服務器獲取只需要的數據。
      2.無需刷新整個頁面, 減少用戶等待時間。
      3.更好的客戶體驗,可以將一些服務器的工作轉移到客戶端完成,節約網絡資源,提高用戶體驗。
      4.基於標準化的對象,不需要安裝特定的插件, 瀏覽器都能支持Ajax
      5.徹底將頁面與數據分離。
    • 缺點:
      1.沒有瀏覽歷史, 不能回退
      2.存在跨域請求問題
      3.對搜索引擎支持比較弱
      4.使用動態頁面更新使得用戶難於將某個特定的狀態保存到收藏夾中,不過這些都有相關方法解決
  • Ajax 解決瀏覽器緩存問題?
  1. ajax發送請求前加上 anyAjaxObj.setRequestHeader("If-Modified-Since","0")
  2. ajax發送請求前加上anyAjaxObj.setRequestHeader("Cache-Control","no-cache")
  3. URL後面加上一個隨機數: "fresh=" + Math.random();
  4. URL後面加上時間戳:"nowtime=" + new Date().getTime();
  5. 如果是使用jQuery,直接這樣就可以了 $.ajaxSetup({cache:false})。這樣頁面的所有ajax都會執行這條語句就是不需要保存緩存記錄。
  • 同步和異步的區別?

同步的概念應該是來自於OS中關於同步的概念:不同進程爲協同完成某項工作而在先後次序上調整(通過阻塞,喚醒等方式).同步強調的是順序性.誰先誰後.異步則不存在這種順序性.

  • 同步:瀏覽器訪問服務器請求,用戶看得到頁面刷新,重新發請求,等請求完,頁面刷新,新內容出現,用戶看到新內容,進行下一步操作。

  • 異步:瀏覽器訪問服務器請求,用戶正常操作,瀏覽器後端進行請求。等請求完,頁面不刷新,新內容也會出現,用戶看到新內容。

  • 如何解決跨域問題?
    jsonpCORS(跨域資源共享)、iframewindow.namewindow.postMessage、服務器上設置代理頁面

  • 怎麼理解不同源

    • 協議名不同
    • 域名不同
    • 端口號不同
  • 詳細說說jsonp

基本思想

  • 網頁通過添加一個<script src=‘’>元素,向服務器請求JSON數據(<script>src屬性獲得js代碼, 不受同源政策限制)
  • 服務器收到請求後,將數據放在一個指定名字的回調函數裏傳回來
  • JSONP 獲取的不是JSON 數據,而是可以直接運行的 JavaScript語句網頁不能跨域的 ajax 請求,<script> 可以跨域<script src='xxxxx'>到本地就執行
  • 動態生成<script>標籤, 然後通過標籤的src屬性發送GET類型的跨域請求, 服務器端返回一段js腳本, 這段js腳本的內容爲一個函數調用,實參爲需要返回的響應數據(json);
  • 客戶端這邊需要提前定義好對應的函數, 當<script>請求成功並接收到數據時, 會自動調用此函數, 在函數中 我們就可以處理響應數據了
  • HTTP狀態碼知道哪些?

    • 100 Continue 繼續,一般在發送post請求時,已發送了http header 之後服務端將返回此信息,表示發送具體參數信息
    • 200 OK 請求成功 正常返回信息
    • 301 Moved Permanently 請求的網頁已永久移動到新位置
    • 302 Move temporarily (暫時性重定向)
    • 304 Not Modified (從上次請求後,請求的網頁未修改。存在緩存,沒修改)
    • 400 Bad Request 服務器無法理解請求的格式,客戶端不應當嘗試再次使用相同的內容發起請求
    • 403 Forbidden (禁止訪問,非法)
    • 404 Not Found 找不到如與URL相匹配的資源
    • 500 Internal Server Error 最常見的服務器錯誤
  • 什麼是XSS攻擊?如何預防?

    • Cross-Site Script:又稱CSS,爲了區分css樣式,我們又叫它XSS,跨站腳本攻擊。
  • 它的原理是:攻擊者向有XSS漏洞的網站輸入惡意的HTML代碼,當其他用戶瀏覽該網站時,這段HTML代碼會自動執行,從而達到攻擊的目的。如:盜取用戶cookie,破壞頁面結構,重定向到其他網站等。
  • XSS分爲兩種:分別是DOM Based XSSStore XSS
  • 理論上,所有可輸入的地方沒有對輸入數據進行處理的話,都會存在XSS漏洞,漏洞的危害取決於攻擊代碼的威力,攻擊代碼也不侷限於script。
  • 如何防禦XSS攻擊?
  • 完善的過濾體系:永遠不相信用戶的輸入。需要對用戶輸入進行處理,只允許輸入合法的值,其他值一概過濾掉。
  • Html Code
  • 假如某些情況下,我們不能對用戶數據進行嚴格的過濾,那我們也需要對標籤進行轉換。

比如用戶輸入:<script>window.location.href=”http://www.baidu.com”;</script>,
保存後最終存儲的會是 &lt;script&gt;window.location.href=&quot;http://www.baidu.com&quot;&lt;/script&gt;
在展現時瀏覽器會對這些字符轉換成文本內容顯示,而不是一段可執行的代碼。

  • 什麼是CSRF攻擊?如何防禦?
    在這裏插入圖片描述
    • Cross-Site Request Forgery: 跨站請求僞造
  • 原理:攻擊者盜用你的身份,以你的名義發送惡意請求。CSRF能做的事情包括:以你的名義發郵件,發消息,盜取你的賬號,甚至購買商品,虛擬貨幣轉賬…
    造成的問題包括:個人隱私的泄露以及財產安全
  • CSRF攻擊是源於web的隱式身份驗證機制!web 的身份驗證機制雖然可以保證一個請求是來自於某個用戶的瀏覽器,但是卻無法保證該請求是用戶批准發送的!
  • 如何防禦呢?
  • CSRF的防禦可以從服務端和客戶端兩方面着手,防禦效果是從服務端着手效果比較好,現在一般的CSRF防禦也都在服務端進行。
  1. Cookie Hashing(所有表單都包含同一個僞隨機值)
    這可能是最簡單的解決方案了,因爲攻擊者不能獲得第三方Cookie(理論上),所以表單中的數據也就構造失敗了:>
    構造加密的Cookie信息
    在表單裏增加Hash值,以認證這確實是用戶發送的請求
    然後在服務端裏進行Hash值驗證
  2. 驗證碼
    這個方案的思路是:每次用戶提交都需要用戶在表單中填寫一個圖片上的隨機字符串,這個方案可以完全解決CSRF,但易用性方面似乎不太好還有聽聞是驗證碼圖片的使用涉及了一個被稱爲MHTML的Bug,可能在某些版本的微軟IE中受影響。
  3. One-Time Tokens (不同的表單包含一個不同的僞隨機值)
    在實現One-Time Tokens時,需要注意一點:就是“並行會話的兼容”。如果用戶在一個站點上同時打開了兩個不同的表單,CSRF保護措施不應該影響到他對任何表單的提交。考慮一下如果每次表單被裝入時站點生成一個僞隨機值來覆蓋以前的僞隨機值將會發生什麼情況:用戶只能成功地提交他最後打開的表單,因爲所有其他的表單都含有非法的僞隨機值。必須小心操作以確保CSRF保護措施不會影響選項卡式的瀏覽或者利用多個瀏覽器窗口瀏覽一個站點。
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章