測試人員如何保證業務安全性?

2021-09-11 14:03:54 字數 2121 閱讀 2221

業務安全:某個平台上的業務是指該平台使用者在使用過程中涉及到的一系列流程,而業務安全就是保證這些流程按照預定的規則執行。

下面先來看看常見的業務安全點(業務威脅)

常見的業務安全點

由於網際網路企業的特性,其主要業務直接體現在其平台上。其中有不少通用的業務流程:

a.註冊

b.登入

c.密碼找回

d.使用者資訊儲存

a.購買/支付

b.優惠活動

c.搶購活動

d.…那麼面對這些威脅,企業安全應該如何改進?

針對賬號體系

通過驗證碼、簡訊驗證碼、郵件驗證碼等增加批量註冊的成本

收集註冊使用者資料,分析註冊後使用者的行為。通過對比正常使用者與馬甲使用者的行為、指紋等,標識馬甲使用者。或凍結沒有行為的賬戶

將分散的登入入口統一,防止由於遺漏而造成撞庫

增加驗證碼等人機識別方式,防止登入撞庫

限制賬號登入頻率以及次數

通過資料分析使用者登入趨勢圖,區分不用時間使用者嘗試登陸曲線、使用者登入失敗曲線、使用者登入成功曲線,可以在發生撞庫行為時做到及時響應

提示高危賬號進行密碼修改(登入後推送)

建立使用者價值體系,通過使用者記錄、信用、行為等不同維度資料建立使用者價值體系

優化密碼找回邏輯,防止邏輯錯誤

對返回使用者資訊進行脫敏處理

通過資料分析使用者重置密碼趨勢圖,可以在發生批量使用者密碼重置時做到及時響應

對使用者資訊進行加鹽雜湊等處理

針對其他具體業務

通過使用者成功下單、支付等建立維度,凍結不符合規範的賬號,或在某段時間內限制其下單

驗證購買/支付流程,後台增加校驗機制

例子: 餓了麼邏輯漏洞之免費吃喝不是夢

繫結優惠券與賬號,限制單個號碼/賬號獲取的優惠券數量

對於批量註冊馬甲賬號的行為可以通過賬號體系進行限制

調整獎勵規則(現金變成券),增加使用成本(繫結身份證、銀行卡)

縱深防禦,從賬號體系開始

購買過程中,增加人機識別,加大惡意搶購成本

增加黃牛檢測機制,通過收貨位址、賬號、訂單數量、手機號碼、收貨人等不同維度檢測黃牛賬號

過濾從其他維度獲取的黃牛賬號

白名單使用者直接通過黃牛驗證

將付款後異常退款加入加入黑名單,標識賬號、收貨位址為黃牛賬號

規範業務上線流程,防止未開放業務上線

增加反爬蟲機制,對訪問**進行限制

處理這類風險較複雜,可以從使用者行為特徵、使用者賬號信任評級加以區分

同時開啟使用者舉報功能

分析具體業務,找出攻擊者獲利點

建立黑名單共享聯盟,將惡意的ip、使用者id、郵箱位址、手機號碼等列入黑名單

在上面的部分中,可以對使用者行為進行分析、建模,例如:

正常使用者的流程/記錄為:註冊—>登入—>查詢—>下單—>支付—>檢視訂單—>收貨

異常使用者的流程/記錄為:註冊—>登入—>領取優惠券

還可以對日誌進行實時分析:

url深度(單斜桿出現次數)

訪問離散度(頁面數/訪問次數)

200響應比例

使用者訪問入口

a.專案立項風控、安全測試介入

業務評審、評估業務風險點

業務上線前經過安全測試,包括傳統安全、業務介面、業務邏輯、黑白盒測試

b.業務資料實時監控

c.異常事件介入分析

通過資料實時分析,確定當前資料是否符合預期

d.業務規則動態調整

當出現非預期的狀況時,適當調整、優化規則

e.止損控制

當業務從需求上無法控制時,就要降低損失比例,減少業務損失

f.業務隔離

隔離重要業務與風險業務,使其單獨執行

業務安全挖掘思路

要挖掘業務漏洞,需要先了解業務邏輯(業務型別/流程),評估風險點。在業務流程中列出正常訪問與異常訪問區別,分析攻擊者的目的及獲利方式,對症下藥,同時還要排除傳統安全威脅。

對軟體測試知識體系不清晰的可以參考

不知道如何學習,沒有方向的可以參考

如何保證資料安全性? 討論

1 是資料本身的安全。主要是指採用現代密碼演算法對資料進行主動保護,如資料保密 資料完整性 雙向強身份認證等 2 是資料防護的安全。主要是採用現代資訊儲存手段對資料進行主動防護,如通過磁碟陣列 資料備份 異地容災等手段保證資料的安全,資料安全是一種主動的包含措施,資料本身的安全必須基於可靠的加密演算...

java 如何保證介面的安全性

根據使用者名稱或者使用者id,結合使用者的ip或者裝置號,生成乙個token。在請求後台,後台獲取http的head中的token,校驗是否合法 和資料庫或者redis中記錄的是否一致,在登入或者初始化的時候,存入資料庫 redis 在使用base64方式的編碼後,token字串還是有20多位,有的...

ajax 如何保證資料的安全性

假如跨站偽造請求成功,怎麼保證 ajax 的資料安全性?答主 bumfod 說的確實有道理。crsf的成因在一定程度上確實是由於http有狀態的原因 cookie維持狀態 並不是我之前所說的是http無狀態的原因。在此如果有人被誤導,我表示抱歉。我們如果能驗證請求確實來是使用者確認 自願 發出的,而...