Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

.NET Security Application/Web Development - Overview

114 views

Published on

Community sharing session for how to development secure web application.

Published in: Software
  • Be the first to comment

.NET Security Application/Web Development - Overview

  1. 1. .NET 安全應用程式開發 .NET Security Application Development Blackie Tsai blackie1019@gmail.com August 2018
  2. 2. 本日課程主題 • Part I • 網際網路安全概觀 • 常見安全漏洞與攻擊 • Part II • .NET 安全開發 – 常見問題防禦 • .NET 安全開發 – Web From and MVC 補充 • Part III • IIS 與安全網站開發部屬設定 • MSSQL 安全設定 • Part IV • 開發與檢測工具介紹 • 安全軟體開發生命週期
  3. 3. 預期效益 • 認識網際網路資訊安全概貌 • 了解常見弱點攻擊手法與威脅 • 了解如何安全開發 .NET 應用程式 • 了解如何在開發流程中注入資安觀念與流程 • 學會如何使用工具協助我們交付更加安全的應用程式
  4. 4. 講者簡歷 • 現於外商擔任解決方案架構師 • 曾任職: • Hyweb • Microsoft • Microsoft MVP : 2017 – 2019 第9 屆 IT 邦幫忙鐵人賽 - DevOps 組冠軍 • Study 4 成員暨講師 • 大內攻城 創始成員 • Microsoft MSP 導師暨內訓講師 • 2017 .NET Conf 講師 • GCP專門家 技術專欄作家 • 部落格 - https://blackie1019.github.io Blackie Tsai
  5. 5. 回顧重點
  6. 6. 安全遠不止於一次性的技術實行 • OWASP Top 10 與 CWE/SANS Top 25 等弱點歸類與排行是協助我們: • 能較為明確的理解弱點的原貌 • 能夠跟他人解釋與溝通 • 設法避開這些常見問題(80/20法則) • 技術實行避開安全問題只是其中整體資安的一部分 • 商業運行所暴露的未知問題 • 社交工程的威脅 • 未來科技與趨勢潛藏的風險
  7. 7. 洋蔥式防禦 第一層防禦 第二層防禦 第三層防禦 資產
  8. 8. Web 應用程式的基本安全性實行方式 • 一般 Web 應用程式的安全性建議 • 以最小權限執行應用程式 • 了解您的使用者 • 防範惡意使用者輸入 • 安全存取資料庫 • 建立安全的錯誤訊息 • 安全存放秘密 • 安全使用 Cookie • 防範拒絕服務的威脅
  9. 9. 一般 Web 應用程式的安全性建議 • 如果惡意使用者可以使用簡單的方法進入您的電腦,即使是最精心設計的 應用程式安全性也可能會失敗。請遵循這些方針: • 勤加備份,並將備份存放在安全的實體中。 • 使用 Windows NTFS 檔案系統,而不是 FAT32。NTFS 能提供較 FAT32 更完善的 安全性。如需詳細資訊,請參閱 Windows 文件。 • 使用更牢靠的密碼 • 保護 IIS 的安全,請參閱 Microsoft TechNet Security Center 網站。 • 關閉未使用的連接埠和服務。 • 執行可監視傳入和傳出流量的病毒檢查程式。 • 建立並實施禁止使用者將密碼寫在容易找到的位置的原則。 • 使用防火牆。請參 Microsoft Firewall Guidelines。 • 安裝 Microsoft 和其他廠商的最新版安全性修補檔案。例如,Microsoft TechNet Security Center 網站提供了所有 Microsoft 產品最新安全性佈告欄的清單。 • 使用 Windows 事件記錄,並經常檢查記錄檔,找出可疑的活動。
  10. 10. 以最小權限執行應用程式 • 當應用程式執行時,它在本機電腦上以及可能在遠端電腦上具有特定權限 的內容上執行。如需設定應用程式識別的詳細資訊,請參閱設定 ASP.NET 處理序識別。若要以最小的權限執行,請遵循下列方針: • 請勿使用系統使用者 (系統管理員) 的識別執行應用程式。 • 以最小實際權限在使用者內容中執行應用程式。 • 設定應用程式所需之所有資源的使用權限 (存取控制清單或 ACL)。使用最小使用權 限的設定。例如,如果在您的應用程式中可行的話,將檔案設為唯讀。如需 ASP.NET 應用程式之識別所需的必要最小 ACL 使用權限清單,請參閱 ASP.NET 所 需的存取控制清單 (ACL)。 • 將這些 Web 應用程式的檔案放在應用程式根目錄下的資料夾中。請勿允許使用者 指定路徑的選項,供其在應用程式中作任何檔案存取。這樣有助於避免使用者取得 對伺服器根目錄的存取。
  11. 11. 了解您的使用者 • 在許多應用程式中,使用者會匿名存取網站 (不需提供認證)。如果是這樣, 應用程式存取資源是在預先定義使用者的內容中執行的。根據預設,這個 內容是本機 ASPNET 使用者 (在 Windows 2000 或 Windows XP 上) 或 在 Web 伺服器電腦上的 NETWORK SERVICE 使用者 (在 Windows Server 2003 上)。若要限制對已驗證使用者的存取,請遵循以下方針: • 如果應用程式為內部網路應用程式,將其設定為使用 Windows 整合安全性。這樣 一來,使用者的登入認證就能用來存取資源。如需詳細資訊,請參閱 ASP.NET 模 擬。 • 如果必須向使用者收集認證,使用其中一項 ASP.NET 驗證策略。如需範例,請參 閱使用成員資格管理使用者。
  12. 12. 防範惡意使用者輸入 • 通則就是,絕對不要假設從使用者取得的輸入是安全的。惡意使用者輕易 就能從用戶端傳送具有潛在危險性的資訊到您的應用程式。若要防範惡意 的輸入資料,請遵循以下方針: • 在 ASP.NET Web 網頁中,篩選使用者輸入並檢查內容與其中可能含有指令碼。請 參閱 HOW TO:利用將 HTML 編碼套用至字串的方法,防止會在 Web 應用程式 中發生的指令碼攻擊。 • 絕對不要 echo (顯示) 未篩選的使用者輸入。在顯示未受信任的資訊前,將 HTML 編碼,使具有潛在傷害性的指令碼轉換成顯示字串。 • 請勿將未篩選的使用者輸入存放在資料庫中。 • 如果收到來自使用者的 HTML,用手動方式篩選。在篩選條件中,明確定義您可 以接受的內容。 • 請勿假設您從 HTTP 要求標頭 (在 HttpRequest 物件中) 取得的資訊是安全的 • 不要將機密資訊儲存在瀏覽器可以存取的地方,如隱藏欄位或 Cookie。例如,不 要將密碼儲存在 Cookie 中。
  13. 13. 安全存取資料庫 • 資料庫通常具有自己的安全性。安全 Web 應用程式的重要觀點,就是設 計應用程式以安全方式存取資料庫。請遵循這些方針: • 使用資料庫固有的安全性,限制能存取資料庫資源的使用者。實際的策略取決於您 的資料庫和應用程式: • 如果您應用程式中可行的話,使用整合式安全性,如此只有 Windows 驗證的 使用者可以存取資料庫。整合式安全性會比將明確認證傳送至資料庫更加安全。 • 如果應用程式涉及匿名存取,您可建立具有非常小使用權限的單一使用者,再 以這個使用者的身分連接以便執行查詢。 • 請勿使用含有使用者輸入的串連字串建立 SQL 陳述式,而是要建立參數型查詢, 並使用使用者輸入設定參數值。 • 如果您必須將使用者名稱和密碼存放在某處以做為資料庫登入認證使用,請將這些 資訊存放在 Web.config 檔中並以受保護的組態保護此檔案。如需詳細資訊,請參 閱使用受保護的組態加密組態資訊。
  14. 14. 保護敏感性資訊的安全 • 敏感性資訊是您需要保持私密的任何資訊。典型的敏感性資訊就是密碼或 加密金鑰。如果惡意使用者可以取得敏感性資訊,則秘密所保護的資料也 會隨之洩漏。請遵循這些方針: • 如果應用程式在瀏覽器和伺服器間傳送機密資訊,可考慮使用 Secure Sockets Layer (SSL)。 • 使用受保護的組態保護組態檔中的敏感性資訊,例如 Web.config 或 Machine.config 檔案。請參閱使用受保護的組態加密組態資訊。 • 如果必須儲存敏感性資訊,請勿將它保存在網頁中,即使是您認為他人無法看到的 表單中 (例如伺服器程式碼中)。 • 使用 System.Security.Cryptography 命名空間中提供的增強式加密演算法。
  15. 15. 安全使用 Cookie • Cookie 是用來保存可用之使用者特定資訊的好方法。然而,因為 Cookie 傳送到瀏覽器的電腦,容易受到欺騙或其他惡意用途之害。請遵循這些方 針: • 請勿將任何重要資訊儲存在 Cookie。例如,不要將使用者密碼儲存在 Cookie 中, 即使只是暫時儲存而已。就常理而言,並不建議將任何資料放在 Cookie,如果發 生假冒身分,就可能危害您的應用程式,所以,應該是在 Cookie 中保留對資訊所 在之伺服器上的參考。 • 將 Cookie 的過期日設定為可設定的最短實際時間。盡可能避免永久保留 Cookie。 • 考慮將 Cookie 中的資訊加密。 • 考慮將 Cookie 上的 Secure 和 HttpOnly 屬性設為 true。
  16. 16. 防範拒絕服務的威脅 • 惡意使用者可用來危害應用程式安全的一種間接方式,就是使應用程式無 法使用。惡意使用者可以使應用程式太忙碌而無法為其他使用者提供服務, 或是直接損毀應用程式。請遵循這些方針: • 使用錯誤處理 (例如,try-catch)。在錯誤發生時,納入您釋放資源所在的 finally 區塊。 • 將 IIS 設定為使用處理序節流,可避免應用程式耗盡大量的 CPU 時間量。 • 在使用和儲存前,測試使用者輸入的大小限制。 • 將大小防護措施放在資料庫查詢中。例如,當您在 ASP.NET Web 網頁中顯示查詢 結果前,請確定沒有不合理的記錄數目。 • 可以限制動態IP的數量達到保護的效果 • 設定 maxRequestLength 可有效阻擋攻擊 • 如果檔案上載是您程式的一部分時,將大小限制放在檔案上傳上。
  17. 17. 常見問題總結
  18. 18. 總結:注入攻擊 • 將最小權限原則應用於數據庫帳戶 • 它真正需要做什麼? • 永遠不將參數視為受信任的數據 • 不要只是將參數直接連接查詢和放入數據庫內 • Stored procedures 通過參數化提供保護 • 請記住,您仍然可以在其中構建注入風險 • 始終針對白名單驗證不受信任的數據 • 透過類型轉換,正則表達式和已知的良好值 • 使用ORM及其原生參數化功能 • 也是一個能節省時間的方式 • 自動化工具很容易進行 Injection • Injection 後果可能很嚴重且也很容易被利用
  19. 19. 總結:跨網站指令碼 • 輸出編碼是保護XSS的基石 • 謹記 Web Form 控制項需要使用不同的編碼方式 • 有許多控制項的編碼需要自己處理 • ASP.NET MVC 預設就有處理部分 XSS 攻擊 • 始終根據允許值的白名單驗證所有不受信任的數據 • Request Validation 是一個很好的安全網 • DB可能存有持久性XSS 內容,不能忽略任何資料輸出 • 現代瀏覽車可以阻擋但不能確保一定能擋 • 攻擊者傾向使用混淆的URL 作為攻擊
  20. 20. 總結: 認證與 Session 破壞 • 將Session ID 保留在URL之外(使用更安全的cookie默認值) • 不要指望URL中的任何內容都是安全的 • 使用 ASP.NET membership provider • 他可以將授權更將全面的處理 • 客製化你的 Session 與逾時 • 如果可以,請停用 sliding forms authentication 到期驗證 • 破壞身份驗證和會話管理是一個廣泛的風險
  21. 21. 總結: 不安全的物件參考 • 不安全的物件直接引用最終都回歸到訪問與控制的處理 • 最終還是需要好好處理授權 • 間接引用可用於隱藏內部鍵值 • 但它永遠不能取代訪問控制 • 代理鍵(Surrogate Key)可以幫助混淆ID
  22. 22. 總結: 跨網站偽造請求 • CSRF是透過重新創建合法請求並包含具有惡意意圖的請求 • 受害者的身份驗證狀態被濫用,瀏覽器被欺騙發出請求 • 唯一真正的能緩解的作法為 Anti-Forgery Token • 在MVC中非常容易實作,在Web表單中卻會使架構變混亂 • 此難以實施其他防禦措施由於請求是由受害者的瀏覽器發出的,所以看起 來合法。且與XSS一樣,瀏覽器能提供部分防禦 • 與對待XSS態度相同,不要依賴瀏覽器的預設安全處理!
  23. 23. 總結 : 不適當的安全配置 • 簡單的配置更改也可能會帶來嚴重的安全問題 • 獲取自定義錯誤和跟踪控制 • 保持當前框架更新運行管理的策略 • NuGet 使套件管理變得容易 • 保護 web.config 中那些高敏感的資訊 • 透過自動產生的值設置於 web.config 所需的安全性欄位內 • 正確配置並使用 config transforms 減少部署期間時的人為疏失 • 啟用伺服器上的 retail mode 最為一道安全網
  24. 24. 總結: 不安全的加密存儲方式 • 加密存儲是系統中的最後一道防線 • 這就是在利用SQL注入等風險後拯救我們的原因 • Password hashing 是試圖透過減緩攻擊,增加密碼破解的時間和成本 • 不是100%安全,但能提升難度 • 通過 PBKDF2 和 bcrypt 等方法創建更高的工作負載是最好的防禦措施 • 加鹽(Salt) 很重要,但沒有許多人想像的那麼有用 • 加密問題仍然需要金鑰管理 • DPAPI 使解決這個問題變得容易(但依舊會延伸其他問題) • 字符旋轉(Character rotation )和編碼(encoding)不是加密的一部分! • 記住 Kerckhoffs 定律 • 即使密碼系統的任何細節已為人悉知,只要密匙(key,又稱金鑰或密鑰)未 洩漏,它也應是安全的
  25. 25. 新一代系統架構的資安考量 • 強化縱深防禦 • 可控的資安管理環境 • 資安可視化架構 • 建立行為和異常檢測模型 • 自動化本地聯防 • 自動化聯防機制 • 限定執行的應用程式 • 資安視覺化儀表板 • 系統從需求開發時就具備資安觀念與功能 • 定期執行滲透測試
  26. 26. 強化縱深防禦 - 空間換取時間
  27. 27. 可控的資安管理環境 •重兵部署 但仍然會遭木馬、勒索軟體感染︖ •封閉式環境但還是有木馬、勒索軟體感染︖ •有相關的資安作業規範但執行上仍有落差︕
  28. 28. 資安可視化架構
  29. 29. 建立行為和異常檢測模型
  30. 30. 資安視覺化儀表板
  31. 31. 系統從需求開發時就具備資安觀念與功能 •開發前,須將資安需求納入非功能需求考量 •開發時,確認撰寫的程式碼無已知弱點與漏洞 •新功能部屬前,進行源碼檢測 •上線前,進行弱點掃描
  32. 32. 定期執行滲透測試 •利用軟體定期檢測網路、系統是否有弱點(漏洞)存 在? •僅是利用軟體檢測還是會有失誤的時候︕ •滲透測試可以 • 有效地確認現有資訊作業環境的弱點與風險 • 直接改善測試所得知的弱點 • 規劃更安全的資訊系統架構,以抵禦更多的入侵
  33. 33. 資安弱點管理 •源碼檢測 • 透過對原始碼的檢查,挖掘已知或未知的網頁問題 • 源碼檢測著重在程式碼安全 •弱點掃描 • 弱點掃描的目標是系統錯誤 • 著眼在環境與系統上的錯誤 •滲透測試 • 以已知弱點或未知為驗證基礎 • 為驗證所知弱點的可行性,以駭客或惡意使用者的角度對目標進行驗證,分析受 測系統的風險層級 • 檢視整個系統的運作邏輯,來思索可能侵入的點
  34. 34. THANK YOU!

×