Go應(yīng)用程序中需要注意27個漏洞，其中包括任意文件寫入、目錄遍歷、反序列化等。  

保護應(yīng)用程序并不是最簡單的事情。而一個應(yīng)用程序有許多組件：服務(wù)器端邏輯、客戶端邏輯、數(shù)據(jù)存儲、數(shù)據(jù)傳輸、API等等。而為了保護所有這些組件的安全，構(gòu)建安全的應(yīng)用程序似乎真的令人生畏。  

值得慶幸的是，大多數(shù)現(xiàn)實生活中的漏洞都有相同的根源。通過研究這些常見的漏洞類型、發(fā)生的原因以及如何發(fā)現(xiàn)它，可以學(xué)會預(yù)防，并保護應(yīng)用程序。

每種語言、框架或環(huán)境的使用都會使應(yīng)用程序暴露于一組獨特的漏洞中。修復(fù)應(yīng)用程序漏洞的第一步是知道需要尋找什么。以下是影響Go應(yīng)用程序的27個最常見的漏洞，以及如何找到預(yù)防的方法。 

企業(yè)需要致力于保護Go應(yīng)用程序。以下是需要關(guān)注的27個漏洞：  

（1）XML外部實體攻擊  

XML外部實體攻擊(XXE)是指攻擊者利用XML解析器讀取服務(wù)器上的任意一些文件。使用XXE，攻擊者還可以檢索用戶信息、配置文件或其他敏感信息，例如AWS憑證。而為了防止XXE攻擊，需要明確禁用這些功能。  

（2）不安全的反序列化  

序列化是將編程語言中的對象（例如Python對象）轉(zhuǎn)換為可以保存到數(shù)據(jù)庫或通過網(wǎng)絡(luò)傳輸格式的過程。而反序列化則相反：它是從文件或網(wǎng)絡(luò)中讀取序列化對象并轉(zhuǎn)換回對象的過程。許多編程語言都支持對象的序列化和反序列化，其中包括Java、PHP、Python和Ruby。  

不安全的反序列化是一種漏洞，當(dāng)攻擊者可以操縱序列化對象并在程序流程中造成意想不到的后果時，就會出現(xiàn)這種漏洞。不安全的反序列化漏洞通常是非常關(guān)鍵的漏洞：不安全的反序列化漏洞通常會導(dǎo)致身份驗證繞過、拒絕服務(wù)，甚至是執(zhí)行任意代碼。  

為了防止不安全的反序列化，需要首先留意最新的補丁并保持依賴關(guān)系。許多不安全的反序列化漏洞是通過依賴項引入的，因此需要確保其第三方代碼是安全的。它還有助于避免使用序列化對象，而是使用簡單的數(shù)據(jù)類型，如字符串和數(shù)組。  

（3）遠(yuǎn)程代碼執(zhí)行  

遠(yuǎn)程代碼執(zhí)行漏洞(RCE)是攻擊者可以在他人的機器上執(zhí)行其代碼時發(fā)生的一類漏洞。當(dāng)Web服務(wù)器成為目標(biāo)時，攻擊者通常通過HTTP請求注入惡意輸入來實現(xiàn)遠(yuǎn)程代碼執(zhí)行漏洞(RCE)，這些輸入被服務(wù)器錯誤地評估為代碼。  

在Go中，開發(fā)人員經(jīng)常使用net/rpc或grpc等數(shù)據(jù)包來允許通過網(wǎng)絡(luò)遠(yuǎn)程調(diào)用方法。在這種情況下，確保任何過程調(diào)用來自受信任的來源非常重要。  

（4）注入  

當(dāng)應(yīng)用程序無法正確區(qū)分不受信任的用戶數(shù)據(jù)和代碼時，就會發(fā)生注入問題。例如以上所說的例子，通過代碼注入的RCE就是一種注入漏洞。但注入漏洞也以其他方式表現(xiàn)出來。  

（5）SQL注入  

