借由查看應(yīng)用通過歸因SDK所發(fā)送的數(shù)據(jù)和歸因公司服務(wù)器中的數(shù)據(jù),欺詐者就能決定他們需要發(fā)送什么信息以“欺騙”歸因公司來接受他們的偽造數(shù)據(jù)。一旦成功,欺詐者便可以創(chuàng)建無限量、看似真實的用戶和應(yīng)用內(nèi)事件,甚至無需在任何手機(jī)上運(yùn)行實際的應(yīng)用。
如今的欺詐者可以得到真實的設(shè)備ID,這意味著,除非您使用了加密簽名來確保數(shù)據(jù)是從應(yīng)用中發(fā)送的,否則他們產(chǎn)生的虛假數(shù)據(jù)看起來就如同真實數(shù)據(jù)一般。
正因為Adjust SDK是開源的,下面的問題更值得我們深究:
如何保護(hù)我們用來驗證請求的代碼,不會輕易遭他人讀取并用來復(fù)制其行為?
Adjust之所以提供開源SDK,是因為我們確信客戶有權(quán)了解他們的應(yīng)用中發(fā)生了什么。除此之外,開源SDK促使我們與客戶的合作,創(chuàng)建市場上最穩(wěn)定且不會崩潰的SDK。事實上,歸因SDK應(yīng)該實現(xiàn)開源化的原因有很多,我們在之前的文章中已有所著墨。
Adjust SDK如何保證安全?
為了使用Adjust進(jìn)行跟蹤,客戶需要先將Adjust SDK集成到他們的應(yīng)用中。但是為了保護(hù)我們的客戶免受偽造影響,我們還要求客戶另外下載一個單獨(dú)的庫(library),并將其插入Adjust SDK。如果沒有這個庫,SDK并不安全,而我們也不會接受來自它的數(shù)據(jù)。
此庫可以創(chuàng)建加密簽名,而該簽名將附加到從SDK發(fā)送的每個數(shù)據(jù)請求中。它可以防御所有已知的攻擊方法,并由我們的安全專家團(tuán)隊不斷更新。每個庫都是不同的,這意味著如果一個應(yīng)用受到攻擊,相同的攻擊方法不會在世界上的任何其他應(yīng)用上起作用。此外,我們的安全團(tuán)隊會持續(xù)更新該庫,因此任何破壞安全性的新嘗試都將很快失效。
庫的代碼是隨機(jī)生成的,之后經(jīng)過特殊的編譯過程,使攻擊者無法對庫進(jìn)行反向工程以讀取代碼。
其他SDK是否更加安全?
大多數(shù)其他歸因SDK都是閉源的,不會向使用它們的客戶顯示其代碼,但這是否使它們更加安全?
“答案是并不會。”
在我們對SDK偽造的研究中,我們檢查了市場中的閉源歸因SDK,以了解它們在沒有加密簽名的情況下的安全性。遺憾的是,我們發(fā)現(xiàn)在每個案例中,這些SDK用來簽署數(shù)據(jù)請求的函數(shù)都能非常輕易地以人類可讀的形式提取,因此要攻破它是輕而易舉。
實際上,對于某些SDK,我們的研究人員只花了幾分鐘就能找到并破解它們的簽名功能——也就是說SDK的保護(hù)在短短的時間內(nèi)便被完全破除。這會導(dǎo)致非常嚴(yán)重的后果,因為一旦攻擊者這樣做,他們就可以使用該簽名來使虛假數(shù)據(jù)看起來完全真實。簡而言之,攻擊者可以輕松欺騙所有現(xiàn)行的閉源解決方案。
客戶插入到SDK的自定義庫里,并不包含歸因SDK的全部函數(shù),只包含防止偽造所必須的相關(guān)函數(shù)。這意味著我們可以用完全不同的方式編寫、編譯和保護(hù)它。
出于安全考量,我們無法透露用于保護(hù)庫的所有方法,但是我們很樂意為客戶與我們的網(wǎng)絡(luò)安全專家之間連線,并提供進(jìn)一步的解釋??偠灾?,保護(hù)開源SDK的安全性是絕對可行的,另一方面,閉源SDK不會遭受偽造的說法也是不正確的。