前端菜鳥來講web安全

前言

哎 七月份開始實習，九月份開始奔波校招。很忙碌也很累也沒怎麼好好學習了。最近面試被問到有關於前端安全，才發現本身一直忽略了這方面，因而趕忙惡補！！！

分類

開發者，通常主要分爲前端和後端。而對於開發者來講，安全就主要分爲了前端安全和後端安全，而WEB基本攻擊大體能夠分爲三大類：「資源枚舉」、「參數操縱」 和 「其它攻擊」。。

資源枚舉

對於一個團隊來講，會有不少編碼規範，命名規範來規範團隊的開發，例如類名用'-'鏈接，id用駝峯命名法等。而後須要對項目作備份，把代碼壓縮成back.rar。而後還把代碼備份放到了服務器上，那麼那些想要訪問你源碼的「有心人」就能夠有途徑去訪問下載到你的源碼，那麼你的項目源碼將再也不是祕密。
「有心人」會遍歷你站點全部可訪問的項目，而後把一些經常使用的備份文件一個個都枚舉下載。若是你想對你站點的編碼語言和數據庫進行保密，但沒有配置好後端錯誤信息的提示。那麼「有心人」就能夠在站點例的某個搜索結果頁面篡改url參數，致使數據庫查詢錯誤而返回數據庫錯誤提示信息，或者輸入一個根本不存在的子頁面地址來獲取錯誤信息，進而可判斷該站點使用了什麼數據庫或動態語言。

參數操縱 - XSS

什麼是XSS呢？XSS全稱是Cross-site scripting，跨域腳本攻擊，是最多見的Web攻擊之一。它是一種典型的出如今web應用中的計算機安全漏洞。XSS容許攻擊者注入客戶端腳本到Web頁面中。一段跨域腳本漏洞可能會被攻擊者用於經過一些入站控制，如同源策略。xss攻擊主要側重於客戶端。

xss的攻擊力：輕則用戶體驗異常彈窗，重則用戶cookie數據被盜取，引導用戶到非法地址。

a.HTML元素：

<input v-model = "textXSS"/>
 <p>{{ textXSS }}</p>

input：
    <script type='text/javascript'>alert('xss');</script>//一個alert彈框將會出現。

b.HTML屬性:

<img src = "{{ img_url }}" />
if img_url = "xss = "alert('xss')' 
瀏覽器就會解析成：
<img src = "" xss = "alert('xss')" />

c.url連接：

假如你想要在一個網站的輸入框中輸入你想搜索的關鍵字（例：「apple」），此時URL會變爲http://dodomonster.org?keywor...正常的搜索。若是沒有結果，則通常會顯示‘apple’搜索結果爲空。可是，若是你輸入"<script type='text/javascript'>alert('xss');</script>"一個alert彈框將會出現。會提示<script type='text/javascript'>alert('xss');</script>搜索結果爲空伴隨着錯誤信息提示彈框「xss」，並且url還會變成http://dodomonster.org?<sc... type='text/javascript'>alert('xss');</script>-這是一個「有心人」可利用的漏洞

d.Javascript腳本：

