源碼掃描 – Privacy Violation: Heap Inspection 隱私侵犯 堆(積)檢查

前言

繼上一集的 Insecure Randomness 不安全的隨機數，可憐如我還是繼續在客戶那修著fortify的問題們

這一次來介紹的是常見且不會特別研究的項目

(本篇文章會以Java的角度去進行修正，若有其他語言的範例會再補充)

Privacy Violation: Heap Inspection 堆(積)檢查

簡單的來說，該漏洞是由於使用記憶體後沒有清除，可能會導致敏感資料(客戶個資、信用卡號碼…等)洩漏的狀況

而最常引發這個狀況的就是我們很常使用的字串 String !!

這是因為String本身是不可變的，舉例來說

String text = "abc";
text = "abcd";

其實前後text佔據的記憶體位置是不相同的，這是因為String不可變，所以重新賦值就會重設記憶體指向的位置

而舊的位置則會在之後GC(*註1)

該怎麼修正 – Java篇

那我們都知道String會有這種問題，那解決方法也比較簡單

使用char array或是stringbuffer來取代String的使用

現在我們來假設一個程式是傳送信用卡資訊

String abc = "信用卡密碼";
sendMessage("客戶ID","客戶信用卡號碼",abc)

原本的程式要是發生記憶體洩漏的狀況，攻擊者可以很輕易的從abc得到使用者的敏感資訊

故可以改成如下，將String棄用改為使用char array的方式

char[] abc = "信用卡密碼".toCharArray();
sendMessage("客戶ID","客戶信用卡號碼",abc);
Arrays.fill(abc , ' ');

不只使用了char array，甚至可以在結束的時候主動清除裡面的資料

結論

這個系列都是親身經歷，但理論以及解決都是根據Fortify提供的資訊以及很多網路上的資訊蒐集而來

希望若是有任何講得不好或是有疑問的地方，都歡迎大家提出來與我分享，在這先謝過大家了~

參考文章 :

• Software Security | Privacy Violation: Heap Inspection (fortify.com) <<中文的，不用擔心

註1 : GC 全稱為Garbage Collection，也就是垃圾回收，在程式中指的清理不再需要的記憶體，以便其他程序可以使用。在Java8之後，GC大多數交由Java本身判斷，故開發人員也不會直接參與。

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

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

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

本人親自經歷的辛酸血淚史 (源碼掃描多寫幾篇，就會改成都是那個分類吧)