第25個冬天

  接續前幾篇系列 經得起原始碼資安弱點掃描的程式設計習慣培養(一)_OWASP Top 10(十大網站安全風險)_學習寫更安全程式碼的網站推薦 經得起原始碼資安弱點掃描的程式設計習慣培養(二)_8.Insecure Deserialization ：不安全的反序列化漏洞ASP.NET處理方式 經得起原始碼資安弱點掃描的程式設計習慣培養(三)_7.Cross Site Scripting(XSS)_Stored XSS_Reflected XSS All Clients 經得起原始碼資安弱點掃描的程式設計習慣培養(四)_1.Injection注入攻擊_SQL Injection)_order by 語句正確參數化套入 經得起原始碼資安弱點掃描的程式設計習慣培養(四)_2.Injection注入攻擊_SQL Injection_In語句正確參數化套入 經得起原始碼資安弱點掃描的程式設計習慣培養(五)_Missing HSTS Header 經得起原始碼資安弱點掃描的程式設計習慣培養(六)_Path Traversal 經得起原始碼資安弱點掃描的程式設計習慣培養(七)_Code Injection 經得起原始碼資安弱點掃描的程式設計習慣培養(八)_Client DOM XSS 經得起原始碼資安弱點掃描的程式設計習慣培養(九)_Use of Cryptographically Weak PRNG(Pseudo-Random Number Generator) 經得起原始碼資安弱點掃描的程式設計習慣培養(十)_Heap Inspection 經得起原始碼資安弱點掃描的程式設計習慣培養(十一)_HttpOnlyCookies In Config 經得起原始碼資安弱點掃描的程式設計習慣培養(十二)_Data Filter Injection 可能發生的問題 將資料存於純文字會讓擁有瀏覽伺服器權限的使用者獲得機密資料。 原因 資料庫的欄位以明文形式儲存，代表如果能通到SQL server 就能輕鬆讀取資料。 將資料存入欄位時加密，既可以保密也不會有風險 。 建議 欄位加密是在SQL server 2017 以及 Azure SQL DB才問世的，如果 在使用這兩個伺服器的話，建議開起Column Encryption 來 確保在SQL server的資料是安全的。

  接續前幾篇系列 經得起原始碼資安弱點掃描的程式設計習慣培養(一)_OWASP Top 10(十大網站安全風險)_學習寫更安全程式碼的網站推薦 經得起原始碼資安弱點掃描的程式設計習慣培養(二)_8.Insecure Deserialization ：不安全的反序列化漏洞ASP.NET處理方式 經得起原始碼資安弱點掃描的程式設計習慣培養(三)_7.Cross Site Scripting(XSS)_Stored XSS_Reflected XSS All Clients 經得起原始碼資安弱點掃描的程式設計習慣培養(四)_1.Injection注入攻擊_SQL Injection)_order by 語句正確參數化套入 經得起原始碼資安弱點掃描的程式設計習慣培養(四)_2.Injection注入攻擊_SQL Injection_In語句正確參數化套入 經得起原始碼資安弱點掃描的程式設計習慣培養(五)_Missing HSTS Header 經得起原始碼資安弱點掃描的程式設計習慣培養(六)_Path Traversal 經得起原始碼資安弱點掃描的程式設計習慣培養(七)_Code Injection 經得起原始碼資安弱點掃描的程式設計習慣培養(八)_Client DOM XSS 經得起原始碼資安弱點掃描的程式設計習慣培養(九)_Use of Cryptographically Weak PRNG(Pseudo-Random Number Generator) 經得起原始碼資安弱點掃描的程式設計習慣培養(十)_Heap Inspection 經得起原始碼資安弱點掃描的程式設計習慣培養(十一)_HttpOnlyCookies In Config Data Filter Injection風險 可能發生問題 攻擊者可能直接存取所有系統的資料。 使用簡單的工具和文字編輯時，攻擊者可以竊取儲存在伺服器中緩存區 (如個人的詳細訊息或信用卡)的任何敏感資訊，並可能更改或刪除隨後被用於其他使用者或依賴安全性決策現有資料。程式臨時的儲存並查詢資料於緩存區中。該應用程序通過簡單的連接字符串包括使用者的輸入建立查詢。由於使用者的輸入包含既沒有檢查資料類型有效性，隨後也未經消毒的命令。 通常也時常發生在 DataTable的Select Filter沒有經過處理 checkmarxC#提...

  https://zh-yue.wikipedia.org/wiki/%E6%9B%B2%E5%A5%87   接續前幾篇系列 經得起原始碼資安弱點掃描的程式設計習慣培養(一)_OWASP Top 10(十大網站安全風險)_學習寫更安全程式碼的網站推薦 經得起原始碼資安弱點掃描的程式設計習慣培養(二)_8.Insecure Deserialization ：不安全的反序列化漏洞ASP.NET處理方式 經得起原始碼資安弱點掃描的程式設計習慣培養(三)_7.Cross Site Scripting(XSS)_Stored XSS_Reflected XSS All Clients 經得起原始碼資安弱點掃描的程式設計習慣培養(四)_1.Injection注入攻擊_SQL Injection)_order by 語句正確參數化套入 經得起原始碼資安弱點掃描的程式設計習慣培養(四)_2.Injection注入攻擊_SQL Injection_In語句正確參數化套入 經得起原始碼資安弱點掃描的程式設計習慣培養(五)_Missing HSTS Header 經得起原始碼資安弱點掃描的程式設計習慣培養(六)_Path Traversal 經得起原始碼資安弱點掃描的程式設計習慣培養(七)_Code Injection 經得起原始碼資安弱點掃描的程式設計習慣培養(八)_Client DOM XSS 經得起原始碼資安弱點掃描的程式設計習慣培養(九)_Use of Cryptographically Weak PRNG(Pseudo-Random Number Generator) 經得起原始碼資安弱點掃描的程式設計習慣培養(十)_Heap Inspection 在網頁風險中掃描當遇到位於web.config中設定安全性不足問題 比如沒有定義 "httpOnly" 標記來保護 cookie中的敏感資訊，可能會遭 客戶端腳本(client-side scripts)存取session cookie。 至web.config 修改階層如下 <configuration> <system.web> <httpCookies httpOnlyCookies="true" requireSSL=...

    接續前幾篇系列 經得起原始碼資安弱點掃描的程式設計習慣培養(一)_OWASP Top 10(十大網站安全風險)_學習寫更安全程式碼的網站推薦 經得起原始碼資安弱點掃描的程式設計習慣培養(二)_8.Insecure Deserialization ：不安全的反序列化漏洞ASP.NET處理方式 經得起原始碼資安弱點掃描的程式設計習慣培養(三)_7.Cross Site Scripting(XSS)_Stored XSS_Reflected XSS All Clients 經得起原始碼資安弱點掃描的程式設計習慣培養(四)_1.Injection注入攻擊_SQL Injection)_order by 語句正確參數化套入 經得起原始碼資安弱點掃描的程式設計習慣培養(四)_2.Injection注入攻擊_SQL Injection_In語句正確參數化套入 經得起原始碼資安弱點掃描的程式設計習慣培養(五)_Missing HSTS Header 經得起原始碼資安弱點掃描的程式設計習慣培養(六)_Path Traversal 經得起原始碼資安弱點掃描的程式設計習慣培養(七)_Code Injection 經得起原始碼資安弱點掃描的程式設計習慣培養(八)_Client DOM XSS 經得起原始碼資安弱點掃描的程式設計習慣培養(九)_Use of Cryptographically Weak PRNG(Pseudo-Random Number Generator) 風險: 應用程式在未加密的memory中存儲的所有變數都可能被主機特權User(privileged access)未經授權的檢索。 例如，特權攻擊者可以對正在執行的process掛上debugger，也可能從swapfile 或crash dump file中檢索process's memory。一旦攻擊者 在Memory中找到User的密碼，就可以輕鬆的假冒User進入系統。 如何避免: 字串變數是不變的(immutable) 換言之，一旦分配了字串變數，就無法更改或刪除其值。 因此，這些字串可能會無限期的留存在memory中，而且 可能分散在多個位置中，直到垃圾收集器(garbage collector)將其刪除。 敏感資料，例如密碼，將作為明文在memory中暴露，無法控制其生命週期。 ...

  接續前幾篇系列 經得起原始碼資安弱點掃描的程式設計習慣培養(一)_OWASP Top 10(十大網站安全風險)_學習寫更安全程式碼的網站推薦 經得起原始碼資安弱點掃描的程式設計習慣培養(二)_8.Insecure Deserialization ：不安全的反序列化漏洞ASP.NET處理方式 經得起原始碼資安弱點掃描的程式設計習慣培養(三)_7.Cross Site Scripting(XSS)_Stored XSS_Reflected XSS All Clients 經得起原始碼資安弱點掃描的程式設計習慣培養(四)_1.Injection注入攻擊_SQL Injection)_order by 語句正確參數化套入 經得起原始碼資安弱點掃描的程式設計習慣培養(四)_2.Injection注入攻擊_SQL Injection_In語句正確參數化套入 經得起原始碼資安弱點掃描的程式設計習慣培養(五)_Missing HSTS Header 經得起原始碼資安弱點掃描的程式設計習慣培養(六)_Path Traversal 經得起原始碼資安弱點掃描的程式設計習慣培養(七)_Code Injection 經得起原始碼資安弱點掃描的程式設計習慣培養(八)_Client DOM XSS 在判讀上屬於中風險的漏洞 通常在於應用程式裡面使用的Random亂數功能不夠隨機亂或者隨機範圍很好被預測到因為範圍較小。 風險 可能發生什麼問題 隨機數值通常被用來作為防止惡意使用者猜測如密碼、加密金鑰或session識別元等數值的機制，依照此 隨機數值用途的不同，攻擊者能夠有辦法預測下一個或已經產生過的隨機值，這使得攻擊者可以奪取另 外一位使用者的session，並取代他的身分，或是破解一組加密金鑰 (端看這組偽隨機值的用途)。 原因 如何發生 應用程式使用較弱的演算法來產生偽隨機值，代表決定其他數值的樣本大小相對來說是較小的。因為產 生隨機值所使用的偽隨機值產生器是基於統計學上的均勻分布所設計的，具有近似確定性。所以在收集 到數個產生出來的數值 (建立幾個獨立session然後收集session辨識碼) 後，攻擊者就有可能計算出其他的session辨識值。 更準確的說，如果這組偽隨機值被用做任何安全性使用，如密碼、金鑰、或是隱密辨識值，攻擊者就可以 預測下一個或已經產生的數值。 如何避...

 接續前幾篇系列 經得起原始碼資安弱點掃描的程式設計習慣培養(一)_OWASP Top 10(十大網站安全風險)_學習寫更安全程式碼的網站推薦 經得起原始碼資安弱點掃描的程式設計習慣培養(二)_8.Insecure Deserialization ：不安全的反序列化漏洞ASP.NET處理方式 經得起原始碼資安弱點掃描的程式設計習慣培養(三)_7.Cross Site Scripting(XSS)_Stored XSS_Reflected XSS All Clients 經得起原始碼資安弱點掃描的程式設計習慣培養(四)_1.Injection注入攻擊_SQL Injection)_order by 語句正確參數化套入 經得起原始碼資安弱點掃描的程式設計習慣培養(五)_Missing HSTS Header 經得起原始碼資安弱點掃描的程式設計習慣培養(六)_Path Traversal 經得起原始碼資安弱點掃描的程式設計習慣培養(七)_Code Injection 經得起原始碼資安弱點掃描的程式設計習慣培養(八)_Client DOM XSS 之前已經有修正過SQL Injection的經驗了是在針對order by情境 而這次遇到舊專案是在於In 一些參數的動態組字串的問題引發白箱弱掃 雖然前人已經有改用參數化方式但仍然會引發Injection風險 首先前人寫一段回傳DataSet給外面資料DataBind的dal函數 在外部呼叫時候 他傳入參數的準備處理比較容易有風險 用字串橫線分割 但傳入到function仍需要轉回成陣列或集合的型別 也會有多此一舉 所以其實在function設計上傳入參數一開始就指定傳入類似List之類的集合型別就好了 再針對In裡面要傳進的參數先prepare好一個condition string 如此可降低一些被弱掃認為是有風險的寫法 少點動態組字串問題

  接續前幾篇系列 經得起原始碼資安弱點掃描的程式設計習慣培養(一)_OWASP Top 10(十大網站安全風險)_學習寫更安全程式碼的網站推薦 經得起原始碼資安弱點掃描的程式設計習慣培養(二)_8.Insecure Deserialization ：不安全的反序列化漏洞ASP.NET處理方式 經得起原始碼資安弱點掃描的程式設計習慣培養(三)_7.Cross Site Scripting(XSS)_Stored XSS_Reflected XSS All Clients 經得起原始碼資安弱點掃描的程式設計習慣培養(四)_1.Injection注入攻擊_SQL Injection)_order by 語句正確參數化套入 經得起原始碼資安弱點掃描的程式設計習慣培養(五)_Missing HSTS Header 經得起原始碼資安弱點掃描的程式設計習慣培養(六)_Path Traversal 經得起原始碼資安弱點掃描的程式設計習慣培養(七)_Code Injection 近期維護到一個10幾年前的一個網站 在修正CheckMarx風險時候踏到一個 問題在於引入的這一個嵌入 Flash套件swfobject.js 由於專案本身其實沒有再使用了 所以解法就是移除掉該swf套件跟引入的部分 Ref: 瀏覽器現在已經不支援 flash，要怎麼播放 SWF 檔案？ https://steachs.com/archives/55733 網頁設計師一定要會的Swfobject.js 崁入Flash .SWF https://ucamc.com/articles/107-swfobject-js-flash swfobject - 網頁輕鬆嵌入 Flash https://blog.amowu.com/swfobject-flash/ 如何安全地嵌入任何Flash文件(SWF)? (How to safely embed any flash file (swf)?) https://zh-tw.coderbridge.com/discussions/b83ba1b6041e4593af2061dc32e7e323

  接續前幾篇系列 經得起原始碼資安弱點掃描的程式設計習慣培養(一)_OWASP Top 10(十大網站安全風險)_學習寫更安全程式碼的網站推薦 經得起原始碼資安弱點掃描的程式設計習慣培養(二)_8.Insecure Deserialization ：不安全的反序列化漏洞ASP.NET處理方式 經得起原始碼資安弱點掃描的程式設計習慣培養(三)_7.Cross Site Scripting(XSS)_Stored XSS_Reflected XSS All Clients 經得起原始碼資安弱點掃描的程式設計習慣培養(四)_1.Injection注入攻擊_SQL Injection)_order by 語句正確參數化套入 經得起原始碼資安弱點掃描的程式設計習慣培養(五)_Missing HSTS Header 經得起原始碼資安弱點掃描的程式設計習慣培養(六)_Path Traversal 近期在修正CheckMarx風險時候踏到一個 比較陌生沒看過的項目Code Injection 果真也是源自於Invoke 的 參數值是來自 Client Request送來的資料。 由於後來資料是卡在Url內容丟給一隻Web Service經過 CodeDom 去Compile出Client端後發送 (透過webservice來間接寄信) 就暫時針對其進行UrlEncode #更 2021/9/17 可能要將程式中有透過.Invoke跟MethodInfo反射的寫法改寫避免透過這類寫法 後來改為SmtpClient來寄信了 Ref: Code_Injection https://rainmakerho.github.io/2020/11/13/checkmarx-csharp-code-injection/ How To: Protect From Injection Attacks in ASP.NET https://docs.microsoft.com/en-us/previous-versions/msp-n-p/ff647397(v=pandp.10)?redirectedfrom=MSDN

  接續前幾篇系列 經得起原始碼資安弱點掃描的程式設計習慣培養(一)_OWASP Top 10(十大網站安全風險)_學習寫更安全程式碼的網站推薦 經得起原始碼資安弱點掃描的程式設計習慣培養(二)_8.Insecure Deserialization ：不安全的反序列化漏洞ASP.NET處理方式 經得起原始碼資安弱點掃描的程式設計習慣培養(三)_7.Cross Site Scripting(XSS)_Stored XSS_Reflected XSS All Clients 經得起原始碼資安弱點掃描的程式設計習慣培養(四)_1.Injection注入攻擊_SQL Injection)_order by 語句正確參數化套入 經得起原始碼資安弱點掃描的程式設計習慣培養(五)_Missing HSTS Header https://spanning.com/blog/directory-traversal-web-based-application-security-part-8/ Path Traversal 為一種利用網站的安全驗證潛在缺陷（如傳遞特定字符串至文件應用程式接口）來列出伺服器目錄的漏洞利用方式。  該攻擊手段的目的是利用存在缺陷的應用程式來獲得目標文件系統上的非授權訪問權限。 過去重大事件 遠通電收再度出包！eTag官網遭駭，民眾資料外洩 https://www.techbang.com/posts/16432-far-powered-collection-again-etags-official-website-were-terrible-population-data-leaks 近期實際案例 中興保全Dr.ID 門禁考勤系統 - Path Traversal https://www.twcert.org.tw/tw/cp-132-4906-89381-1.html 近期遇到這項掃描報告要做改善 對斜線、反斜線及點符號做一個取代為空字串處理 1 2 3 4 5 6 7 8 9 10 //https://owasp.org/www-community/attacks/Path_Traversal /// <summary> /// 取代會導致Path Traversal的符號 /// </summ...

  接續前幾篇系列 經得起原始碼資安弱點掃描的程式設計習慣培養(一)_OWASP Top 10(十大網站安全風險)_學習寫更安全程式碼的網站推薦 經得起原始碼資安弱點掃描的程式設計習慣培養(二)_8.Insecure Deserialization ：不安全的反序列化漏洞ASP.NET處理方式 經得起原始碼資安弱點掃描的程式設計習慣培養(三)_7.Cross Site Scripting(XSS)_Stored XSS_Reflected XSS All Clients 經得起原始碼資安弱點掃描的程式設計習慣培養(四)_1.Injection注入攻擊_SQL Injection)_order by 語句正確參數化套入 最近又遇到被若安掃描到高風險要修正的程式碼啦.... 一看這還真是搞不懂該怎麼修呢 HSTS(HTTP Strict Transport Security)  主要是一份國際標準規格 (RFC 6797) 的網際網路瀏覽安全機制， 用於宣告瀏覽器與伺服器之間通訊方式必須強制採用 TLS/SSL 加密通道。 只要從伺服器端送出一個 Strict-Transport-Security 標頭 (Header) 給瀏覽器，即可告知瀏覽器於未來的某段時間內一律使用 SSL 來和該網站連接 (設定可涵蓋所有子域名網站)， 一旦發生憑證失效情況，使用者將無法再瀏覽該網站，如此一來便可大幅減少中間人攻擊的問題發生。 再更白話一點 HSTS Header 就是負責將 http 強制轉為 https CheckMarx掃碼報告給的說明 ============================================================ 風險: 如果web config沒有設置HSTS表頭、"max-age"(有效期)不足一年， 或沒有設定"includeSubDomains"(包含所有子網域)，可能會使用戶容易遭受中間人攻擊。 發生原因: 許多使用者只要在瀏覽器的網址列輸入網域名稱(Domain Name)即可瀏覽網站， 並沒有輸入協定(Protocol)的名稱。 瀏覽器會自動假設使用者使用的是HTTP協定而不是有加密機制的HTTPS協定。 在第一次發出前往特定網站的請求時，攻擊者可以執行中間人攻擊並將用戶轉址到...

  接續前幾篇系列 經得起原始碼資安弱點掃描的程式設計習慣培養(一)_OWASP Top 10(十大網站安全風險)_學習寫更安全程式碼的網站推薦 經得起原始碼資安弱點掃描的程式設計習慣培養(二)_8.Insecure Deserialization ：不安全的反序列化漏洞ASP.NET處理方式 經得起原始碼資安弱點掃描的程式設計習慣培養(三)_7.Cross Site Scripting(XSS)_Stored XSS_Reflected XSS All Clients 在專案不斷去累積具有資安程式撰寫設計習慣更上一層樓 於近期又被掃到程式寫的部分具有高風險 而且是在SQL部分注入的風險 這就令人納悶因為早已知道要遵照Parameter來防止這種安全問題才對 查閱了報告後才得知 原來其中一段在order by 由於採用變動帶字串取代方式的可變動設計 但忽略了參數化處理 這裡要小心只要是用字串格式化串接外部傳入的變動內容的方式來產生 SQL 語句就一定會有 SQL injection的風險！ 此外除where 語句部分也可能在order by 語句部分發生 只是打從 娘胎 痾不是我是說從開始寫.net以來好像沒看過有人參數化是 直接套入order by [@FieldName] [@SortDir(asc/desc)] 來試試看好了果真會報錯 (｡ŏ﹏ŏ) 而比較正確設計方式就是利用  CASE WHEN 排序方向 + CASE WHEN 排序對應欄位 來自己寫入對應order by 後續指令字串 外部傳入的參數則用於條件分支判斷而已 Ref: [如何提升系統品質-Day20]Security - SQL injection https://ithelp.ithome.com.tw/articles/10080209 “Order By” using a parameter for the column name https://stackoverflow.com/questions/13844678/order-by-using-a-parameter-for-the-column-name How do you ORDER BY a parameter? https://dba.stackexchange.com/questions/4104/...

  近期新加入的功能code剛好也被CheckMarx掃出高風險部分的程式碼漏洞 我也踏到這個Issue啦 Cross Site Scripting(XSS)  第一種.Stored XSS 高風險 CheckMarx掃碼報告給的說明[Stored XSS] ============================================================ 風險: 攻擊者可以利用合法存取應用程式提交資料到資料庫。 當另一個使用者隨後存取該資料，網頁可能會被改寫且惡意腳本可能會被啟動。 發生原因: 從資料庫中的資料建立網頁。資料直接嵌入至HTML的頁面，利用瀏覽器顯示。 資料可能源自於其他使用者的輸入。 如果資料包含HTML片段或Javascript，使用者無法分辨是否為預期的頁面。 該漏洞主因為未先對嵌入資料庫中的資料進行編碼(Encode) 來預防瀏覽器將其當為HTML的格式而非純文字。 如何避免: 1.驗證所有資料，無論其來源為何。驗證應基於白名單：僅接受預定結構的資訊，而不是拒絕不良的樣式(Patterns)。  應確認：  ● 資料型態  ● 大小  ● 範圍  ● 格式  ● 期望值  2. 驗證無法取代編碼. 輸出嵌入之前，不論其來源， 將所有動態資料進行編碼. 編碼方式應該是上下文相關的. 例如: ● HTML內容使用HTML的編碼方式  ● HTML編碼特性是將資料輸出到特性的值 ● JavaScript的編碼方式為伺服器產生的Javascript  3.考慮使用ESAPI的編碼庫，或它的內置功能。對於舊版的ASP.NET，請考慮使用AntiXSS.  4.在HTTP類型對應的表頭， 明確定義整個頁面的字元編碼.  5. 設置 httpOnly 標誌於會期資訊，以防止利用XSS來竊取資訊. ============================================================ 這裡報告描述是指我對傳進來字串參數直接拋給DAL處裡的類別執行查詢 這裡缺乏對輸入進來的字串參數做一些查檢判斷 也建議在帶入時對參數也做一些html encode處理 這裡用AntiXSS來Enc...