例如，在SQL注入攻擊中，攻擊者通過注入數(shù)據(jù)來操縱SQL命令。當(dāng)應(yīng)用程序沒有正確驗證用戶輸入時，攻擊者可以插入SQL語言的特殊字符來擾亂查詢邏輯，從而執(zhí)行任意SQL代碼。  

SQL注入能夠讓攻擊者代碼更改應(yīng)用程序SQL查詢的結(jié)構(gòu)，以竊取數(shù)據(jù)、修改數(shù)據(jù)或可能在底層操作系統(tǒng)中執(zhí)行任意命令。防止SQL注入的最好方法是使用參數(shù)化語句，這使得SQL注入幾乎不可能。  

（6）NoSQL注入  

數(shù)據(jù)庫并不總是使用SQL。NoSQL數(shù)據(jù)庫或NotOnlySQL數(shù)據(jù)庫是不使用SQL語言的數(shù)據(jù)庫。NoSQL注入是指將數(shù)據(jù)注入到這些數(shù)據(jù)庫語言的邏輯中的攻擊。NoSQL注入可能與SQL注入一樣嚴(yán)重：它們可能導(dǎo)致身份驗證繞過和遠(yuǎn)程代碼執(zhí)行。  

（7）日志注入  

用戶可能會執(zhí)行系統(tǒng)日志記錄以監(jiān)控網(wǎng)絡(luò)中發(fā)生的惡意活動。但是有沒有想過其日志文件條目可能會撒謊？與其他系統(tǒng)文件一樣，日志文件可能會被惡意行為者篡改。攻擊者經(jīng)常修改日志文件以在攻擊期間掩蓋他們的蹤跡。日志注入是攻擊者可以更改其日志文件的方式之一。當(dāng)攻擊者欺騙應(yīng)用程序在用戶的日志文件中寫入虛假條目時，就會發(fā)生這種情況。  

當(dāng)應(yīng)用程序不清理寫入日志的輸入中的換行符“\n”時，通常會發(fā)生日志注入。攻擊者可以利用換行符將新條目插入應(yīng)用程序日志。攻擊者可以利用日志中的用戶輸入的另一種方式是，他們可以將惡意HTML注入日志條目，以嘗試在查看日志的管理員的瀏覽器上觸發(fā)XSS。  

為了防止日志注入攻擊，需要一種方法來區(qū)分真實日志條目和攻擊者注入的虛假日志條目。一種方法是在每個日志條目前添加額外的元數(shù)據(jù)，如時間戳、進程ID和主機名。用戶還應(yīng)該將日志文件的內(nèi)容視為不受信任的輸入，并在訪問或操作它們之前對其進行驗證。  

（8）郵件注入  

許多Web應(yīng)用程序會根據(jù)用戶的操作向用戶發(fā)送電子郵件。例如，如果訂閱了新聞媒體上的提要，該網(wǎng)站可能會向用戶發(fā)送包含提要名稱的確認(rèn)信息。  

當(dāng)應(yīng)用程序使用用戶輸入來確定將電子郵件發(fā)送到哪些地址或包含在電子郵件中的內(nèi)容時，就會發(fā)生郵件注入。這可以讓垃圾郵件發(fā)送者使用其服務(wù)器向用戶發(fā)送大量電子郵件，或者使詐騙者能夠通過其電子郵件地址進行社會工程活動。  

（9）模板注入  

模板引擎是一種用于確定網(wǎng)頁外觀的軟件。這些Web模板以Jinja等模板語言編寫，為開發(fā)人員提供了一種通過將應(yīng)用程序數(shù)據(jù)與Web模板相結(jié)合來指定如何呈現(xiàn)頁面的方法。Web模板和模板引擎一起允許開發(fā)人員在Web開發(fā)期間將服務(wù)器端應(yīng)用程序邏輯與客戶端表示代碼分開。  

