常見(jiàn)的網(wǎng)站安全問(wèn)題

經(jīng)過(guò)一番 996，精心打造的網(wǎng)站眼看就要部屬上線(xiàn)了，但在網(wǎng)站正式上線(xiàn)之前，你有沒(méi)有想過(guò)自己的網(wǎng)站是否安全嗎？

盡管你的網(wǎng)站用了很多高大上的技術(shù)，但是如果網(wǎng)站的安全性不足，無(wú)法保護網(wǎng)站的數據，甚至成為惡意程序的寄生溫床，那前面堆砌了再多的美好也都成了枉然。

SQL注入

在眾多安全性漏洞中，SQL 注入絕對是最嚴重但也是最好處理的一種安全漏洞。在數據庫執行查詢(xún)句時(shí)，如果將惡意用戶(hù)給出的參數直接拼接在查詢(xún)句上，就有可能發(fā)生。

舉個(gè)例子，假設原本某網(wǎng)站登錄驗證的查詢(xún)句長(cháng)這樣：

1. strSQL = "SELECT * FROM users WHERE (name = '" + userName + "') and (pw = '"+ passWord +"');" 

而惡意用戶(hù)輸入的參數為：

1. userName = "1' OR '1'='1"; 
2. passWord = "1' OR '1'='1"; 

由于代碼中是直接將參數與查詢(xún)句做字串做的拼接，所以 SQL 就成為了這樣：

1. strSQL = "SELECT * FROM users WHERE (name = '1' OR '1'='1') and (pw = '1' OR '1'='1');" 
2. // 相當于 
3. strSQL = "SELECT * FROM users;" 

這樣一來(lái)，賬號密碼就形同虛設，甚至可以拿到整個(gè)數據庫的結構(SELECT * FROM sys.tables)、任意修改、查詢(xún)數據，整個(gè)網(wǎng)站的數據就全部泄露了。

不過(guò)解決方法也很簡(jiǎn)單，只要通過(guò)參數化查詢(xún)來(lái)避免直接將參數與查詢(xún)句拼接，并進(jìn)行適當的輸入檢查、插入轉義字符、嚴格設定程序權限，就能夠有效避免 SQL 注入了。

XSS

XSS（跨站攻擊）也叫JavaScript 注入，是現代網(wǎng)站最頻繁出現的問(wèn)題之一，它指的是網(wǎng)站被惡意用戶(hù)植入了其他代碼，通常發(fā)生在網(wǎng)站將用戶(hù)輸入的內容直接放到網(wǎng)站內容時(shí)。例如論壇、留言板等可以輸入任意文字的網(wǎng)站，惡意用戶(hù)如果寫(xiě)入一小段 <script>，并且前、后端都沒(méi)有針對輸入內容做字符轉換和過(guò)濾處理，直接把用戶(hù)輸入的字串作為頁(yè)面內容的話(huà)，就有可能遭到 XSS。

常見(jiàn)的 XSS 有幾個(gè)類(lèi)型：將惡意代碼寫(xiě)入數據庫，當數據被讀取出來(lái)時(shí)就會(huì )執行的儲存型 XSS;將用戶(hù)輸入的內容直接帶回頁(yè)面上的反射型 XSS;以及利用 DOM 的特性，各種花式執行惡意代碼的DOM-based 型 XSS。

儲存型及反射型都很好理解，DOM-based 型就非常有意思了;可以參考OSWAP 整理的XSS Filter Evasion Cheat Sheet[1]，絕大多數的 XSS 方式，都是通過(guò)各個(gè)元素的 background-image 屬性或者元素上的各種事件回調來(lái)實(shí)現;其中特別值得注意的是 SVG，由于 SVG 中可以寫(xiě)入任意 HTML，還可以加上 onload 事件，如果把 SVG 當成普通圖片處理，直接作為網(wǎng)站內容使用，如果遇到惡意用戶(hù)的話(huà)，后果不堪設想。所以在上線(xiàn)上傳圖片功能時(shí)，務(wù)必要把 SVG 過(guò)濾掉!

避免 XSS 的方法其實(shí)也很簡(jiǎn)單，只要在數據輸入輸出時(shí)做好字符轉換，使惡意代碼不被執行，而是被解析成字符就可以了。

CSRF

CSRF(跨站請求偽造)是一種利用 Cookie 及 Session 認證機制進(jìn)行攻擊的手段;由于 Session 認證的其實(shí)不是用戶(hù)本人，而是瀏覽器，那么只要通過(guò)網(wǎng)頁(yè)DOM 元素可以跨域的機制，對已經(jīng)得到認證的網(wǎng)站發(fā)出請求，就可以假冒用戶(hù)，從而拿到敏感信息。

例如某家銀行的轉賬 API 的URL 是這樣的：

