明明同事用了using來確保區塊結束時會呼叫Dispose()作到自動釋放資源,但還是被源碼檢測工具fortify舉報。呼~~來解題。
2018-07-08
明明同事用了using來確保區塊結束時會呼叫Dispose()作到自動釋放資源,但還是被源碼檢測工具fortify舉報。呼~~來解題。
在.NET程式透過WebRequest來建立HTTPS或FTPS連線時,有時攻城獅可能因為無法確認憑證有效性,寫了不理會憑證是否有效的程式碼來讓程式正常運作,上線前,送到源碼檢測健康檢查時,就會被列出來*標示Critical的風險,來還技術債吧。
為了避免SQL Server與AP伺服器傳輸時的內容被攔截竊取後容易解析,我們可以採用加密的傳輸通道,一來可以增加傳輸封包安全性,二來也避免源碼檢測工具打小報告。
以前都是在DB Server手動裝憑證,然後DB匯出,AP伺服器匯入再設定連線字串啟用加密,才能啟用加密連線(大誤)。最近和同事討論,意外發現,即使沒有額外處理憑證,單只要AP連線字串加上TrustServerCertificate=true;Encrypt=true,實際連線時,SQL會自動產生憑證,重要的TDS封包就被加密了,而且專案中的組態檔還可以通過源碼檢測的盤查。
再次和Fortify神鬼交鋒(新的Rule Pack上市),Fortify SCA新檢測出Path Manipulation及XML External Entity Injection(Input Validation and Representation, Data Flow),來筆記這次的修正。