模板注入是指注入到網(wǎng)頁模板中。根據(jù)受感染的應(yīng)用程序的權(quán)限，攻擊者可能能夠使用模板注入漏洞來讀取敏感文件、執(zhí)行代碼或提升他們在系統(tǒng)上的權(quán)限。  

（10）正則表達式注入  

正則表達式是描述文本中搜索模式的特殊字符串。有時，應(yīng)用程序讓用戶提供自己的正則表達式模式，以供服務(wù)器執(zhí)行或使用用戶輸入構(gòu)建正則表達式。正則表達式注入攻擊或正則表達式拒絕服務(wù)攻擊(ReDoS)發(fā)生在攻擊者為正則表達式引擎提供需要很長時間評估的模式的時候。  

值得慶幸的是，通過不從用戶輸入生成正則表達式模式，并通過構(gòu)造精心設(shè)計的正則表達式模式，其所需的計算時間不會隨著文本字符串的增長而呈指數(shù)增長，能夠可靠地防止正則表達式注入。  

（11）XPath注入  

XPath是一種用于XML文檔的查詢語言。為XML考慮SQL。XPath用于對存儲在XML文檔中的數(shù)據(jù)進行查詢和操作。例如，XPath可用于檢索存儲在XML文檔中的員工工資信息。它還可用于對該數(shù)據(jù)執(zhí)行數(shù)字運算或比較。  

XPath注入是一種注入XPath表達式以改變查詢結(jié)果的攻擊。和SQL注入一樣，它可以用來繞過業(yè)務(wù)邏輯，提升用戶權(quán)限，泄露敏感數(shù)據(jù)。由于應(yīng)用程序經(jīng)常使用XML在系統(tǒng)和Web服務(wù)之間傳遞敏感數(shù)據(jù)，因此這些地方更容易受到XPath注入的影響。與其他類型的注入漏洞類似，用戶可以通過驗證和清理用戶輸入來防止XPath注入。  

（12）標(biāo)頭注入  

當(dāng)HTTP響應(yīng)標(biāo)頭是從不受信任的輸入動態(tài)構(gòu)建時，就會發(fā)生標(biāo)頭注入。根據(jù)漏洞影響的響應(yīng)標(biāo)頭，標(biāo)頭注入可能導(dǎo)致跨站點腳本、開放重定向和會話固定。  

例如，如果標(biāo)頭可以由URL參數(shù)控制，則攻擊者可以通過在參數(shù)中指定他們的惡意站點來導(dǎo)致開放重定向。攻擊者甚至可以在受害者的瀏覽器上執(zhí)行惡意腳本，或者通過標(biāo)頭注入向受害者發(fā)送完全受控的HTTP響應(yīng)來強制受害者下載惡意軟件。  

可以通過避免將用戶輸入寫入響應(yīng)標(biāo)頭、從用戶輸入中去除換行符（換行符用于創(chuàng)建新的HTTP響應(yīng)標(biāo)頭）以及使用允許列表來驗證標(biāo)頭值來防止標(biāo)頭注入。  

（13）會話注入和不安全的cookie  

會話注入是一種標(biāo)頭注入。如果攻擊者可以操縱他們的會話cookie的內(nèi)容，或者竊取其他人的cookie，他們可以欺騙應(yīng)用程序。攻擊者可以通過三種主要方式獲取他人的會話：會話劫持、會話篡改和會話欺騙。  

會話劫持是指攻擊者竊取別人的會話cookie并將其用作自己的。攻擊者經(jīng)常通過XSS或MITM（中間人）攻擊竊取會話cookie。會話篡改是指攻擊者可以更改其會話cookie以更改服務(wù)器解釋其身份的方式。當(dāng)會話狀態(tài)在cookie中進行通信并且cookie沒有正確簽名或加密時，就會發(fā)生這種情況。最后，當(dāng)會話ID是可預(yù)測的時，攻擊者可以欺騙會話。如果是這種情況，攻擊者可以偽造有效的會話cookie并以其他人的身份登錄。防止這些會話管理陷阱需要多層防御。  

