自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

企業(yè)安全體系建設(shè)之路之Web安全篇

安全 應(yīng)用安全
目前的網(wǎng)絡(luò)攻擊主要還是以WEB攻擊為主流,畢竟這是與外界溝通獲取知識和了解世界的主要橋梁。目前隨著各大企業(yè)對安全的重視,Web的攻擊成本逐漸高于了防御成本,導(dǎo)致業(yè)務(wù)中Web安全漏洞的逐漸減少,甚至常規(guī)漏洞的消亡。

 目前的網(wǎng)絡(luò)攻擊主要還是以WEB攻擊為主流,畢竟這是與外界溝通獲取知識和了解世界的主要橋梁。

目前隨著各大企業(yè)對安全的重視,Web的攻擊成本逐漸高于了防御成本,導(dǎo)致業(yè)務(wù)中Web安全漏洞的逐漸減少,甚至常規(guī)漏洞的消亡。當(dāng)然,一個漏洞的消亡必會有新的漏洞或者攻擊手法的出現(xiàn),攻擊的入門門檻隨之而然逐漸的提高。攻防只有前進,沒有倒退,即使目前Web安全的攻擊成本高于防御成本,防御Web攻擊的軟件再多,我們也不能放松每一個防御點。

Web攻擊現(xiàn)狀

DDoS攻擊和Web應(yīng)用攻擊是當(dāng)今互聯(lián)網(wǎng)面臨的較為突出的兩大安全威脅,DDoS是非漏洞型攻擊,我們暫且不談。Web應(yīng)用攻擊占了網(wǎng)絡(luò)攻擊的主流,由于其地位,這是事實。由于目前國內(nèi)某些原因,導(dǎo)致以前以技術(shù)為主導(dǎo)的現(xiàn)狀不在,現(xiàn)在相對于過去封閉,當(dāng)前往往一個新的攻擊手法出現(xiàn),很長時間都沒有人知道,只在某一小圈子里流傳。所以在Web防御逐漸完善的過程中,我們可以感覺的到,滲透一個網(wǎng)站越來越吃力,而是Web這個東西,目前已知的漏洞挖掘方向點就那么多,針對這些漏洞點的防御軟件又多如牛毛,防御者把這些走已知常規(guī)漏洞路給堵死了,一般的攻擊者可能無能為力,但是對于一些高水平的攻擊者來說,也許并不是無路可走。

所以,依照現(xiàn)狀來看,目前的Web漏洞利用走向開始往邏輯漏洞方面走,如黑產(chǎn)最喜歡的薅羊毛就是一個例子,現(xiàn)在想要拿到Web站點服務(wù)器系統(tǒng)權(quán)限不容易,不過利用邏輯漏洞拿到用戶數(shù)據(jù)信息倒是不難。目前常規(guī)的攻擊手法已很難能夠攻破防護做的比較好的企業(yè),所以,為了了解最新攻擊技術(shù)或漏洞,我們需要搭建蜜罐系統(tǒng)來捕獲攻擊樣本,獲取自家產(chǎn)品的0day漏洞或更新現(xiàn)有落后技術(shù)。

常見漏洞防護

一些常規(guī)的漏洞防護就不說了,防護的軟件已經(jīng)有很多了,漏洞掃描器都可以掃出來,掃不出來的,好一點的防護軟件也是可以識別的。按道理來講,我們應(yīng)用部署安全監(jiān)控軟件是可以防護常見漏洞的,當(dāng)然,我們企業(yè)自身也可以通過漏洞攻擊指紋進行攻擊特征識別,攻擊者繞過防護軟件進行攻擊這個也是我們防護不了的也是不可避免的,只要按照標(biāo)準(zhǔn)化安全編程手冊,出現(xiàn)常規(guī)漏洞的點會很少,至少顯性漏洞不可見。這里主要講講邏輯漏洞問題。

邏輯問題層出不窮,其他的常規(guī)漏洞防范已經(jīng)有了規(guī)范化流程,而邏輯漏洞到目前還沒有一個流程化的防護方案,因為其特殊性,所以我們也得特殊對待。

邏輯漏洞常出現(xiàn)在用戶交互和信息展示之處,當(dāng)然還有與系統(tǒng)進行交互的地方,下面列幾點

驗證碼

驗證碼是我們常見的一種應(yīng)對暴力攻擊的方式之一,主要是為了區(qū)分人和非人的產(chǎn)物,驗證碼經(jīng)歷了多次改版,幾乎每個網(wǎng)站的驗證碼都不盡相同,驗證碼在應(yīng)對繞過和攻擊識別時變得越來越復(fù)雜,用戶體驗也越來越不好。

拿以前的12306的驗證碼為例。

請點擊下面所有的熟雞蛋,鬼都不知道哪個雞蛋是熟雞蛋,怎么猜?

[[254721]]

 

當(dāng)然了,這個只是個笑話,但是也恰恰說明了問題,我們不僅要做好驗證碼,而且還要讓用戶不感到體驗效果差。

驗證碼經(jīng)過了長期的變化,目前主要分為以下這幾類,我們來了解下

靜態(tài)驗證碼

此類驗證碼是比較古老的,應(yīng)該說是最初的驗證碼了,靜態(tài)驗證碼從以前的文本型過度到了現(xiàn)在的圖片型,雖然目前靜態(tài)驗證碼加了很多抗干擾加花等等操作,但是目前能夠識別靜態(tài)驗證碼的手段還是很多的,大多數(shù)的靜態(tài)驗證碼比較容易被ocr軟件識別,通過打碼平臺等,還有就是當(dāng)前火熱的機器學(xué)習(xí),通過訓(xùn)練機器,其靜態(tài)驗證碼的識別率可以達到80%以上,所以現(xiàn)在很多站點都開始棄用此類驗證碼了

Gif動畫驗證碼

有的網(wǎng)站提供GIF動態(tài)的驗證碼圖片,由于在Gif驗證碼中,有多個驗證碼圖層,這些都是隨機的,使得識別器不容易辨識哪一個圖層是真正的驗證碼圖片,可以更有效得防止識別器的識別。但是也是有弊端的,Gif在顯示的最后都會暫停供用戶識別,只要識別出最后暫停的那張圖層,就可以像識別靜態(tài)驗證碼那樣識別Gif驗證碼了。

手機短信驗證碼

手機驗證碼是通過發(fā)送驗證碼到手機,這個是比較好的驗證手段,目前使用這類驗證碼的站點還是很多的。

手機語音驗證碼

這個驗證碼的成本比較高,一般用于金融等站點的驗證碼,不過效果還是很好的。

視頻驗證碼

視頻驗證碼中隨機組合而成的驗證碼動態(tài)嵌入到MP4,flv等格式的視頻中,增大了破解難度。驗證碼視頻動態(tài)變換,隨機響應(yīng),可以有效防范字典攻擊、窮舉攻擊等攻擊行為。攻擊者可以通過抓屏的方式進行識別,但是效果不是很好。

滑動驗證碼

這種驗證碼是最近幾年流行起來的,這個驗證碼需要與用戶進行交互,采用拼圖或滑動左右模式進行驗證。應(yīng)對此類驗證碼攻擊者一般是通過網(wǎng)站的驗證碼接口找突破,或者采用如鼠標(biāo)模擬等操作進行驗證碼識別。

點擊驗證碼

此類驗證碼一般是給出一張圖片讓用戶進行識別,如12306的驗證碼識別。應(yīng)對此類驗證碼攻擊者一樣可以通過鼠標(biāo)模擬等操作進行驗證碼識別。

智力驗證碼

顧名思義就是,給用戶出一道題,讓用戶把答案算出來進行驗證。此類驗證也是存在一定的弊端的,因為驗證碼大多數(shù)是以圖片的形式出現(xiàn)的,而相對于比較低級的算數(shù)題類驗證碼,攻擊者可以用靜態(tài)驗證碼識別的手段進行問題提取,繼而進行算數(shù)運算,從而達到識別此類驗證碼的目的。

交互驗證碼

此類驗證應(yīng)該算是目前前端驗證碼驗證比較安全的驗證碼了。

在有客戶端的站點上應(yīng)用比較廣泛,首先要登錄站點,需要客戶端進行授權(quán),如掃碼登錄,客戶端驗證后,服務(wù)端把登錄信息發(fā)送前端進行登錄操作。

當(dāng)然還有其他的驗證碼驗證手段,這里就不一一介紹了,具體使用什么驗證碼還得看站點的特性和業(yè)務(wù)的類型,沒全有最好最安全的驗證碼,只有最適合的驗證碼。

交互邏輯

交互邏輯漏洞雖然不像常規(guī)漏洞那么厲害,可以直接拿下系統(tǒng)權(quán)限,但是給企業(yè)造成的損失卻是很大的。我們經(jīng)常可以看到一些新聞,說某某網(wǎng)站由于出現(xiàn)支付漏洞,導(dǎo)致?lián)p失多少錢。因為邏輯漏洞是不可避免的,它不像常規(guī)漏洞可以容易的被漏洞掃描器掃出,它更多的是需要測試人員代碼審計或黑盒測試找出。所以這個交互邏輯漏洞也是比較難以防控的一個點。

通常出現(xiàn)交互邏輯漏洞的點為登錄處、支付處、用戶信息交互處和與數(shù)據(jù)庫交互處。因為網(wǎng)站程序的某些交互接口或者數(shù)據(jù)交互接口信息驗證邏輯問題,對提交的數(shù)據(jù)參數(shù)審計不嚴(yán)格,造成交互邏輯漏洞,下面列出比較常見的交互邏輯漏洞。

登錄交互邏輯

在登陸處,一般的測試會測試站點是否嚴(yán)格控制登錄交互,

攻擊者通過抓包查看提交參數(shù),查看是否有可以利用的交互邏輯漏洞,有些站點在登錄參數(shù),也就是帳號密碼傳過來后,會驗證帳號密碼是否正確,然后返回true或者返回false,即使使用錯誤的帳號密碼,當(dāng)返回false時,那么我們就可以改返回數(shù)據(jù)包為true,那么就直接登錄了,更有勝者當(dāng)用戶名正確后,無論密碼是否正確,都直接返回正確的帳號密碼。有人可能會想,即使你改掉包,不是還有cookie或者token嗎?話雖沒錯,但是某些站點的cookie是直接在前端生成,或者在我們改掉包后,服務(wù)器端會把正確的cookie給你返回回來。

還有在找回密碼處,通過找回密碼這個交互邏輯漏洞,攻擊者可以重置任意賬戶密碼,從而達到自己的目的,這對于金融行業(yè)和電商行業(yè)等用戶量大的站點,造成用戶信息泄漏或者資金被盜甚至對用戶造成詐騙等后果,這對企業(yè)的聲譽和發(fā)展都會造成影響和損失。

在找回密碼處,攻擊者一般通過驗證郵箱或者手機號找回密碼,如果帳號匹配,服務(wù)器一般會發(fā)送短信驗證碼或者郵箱驗證碼到用戶手里,那么這個過程如果服務(wù)器端驗證不嚴(yán)格就有可能會造成交互邏輯漏洞的發(fā)生。

重置密碼的攻擊邏輯常見的有如下幾點

  • 攻擊者通過修改返回包,繞過驗證步驟,直接到達修改密碼處
  • 攻擊者通過修改返回包,把當(dāng)前重置帳號(如手機號,郵箱地址),修改為自己的帳號(如手機號,郵箱地址),那么在服務(wù)器沒有對帳號進行嚴(yán)格驗證的情況下,服務(wù)器端會直接把重置驗證憑證發(fā)送到攻擊者的手里
  • 攻擊者通過抓取返回包,由于服務(wù)器端的自身邏輯問題,可能會把帳號密碼等等與當(dāng)前重置帳號的相關(guān)信息給返回過來,不用重置,就知道了用戶密碼
  • 站點找回密碼設(shè)計問題,當(dāng)重置密碼后,服務(wù)器會發(fā)送新的密碼到用戶手中,而這個密碼是幾位的純數(shù)字,攻擊者是可以通過暴力窮舉的方式知道重置的密碼,更有趣的是,某些站點直接是重置密碼為固定的密碼字符串
  • 網(wǎng)頁驗證不嚴(yán)格,可通過url直接到達修改密碼處
  • 某些通過郵件找回的,其重置密碼的鏈接是可以猜測和預(yù)知的

還有就是驗證碼邏輯問題,某些驗證碼雖然在前端進行了驗證,但是在后端卻沒有進行很嚴(yán)格的檢查,攻擊者可以通過刪除驗證碼或者驗證碼是不變的,可有可無的,那么攻擊者就可以實施撞庫或這暴力破解用戶帳號密碼了。在用手機或郵箱或其他接收攻擊接收登錄或重置密碼時,可能出現(xiàn)驗證碼交互邏輯漏洞。我們知道,一般情況下,站點發(fā)送的驗證碼是有時間限制的,通常為幾分鐘,如果驗證碼在后端發(fā)送邏輯有問題的話,就會出現(xiàn)問題。如,當(dāng)攻擊者在爆破時,驗證碼過期時間為5分鐘,時間快到了時,攻擊者再發(fā)送一次請求,因為后端沒有做失效控制策略,就又會收到一次一模一樣的驗證碼,而且時間又是5分鐘,那么想要爆破某一個帳號的密碼就不再是什么難事了。當(dāng)然還有站點直接返回驗證碼的,或者驗證碼是在前端生成通過后端直接發(fā)送到用戶手中的。

想要防護登錄交互邏輯此類的漏洞也很簡單,就是要對相關(guān)的參數(shù)做個嚴(yán)格的驗證,如

  • 登錄的邏輯不返回前端,由后端管控,前端進行調(diào)用
  • 驗證碼失效時間進行嚴(yán)格控制,驗證碼不能多次使用,為一次性驗證碼,獲取驗證碼的時間也要有時間限制,由后端管控,預(yù)防被用于短信轟炸
  • 所有的賬戶重置信息都不返回給前端
  • 生成的重置密碼連接是不可預(yù)知的,隨機的

當(dāng)然,防護手端多種多樣,最主要的只有一點,那就是嚴(yán)格檢查參數(shù),對參數(shù)進行嚴(yán)格的校檢,預(yù)防此類漏洞就只能是提高驗證邏輯。

支付邏輯

支付漏洞可以說是比較嚴(yán)重的邏輯漏洞了,畢竟是涉及到錢這個問題。一個支付漏洞有可能會對企業(yè)造成巨大的損失。

支付漏洞的產(chǎn)生符合邏輯漏洞特點,都是其修改自身邏輯達到欺騙的效果。

支付的一般流程為:確認(rèn)信息=>提交訂單=>支付=>支付成功

主要的漏洞點如下

1.修改參數(shù)屬性值

參數(shù)的屬性值有

  • 支付金額
  • 代金卷
  • 積分
  • 其他

這幾個屬性值也是最為基礎(chǔ)和常見的支付邏輯漏洞發(fā)生點,攻擊者一般的攻擊手法為修改支付金額的多少來進行測試,出現(xiàn)漏洞的支付步驟一般在提交訂單時或提交訂單之后,通過把支付的金額修改成低價格或者修改為負(fù)數(shù),如果后端判斷邏輯有問題,那么就會出現(xiàn)支付邏輯漏洞了。

所以,在后端進行判斷時,要對相關(guān)參數(shù)進行綁定,即使在前端修改了,后端也是可以初始化參數(shù)的。

2.修改數(shù)量值

這個和修改參數(shù)屬性值差不多,也是把商品數(shù)量修改為負(fù)數(shù)達到支付金額成負(fù)數(shù)的效果,當(dāng)然還有一種就是商品差價修改,用一種低價格商品的數(shù)量總金額去支付高價格商品的數(shù)量總金額,如果后端邏輯有問題,那么就可以低價格購買高價格商品了。

3.越權(quán)支付

越權(quán)一般發(fā)生在支付環(huán)節(jié),攻擊者可以通過修改自身ID為其他用戶的ID值,如果沒有嚴(yán)格的支付密碼或驗證碼的話,就可以達到用他人賬戶為自己的商品買單的效果,當(dāng)然還有其他的越權(quán)支付手段,如越權(quán)支付他人賬單,越權(quán)提現(xiàn)他人現(xiàn)金等。

4.條件競爭

條件競爭這個詞我們在Web漏洞或是其他系統(tǒng)漏洞中都是可以看到的,條件競爭利用其高并發(fā)線程,利用時鐘延遲(后臺處理延遲)達到多出或或高于現(xiàn)有正常結(jié)果。如LFI漏洞,通過不斷寫入tmp文件,達到getshell的目的。同樣,如提現(xiàn)功能來說,如果我們把要提現(xiàn)的金額分成多份,通過高并發(fā)線程,如果后端處理能力或者邏輯判斷能力存在缺陷的話,那么我們就可以提現(xiàn)高于提現(xiàn)次數(shù)的金額。

5.支付狀態(tài)

通常在我們支付成功后,服務(wù)器會返回一個支付成功或支付失敗的結(jié)果,如果在后端沒有對支付狀態(tài)和訂單號進行綁定的話,那么攻擊者只需要修改返回狀態(tài)為True就會成功購買商品,而無論支付是否成功。

支付邏輯漏洞主要是代碼層方面的防護,如果后端對提交的參數(shù)進行了綁定,那么無論前端怎么的修改,后端都是可以判斷和初始化參數(shù)的;對于支付接口來說,如果調(diào)用第三方支付接口的話,也是要對接口進行綁定,最好對訂單號進行綁定,避免用不存在的支付接口支付成功。

對于此類支付漏洞來講,我們能做的就是提高風(fēng)控手段,所有的支付結(jié)果要進行延時處理,把支付結(jié)果與訂單之前的結(jié)果進行對比,查看是否異常,必要時加入人工審核,以此來減小事故發(fā)生幾率。

越權(quán)

對于越權(quán),越權(quán)也是屬于邏輯漏洞的一種。

越權(quán)漏洞的存在環(huán)境,在Web環(huán)境中的不同而不同,拿有登錄操作的站點來聊聊。在這類站點中,越權(quán)一般出現(xiàn)在個人信息處,如我們點擊個人信息,通常在個人信息鏈接數(shù)據(jù)包里會帶有用戶userid,不出意外的話,我們修改其userid為其他用戶userid會出現(xiàn)其他用戶的信息。這個漏洞的產(chǎn)生是后端對用戶的權(quán)限或登錄狀態(tài)判斷不嚴(yán)造成的,對于此類漏洞站點一般的做法是添加用戶token或附帶其他什么亂七八糟的驗證,對于越權(quán)也算是比較好的防范了。

