[[337378]]

本文轉(zhuǎn)載自微信公眾號「虞大膽的嘰嘰喳喳」，作者虞大膽  。轉(zhuǎn)載本文請聯(lián)系虞大膽的嘰嘰喳喳公眾號。

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

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

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

另外攻擊就是sql注入，破壞過一些表數(shù)據(jù)，但大范圍的故障沒有出現(xiàn)過。

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

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

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

所以現(xiàn)在攻擊的土壤就是企業(yè)內(nèi)部網(wǎng)站了，因為它們大多數(shù)運行在瀏覽器之下，那如何解決呢?

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

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

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

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

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

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

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

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

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

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

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

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

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

當然核心安全還是數(shù)據(jù)庫資源，數(shù)據(jù)是一切之本。

最后沒有絕對的安全，都是博弈，如果網(wǎng)站規(guī)模不大，可能沒人愿意黑你。而如果規(guī)?；耍敲淳蜆浯笳酗L了。提前做好準備，以便應對，不至于出現(xiàn)問題的時候手足無措。