（14）主機標(biāo)頭中毒

Web服務(wù)器通常在同一個IP地址上托管多個不同的網(wǎng)站。HTTP請求到達某個IP地址后，服務(wù)器會將請求轉(zhuǎn)發(fā)到主機標(biāo)頭中指定的主機。盡管主機標(biāo)頭通常由用戶的瀏覽器設(shè)置，但它仍然是用戶提供的輸入，因此不應(yīng)被信任。  

如果Web應(yīng)用程序在使用主機標(biāo)頭構(gòu)造地址之前未對其進行驗證，則攻擊者可以通過Host標(biāo)頭發(fā)起一系列攻擊，例如XSS、服務(wù)器端請求偽造(SSRF)和Web緩存中毒攻擊。例如，如果應(yīng)用程序使用主機標(biāo)頭來確定腳本的位置，則攻擊者可以提交惡意主機標(biāo)頭以使應(yīng)用程序執(zhí)行惡意腳本：  

Go

1 scriptURL := fmt.Sprintf("https://%s/script.js",

2  request.Header.Get("Host"))

（15）敏感數(shù)據(jù)泄露  

當(dāng)應(yīng)用程序未能正確保護敏感信息時，就會發(fā)生敏感數(shù)據(jù)泄漏，從而使用戶能夠訪問他們不應(yīng)該獲得的信息。這些敏感信息可能包括有助于攻擊的技術(shù)細(xì)節(jié)，例如軟件版本號、內(nèi)部IP地址、敏感文件名和文件路徑。它還可能包含允許攻擊者對應(yīng)用程序進行源代碼審查的源代碼。有時，該應(yīng)用程序會泄露用戶的私人信息，例如他們的銀行帳號、電子郵件地址和郵寄地址。  

應(yīng)用程序泄漏敏感技術(shù)細(xì)節(jié)的一些常見方式是通過描述性響應(yīng)頭、帶有堆棧跟蹤或數(shù)據(jù)庫錯誤消息的描述性錯誤消息、系統(tǒng)文件系統(tǒng)上的開放目錄列表，以及在HTML和模板文件中顯示注釋。

（16）身份驗證繞過  

身份驗證指的是在執(zhí)行敏感操作或訪問敏感數(shù)據(jù)之前證明自己的身份。如果未在應(yīng)用程序上正確實施身份驗證，攻擊者可以利用這些錯誤配置來訪問他們不能夠訪問的功能。

（17）訪問控制不當(dāng)  

身份驗證繞過問題本質(zhì)上是不正確的訪問控制。當(dāng)應(yīng)用程序中的訪問控制實施不當(dāng)并且可以被攻擊者繞過時，任何時候都會發(fā)生不當(dāng)?shù)脑L問控制。然而，訪問控制不僅僅包括身份驗證。雖然身份驗證要求用戶證明他們的身份：“你是誰？”，但授權(quán)要求應(yīng)用程序“允許此用戶做什么？”。適當(dāng)?shù)纳矸蒡炞C和授權(quán)共同確保用戶無法訪問超出其權(quán)限的功能。  

為用戶配置授權(quán)有多種方式：基于角色的訪問控制、基于所有權(quán)的訪問控制、訪問控制列表等。  

（18）目錄遍歷  

目錄遍歷漏洞是另一種不恰當(dāng)?shù)脑L問控制。當(dāng)攻擊者可以通過操縱用戶輸入字段中的文件路徑來查看、修改或執(zhí)行他們不應(yīng)訪問的文件時，就會發(fā)生這種情況。這一過程涉及通過將../字符或其他特殊字符添加到文件路徑來操作應(yīng)用程序，用于引用文件的文件路徑變量。../序列指的是Unix系統(tǒng)中當(dāng)前目錄的父目錄，因此通過將其添加到文件路徑中，通常可以訪問web目錄之外的系統(tǒng)文件。  