當(dāng)然,邏輯漏洞遠不止上面提到的這么多,邏輯漏洞的防范是一個長期的過程,隨著站點的業(yè)務(wù)和功能的拓展,其邏輯復(fù)雜度也在增加,只要企業(yè)把控好權(quán)限、驗證、輸出這三個點,邏輯漏洞出現(xiàn)的幾率也就小了許多。

系統(tǒng)錯誤配置

某些站點的安全管控做的非常好,但是細(xì)節(jié)卻處理的不好,其中不乏一些大的廠商,站點不出現(xiàn)漏洞,但是支持站點運行的服務(wù)器軟件由于站點管理員的違規(guī)操作可能會導(dǎo)致大的漏洞產(chǎn)生。如Apache開放了PUT功能,權(quán)限管控不到位所導(dǎo)致的目錄遍歷操作,IIS的短文件名漏洞等。所以按照規(guī)范定期進行服務(wù)器基線檢查是非常有必要的。

數(shù)據(jù)庫漏洞

數(shù)據(jù)庫漏洞一般就是弱口令或未授權(quán)訪問,其余的如REC等漏洞或多或少還是需要點權(quán)限的,隨著企業(yè)的安全意識提高,建站一般會使用站庫分離的做法,這樣做可以很好的保護數(shù)據(jù)庫服務(wù)器和提高站點服務(wù)器的系統(tǒng)資源利用率,提高站點安全性。當(dāng)然,站點的權(quán)限如非必要,最好還是進行降權(quán)賬號登錄,很多的數(shù)據(jù)庫漏洞都是因為暴露在公網(wǎng)導(dǎo)致的被入侵,如果權(quán)限較低的話,那么被攻下的難度就很高了。

從站點的SQL注入漏洞來講,這本身就不屬于數(shù)據(jù)庫漏洞了,屬于站點自身的漏洞,所以SQL注入的根源在于站點代碼,而非數(shù)據(jù)庫。

薅羊毛

薅羊毛這個雖不能算是漏洞(也可以說和漏洞危害差不多),但是對企業(yè)造成的損失還是很大的,目前薅羊毛現(xiàn)已經(jīng)成為了一個產(chǎn)業(yè)鏈,羊毛黨利用網(wǎng)站漏洞或者人員條件(黑產(chǎn))等其他優(yōu)勢,合法占用企業(yè)資源,使企業(yè)的宣傳或活動達不到預(yù)期的效果,浪費企業(yè)資源,甚至造成損失。

當(dāng)企業(yè)辛辛苦苦策劃出來的活動被羊毛黨利用,企業(yè)投入了大量物力換來的是羊毛黨的流量,那么,我們有什么方法能減少被薅羊毛額幾率呢?

防范羊毛黨可以從以下幾個方面著手

  • 嚴(yán)控注冊流程,阻止非法注冊
  • 定期清理垃圾帳號
  • 提高參加活動的門檻
  • 對參加活動的用戶進行嚴(yán)格的資格審核,提高用戶真實性
  • 平臺漏洞:嚴(yán)控相關(guān)活動的接口調(diào)用邏輯,確保通過了安全檢測后上線
  • 延遲活動獎勵的時限
  • 增加和提高合法用戶真實性(人機用戶)驗證機制

當(dāng)然,具體的防范措施也不是依照以上幾種防范措施就能完全杜絕薅羊毛的行為,所謂完善的安全管控體系,都是建立在具體實踐的基礎(chǔ)上的,防范管控經(jīng)驗都是在經(jīng)歷了”具體事故“才能很完美的總結(jié)出來,這樣才能對企業(yè)自身或者具體業(yè)務(wù)量身定制一套薅羊毛應(yīng)對措施,往大了說還能通用于某一行業(yè)的所有產(chǎn)品。

第三方程序管控

一個企業(yè)里面,用到的Web程序不敢說都是自己開發(fā)的,或多或少會用到其他企業(yè)的開源或收費的Web程序,那么這些Web程序又該如何管控呢?

對于此類應(yīng)用來說,上線和自身產(chǎn)品差不多,都是需要經(jīng)過安全評估的,通過了安全評估以后,進行備案上線。后續(xù)需定期關(guān)注官網(wǎng)補丁并及時進行補丁更新,如果Web程序存在0day漏洞的話,結(jié)合當(dāng)前服務(wù)器的安全策略進行管控。

權(quán)限管控

權(quán)限這個問題是站點被攻破后的最后一道防御點,如果站點權(quán)限出現(xiàn)問題,那么整個站點就真的淪陷了。

