[[337378]]

本文轉載自微信公眾號「虞大膽的嘰嘰喳喳」，作者虞大膽  。轉載本文請聯系虞大膽的嘰嘰喳喳公眾號。

今天回憶下web開發安全問題，以前在新浪博客時，遇到最多的攻擊是XSS和SQL注入攻擊。

博客最核心的功能就是富文本發文，允許執行html語義標簽，如果處理不當，就能執行js語句，導致各種的xss攻擊。

那時候解析文章內容沒有很好的dom解析庫，堵住漏洞非常辛苦和被動。

另外攻擊就是sql注入，破壞過一些表數據，但大范圍的故障沒有出現過。

這二個攻擊在互聯網剛開始的時候非常流行，最重要的原因就是它們的宿主環境是瀏覽器，瀏覽器能夠執行html和js。SQL攻擊同樣如此，如果宿主環境不能打印sql執行結果，攻擊力度會小很多。

而現在是APP時代，都是接口調用，即使接口中含有html字符，APP也不會去執行;同時API接口的鑒權也非常嚴格，很少出現SQL注入攻擊。

當然HTTPS的推廣和普及也讓http服務安全提高了不少，至少很難出現殘暴的篡改攻擊了。

所以現在攻擊的土壤就是企業內部網站了，因為它們大多數運行在瀏覽器之下，那如何解決呢?

從Web安全的角度看，cookie和session的設計本身就是有問題的，以前寫過一篇文章，后面可以發到公眾號中。

xss攻擊本質上也是結合cookie一起形成危害的，今天同事提了個方法，現在很多cookie不會校驗它的出處，如果能夠綁定cookie和設備(比如設備號或者IP)，那么攻擊就小了很多，比如發現攻擊者附帶的cookie值和IP與存儲在redis中的cookie和IP不一致，就拒絕訪問。

對于內部系統，可以采取二次auth驗證，比如nginx就有http basic auth驗證;或者登陸才能訪問內部系統。

攻擊分為主動攻擊和被動攻擊，主動攻擊不可怕，總能找到方法解決，而被動攻擊就非常危險，在關鍵時刻可以給人致命一擊。

在出現安全問題的時候，首先要判斷服務器有沒有被人控制，如果被控制了，危險非常大;如果僅僅是利用應用程序漏洞，那么危險性就會小很多。

服務器一旦被攻擊，那么數據庫密碼等關鍵信息就會泄露，數據庫就相當于裸奔了，就算數據庫隔離的好，還是抵擋不住別人一條DELETE語句;為了減少損失，有兩個建議。

第一就是數據庫用戶授權要做的更精細一點;另外使用proxy代理數據庫，通過proxy來抵擋一些攻擊。

應用層的攻擊主要利用軟件的漏洞，或者考驗編程人員的能力。所以經常升級系統和軟件，使用相對成熟的代碼框架，嚴謹編程，能夠減少很多問題，大概90%的安全問題還是由于代碼的原因。

當然口令安全也非常重要，有很多理論知識，但只要掌握幾點就能解決大部分問題，口令一定要是強口令，避免暴力破解;另外就是口令存儲要使用更嚴格的密碼學算法，不要簡單的sha1然后存儲到數據庫中，很容易字典攻擊;最后在應用層的防攻擊也很重要，不過現在很少直接口令登陸了，都是驗證碼或者微信授權。

當然很重要的一個習慣就是經常性變更口令，能夠解決很多問題，其實有的時候出現一個安全問題，最后才發現，口令泄露了，根本不是技術問題。

對于服務器本身安全，就是盡量少裝軟件;少開外網端口(比如mongodb，es一定不要綁定外網端口)，即使開了，也要做白名單;使用防火墻做更細顆粒度的控制;服務之間做隔離，比如web服務器被攻擊了，但web服務器訪問的數據庫密碼由更安全的硬件存儲，這樣危險性就少了很多。

有的時候大家很注意外部安全，但內網之間的隔離也非常重要，不能暢通無阻。

隔離還有個好處就是出現問題后，可以快速在其他機房復制服務，從而減少故障的影響。授權也很重要，服務之間的授權方式一定要在云端，不能依賴本地。

當然核心安全還是數據庫資源，數據是一切之本。

最后沒有絕對的安全，都是博弈，如果網站規模不大，可能沒人愿意黑你。而如果規模化了，那么就樹大招風了。提前做好準備，以便應對，不至于出現問題的時候手足無措。