web安全及防禦

時間 2019-11-24

標籤 web 安全防禦欄目 HTML 简体版

原文原文鏈接

本文將對web方面的安全問題以及相應的防禦方法進行一個簡單的介紹。javascript

SQL注入（SQL Injection）php

　　原理：就是經過把SQL命令插入到Web表單遞交或輸入域名或頁面請求的查詢字符串，最終達到欺騙服務器執行惡意的SQL命令。具體來講就是用戶能夠利用惡意的SQL語句提交以後，到後臺數據庫執行，獲得一個存在安全漏洞的網站上的數據庫，而不是按照設計者的意圖去執行SQL語句。html

　　SQL注入的攻擊力到底有多強：輕的話會暴露數據庫中的數據，嚴重的話會對數據庫中的數據進行惡意的增刪改查。java

　　爲何會發生SQL注入？主要仍是程序沒有很好地去過濾掉用戶輸入的數據，致使數據能夠非法輸入。程序員

　　根據相關技術原理，SQL注入能夠分爲平臺層注入和代碼層注入。前者由不安全的數據庫配置或數據庫平臺的漏洞所致；後者主要是因爲程序員對輸入未進行細緻地過濾，從而執行了非法的數據查詢。web

關於防禦總的來講有如下幾點：正則表達式

　　1.永遠不要信任用戶的輸入，要對用戶的輸入進行校驗，能夠經過正則表達式，或限制長度，對單引號和雙"-"進行轉換等。
　　2.永遠不要使用動態拼裝SQL，可使用參數化的SQL或者直接使用存儲過程進行數據查詢存取。
　　3.永遠不要使用管理員權限的數據庫鏈接，爲每一個應用使用單獨的權限有限的數據庫鏈接。
　　4.不要把機密信息明文存放，請加密或者hash掉密碼和敏感的信息。數據庫

能夠參考：SQL注入系列的文章segmentfault

XSS(Cross-site scripting 跨站腳本分析)瀏覽器

　　XSS攻擊指的是攻擊者往Web頁面裏插入惡意 html標籤或者javascript代碼。好比：攻擊者在論壇中放一個看似安全的連接，騙取用戶點擊後，竊取cookie中的用戶私密信息；或者攻擊者在論壇中加一個惡意表單，當用戶提交表單的時候，卻把信息傳送到攻擊者的服務器中，而不是用戶本來覺得的信任站點。

分類：

　　一、反射型跨站腳本(Reflected Cross-site Scripting)。主要是將惡意腳本附加到URL地址的參數中，原理以下：發現存在反射XSS的URL——根據輸出點的環境構造XSS代碼——進行編碼等迷惑手法——發送給受害人——受害打開後，執行XSS代碼——完成攻擊(獲取cookies、url、瀏覽器信息、IP等)。反射型XSS的特色是隻在用戶單擊時觸發，且只執行一次，故也稱做非持久型跨站。

http://www.test.com/search.php?key="><script>alert("XSS")</script>
http://www.test.com/view.shtml?query=%3Cscript%3Ealert%281%29%3C/script%3E
http://www.test.com/logout.asp?out=1&url=javascript:alert(document.cookie)

　　二、持久型跨站腳本(Persistent Cross-site Scripting)。攻擊者事先將惡意Javascript代碼上傳或儲存到漏洞服務器上，只要受害者瀏覽包含此惡意代碼的頁面就會中招。通常出如今留言、評論等交互處。

　　三、DOM XSS。前面兩種XSS通常出如今服務器端代碼中，而DOM-Based XSS是基於DOM文檔對象模型，受客戶端瀏覽器代碼的影響。這一漏洞的前提是，一個網頁以不安全的方式使用document.location、document.URL、document.referrer等對象獲取數據。
舉個例子，有以下HTML代碼：

<html>
<head>
<title>Welcome!</title>
</head>
<body>
  <p>Hi</p>
  <script>
    var pos=document.URL.indexOf("name=")+5;
    document.write(document.URL.substring(pos,document.URL.length));
  </script>
</body>
</html>

　　一般，這個歡迎網頁的請求是這樣的：

http://www.test.com/welcome.html?name=lihua