<script>var user_data = {{ user_data|json_encode }};</script>
 if user_data = {"xss": "</script><script>alert('xss');"}
 
 瀏覽器會解析成：
 <script>var user_data = {"xss": "</script>
 <script>alert('xss');"};</script>

解決辦法：
① 在不一樣上下文中，使用合適的escape方式
② 不要相信任何來自用戶的輸入

參數操縱 - SQL注入

所謂SQL注入就是經過把SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字符串，最終達到欺騙服務器執行惡意的SQL命令。具體來講，它是利用現有應用程序，將（惡意）的SQL命令注入到後臺數據庫引擎執行的能力，它能夠經過在Web表單中輸入（惡意）SQL語句獲得一個存在安全漏洞的網站上的數據庫，而不是按照設計者意圖去執行SQL語句。

SQL注入的攻擊力：輕則暴露數據，刷爆數據庫，重則表數據被惡意編輯、刪除，或表被刪除。

發生的主要緣由是程序沒有細緻地過濾用戶輸入的數據，導致非法數據侵入系統。

根據相關技術原理，SQL注入能夠分爲平臺層注入和代碼層注入。前者由不安全的數據庫配置或數據庫平臺的漏洞所致；後者主要是因爲程序員對輸入未進行細緻地過濾，從而執行了非法的數據查詢。基於此，SQL注入的產生緣由一般表如今如下幾方面：

• 不當的類型處理；

• 不安全的數據庫配置；

• 不合理的查詢集處理；

• 不當的錯誤處理；

• 轉義字符處理不合適；

• 多個提交處理不當。

如：你想在一個超市站點查看apple的相關信息，url：http://dodomonster.org?id=99,你就會知道哦，原來apple的鍵值id爲99

後臺收到url會執行查詢語句：select * from fruit where id = 99;

若是咱們把url改成http://dodomonster.org?id=99 or 1>0，數據庫查詢語句就會變爲select * from fruit where appleId = 99 or 1>0，從而有心人就會獲取了整個數據庫中全部的水果信息。

參數操縱 - XPath注入

XPath注入和SQL注入原理差很少，只不過XPath注入的數據庫是xml格式的。

參數操縱 - 會話劫持

在現實生活中，好比你去市場買菜，在交完錢後你要求先去幹一些別的事情，稍候再來拿菜；若是這個時候某個陌生人要求把菜拿走，賣菜的人會把菜給陌生人嗎？！固然，這只是一個比喻，但這偏偏就是會話劫持的喻意。所謂會話，就是兩臺主機之間的一次通信。[引自百度百科]

訪問一個http網站要與服務器創建一次HTTP回話。假設跟你處於同一個子網上的「朋友」，想假裝成你來劫持你的HTTP會話，那麼服務器會信息返回給那我的嗎？

答案是確定的，由於HTTP會話並不安全。它在通過TCP/IP協議封裝傳輸數據時，在傳輸的數據的每個字節中插入一個32位的序列號碼，這個序列號用來保持跟蹤數據和提供可靠性（序列號是依循數據順序逐步遞增的）。第三方攻擊者能夠經過嗅探的方式來獲取用戶與服務器通信中的報文信息，若是他能猜想到數據中的序列號，那便能把合法的用戶斷開，假裝成合法用戶讓本身控制後續的通話。

對於會話劫持的預防，能夠走SSH協議、加強網絡安全系統健壯性，也可使用無序的UUID來替代通信中的序列號碼（而非逐步遞增）。

其餘攻擊 - CSRF

CSRF，cross-site request forgery,跨站請求僞造。與XSS很是類似，可是XSS是利用用戶對當前網站的信任來發起攻擊，而CSRF是利用網站對用戶的信任來發起攻擊。

CSRF攻擊力：以你的名義發送郵件、發消息，盜取你的帳號，甚至購買商品，虛擬貨幣轉帳，我的隱私泄露以及財產安全。

對於一個安全性很低的電商網站，若是你已經登陸了網站，且沒關閉瀏覽器，在任何狀況均可以做爲一個已經過身份驗證登陸的用戶來購買商品等操做，而無須從新登陸或者輸入支付密碼。

咱們能夠給一個用戶的郵箱發送一份郵件裏面包含一張圖片
<img src = "http://dodomonster.com/pay?ap... = 99"/>
img、src、iframe都是不受同源限制的，假設你使用的郵箱很直白地顯示了這張圖片那你就會直接跳到購買id爲99的支付頁面，直接支付，作了購買的動做操做。

這就是爲何如今大部分的郵箱都不會直接顯示圖片的緣由！all for u！

防範CSRF：

1. 檢查報頭中的Referer參數確保請求發自正確的網站（但XHR請求可調用setRequestHeader方法來修改Referer報頭）；

2. 對於任何重要的請求都須要從新驗證用戶的身份；

3. 建立一個惟一的令牌（Token），將其存在服務端的session中及客戶端的cookie中，對任何請求，都檢查兩者是否一致。

後話

夜深了，早點休息！