Web高級 網站安全

1. SQL注入

雖然如今SQL注入發生的狀況總的來講愈來愈少,仍是提二句。關於什麼是SQL注入你們都知道就很少說了。

1.1 原理

咱們在作前端頁面的時候,少不了會又各類輸入框,而後經過GET或者POST發送至後端。
那麼若是後端在處理時直接使用SQL拼接的話就會產生問題。

//好比提交地址以下
//http://mysite/search?name='SQL'
在後端生成SQL語句爲
var paramName = 'SQL'//從URL獲取
var sqlQuery = "select * from table1 where name='"+paramName+"'"
//生成的結果爲 - select * from table1 where name='SQL'
//若是咱們在URL中帶過來的參數是 SQL or 1=1
//生成的結果則爲 - select * from table1 where name='SQL' or 1=1
//那麼學過SQL都知道咱們還能夠在後面再添加語句以獲取額外的數據

1.2 防範手段

1. 經過正則表達校驗用戶輸入
   不實用,不論是在客戶端仍是服務端作驗證,都不能100%保證過濾全部狀況.
   還有一個缺點就是會對正常數據輸入形成必定影響。
2. 使用存儲過程
   不實用,無論哪一個項目都不可能全局使用存儲過程。
   
3. 參數化SQL語句
   較爲常見
   如: SqlCommand.Parameters.Add("@name", SqlDbType.string).Value = "SQL";
   原理概述：數據庫有一套執行計劃重用原理,SQL語句的語句體會被預編譯爲執行計劃,而參數會被隔離和辨識爲獨立部分。那麼對於不符合預期的參數值或類型就不會獲得正確執行。
4. 語言框架攜帶的對象->SQL轉換機制
   較爲常見，如Hibernate、Entity Framework 的LINQ

2. XSS

2.1 類型

• 反射型
  數據流向：瀏覽器 -> 後端 -> 瀏覽器
  如何產生：前端進行GET形式的數據提交至後端,由後端處理並將處理結果反饋到前端,前端將結果插入DOM。
  漏洞：A將一段帶有特殊參數的連接發送給B，如http://ASite/pageA?param=,在服務端並未進行特殊處理的狀況下,返回參數中的字符串到A。
  那麼A將爲加載從BSite的hack.js。則B站點能夠竊取到A用戶的cookie等信息。
  
• 存儲型
  數據流向：瀏覽器 -> 後端 -> 存儲 -> 後端 -> 瀏覽器
  如何產生：前端提交的數據並未進行特殊處理,就進行持久化存儲,並將持久化存儲的結果又展現給其餘用戶。
  漏洞：好比A在cnblog發表了一篇新的文章,他在該文章中嵌入了標籤,那麼全部訪問過該文章的人就會被竊取到cookie等信息。

• DOM型
  數據流向：瀏覽器 -> 瀏覽器
  如何產生：前端使用腳本直接獲取URL參數並插入到DOM中,全程沒有服務端參與
  漏洞：A將一段帶有特殊參數的連接發送給B，如http://ASite/pageA?param=,前端腳本會直接獲取參數並插入DOM中,則B會加載B站點的hack.js，與反射型不一樣的是這裏不須要後端的參與.

  2.2 防護手段

1. Content Security Policy (CSP)
   CSP 的實質就是白名單制度，服務端明確告訴客戶端，哪些外部資源能夠加載和執行，等同於提供白名單。它的實現和執行所有由瀏覽器完成，開發者只需提供配置。CSP 大大加強了網頁的安全性。攻擊者即便發現了漏洞，也無法注入腳本。

• 如何啓用：
  經過HTTP協議頭Content-Security-Policy或meta標籤來指定白名單
• 限制類型
  js,css,img,media,font,plugin,frame,workerjs,manifest,http connect等
• 違反處理X-XSS-Protection頭
  禁止該頁面加載
  或，上報違反行爲
  注:如今不少代理網關或CDN會在頁面中插入廣告(經過劫持或內容替換等)或其餘東西,若是採用禁止頁面加載會影響終端用戶的體驗。對這種流氓行爲怎麼處理之後的文章會有提到。

3. CSRF

3.1 例子

1. 用戶C訪問正常網站A時進行登陸，瀏覽器保存A的cookie
2. 用戶C再訪問攻擊網站B，網站B上有某個隱藏的連接或者圖片標籤會自動請求網站A的URL地址,例如表單提交，傳指定的參數
3. 而攻擊網站B在訪問網站A的時候，瀏覽器會自動帶上網站A的cookie

4. 因此網站A在接收到請求以後可判斷當前用戶是登陸狀態，因此根據用戶的權限作具體的操做邏輯，形成僞形成功

   3.2 原理

• CSRF可以攻擊成功在於Web的身份驗證機制->使用cookie

  3.3 防護手段

1. HTTP Referer 頭驗證
   根據Http協議,發送Http請求時會帶有Referer字段,其值由瀏覽器負責添加,爲發起該請求的站點的域名.可是,該值並非必定能獲取到,取決於瀏覽器實現和用戶配置是否啓用.
   結論：不可靠
2. Anti CSRF Token
   在進行頁面請求的時候,由服務端生成隨機動態Token附加到Session或header中.在進行後續請求時,不論是Get/Post/Form都須要帶上該Token,由服務端驗證.
   結論:常見手段
3. HTTP自定義頭
   在請求的HTTP頭部中附加自定義頭部.
   結論:常見手段

4. clickjacking(點擊劫持)

4.1 例子

1. 用戶C訪問網站A,在網站A的頁面中嵌入了網站B的內容,如新聞、圖片等
2. 用戶C點擊看見的網站B的內容

3. 該點擊事件被劫持,從而讓用戶訪問其不該該訪問的內容
   注：單一的點擊劫持也許粗略一看並不能達到太惡略的攻擊效果,但若是聯合 XSS+CSRF+clickjacking,能夠作的事情就不少了。

   4.2 防護手段

   HTTP協議中的頭部 X-Frame-Options

• DENY：表示該頁面不容許在 frame 中展現，即使是在相同域名的頁面中嵌套也不容許
• SAMEORIGIN：表示該頁面能夠在相同域名頁面的 frame 中展現
• ALLOW-FROM：表示該頁面能夠在指定來源的 frame 中展現。

5. 其餘

1. HTTP Strict Transport Security (HSTS)
   告訴瀏覽器只能經過HTTPS訪問當前資源，而不是HTTP.阻止黑客的中間人攻擊.
   使用場景，好比升級全部http連接到https。
2. Cookie security

• Secure
  標記爲 Secure 的Cookie只應經過被HTTPS協議加密過的請求發送給服務端
• HttpOnly
  標記爲 HttpOnly 的Cookie沒法經過JavaScript的 Document.cookie API訪問,它們只發送給服務端

refs:
https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP