1. 程式人生 > >Web框架下安全漏洞的測試反思

Web框架下安全漏洞的測試反思

此文已由作者王婷英授權網易雲社群釋出。

歡迎訪問網易雲社群,瞭解更多網易技術產品運營經驗。


在平時的測試中,一般情況下,我們都是比較關注功能業務測試,以及對應的介面測試,很少去關注對應的業務設計上存在的安全漏洞測試分析。隨著行業對安全的要求越來越高,同時我們電商是經常在網路上發生交易操作的網站,更是要關注安全測試相關的測試場景的考慮。

之所以來編寫這篇web的裡的安全測試的文章,主要是在平時的測試過程中,發現了我們的考拉網站上存在一些安全性的漏洞。一部分的安全漏洞不會公司帶來資損,但是還有一部分的安全性漏洞會對公司造成一定的資損,這樣子的安全性的漏洞更應該被重視,那麼安全性的測試也更應該被重視起來。

簡單羅列目前發現的安全性問題:

  • 使用者購買會員的金額可以通過修改請求裡的金額,進行購買--------根本原因:後端的程式碼沒有將拿到的使用者的金額和實際的金額進行對比,再去發出下一步的支付流程。

  • 對訂單進行評論的獲取考拉豆的時候,可以通過變更URL上的orderID來進行變更,從而將別人的訂單進行評價,而獲取別人的考拉豆---根本原因:後端沒有對訂單的所屬進行判斷,只是核對該訂單是否存在

下面詳細的說明幾種常見的漏洞:


1、通過修改請求裡的Response引數

   

實名認證這裡的請求:https://m.kaola.com/member/activity/valid/nameAuth.html,只需將請求裡Response裡的code修改為:unknown200,以及將success的值修改為true,然後將這個請求發出去之後,我們的刷子使用者就可以成功的繞過這個圍牆了,去購買參加我們的試用會員了,從而可以享受我們的7天的會員96折的價格

 

2、修改URL上的引數,操作不屬於自己的訂單資訊(越權)

這個是通過修改URL上的訂單引數,可以檢視別人的訂單資訊,以及物流狀況,以及對訂單進行申請售後等操作
這個也是對訂單進行變更,對別人的訂單進行評價,來收穫別人的訂單的返考拉豆

通過修改URL連結上的引數來進行一些非對應賬號的資訊的檢視和操作,從安全的角度來看是沒有進行隱私保護操作。甚至會帶來一些客戶投訴,更加嚴重的是,使用者對我們的產品失去信任,不再使用。這些不應該是是開發人員去思考的,更應該是QA在平時的需求測試中進行關注的地方。

有人說,修改訂單號,怎麼可能,別人怎麼知道我們的訂單號生成的規律。其實我們認真的分析我們的訂單號,還是可以找到一定的規律

如:gid=201712102237GORDER36432705---在GORDER前面的是我們的訂單生成的年月日,後面是8位流水號,其實真的要去操作,還是在一定程度上可以修改URL的引數。

   

3、本應該是post請求,硬是設計成get請求

   

    

為加強QA對功能業務重視的情況下,同時也要在平時的業務測試的過程中重視安全性相關方面的測試,為了更好的在測試過程中養成敏銳的觀察能力。首先web需要了解下,Web的相關節點,瀏覽器、http請求、中介軟體、資料庫等之間的關係。


在資料的傳輸中,我們可以把 web 簡單的分為幾個層次:

  1. 瀏覽器:瀏覽器即客戶端,提供客戶端和伺服器端的資料資訊互動。

  2. http:客戶端與web伺服器進行互動時就存在web請求,這種請求都基於統一的應用層協議——HTTP協議來互動資料。http屬於輕量級協議,無需連線,提供了對通訊錯誤的容錯性(常見的3次握手)。

  3. 中介軟體:中介軟體是位於平臺(硬體和作業系統)和應用之間的通用服務

  4. Server容器:Server容器負責解析使用者請求和指令碼語言,類似的有Tomcat,JBoss等。我們訪問網頁看到是web容器處理後的內容。

  5. 資料庫:動態頁面可提供互動式的資訊查詢服務,主要依賴於web資料庫的實現,對外提供包含表單的Web頁面作為訪問介面,查詢結果也以包含資料列表的Web頁面形式返回給使用者。

那麼針對上面的一些問題,我們應該怎麼去避免呢?如上面的越權的資訊,實際上是沒有對當前的cookie進行驗證,以致可以通過修改URL上的引數就能操作別人的訂單資訊。

對敏感資料存在的介面和頁面做cookie,ssid,token或者其它驗證,如下圖所示:

 
其實,還有很多安全方面的測試,如cookie裡不應該暴露比較敏感的資訊等等。


結束語:

這些安全的漏洞的根本的來源是開發設計邏輯存在缺陷,於是給我們的黑客存在可利用的空間。在平常的業務測試中,我們不可能要求開發設計邏輯能面面俱到,也不可能發現所有的邏輯缺陷,這些缺陷給我們帶來的傷害其實是巨大的。如使用者的驗證碼被爆破、會員手機號被遍歷、抽獎次數本地被修改、跳過手機簡訊驗證修改他人密碼、登陸等介面返回使用者密碼等資訊、簽到邏輯不嚴,導致薅羊毛等等問題,都會給我們的產品打上一個不好的標籤。因此,功能QA不僅子在乎開發的需求是否滿足互動稿的同時,而且也要考慮下各種安全的場景測試,在一定程度上規避安全漏洞被不法使用者使用,造成不堪後果的損失。

       

網易雲免費體驗館,0成本體驗20+款雲產品! 

更多網易技術、產品、運營經驗分享請點選

相關文章:
【推薦】 Docker容器的原理與實踐(下)