源碼掃描 – Log Forging 日誌偽造 – 原因及處理

前言

度過了愉快的周末，繼續回到客戶那邊進行源碼掃描

那今天就來講個很常出現的問題，LOG相關的

相信各位在寫程式時，為了方便之後查閱肯定會這邊加加，那邊加加吧

最後整支程式都充滿著LOG哈哈!

Log Forging

先來看下Fotify報告怎麼說

Log Forging 弱點會在以下情況中出現：

1. 資料從不可信賴的來源進入應用程式。
2. 將資料寫入應用程式或系統記錄檔。

⬆️根據說明，可以看的出來，這是因為如果將輸入的資料直接寫入LOG

可能會造成惡意寫入的狀況，就有可能導致後續判斷LOG時造成錯誤的判斷

而最糟糕的情況是，攻擊者可能會在記錄檔中插入程式碼，並利用記錄檔相關程式的弱點進行破壞

該怎麼修正

最簡單的方式，其實就是移除不需要的記錄

像是一套系統通常在測試及前期上線為了DEBUG會加上很多LOG

但若是穩定的系統，則只需在必要時記錄即可 (像是ERROR、很常調閱的問題…等)

不過，我相信看到現在的各位鐵定是走投無路才會繼續看下去

那讓我們來看看Fortify中的一段說明吧

「在大多數 Log Forging 攻擊中，最關鍵的字元是「\n」(新行) 字元，這樣的字元絕對不應出現在記
錄檔項目的允許清單中。」

本來看到這一段，我就寫了一個簡單的replace，但參考了網路上其他大神的答案後又增加了其他幾個條件

方法2: 建立黑名單

public static String validLog(String log) {
    List<String> list = new ArrayList<String>();
    list.add("%0d");
    list.add("\r");
    list.add("%0a");
    list.add("\n");
    String encode = Normalizer.normalize(log, Normalizer.Form.NFKC);
    
    for (String item : list) {
        encode = encode.replace(item, "存在不該存在之換行字元");
    }
    
    return encode;
}

(這裡提供的是Java的範例)

這裡除了常見的 “\r”、”\n”之外，另外的兩個其實也是換行字符

%後面的其實是16進位表示的，故對應後為 10以及13，而在 ASCII code 中這兩個分別代表著 「LF」以及「CR 」

( 在之前的筆記文章中有提到過 – 可以參考 textarea placeholder 文本輸入框的提示文字 該怎麼換行 )

另外 NFKC 則是一種正規化的型態，有機會讓我研究下再介紹

這樣改完之後，其實就達成Fortify所說的針對換行字元的限制

當然，如果認為還有其他有風險的字眼，也可以一併替換掉

這樣修正完後，錯誤就消失了嗎?

其實沒有，掃描可能還是會掃描出來! 但應該可以標註為修正過了，畢竟已經達成掃描軟體說的要求了

結論

其實修源掃的這幾天下來，就會發現很多漏洞都是關於隱私及使用者輸入字串的檢核

那最簡單的方法，自然就是除必要的資料外，都不要另外記錄才會是最好的

但等到程式出問題的時候(非安全洩漏這種的)，誰都巴不得LOG記的越多越好哈哈!

參考文章 :

• Software Security | Log Forging (fortify.com)
• java – Can’t resolve Log Forging Fortify issue – Stack Overflow
• Fortify漏洞之 Log Forging（日志伪造） – Xavier-Xu – 博客园 (cnblogs.com)

🧡希望文章能幫上您的一點忙!

🧡幫我分享給朋友或是在底下留下您寶貴的意見，都是對我的支持

✅如有任何疑問，歡迎踴躍留言或messenger讓我知道 !

沒有記在筆記本上的筆記