　　然而，若是這個請求是這樣的：

http://www.test.com/welcome.html?name=<script>alert(document.cookie)</script>

　　這就致使了XSS，彈出了cookie。

XSS防範方法

　　首先代碼裏對用戶輸入的地方和變量都須要仔細檢查長度和對」<」,」>」,」;」,」’」等字符作過濾；其次任何內容寫到頁面以前都必須加以encode，避免不當心把html tag 弄出來。這一個層面作好，至少能夠堵住超過一半的XSS 攻擊。
　　首先，避免直接在cookie 中泄露用戶隱私，例如email、密碼等等。
　　其次，經過使cookie 和系統ip 綁定來下降cookie 泄露後的危險。這樣攻擊者獲得的cookie 沒有實際價值，不可能拿來重放。
　　若是網站不須要再瀏覽器端對cookie 進行操做，能夠在Set-Cookie 末尾加上HttpOnly 來防止javascript 代碼直接獲取cookie 。
　　儘可能採用POST 而非GET 提交表單

CSRF（Cross-site request forgery 跨站請求僞造）

　　也被稱爲 one-click attack 或者 session riding，一般縮寫爲 CSRF 或者 XSRF，是一種挾制用戶在當前已登陸的Web應用程序上執行非本意的操做的攻擊方法。就是冒充用戶發起請求（在用戶不知情的狀況下）,完成一些違背用戶意願的請求（如惡意發帖，刪帖，改密碼，發郵件等）。

關於CSRF與XSS的區別：

　　CSRF 的全稱是「跨站請求僞造」，而 XSS 的全稱是「跨站腳本」。看起來有點類似，它們都是屬於跨站攻擊——不攻擊服務器端而攻擊正常訪問網站的用戶，它們的攻擊類型是不一樣維度上的分類。CSRF 顧名思義，是僞造請求，冒充用戶在站內的正常操做。咱們知道，絕大多數網站是經過 cookie 等方式辨識用戶身份（包括使用服務器端 Session 的網站，由於 Session ID 也是大多保存在 cookie 裏面的），再予以受權的。因此要僞造用戶的正常操做，最好的方法是經過 XSS 或連接欺騙等途徑，讓用戶在本機（即擁有身份 cookie 的瀏覽器端）發起用戶所不知道的請求。

　　一般來講CSRF是由XSS實現的，因此CSRF時常也被稱爲XSRF[用XSS的方式實現僞造請求]（但實現的方式毫不止一種，還能夠直接經過命令行模式（命令行敲命令來發起請求）直接僞造請求[只要經過合法驗證便可]）。 XSS更偏向於代碼實現（即寫一段擁有跨站請求功能的JavaScript腳本注入到一條帖子裏，而後有用戶訪問了這個帖子，這就算是中了XSS攻擊了），CSRF更偏向於一個攻擊結果，只要發起了冒牌請求那麼就算是CSRF了。

　　在知乎上看到一句比較形象的對比：如何用簡潔生動的語言理清XSS和CSRF的區別？

　　　　xss：我（做爲公司內部人員）由於內部監管不嚴混進領導層和領導喝酒打牌
　　　　csrf：我（假裝成公司領導）混進領導層裏喝酒打牌

　　XSS是獲取信息，不須要提早知道其餘用戶頁面的代碼和數據包。CSRF是代替用戶完成指定的動做，須要知道其餘用戶頁面的代碼和數據包。

要完成一次CSRF攻擊，受害者必須依次完成兩個步驟：

　　登陸受信任網站A，並在本地生成Cookie。
　　在不登出A的狀況下，訪問危險網站B。

CSRF的防護

　　服務端的CSRF方式方法不少樣，但總的思想都是一致的，就是在客戶端頁面增長僞隨機數。

　　主要能夠從三個層面進行，即服務端的防護、用戶端的防護和安全設備的防護。服務器端防護CSRF攻擊主要有三種策略：驗證HTTP Referer字段，在請求地址中添加token並驗證，在HTTP頭中自定義屬性並驗證。

參考：

XSS跨站腳本初學總結

XSS分析及預防

總結 XSS 與 CSRF 兩種跨站攻擊