.NET Security Application/Web Development - Overview
•Download as PPTX, PDF•
3 likes•350 views
Community sharing session for how to development secure web application.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to .NET Security Application/Web Development - Overview
Similar to .NET Security Application/Web Development - Overview (20)
More from Chen-Tien Tsai
More from Chen-Tien Tsai (20)
.NET Security Application/Web Development - Overview
- 1. .NET 安全應用程式開發 .NET Security Application Development Blackie Tsai blackie1019@gmail.com August 2018
- 2. 本日課程主題 • Part I • 網際網路安全概觀 • 常見安全漏洞與攻擊 • Part II • .NET 安全開發 – 常見問題防禦 • .NET 安全開發 – Web From and MVC 補充 • Part III • IIS 與安全網站開發部屬設定 • MSSQL 安全設定 • Part IV • 開發與檢測工具介紹 • 安全軟體開發生命週期
- 3. 預期效益 • 認識網際網路資訊安全概貌 • 了解常見弱點攻擊手法與威脅 • 了解如何安全開發 .NET 應用程式 • 了解如何在開發流程中注入資安觀念與流程 • 學會如何使用工具協助我們交付更加安全的應用程式
- 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. 回顧重點
- 6. 安全遠不止於一次性的技術實行 • OWASP Top 10 與 CWE/SANS Top 25 等弱點歸類與排行是協助我們: • 能較為明確的理解弱點的原貌 • 能夠跟他人解釋與溝通 • 設法避開這些常見問題(80/20法則) • 技術實行避開安全問題只是其中整體資安的一部分 • 商業運行所暴露的未知問題 • 社交工程的威脅 • 未來科技與趨勢潛藏的風險
- 8. Web 應用程式的基本安全性實行方式 • 一般 Web 應用程式的安全性建議 • 以最小權限執行應用程式 • 了解您的使用者 • 防範惡意使用者輸入 • 安全存取資料庫 • 建立安全的錯誤訊息 • 安全存放秘密 • 安全使用 Cookie • 防範拒絕服務的威脅
- 9. 一般 Web 應用程式的安全性建議 • 如果惡意使用者可以使用簡單的方法進入您的電腦，即使是最精心設計的 應用程式安全性也可能會失敗。請遵循這些方針： • 勤加備份，並將備份存放在安全的實體中。 • 使用 Windows NTFS 檔案系統，而不是 FAT32。NTFS 能提供較 FAT32 更完善的 安全性。如需詳細資訊，請參閱 Windows 文件。 • 使用更牢靠的密碼 • 保護 IIS 的安全，請參閱 Microsoft TechNet Security Center 網站。 • 關閉未使用的連接埠和服務。 • 執行可監視傳入和傳出流量的病毒檢查程式。 • 建立並實施禁止使用者將密碼寫在容易找到的位置的原則。 • 使用防火牆。請參 Microsoft Firewall Guidelines。 • 安裝 Microsoft 和其他廠商的最新版安全性修補檔案。例如，Microsoft TechNet Security Center 網站提供了所有 Microsoft 產品最新安全性佈告欄的清單。 • 使用 Windows 事件記錄，並經常檢查記錄檔，找出可疑的活動。
- 10. 以最小權限執行應用程式 • 當應用程式執行時，它在本機電腦上以及可能在遠端電腦上具有特定權限 的內容上執行。如需設定應用程式識別的詳細資訊，請參閱設定 ASP.NET 處理序識別。若要以最小的權限執行，請遵循下列方針： • 請勿使用系統使用者 (系統管理員) 的識別執行應用程式。 • 以最小實際權限在使用者內容中執行應用程式。 • 設定應用程式所需之所有資源的使用權限 (存取控制清單或 ACL)。使用最小使用權 限的設定。例如，如果在您的應用程式中可行的話，將檔案設為唯讀。如需 ASP.NET 應用程式之識別所需的必要最小 ACL 使用權限清單，請參閱 ASP.NET 所 需的存取控制清單 (ACL)。 • 將這些 Web 應用程式的檔案放在應用程式根目錄下的資料夾中。請勿允許使用者 指定路徑的選項，供其在應用程式中作任何檔案存取。這樣有助於避免使用者取得 對伺服器根目錄的存取。
- 11. 了解您的使用者 • 在許多應用程式中，使用者會匿名存取網站 (不需提供認證)。如果是這樣， 應用程式存取資源是在預先定義使用者的內容中執行的。根據預設，這個 內容是本機 ASPNET 使用者 (在 Windows 2000 或 Windows XP 上) 或 在 Web 伺服器電腦上的 NETWORK SERVICE 使用者 (在 Windows Server 2003 上)。若要限制對已驗證使用者的存取，請遵循以下方針： • 如果應用程式為內部網路應用程式，將其設定為使用 Windows 整合安全性。這樣 一來，使用者的登入認證就能用來存取資源。如需詳細資訊，請參閱 ASP.NET 模 擬。 • 如果必須向使用者收集認證，使用其中一項 ASP.NET 驗證策略。如需範例，請參 閱使用成員資格管理使用者。
- 12. 防範惡意使用者輸入 • 通則就是，絕對不要假設從使用者取得的輸入是安全的。惡意使用者輕易 就能從用戶端傳送具有潛在危險性的資訊到您的應用程式。若要防範惡意 的輸入資料，請遵循以下方針： • 在 ASP.NET Web 網頁中，篩選使用者輸入並檢查內容與其中可能含有指令碼。請 參閱 HOW TO：利用將 HTML 編碼套用至字串的方法，防止會在 Web 應用程式 中發生的指令碼攻擊。 • 絕對不要 echo (顯示) 未篩選的使用者輸入。在顯示未受信任的資訊前，將 HTML 編碼，使具有潛在傷害性的指令碼轉換成顯示字串。 • 請勿將未篩選的使用者輸入存放在資料庫中。 • 如果收到來自使用者的 HTML，用手動方式篩選。在篩選條件中，明確定義您可 以接受的內容。 • 請勿假設您從 HTTP 要求標頭 (在 HttpRequest 物件中) 取得的資訊是安全的 • 不要將機密資訊儲存在瀏覽器可以存取的地方，如隱藏欄位或 Cookie。例如，不 要將密碼儲存在 Cookie 中。
- 13. 安全存取資料庫 • 資料庫通常具有自己的安全性。安全 Web 應用程式的重要觀點，就是設 計應用程式以安全方式存取資料庫。請遵循這些方針： • 使用資料庫固有的安全性，限制能存取資料庫資源的使用者。實際的策略取決於您 的資料庫和應用程式： • 如果您應用程式中可行的話，使用整合式安全性，如此只有 Windows 驗證的 使用者可以存取資料庫。整合式安全性會比將明確認證傳送至資料庫更加安全。 • 如果應用程式涉及匿名存取，您可建立具有非常小使用權限的單一使用者，再 以這個使用者的身分連接以便執行查詢。 • 請勿使用含有使用者輸入的串連字串建立 SQL 陳述式，而是要建立參數型查詢， 並使用使用者輸入設定參數值。 • 如果您必須將使用者名稱和密碼存放在某處以做為資料庫登入認證使用，請將這些 資訊存放在 Web.config 檔中並以受保護的組態保護此檔案。如需詳細資訊，請參 閱使用受保護的組態加密組態資訊。
- 14. 保護敏感性資訊的安全 • 敏感性資訊是您需要保持私密的任何資訊。典型的敏感性資訊就是密碼或 加密金鑰。如果惡意使用者可以取得敏感性資訊，則秘密所保護的資料也 會隨之洩漏。請遵循這些方針： • 如果應用程式在瀏覽器和伺服器間傳送機密資訊，可考慮使用 Secure Sockets Layer (SSL)。 • 使用受保護的組態保護組態檔中的敏感性資訊，例如 Web.config 或 Machine.config 檔案。請參閱使用受保護的組態加密組態資訊。 • 如果必須儲存敏感性資訊，請勿將它保存在網頁中，即使是您認為他人無法看到的 表單中 (例如伺服器程式碼中)。 • 使用 System.Security.Cryptography 命名空間中提供的增強式加密演算法。
- 15. 安全使用 Cookie • Cookie 是用來保存可用之使用者特定資訊的好方法。然而，因為 Cookie 傳送到瀏覽器的電腦，容易受到欺騙或其他惡意用途之害。請遵循這些方 針： • 請勿將任何重要資訊儲存在 Cookie。例如，不要將使用者密碼儲存在 Cookie 中， 即使只是暫時儲存而已。就常理而言，並不建議將任何資料放在 Cookie，如果發 生假冒身分，就可能危害您的應用程式，所以，應該是在 Cookie 中保留對資訊所 在之伺服器上的參考。 • 將 Cookie 的過期日設定為可設定的最短實際時間。盡可能避免永久保留 Cookie。 • 考慮將 Cookie 中的資訊加密。 • 考慮將 Cookie 上的 Secure 和 HttpOnly 屬性設為 true。
- 16. 防範拒絕服務的威脅 • 惡意使用者可用來危害應用程式安全的一種間接方式，就是使應用程式無 法使用。惡意使用者可以使應用程式太忙碌而無法為其他使用者提供服務， 或是直接損毀應用程式。請遵循這些方針： • 使用錯誤處理 (例如，try-catch)。在錯誤發生時，納入您釋放資源所在的 finally 區塊。 • 將 IIS 設定為使用處理序節流，可避免應用程式耗盡大量的 CPU 時間量。 • 在使用和儲存前，測試使用者輸入的大小限制。 • 將大小防護措施放在資料庫查詢中。例如，當您在 ASP.NET Web 網頁中顯示查詢 結果前，請確定沒有不合理的記錄數目。 • 可以限制動態IP的數量達到保護的效果 • 設定 maxRequestLength 可有效阻擋攻擊 • 如果檔案上載是您程式的一部分時，將大小限制放在檔案上傳上。
- 17. 常見問題總結
- 18. 總結:注入攻擊 • 將最小權限原則應用於數據庫帳戶 • 它真正需要做什麼？ • 永遠不將參數視為受信任的數據 • 不要只是將參數直接連接查詢和放入數據庫內 • Stored procedures 通過參數化提供保護 • 請記住，您仍然可以在其中構建注入風險 • 始終針對白名單驗證不受信任的數據 • 透過類型轉換，正則表達式和已知的良好值 • 使用ORM及其原生參數化功能 • 也是一個能節省時間的方式 • 自動化工具很容易進行 Injection • Injection 後果可能很嚴重且也很容易被利用
- 19. 總結:跨網站指令碼 • 輸出編碼是保護XSS的基石 • 謹記 Web Form 控制項需要使用不同的編碼方式 • 有許多控制項的編碼需要自己處理 • ASP.NET MVC 預設就有處理部分 XSS 攻擊 • 始終根據允許值的白名單驗證所有不受信任的數據 • Request Validation 是一個很好的安全網 • DB可能存有持久性XSS 內容，不能忽略任何資料輸出 • 現代瀏覽車可以阻擋但不能確保一定能擋 • 攻擊者傾向使用混淆的URL 作為攻擊
- 20. 總結: 認證與 Session 破壞 • 將Session ID 保留在URL之外（使用更安全的cookie默認值） • 不要指望URL中的任何內容都是安全的 • 使用 ASP.NET membership provider • 他可以將授權更將全面的處理 • 客製化你的 Session 與逾時 • 如果可以，請停用 sliding forms authentication 到期驗證 • 破壞身份驗證和會話管理是一個廣泛的風險
- 21. 總結: 不安全的物件參考 • 不安全的物件直接引用最終都回歸到訪問與控制的處理 • 最終還是需要好好處理授權 • 間接引用可用於隱藏內部鍵值 • 但它永遠不能取代訪問控制 • 代理鍵(Surrogate Key)可以幫助混淆ID
- 22. 總結: 跨網站偽造請求 • CSRF是透過重新創建合法請求並包含具有惡意意圖的請求 • 受害者的身份驗證狀態被濫用，瀏覽器被欺騙發出請求 • 唯一真正的能緩解的作法為 Anti-Forgery Token • 在MVC中非常容易實作，在Web表單中卻會使架構變混亂 • 此難以實施其他防禦措施由於請求是由受害者的瀏覽器發出的，所以看起 來合法。且與XSS一樣，瀏覽器能提供部分防禦 • 與對待XSS態度相同，不要依賴瀏覽器的預設安全處理！
- 23. 總結 : 不適當的安全配置 • 簡單的配置更改也可能會帶來嚴重的安全問題 • 獲取自定義錯誤和跟踪控制 • 保持當前框架更新運行管理的策略 • NuGet 使套件管理變得容易 • 保護 web.config 中那些高敏感的資訊 • 透過自動產生的值設置於 web.config 所需的安全性欄位內 • 正確配置並使用 config transforms 減少部署期間時的人為疏失 • 啟用伺服器上的 retail mode 最為一道安全網
- 24. 總結: 不安全的加密存儲方式 • 加密存儲是系統中的最後一道防線 • 這就是在利用SQL注入等風險後拯救我們的原因 • Password hashing 是試圖透過減緩攻擊，增加密碼破解的時間和成本 • 不是100％安全，但能提升難度 • 通過 PBKDF2 和 bcrypt 等方法創建更高的工作負載是最好的防禦措施 • 加鹽(Salt) 很重要，但沒有許多人想像的那麼有用 • 加密問題仍然需要金鑰管理 • DPAPI 使解決這個問題變得容易（但依舊會延伸其他問題） • 字符旋轉(Character rotation )和編碼(encoding)不是加密的一部分！ • 記住 Kerckhoffs 定律 • 即使密碼系統的任何細節已為人悉知，只要密匙（key，又稱金鑰或密鑰）未 洩漏，它也應是安全的
- 25. 新一代系統架構的資安考量 • 強化縱深防禦 • 可控的資安管理環境 • 資安可視化架構 • 建立行為和異常檢測模型 • 自動化本地聯防 • 自動化聯防機制 • 限定執行的應用程式 • 資安視覺化儀表板 • 系統從需求開發時就具備資安觀念與功能 • 定期執行滲透測試
- 26. 強化縱深防禦 - 空間換取時間
- 28. 資安可視化架構
- 29. 建立行為和異常檢測模型
- 30. 資安視覺化儀表板
- 32. 定期執行滲透測試 •利用軟體定期檢測網路、系統是否有弱點(漏洞)存 在? •僅是利用軟體檢測還是會有失誤的時候︕ •滲透測試可以 • 有效地確認現有資訊作業環境的弱點與風險 • 直接改善測試所得知的弱點 • 規劃更安全的資訊系統架構，以抵禦更多的入侵
- 33. 資安弱點管理 •源碼檢測 • 透過對原始碼的檢查，挖掘已知或未知的網頁問題 • 源碼檢測著重在程式碼安全 •弱點掃描 • 弱點掃描的目標是系統錯誤 • 著眼在環境與系統上的錯誤 •滲透測試 • 以已知弱點或未知為驗證基礎 • 為驗證所知弱點的可行性，以駭客或惡意使用者的角度對目標進行驗證，分析受 測系統的風險層級 • 檢視整個系統的運作邏輯，來思索可能侵入的點
- 34. THANK YOU!
Editor's Notes
- 在開始之前先跟大家確認一下整體開發的環境與工具
- Part I (75 mins) 網際網路安全概觀 常見安全漏洞與攻擊 Part II (165 mins) .NET 安全開發 – 常見問題防禦 .NET 安全開發 – Web From and MVC 補充(60 min) Part III(60 mins) IIS 與安全網站開發部屬設定 MSSQL 安全設定 Part IV(30 mins) 開發與檢測工具介紹 安全軟體開發生命週期 回顧重點(30 mins)
- Apply the principle of least privilege to the database account What does it really need to be able to do? Always parameterise untrusted data Never just concatenate query and data Stored procedures also offer protection via parameterisation Just remember you can still build an injection risk into them Always validate untrusted data against a whitelist Remember type conversion, regexes and known good values Use ORMs and their native ability to parameterise They’re also a great time saver Remember the ease of exploitation by automated tools Injection consequences can be severe and be easily exploited
- Keep session IDs out of the URL (use the more secure cookie default) Don’t expect anything in the URL to be secure Make use of the ASP.NET membership provider It abstracts away all the hard work of managing authentication Customise your session and forms timeout Find the right balance between convenient and secure If possible, disable sliding forms authentication expiration Consider the potential adverse impact on usability Remember that broken authentication and session management is a broad risk Don’t forget the other areas of the Top 10 that can jeopardise this one
- Insecure direct object references are ultimately about access control It always boils back down to insufficient authorisation Indirect references can be used to conceal internal keys But they’re never a substitute for access controls Surrogate keys can assist in obfuscating IDs Bit it’s still not an access control and has other downsides
- CSRF is made possible when a legitimate request is reconstructed into one with malicious intent The authenticated state of the victim is abused and the browser tricked into issuing the request The only real mitigation is anti-forgery tokens Easy in MVC, messier in web forms Because the request is issued by the victim’s browser, it appears legitimate thus difficult to implement other defences around Like with XSS, browsers offer some defenses Also like XSS, don’t rely on them!
- Simple configuration changes can introduce serious security risks Get custom errors and tracing under control Make sure you have a strategy for keep frameworks current NuGet makes package management easy Protect sensitive data in the web.config Automate the security configuration of the web.config settings Use config transforms to correctly configure it during deployment Consider retail mode on the server as a safety net
- Cryptographic storage is the last line of defence in a system It’s what saves us after a risk such as SQL injection is exploited Password hashing is all about trying to slow the process down in order to increase the time and cost of cracking It’s not about being 100% secure, it’s about increasing difficulty Creating higher workloads through approaches such as PBKDF2 and bcrypt is the best defence Salt is still important, but not as useful as many people think The problem with encryption remains key management DPAPI makes it easy to solve this problem (but introduces other problems) Character rotation and encoding aren’t cryptographic! Remember Kerckhoffs's principle; are you happy for the enemy to view your implementation?
- 源碼檢測 是最基本的網頁程式稽核方式。透過對原始碼的檢查，挖掘已知或未知的網頁問題。常見的作法是利用人力檢測，如果是寫程式能力有自信的開發團體，是由公司自有的資深工程師負責，對品質要求較為嚴格的單位，則會雇用資安專家協助進行。但近年來各種工具已將檢測準確率提升到九成以上，故也有許多公司採用自動工具進行檢測。 弱點掃描 目標是系統錯誤，採用源碼檢測的同時，驗收與稽核單位也會一併執行弱點掃描與滲透測試。源碼檢測著重在程式碼安全，弱點掃描則是著眼在環境與系統上的錯誤。 舉例而言，你的團隊設計出「完全」安全的購物車程式，卻因為系統管理者誤將密碼設成空白，或因為安裝在舊版的網站伺服器上，而遭入侵竄改，就像「百萬金門三夾牆」的故事一樣，豈不倒霉？除了網頁程式碼本身的問題之外，使用者設定疏漏與安裝環境的強固性也是最常被入侵的環節，行之有年的弱點掃描就是最方便的檢查工具。 弱點掃描工具是以使用者角度來審視整個專案計畫，不只是程式本身，也包含整個執行環境。傳統弱點掃描工具只針對作業系統與網站伺服器本身的問題，近年來網頁安全意識抬頭，專業的網頁弱點掃描工具也逐漸興起，IBM及HP等大廠都將網頁弱點掃描工具納入軟體測試套件中。除了檢查已知的網站伺服器漏洞外，網頁弱點掃描工具主要作用是模擬惡意使用者的瀏覽行為，爬蒐受測程式的所有連結後，對所有可輸入的連結送出惡意數值，觀察記錄回應狀態。 網頁弱點掃描工具也會猜測所有隱藏目錄、管理後臺、程式備份檔或資料庫檔案位置。對於可登入的頁面，則進行密碼猜測的工作，以便檢測管理者的安全警覺性。弱點掃描由上層角度來找出整套系統的安全性，測試的出發點較為接近真實世界，是十分確實的黑箱測試工具。 滲透測試 傳統對滲透測試的觀念為驗證所知弱點的可行性，以駭客或惡意使用者的角度對目標進行驗證，分析受測系統的風險層級。許多滲透測試自動工具亦圍繞此一傳統觀念寫成，反而局限了滲透測試的目的，讓終端使用者誤以為滲透測試只針對軟體廠商或系統開發商，而非找出整體問題。 事實上，滲透測試所看的層面更廣。滲透測試所針對的目標是受測系統與所有大環境的運作，像是程式中的邏輯問題（而非程式問題）、系統運作流程瑕疵、社交工程漏洞等，都包含在滲透測試範疇內。
- http://study4.tw/Activity/Details/19 Study4TW-July-2018 活動時間： 7/28/2018 1:30:00 PM 活動地點： 台中市西屯區文華路100號資訊電機館2F(資電234) 15:10 - 16:10 靜態原始碼掃描常見問題處理 議程簡介 在一些網頁專標案或是發包案時，經常會在專案規格書中提到需要符合資安規定才能進行驗收，通常資安規定包含了原始碼掃描或是主機弱點，如果沒有通過時則沒辦法驗收請款，本課程主要以講者本身的經驗，在使用靜態原始碼掃描軟體HP Fortify掃描一些網頁專案的結果，說明當掃描出原始碼有問題時改善的建議，如果事先了解相關問題，在開發時就可以先行避開這些問題