在Web的滲透測試中,攻擊者在拿到了可以操控站點的權(quán)限時(如后臺登錄權(quán)限),首先想到的就是上傳腳本木馬來控制服務(wù)器,然后利用腳本木馬來進行提權(quán)操作,最后內(nèi)網(wǎng)滲透等等。

所以在攻擊者有了操作站點權(quán)限的這個節(jié)點時是企業(yè)管控Web這最后一道防線的關(guān)鍵點,下面我們來討論下權(quán)限問題。

站點的啟動一般不用最高權(quán)限啟動,一般管理員會新建一個低權(quán)限的賬號來啟動Web站點服務(wù),用低權(quán)限啟動的Web服務(wù)權(quán)限有限,無法執(zhí)行創(chuàng)建修改或刪除文件等高權(quán)限操作,所以對腳本木馬的寫入有一定的防范作用;但是有一些站點因為要使用某些第三方庫,或者需要執(zhí)行某些合法的敏感操作,可能會要求請求高權(quán)限啟動,這個時候權(quán)限管控就會有一定風(fēng)險存在了,企業(yè)能做的就是對整個站點進行旁路權(quán)限管控,如:

  • 上傳目錄的腳本解析和執(zhí)行權(quán)限
  • 站點的命令執(zhí)行權(quán)限
  • 跨目錄權(quán)限

所以,權(quán)限最大的問題在于執(zhí)行上,如果控制了執(zhí)行權(quán)限,那么無論你怎么上傳,上傳什么文件,都執(zhí)行不起來。

權(quán)限管控是一個老生常談的問題,權(quán)限和業(yè)務(wù)有著比較矛盾的問題,因為有些情況下需要開啟高權(quán)限來支撐站點的某一功能,但是在該功能的高權(quán)限開啟情況下又會出現(xiàn)安全問題。所以說,權(quán)限管控并不難,難就難在要配合具體業(yè)務(wù)場景而又不要出現(xiàn)安全問題上。

日常監(jiān)控

監(jiān)控站點是一種了解當(dāng)前站點運行狀態(tài)的必要手段,也是一種獲取攻擊和威脅情報的來源之一。

監(jiān)控的手段一般為

  • 日志監(jiān)控
  • 通信流量監(jiān)控
  • 文件監(jiān)控
  • 系統(tǒng)操作監(jiān)控

通過監(jiān)控手段,企業(yè)可以獲取大量有用的信息,能夠幫助企業(yè)改善產(chǎn)品、獲取威脅情報、調(diào)查取證等方面有著很大的幫助。

日志監(jiān)控主要是針對于Web服務(wù)器和站點所產(chǎn)生的日志情況,提取日志中所產(chǎn)生的異常并針對性的進行處理。

通信流量監(jiān)控主要是針對Web站點的所有流量進行的監(jiān)控,在通信流量里面一般會包含攻擊行為,那么對于匹配性的攻擊行為進行預(yù)警,篩選出攻擊流量進行分析,如果可靠的話,我們有一定的幾率可以獲得新的攻擊技巧、0day漏洞或者發(fā)現(xiàn)站點新的漏洞等。對于某些攻擊流量來說,一個站點存在命令執(zhí)行,在流量中會出現(xiàn)系統(tǒng)命令或其他第三方命令等特征字符。

文件監(jiān)控是站點監(jiān)控里比較重要的監(jiān)控之一了,因為攻擊者攻擊站點時一般都會對文件進行操作,文件的變動可以讓被入侵的站點快速定位入侵點,從而應(yīng)急及時,減小損失;文件監(jiān)控對于權(quán)限管控不到位而造成的安全問題有著比較好的支撐,對于那些正常文件被寫入腳本木馬的文件來說,我們可以知道寫入的代碼是否為木馬代碼,是否為正常代碼,是否為非法寫入。

系統(tǒng)操作監(jiān)控主要為針對Web站點所執(zhí)行的系統(tǒng)操作,在系統(tǒng)操作監(jiān)控里面,我們可以看到Web站點和系統(tǒng)的所有交互行為,通過監(jiān)控日志,我們可以分析得出,Web站點的哪些文件在與系統(tǒng)進行交互,執(zhí)行的行為是否為正當(dāng)合法的行為(和syslog取證差不多)。

通過監(jiān)控的手段,我們可以清楚的了解到站點服務(wù)器都做了些什么,它們所做的事情是否是正當(dāng)?shù)?。監(jiān)控手段所帶來的好處就是,如果出現(xiàn)安全問題能夠在第一時間找出問題所在,監(jiān)控手段在檢測到疑是攻擊行為時,可以進行有效的攻擊阻斷,即使是Web站點存在漏洞情況下。這一點就和WAF的功能有相識之處了。

WAF