攻擊者通?？梢允褂媚夸洷闅v來訪問敏感文件，如配置文件、日志文件和源代碼。為了防止目錄遍歷，應(yīng)該驗證插入到文件路徑中的用戶輸入，或者避免直接引用文件名并改用間接標(biāo)識符。  

（19）任意文件寫入  

任意文件寫入漏洞的工作方式與目錄遍歷類似。如果應(yīng)用程序?qū)⑽募懭氲讓訖C器，并通過用戶輸入確定輸出文件名，則攻擊者可能能夠在他們想要的任何路徑上創(chuàng)建任意文件或覆蓋現(xiàn)有系統(tǒng)文件。攻擊者可能能夠更改密碼文件或日志文件等關(guān)鍵系統(tǒng)文件，或?qū)⑺麄冏约旱目蓤?zhí)行文件添加到腳本目錄中。  

減輕這種風(fēng)險的最佳方法是不根據(jù)任何用戶輸入創(chuàng)建文件名，包括會話信息、HTTP輸入或用戶控制的任何內(nèi)容。應(yīng)該控制每個創(chuàng)建的文件的文件名、路徑和擴展名。例如，在用戶每次需要生成唯一文件時生成一個隨機的字母數(shù)字文件名，還可以在創(chuàng)建文件之前去除用戶輸入的特殊字符。  

（20）拒絕服務(wù)攻擊  

拒絕服務(wù)攻擊或DoS攻擊會破壞目標(biāo)機器，使合法用戶無法訪問其服務(wù)。攻擊者可以通過耗盡所有服務(wù)器資源、崩潰進程或一次發(fā)出過多耗時的HTTP請求來發(fā)起DoS攻擊。  

拒絕服務(wù)攻擊很難防御。但是有一些方法可以通過讓攻擊者盡可能地困難來最小化風(fēng)險。例如，可以部署提供DoS保護的防火墻，并通過設(shè)置文件大小限制和禁止某些文件類型來防止基于邏輯的DoS攻擊。  

（21）加密漏洞  

加密問題可能是應(yīng)用程序中可能發(fā)生的最嚴(yán)重的漏洞之一。加密漏洞是指未正確實施加密和散列。這可能導(dǎo)致廣泛的數(shù)據(jù)泄漏和通過會話欺騙繞過身份驗證。

開發(fā)人員在網(wǎng)站上實施加密時常犯的一些錯誤是：  

?使用弱算法。

?使用錯誤的算法達到目的。  

?創(chuàng)建自定義算法。  

?生成弱隨機數(shù)。  

?將編碼誤認(rèn)為加密。  

（22）不安全的TLS配置和不正確的證書驗證  

除了正確加密數(shù)據(jù)存儲中的信息之外，用戶還需要確保正在與受信任的機器進行通信，而不是與惡意的第三方進行通信。TLS使用數(shù)字證書作為其公鑰加密的基礎(chǔ)，需要在與第三方建立連接之前驗證這些證書。用戶應(yīng)該驗證其嘗試連接的服務(wù)器是否具有由受信任的證書頒發(fā)機構(gòu)(CA)頒發(fā)的證書，并且證書鏈中的任何證書都沒有過期。  

（23）批量分配  

“批量賦值”是指一次為多個變量或?qū)ο髮傩再x值的做法。當(dāng)應(yīng)用程序自動將用戶輸入分配給多個程序變量或?qū)ο髸r，就會出現(xiàn)批量分配漏洞。這是許多旨在簡化應(yīng)用程序開發(fā)的應(yīng)用程序框架中的一個功能。  

但是，這一功能有時允許攻擊者隨意覆蓋、修改或創(chuàng)建新的程序變量或?qū)ο髮傩?。這可能導(dǎo)致身份驗證繞過和對程序邏輯的操縱。要防止批量分配，可以使用正在使用的框架禁用批量分配功能，或者使用白名單僅允許對某些屬性或變量進行分配。  

（24）打開重定向  

