史丹利好熱

明明同事用了using來確保區塊結束時會呼叫Dispose()作到自動釋放資源，但還是被源碼檢測工具fortify舉報。呼~~來解題。

在.NET程式透過WebRequest來建立HTTPS或FTPS連線時，有時攻城獅可能因為無法確認憑證有效性，寫了不理會憑證是否有效的程式碼來讓程式正常運作，上線前，送到源碼檢測健康檢查時，就會被列出來*標示Critical的風險，來還技術債吧。

為了避免SQL Server與AP伺服器傳輸時的內容被攔截竊取後容易解析，我們可以採用加密的傳輸通道，一來可以增加傳輸封包安全性，二來也避免源碼檢測工具打小報告。

以前都是在DB Server手動裝憑證，然後DB匯出，AP伺服器匯入再設定連線字串啟用加密，才能啟用加密連線(大誤)。最近和同事討論，意外發現，即使沒有額外處理憑證，單只要AP連線字串加上TrustServerCertificate=true;Encrypt=true，實際連線時，SQL會自動產生憑證，重要的TDS封包就被加密了，而且專案中的組態檔還可以通過源碼檢測的盤查。

由於工作的關係，時常需要和源碼檢測工具神鬼交鋒一下，持續整合之路上也有源碼檢測的探險，累積幾家客戶的要求，半數是以Fortify SCA(Source Code Analyzer)作為檢測工具，也寫筆記留給同事及以後的自己參考。

再次和Fortify神鬼交鋒(新的Rule Pack上市)，Fortify SCA新檢測出Path Manipulation及XML External Entity Injection(Input Validation and Representation, Data Flow)，來筆記這次的修正。