權(quán)限管控是Web安全的最后一道防線,那么WAF(Web Application Firewall)可以說是Web安全中的第一道防線。

在目前互聯(lián)網(wǎng)的Web站點中,無論網(wǎng)站大小或多或少會安裝WAF來保護網(wǎng)站,在安裝了WAF的網(wǎng)站比不安裝WAF的網(wǎng)站安全性要高,站點安裝了WAF提高了攻擊的門檻,可以防范一般的(沒有什么技術(shù)能力的)攻擊者。隨著技術(shù)的發(fā)展和安全攻防的交鋒加劇,WAF的功能也從以前的功能單一逐漸變?yōu)楝F(xiàn)在的多功能WAF,不僅能夠攔截過濾還能殺毒等。

當(dāng)然,不得不說的就是現(xiàn)在常用的加速器CDN(Content Delivery Network)了,CDN發(fā)展也是差不多,以前只是單一個給網(wǎng)站加個速,發(fā)展到現(xiàn)在,CDN有了WAF的功能,能夠代替WAF做一些攻擊攔截的事情,當(dāng)然不是有了CDN就能完全代替WAF了,如果攻擊者繞過了CDN找到了服務(wù)器的真實IP地址呢,又當(dāng)如何?

在Web安全的建設(shè)中,WAF不能說必不可少,但是有了WAF,站點的安全性能夠提高到一個檔次,不僅能夠擋掉一些普通攻擊者的攻擊,還能夠提高高級攻擊者的攻擊成本,即使網(wǎng)站淪陷了,不是還有其他的防護手段嗎?都是擺設(shè)?沒錯,其他的防護手段就是擺設(shè)。

安全建設(shè)就是這樣,防護做的再好,如果沒有從根源解決問題,攻擊者只要有心,那么一切的防護手段繞過只是時間問題,這個就和擒賊先擒王是一個道理了。所以,Web漏洞的根源就是站點代碼,只要代碼層顯性漏洞不存在,加上代碼層的其他安全防護措施做到位,那么站點就能做到相對安全,而能夠讓站點做到相對安全的就是“代碼安全審計”。

代碼安全審計

代碼審計作為安全測試中重要的一環(huán),代碼審計能夠發(fā)現(xiàn)一些潛在的漏洞,幫助企業(yè)更好的完善Web程序,減少被攻擊的風(fēng)險。

如上文所述,站點服務(wù)器的防護做的再好,如果站點的程序代碼存在問題的話,那么一切的防護措施可能成為擺設(shè)。作為一個負(fù)責(zé)的企業(yè),要對自己和自己的用戶負(fù)責(zé),那么Web產(chǎn)品在發(fā)布或新版本更新時,就需要進行代碼審計,以最大的可能減小漏洞發(fā)生的幾率。

對于Web程序來講,代碼審計一般特別針對常規(guī)高危漏洞,因為對于常規(guī)漏洞一般的掃描器都是可以掃的出來的,而對于那些需要特定條件才能觸發(fā)的漏洞(如CSRF,埋雷攻擊),產(chǎn)品能做的就是盡可能的控制各個交互的權(quán)限分離和綁定(加強驗證)。

目前市面上免費的和收費的代碼審計產(chǎn)品有很多,大多數(shù)都是基于靜態(tài)分析,所以誤報率還是比較高的,審計工具它只能是個參考,具體的邏輯分析還是需要專業(yè)的安全技術(shù)人員跟進。那么代碼審計也有一定的盲區(qū),因為隨著一個產(chǎn)品的功能增加,代碼量的加大,有時候一個產(chǎn)品的代碼就有幾萬行,大小幾十上百兆,不可能說完全依靠人工能夠?qū)徲嫷耐甑?,就算審計完了,質(zhì)量還是得不到保證。在這個情況下,工具就有了用武之地,代碼審計可以以白加黑的方式進行,審計效率可以提升很多。

在我們代碼審計無法觸及之處,其余的漏洞就只能交由網(wǎng)絡(luò)白帽子來進行發(fā)現(xiàn)了。

安全眾測

眾測是最近幾年火起來的,在網(wǎng)上也有許多的眾測平臺,在這些平臺上,企業(yè)可以花比較少的錢就能把Web安全做的上個大的檔次。由于人的精力和攻擊知識面不同,在企業(yè)內(nèi)部代碼審計和滲透測試無法再找到漏洞時,拿去進行一次眾測,不出意外的話,一定可以收到不一樣的效果。正所謂“山外青山樓外樓”,白帽子發(fā)現(xiàn)的漏洞和其獨特的利用姿勢可以作為Web產(chǎn)品安全的完善方向。而對于比較小型的網(wǎng)站來說,眾測就顯得沒有什么必要了。

業(yè)務(wù)風(fēng)控

