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

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

值得慶幸的是，大多數現實生活中的漏洞都有相同的根源。通過研究這些常見的漏洞類型、發生的原因以及如何發現它，可以學會預防，并保護應用程序。

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

企業需要致力于保護Go應用程序。以下是需要關注的27個漏洞：  

（1）XML外部實體攻擊  

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

（2）不安全的反序列化  

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

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

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

（3）遠程代碼執行  

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

在Go中，開發人員經常使用net/rpc或grpc等數據包來允許通過網絡遠程調用方法。在這種情況下，確保任何過程調用來自受信任的來源非常重要。  

（4）注入  

當應用程序無法正確區分不受信任的用戶數據和代碼時，就會發生注入問題。例如以上所說的例子，通過代碼注入的RCE就是一種注入漏洞。但注入漏洞也以其他方式表現出來。  

（5）SQL注入  

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

SQL注入能夠讓攻擊者代碼更改應用程序SQL查詢的結構，以竊取數據、修改數據或可能在底層操作系統中執行任意命令。防止SQL注入的最好方法是使用參數化語句，這使得SQL注入幾乎不可能。  

（6）NoSQL注入  

數據庫并不總是使用SQL。NoSQL數據庫或NotOnlySQL數據庫是不使用SQL語言的數據庫。NoSQL注入是指將數據注入到這些數據庫語言的邏輯中的攻擊。NoSQL注入可能與SQL注入一樣嚴重：它們可能導致身份驗證繞過和遠程代碼執行。  

（7）日志注入  

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

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

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

（8）郵件注入  

許多Web應用程序會根據用戶的操作向用戶發送電子郵件。例如，如果訂閱了新聞媒體上的提要，該網站可能會向用戶發送包含提要名稱的確認信息。  

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

（9）模板注入  

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

模板注入是指注入到網頁模板中。根據受感染的應用程序的權限，攻擊者可能能夠使用模板注入漏洞來讀取敏感文件、執行代碼或提升他們在系統上的權限。  

（10）正則表達式注入  

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

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

（11）XPath注入  

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

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

（12）標頭注入  

當HTTP響應標頭是從不受信任的輸入動態構建時，就會發生標頭注入。根據漏洞影響的響應標頭，標頭注入可能導致跨站點腳本、開放重定向和會話固定。  

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

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

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

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

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

（14）主機標頭中毒

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

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

Go

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

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

（15）敏感數據泄露  

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

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

（16）身份驗證繞過  

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

（17）訪問控制不當  

身份驗證繞過問題本質上是不正確的訪問控制。當應用程序中的訪問控制實施不當并且可以被攻擊者繞過時，任何時候都會發生不當的訪問控制。然而，訪問控制不僅僅包括身份驗證。雖然身份驗證要求用戶證明他們的身份：“你是誰？”，但授權要求應用程序“允許此用戶做什么？”。適當的身份驗證和授權共同確保用戶無法訪問超出其權限的功能。  

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

（18）目錄遍歷  

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

攻擊者通常可以使用目錄遍歷來訪問敏感文件，如配置文件、日志文件和源代碼。為了防止目錄遍歷，應該驗證插入到文件路徑中的用戶輸入，或者避免直接引用文件名并改用間接標識符。  

（19）任意文件寫入  

任意文件寫入漏洞的工作方式與目錄遍歷類似。如果應用程序將文件寫入底層機器，并通過用戶輸入確定輸出文件名，則攻擊者可能能夠在他們想要的任何路徑上創建任意文件或覆蓋現有系統文件。攻擊者可能能夠更改密碼文件或日志文件等關鍵系統文件，或將他們自己的可執行文件添加到腳本目錄中。  

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

（20）拒絕服務攻擊  

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

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

（21）加密漏洞  

加密問題可能是應用程序中可能發生的最嚴重的漏洞之一。加密漏洞是指未正確實施加密和散列。這可能導致廣泛的數據泄漏和通過會話欺騙繞過身份驗證。

開發人員在網站上實施加密時常犯的一些錯誤是：  

?使用弱算法。

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

?創建自定義算法。  

?生成弱隨機數。  

?將編碼誤認為加密。  

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

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

（23）批量分配  

“批量賦值”是指一次為多個變量或對象屬性賦值的做法。當應用程序自動將用戶輸入分配給多個程序變量或對象時，就會出現批量分配漏洞。這是許多旨在簡化應用程序開發的應用程序框架中的一個功能。  

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

（24）打開重定向  

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

在開放式重定向攻擊期間，攻擊者誘騙用戶訪問通過向他們提供來自合法站點的URL來訪問外部站點重定向到其他地方。這可以讓用戶相信他們仍然在原始網站上，并幫助詐騙者構建更可信的網絡釣魚活動。  

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

 （25）跨站請求偽造  

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

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

（26）服務器端請求偽造  

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

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

（27）信任邊界違規  

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

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

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

原文標題：Go Application Vulnerability Cheatsheet，作者：Vickie Li

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