常見的四大網(wǎng)站安全問題
盡管你的網(wǎng)站用了很多高大上的技術，但是如果網(wǎng)站的安全性不足，無法保護網(wǎng)站的數(shù)據(jù)，甚至成為惡意程序的寄生溫床，那前面堆砌了再多的美好也都成了枉然。
SQL注入
在眾多安全性漏洞中，SQL 注入絕對是最嚴重但也是最好處理的一種安全漏洞。在數(shù)據(jù)庫執(zhí)行查詢句時，如果將惡意用戶給出的參數(shù)直接拼接在查詢句上，就有可能發(fā)生。
舉個例子，假設原本某網(wǎng)站登錄驗證的查詢句長這樣：
- strSQL = "SELECT * FROM users WHERE (name = '" + userName + "') and (pw = '"+ passWord +"');"
而惡意用戶輸入的參數(shù)為：
- userName = "1' OR '1'='1";
- passWord = "1' OR '1'='1";
由于代碼中是直接將參數(shù)與查詢句做字串做的拼接，所以 SQL 就成為了這樣：
- strSQL = "SELECT * FROM users WHERE (name = '1' OR '1'='1') and (pw = '1' OR '1'='1');"
- // 相當于
- strSQL = "SELECT * FROM users;"
這樣一來，賬號密碼就形同虛設，甚至可以拿到整個數(shù)據(jù)庫的結(jié)構(gòu)(SELECT * FROM sys.tables)、任意修改、查詢數(shù)據(jù)，整個網(wǎng)站的數(shù)據(jù)就全部泄露了。
不過解決方法也很簡單，只要通過參數(shù)化查詢來避免直接將參數(shù)與查詢句拼接，并進行適當?shù)妮斎霗z查、插入轉(zhuǎn)義字符、嚴格設定程序權(quán)限，就能夠有效避免 SQL 注入了。
XSS
XSS（跨站攻擊）也叫JavaScript 注入，是現(xiàn)代網(wǎng)站最頻繁出現(xiàn)的問題之一，它指的是網(wǎng)站被惡意用戶植入了其他代碼，通常發(fā)生在網(wǎng)站將用戶輸入的內(nèi)容直接放到網(wǎng)站內(nèi)容時。例如論壇、留言板等可以輸入任意文字的網(wǎng)站，惡意用戶如果寫入一小段 <script>，并且前、后端都沒有針對輸入內(nèi)容做字符轉(zhuǎn)換和過濾處理，直接把用戶輸入的字串作為頁面內(nèi)容的話，就有可能遭到 XSS。
常見的 XSS 有幾個類型：將惡意代碼寫入數(shù)據(jù)庫，當數(shù)據(jù)被讀取出來時就會執(zhí)行的儲存型 XSS;將用戶輸入的內(nèi)容直接帶回頁面上的反射型 XSS;以及利用 DOM 的特性，各種花式執(zhí)行惡意代碼的DOM-based 型 XSS。
儲存型及反射型都很好理解，DOM-based 型就非常有意思了;可以參考OSWAP 整理的XSS Filter Evasion Cheat Sheet[1]，絕大多數(shù)的 XSS 方式，都是通過各個元素的 background-image 屬性或者元素上的各種事件回調(diào)來實現(xiàn);其中特別值得注意的是 SVG，由于 SVG 中可以寫入任意 HTML，還可以加上 onload 事件，如果把 SVG 當成普通圖片處理，直接作為網(wǎng)站內(nèi)容使用，如果遇到惡意用戶的話，后果不堪設想。所以在上線上傳圖片功能時，務必要把 SVG 過濾掉!
避免 XSS 的方法其實也很簡單，只要在數(shù)據(jù)輸入輸出時做好字符轉(zhuǎn)換，使惡意代碼不被執(zhí)行，而是被解析成字符就可以了。
CSRF
CSRF(跨站請求偽造)是一種利用 Cookie 及 Session 認證機制進行攻擊的手段;由于 Session 認證的其實不是用戶本人，而是瀏覽器，那么只要通過網(wǎng)頁DOM 元素可以跨域的機制，對已經(jīng)得到認證的網(wǎng)站發(fā)出請求，就可以假冒用戶，從而拿到敏感信息。
例如某家銀行的轉(zhuǎn)賬 API 的URL 是這樣的：
- http://www.examplebank.com/withdraw?account=AccoutName&amount=1000&for=PayeeName
而惡意用戶如果在網(wǎng)站中塞進一個 的話：
- <img src="http://www.examplebank.com/withdraw?account=Alice&amount=1000&for=Badman">
當不知情的用戶瀏覽到攻擊者的網(wǎng)站時， 會自動發(fā)出這個請求，如果用戶登錄銀行的 Session 尚未過期，那么這個請求很可能就會被銀行接受，最后會在用戶本人不知情的情況下“被”轉(zhuǎn)帳。
這種攻擊方式可以與前面所說的 XSS 是相輔相成，例如在沒有防范 XSS 的論壇網(wǎng)站中植入 ，那么其 src 屬性就應該是獲取敏感信息的 API URL。
解決方法主要有以下幾種：
- 檢查 Referer：在服務器端檢查請求頭中 Referer 的值，也就是檢查請求的來源，如果是來自允許的網(wǎng)站，才會正常執(zhí)行 API 的功能。
- CSRF Token：在 Cookie 及請求發(fā)送的數(shù)據(jù)中都加上 csrftoken，并檢查值是否相同，如果請求來源是自己的網(wǎng)站驗證就會通過;反之，由于外部網(wǎng)站無法在代碼中得到其他網(wǎng)站的 Cookie，因此無法在請求中帶上 csrftoken。
- SameSite Cookie：在 Cookie 中加上 SameSite 屬性，確保 Cookie 僅能在自己的網(wǎng)站使用。
JSON 劫持
JSON 劫持是利用現(xiàn)代網(wǎng)站前后端通過 API 進行數(shù)據(jù)交換的特性，只要能獲得使用者權(quán)限，并調(diào)用獲取資料的 API，再加上改寫原生的 JavaScript 對象，就可以竊取用戶的敏感信息。
獲得權(quán)限的部分于 CSRF 相同，通過 <script> 可以跨域的特性直接使用瀏覽器用戶的 Cookie；攻擊者只需要在網(wǎng)頁上通過 <script> 調(diào)用獲取數(shù)據(jù)的 API 完成對數(shù)據(jù)的竊取。
例如：
- Object.prototype.__defineSetter__('user',function(obj){
- for(var i in obj) {
- alert(i + '=' + obj[i]);
- }
- });
當回傳的數(shù)據(jù)中含有 user 屬性時，由于 Setter 通過 Object.prototype.__defineSetter__ 改寫了，user 中的值會被全部讀取。
然而 Object.prototype.__defineSetter__ 可以修改原生對象所造成的問題，早已經(jīng)在 ES4 中就被修復了，JSON 劫持也因此銷聲匿跡，但是從 ES6 開始又添加了 Proxy，使 JSON 劫持又再次成為可能：
- <script>
- <script>
- Object.setPrototypeOf(
- __proto__,
- new Proxy(__proto__, {
- has: function(target, name) {
- alert(
- name.replace(/./g, function(c) {
- c = c.charCodeAt(0)
- return String.fromCharCode(c >> 8, c & 0xff)
- })
- )
- }
- })
- )
- </script>
- <script charset="UTF-16BE" src="external-script-with-array-literal"></script>
看起來很恐怖，那么該如何解決呢？除了前面所說的 CSRF Token 外，許多大公司還采用了另一種有趣的解決方式。即 API 的響應內(nèi)容開頭為 for (;;);，這也是利用 了<script> 引入的 JavaScript 會立即執(zhí)行的特性，把攻擊者的網(wǎng)站卡死在循環(huán)里。
總結(jié)
除了文中提到的四種常見的網(wǎng)站安全漏洞外，一個網(wǎng)站還有很多細節(jié)需要考慮，例如不要用明碼存儲密碼等敏感信息，針對來源 IP 做流量限制防止 DOS 等等。所以在進行網(wǎng)站開發(fā)時要保持安全意識，盡可能做好基本的防護措施。