1. http://www.examplebank.com/withdraw?account=AccoutName&amount=1000&for=PayeeName 

而惡意用戶(hù)如果在網(wǎng)站中塞進(jìn)一個(gè) 的話(huà)：

1. <img src="http://www.examplebank.com/withdraw?account=Alice&amount=1000&for=Badman"> 

當不知情的用戶(hù)瀏覽到攻擊者的網(wǎng)站時(shí)， 會(huì )自動(dòng)發(fā)出這個(gè)請求，如果用戶(hù)登錄銀行的 Session 尚未過(guò)期，那么這個(gè)請求很可能就會(huì )被銀行接受，最后會(huì )在用戶(hù)本人不知情的情況下“被”轉帳。

這種攻擊方式可以與前面所說(shuō)的 XSS 是相輔相成，例如在沒(méi)有防范 XSS 的論壇網(wǎng)站中植入 ，那么其 src 屬性就應該是獲取敏感信息的 API URL。

解決方法主要有以下幾種：

• 檢查 Referer：在服務(wù)器端檢查請求頭中 Referer 的值，也就是檢查請求的來(lái)源，如果是來(lái)自允許的網(wǎng)站，才會(huì )正常執行 API 的功能。
• CSRF Token：在 Cookie 及請求發(fā)送的數據中都加上 csrftoken，并檢查值是否相同，如果請求來(lái)源是自己的網(wǎng)站驗證就會(huì )通過(guò);反之，由于外部網(wǎng)站無(wú)法在代碼中得到其他網(wǎng)站的 Cookie，因此無(wú)法在請求中帶上 csrftoken。
• SameSite Cookie：在 Cookie 中加上 SameSite 屬性，確保 Cookie 僅能在自己的網(wǎng)站使用。

JSON 劫持

JSON 劫持是利用現代網(wǎng)站前后端通過(guò) API 進(jìn)行數據交換的特性，只要能獲得使用者權限，并調用獲取資料的 API，再加上改寫(xiě)原生的 JavaScript 對象，就可以竊取用戶(hù)的敏感信息。

獲得權限的部分于 CSRF 相同，通過(guò) <script> 可以跨域的特性直接使用瀏覽器用戶(hù)的 Cookie；攻擊者只需要在網(wǎng)頁(yè)上通過(guò) <script> 調用獲取數據的 API 完成對數據的竊取。

例如：

1. Object.prototype.__defineSetter__('user',function(obj){ 
2.   for(var i in obj) { 
3.     alert(i + '=' + obj[i]); 
4.   } 
5. }); 

當回傳的數據中含有 user 屬性時(shí)，由于 Setter 通過(guò) Object.prototype.__defineSetter__ 改寫(xiě)了，user 中的值會(huì )被全部讀取。

然而 Object.prototype.__defineSetter__ 可以修改原生對象所造成的問(wèn)題，早已經(jīng)在 ES4 中就被修復了，JSON 劫持也因此銷(xiāo)聲匿跡，但是從 ES6 開(kāi)始又添加了 Proxy，使 JSON 劫持又再次成為可能：

1. <script> 
2. <script> 
3.   Object.setPrototypeOf( 
4.     __proto__, 
5.     new Proxy(__proto__, { 
6.       has: function(target, name) { 
7.         alert( 
8.           name.replace(/./g, function(c) { 
9.             c = c.charCodeAt(0) 
10.             return String.fromCharCode(c >> 8, c & 0xff) 
11.           }) 
12.         ) 
13.       } 
14.     }) 
15.   ) 
16. </script> 
17. <script charset="UTF-16BE" src="external-script-with-array-literal"></script> 

看起來(lái)很恐怖，那么該如何解決呢？除了前面所說(shuō)的 CSRF Token 外，許多大公司還采用了另一種有趣的解決方式。即 API 的響應內容開(kāi)頭為 for (;;);，這也是利用 了<script> 引入的 JavaScript 會(huì )立即執行的特性，把攻擊者的網(wǎng)站卡死在循環(huán)里。

總結

除了文中提到的四種常見(jiàn)的漏洞外，一個(gè)網(wǎng)站還有很多細節需要考慮，例如不要用明碼存儲密碼等敏感信息，針對來(lái)源 IP 做流量限制防止 DOS 等等。所以在進(jìn)行網(wǎng)站開(kāi)發(fā)時(shí)要保持安全意識，盡可能做好基本的防護措施。

原文鏈接：https://mp.weixin.qq.com/s?__biz=MzI3NzIzMDY0NA==&mid=2247503874&idx=1&sn=9f23e3f5e29cd12f167ddd4f7462cb71&chksm=eb6bf559dc1c7c4f1ef8efab781c34df153076ac22988e3ea778d31b60ffd72f8525f6e357f1&mpshare=1&