平時遇到的一些零星的安全問題，總結一下：
在SDL中，越權類漏洞如何檢測？
在應用安全實踐中，目前已知的OWASP TOP10 很多都是可以通過框架或者一些組件解決的，再加上DAST/IAST/SAST這些產品的集成，一般的漏洞類型都是可以檢測出來的並處理掉的，但是業務邏輯類漏洞是個例外，以至於現在很多的SRC上爆出來的都是越權這類的業務邏輯類漏洞，越權類漏洞分3種，未授權訪問/平行越權/垂直越權。接下來總結一下這類漏洞的解決方案
1.框架層面上解決:
很多類型的漏洞都是可以在框架上解決的，一方面確實方便，推廣起來也容易。所以有些公司也想着在框架上面來解決越權類漏洞，以此來達到方便快捷解決這類漏洞，其實不然，我們細細會想一下，在框架上解決這類漏洞它的實現機制是框架上要求用戶輸入的內容時要求校驗用戶是否登陸，也就是拿到用戶的token去訪問。
舉個例子，不一定普適。之前遇到一類漏洞，就是改了cookie裏面的uin，結果可以在某個業務上越權，原因是該業務沒有去校驗cookie中的uin與skey的對應關係，下放到各個業務去做這個事，有的開發就不檢查，後頭我們把框架改了，不讓開發自己檢查，而已必須把uin和skey傳到SSO服務來檢查，否則就沒法通過認證。大概這樣子，然後這類問題就解決了
這個例子是別人的，但在我經歷過的公司是真實發生過的案例
缺點：
1.業務和框架耦合度過高，框架變複雜
2.解決的其實是未授權的問題，並沒有解決平行越權的問題
3.uin一般是app端生成的隨機🈯️，一般就算修改也是碰撞，很難碰到，但是app端被逆向後就會發生嚴重的問題
2.數據庫前面加一層校驗
這個方案請參考美團職業欠缺在知乎的帖子吧。這裏大概說一下重點，把業務直接訪問數據庫給拆開來，弄箇中間層，業務只能請求中間層要數據，而且每次請求都要帶上用戶的身份票據，中間層根據身份票據來判斷返回數據與否。
微信的全程票據和google的gmail都是類似的思想(這2個我各種查找資料沒找到)
缺點
1.和方案一雷同，其實不能解決平行越權的問題
2.實現成本同樣很高
3.和業務配合
這個方案其實別人也有講，只是聽的雲裏霧裏的沒搞明白細節，後來又諮詢類很多大佬明白了。
第一步是業務方配合，先和研發配合，要求研發在寫藉口的時候必須加上越權類的測試用例
第二步:安全定期檢查gitlab上的代碼，發現有接口沒有越權測試用例就發通知告警讓加上。這個越權類自然包括類平行和垂直以及未授權
第三步：業務測試人員測試代碼必須測試研發的測試用例。這是個要求，其實也是業務測試人員必備的，因爲他們測試業務接口肯定是都得挨個測試的。這一步也就沒法再檢測業務測試人員到底測試了沒有。
缺點
1.無法約束業務測試人員到底測試了沒有
4.滲透測試
這個地方的滲透測試包括上面提到的所有吧，不過SAST自動化工具檢測的化也是不佳，主流的解決方案還是DAST，
DAST 實現思路是用多個賬號對同一個URL進行測試，交換訂單ID等操作思路，判斷返回包是否相同，進一步判斷是否存在越權類漏洞，目前是有中通開源的越權類漏洞掃描器。這個方案有個難點也是誤報很高，URL量很大，需要做成平臺化去檢測。未授權訪問的業務比較多的時候人工檢測也是很大的工作量，其次URL去重過程中也會遇到很多問題，需要逐個去細化，有些業務的URL寫法非常的不規範會導致去重艱難，做過的都知道這一步是個體力活
IAST 交互式掃描器最近這幾年大火，主流的openRAST是典型的代表。不過看官方文檔截止目前還沒有這方面檢測的功能。但是一定是可以實現的。
人工滲透測試：有耐心的白帽子很願意挖掘這類漏洞，優惠卷各種騷姿勢便利，思路要多廣有多廣。看SRC能學到不少騷姿勢
總結
說這麼多，在甲方落地的化其實還是方案3加上方案4是最佳方案。IAST的痛點太大，業務接受agent方案有些難，目前看到一些新奇的思路實現的也都非常棒，這個方案檢測越權類也是可以的，旁路部署不影響業務
詳見：https://mp.weixin.qq.com/s/y2EWoAGByaQ1eNyKmUoP7A