一個web系統(tǒng)的安全性如果做的很好了,常規(guī)漏洞一般是不會出現(xiàn)的,那么由于攻擊手法的不確定性,如果有新型的漏洞或者更高級的攻擊手法出現(xiàn),那么一個web系統(tǒng)將面臨高風(fēng)險。所以企業(yè)需要自身有一套完善的風(fēng)控制度,一旦發(fā)生安全問題,能夠在第一時間以最快速度解決問題,降低損失。整個風(fēng)控的方面可以從:社會影響、內(nèi)部影響、經(jīng)濟損失等方面著手,建立起完善的災(zāi)備恢復(fù)體系。著重加強縱深防御,防止外部威脅擴大到內(nèi)部。

Web安全建設(shè)總結(jié)

在Web安全中,攻擊利用的手法多變,它不像系統(tǒng)漏洞那樣,只要管控好端口,那么遠程攻擊就會失效。Web雖然簡單,但是漏洞的成因還是很復(fù)雜的,不是我們把可能存在的漏洞點堵上就能沒事的,反之,Web以一個小小的錯誤都有可能會導(dǎo)致所有的防御失效。攻擊者攻擊Web程序只需要一個點,而防御者卻需要防御的是整個面,在Web攻防中,一直以來Web的防御都是處于被動的局面,企業(yè)想要改變這一局面,只能是任重而道遠。

鑒于Web漏洞防御和漏洞成因的復(fù)雜性,Web安全建設(shè)不是本篇文章能夠說的清的,也不是企業(yè)把握好文章中的幾個點就能把Web安全建設(shè)的好的,這樣的話只能說筆者站著說話不嫌腰疼了。Web安全的體系建設(shè)不僅僅是安全漏洞的管控,當(dāng)然還包括了其他的方方面面,攻擊者可能利用合法的網(wǎng)站功能來干一些不可描述的事情,如果Web安全的建設(shè)是很簡單的話,就不會出現(xiàn)眾多安全專家都頭疼的事情了。

所以,具體的Web安全建設(shè)各個企業(yè)不同,所屬業(yè)務(wù)不同,自然所做的建設(shè)方案也會有所不同,能夠建設(shè)起來非常棒的Web安全體系,企業(yè)都是經(jīng)過了眾多實踐積累下來的經(jīng)驗。

不過,對于Web防御重要的幾個點,倒還是比較通用的。

權(quán)限問題

權(quán)限在Web安全中是很重要的,因為攻擊者有了操控站點的權(quán)限后,就會想方設(shè)法的拿到服務(wù)器的權(quán)限,進而完成更深入的滲透。權(quán)限的管控在于當(dāng)前業(yè)務(wù)所屬類型決定,權(quán)限分制能夠讓權(quán)限得到更好的管控。

主動防御問題

主動防御就是一些WAF等審計系統(tǒng)了,主動防御不是萬能的,使用不當(dāng)還可能會對自身業(yè)務(wù)產(chǎn)生影響,主動防御會被繞過的幾率還是有的。

監(jiān)控問題

監(jiān)控這一部分是比較難的點,因為由于攻擊手法的不確定性,監(jiān)控規(guī)則不夠靈活等方面,造成了監(jiān)控可能會有遺漏的地方。

代碼安全審計問題

代碼的安全審計是Web安全之根本,如果沒有審計過的程序上線的話,可能存在的高風(fēng)險就會比審計過的程序多,所以,代碼審計是Web程序正式發(fā)布版本前的必要工作。

責(zé)任編輯:武曉燕 來源: HACK學(xué)習(xí)呀
相關(guān)推薦

2019-07-01 12:55:05

安全體系架構(gòu)網(wǎng)絡(luò)安全企業(yè)安全

2018-05-26 16:31:31

2020-08-18 08:11:08

安全體系化建設(shè)漏洞網(wǎng)絡(luò)安全

2022-09-13 11:40:49

智慧城市

2025-01-08 10:30:24

2017-01-20 15:37:06

2016-10-17 23:11:41

2009-12-09 09:49:29

ibmdwWebSphere

2024-01-29 00:17:02

2011-01-21 11:05:46

2020-06-03 11:15:37

數(shù)據(jù)安全信息安全安全威脅

2012-12-25 14:23:10

2021-04-30 10:09:32

終端安全

2017-07-11 12:29:35

2011-10-13 15:05:01

趨勢科技廣發(fā)銀行

2010-05-25 11:05:34

2011-10-14 11:18:14

數(shù)據(jù)安全

2017-08-03 16:00:43

2019-12-05 10:46:32

網(wǎng)絡(luò)安全架構(gòu)DHS

2018-01-17 17:20:08

點贊
收藏

51CTO技術(shù)棧公眾號