網(wǎng)站通常需要自動重定向其用戶。例如，這個當(dāng)未經(jīng)身份驗證的用戶嘗試訪問頁面時會發(fā)生這種情況需要登錄。網(wǎng)站通常會將這些用戶重定向到登錄頁面，然后在他們通過身份驗證后將它們返回到原來的位置。  

在開放式重定向攻擊期間，攻擊者誘騙用戶訪問通過向他們提供來自合法站點的URL來訪問外部站點重定向到其他地方。這可以讓用戶相信他們?nèi)匀辉谠季W(wǎng)站上，并幫助詐騙者構(gòu)建更可信的網(wǎng)絡(luò)釣魚活動。  

為了防止開放重定向，需要確保應(yīng)用程序不會將用戶重定向到惡意位置。例如，可以通過驗證重定向URL來完全禁止異地重定向。還有許多其他方法可以防止打開重定向，例如檢查請求的引用者或使用頁面索引進行重定向。但是由于驗證URL很困難，開放重定向仍然是現(xiàn)代Web應(yīng)用程序中的一個普遍問題。  

 （25）跨站請求偽造  

跨站點請求偽造(CSRF)是一種客戶端技術(shù)，用于攻擊Web應(yīng)用程序的其他用戶。使用跨站點請求偽造(CSRF)，攻擊者可以發(fā)送假裝來自受害者的HTTP請求，代表受害者執(zhí)行不需要的操作。例如，攻擊者可能會在未經(jīng)許可的情況下更改密碼或銀行賬戶轉(zhuǎn)賬。  

與開放式重定向不同，有一種防止跨站點請求偽造(CSRF)的萬無一失的方法：結(jié)合使用跨站點請求偽造(CSRF)令牌和SameSite cookie，并避免使用GET請求進行狀態(tài)更改操作。  

（26）服務(wù)器端請求偽造  

服務(wù)器端請求偽造（SSRF）或服務(wù)器端請求偽造是攻擊者能夠代表服務(wù)器發(fā)送請求時發(fā)生的漏洞。它允許攻擊者“偽造”易受攻擊的服務(wù)器的請求簽名，從而在網(wǎng)絡(luò)上占據(jù)特權(quán)地位，繞過防火墻控制并獲得對內(nèi)部服務(wù)的訪問權(quán)限。  

根據(jù)授予易受攻擊服務(wù)器的權(quán)限，攻擊者可能能夠讀取敏感文件、進行內(nèi)部API調(diào)用以及訪問隱藏管理面板等內(nèi)部服務(wù)。防止SSRF漏洞的最簡單方法是永遠(yuǎn)不要根據(jù)用戶輸入發(fā)出出站請求。但是，如果確實需要根據(jù)用戶輸入發(fā)出出站請求，則需要在發(fā)起請求之前驗證這些地址。  

（27）信任邊界違規(guī)  

“信任邊界”是指不受信任的用戶輸入進入受控環(huán)境的位置。例如，一個HTTP請求在被服務(wù)器驗證之前被認(rèn)為是不可信的輸入。  

用戶存儲、傳輸和處理可信和不可信輸入的方式應(yīng)該有明顯的區(qū)別。當(dāng)不尊重這種區(qū)別并且信任和不信任的數(shù)據(jù)相互混淆時，就會發(fā)生信任邊界違規(guī)。例如，如果受信任和不受信任的數(shù)據(jù)存儲在同一個數(shù)據(jù)結(jié)構(gòu)或數(shù)據(jù)庫中，應(yīng)用程序可能將這二者混淆。在這種情況下，不受信任的數(shù)據(jù)可能會被錯誤地視為已驗證。  

防止信任邊界違規(guī)的一個很好方法是在驗證之前永遠(yuǎn)不要將不受信任的輸入寫入會話存儲。

原文標(biāo)題：Go Application Vulnerability Cheatsheet，作者：Vickie Li

鏈接：https://dzone.com/articles/go-applications-vulnerability-cheatsheet