Go应用程序中需要注意的27个漏洞，包括任意文件写入、目录遍历、反序列化等。保护应用程序的安全并不是最简单的事情。而一个应用程序有很多组件：服务器端逻辑、客户端逻辑、数据存储、数据传输、API等等。为了保证所有这些组件的安全，构建一个安全的应用程序看起来确实令人生畏。值得庆幸的是，大多数现实生活中的错误都有相同的根源。通过研究这些常见类型的漏洞、它们发生的原因以及如何发现它们，您可以学习如何预防和保护您的应用程序。每种语言、框架或环境的使用都会使应用程序面临一组独特的漏洞。修复应用程序漏洞的第一步是了解要查找的内容。这里有27个影响Go应用程序的最常见漏洞，以及如何找到防止它们的方法。企业需要致力于保护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)邮件注入许多网络应用程序根据用户的操作向用户发送电子邮件。例如，当订阅新闻媒体上的提要时，站点可能会向用户发送包含提要名称的确认消息。当应用程序使用用户输入来确定将电子邮件发送到哪些地址或电子邮件中包含哪些内容时，就会发生邮件注入。这可能允许垃圾邮件发送者使用他们的服务器向用户发送大量电子邮件，或者诈骗者使用他们的电子邮件地址进行社会工程活动。(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)HeaderInjectionHeaderinjection当HTTP响应头是从不受信任的输入中动态构建的时，就会发生头注入。根据受漏洞影响的响应标头，标头注入可能导致跨站点脚本、开放重定向和会话固定。例如，如果标头可以由URL参数控制，则攻击者可以通过在参数中指定他们的恶意站点来导致开放重定向。攻击者甚至可以在受害者的浏览器上执行恶意脚本，或者通过标头注入向受害者发送完全受控的HTTP响应来强制受害者下载恶意软件。可以通过避免将用户输入写入响应标头、从用户输入中去除换行符（换行符用于创建新的HTTP响应标头）以及使用允许列表来验证标头值来防止标头注入。(13)Session注入和不安全的cookieSession注入是header注入的一种。如果攻击者可以操纵他们的会话cookie的内容，或者窃取其他人的cookie，他们就可以欺骗应用程序。攻击者可以通过三种主要方式访问其他人的会话：会话劫持、会话篡改和会话欺骗。会话劫持是指攻击者窃取他人的会话cookie并将其据为己有。攻击者经常通过XSS或MITM（中间人）攻击窃取会话cookie。会话篡改是指攻击者可以更改其会话cookie以更改服务器解释其身份的方式。当在cookie中传递会话状态并且cookie未正确签名或加密时，会发生这种情况。最后，攻击者可以在会话ID可预测时欺骗会话。如果是这种情况，攻击者可以伪造一个有效的会话cookie并以其他人的身份登录。防止这些会话管理陷阱需要多层防御。(14)主机标头中毒Web服务器经常在同一个IP地址上托管多个不同的网站。HTTP请求到达某个IP地址后，服务器将请求转发到主机头中指定的主机。尽管主机标头通常由用户的浏览器设置，但它仍然是用户提供的输入，不应被信任。如果Web应用程序在使用主机头构造地址之前不验证主机头，攻击者可以通过主机头发起一系列攻击，例如XSS、服务器端请求伪造(SSRF)和Web缓存中毒攻击。例如，如果应用程序使用主机标头来确定脚本的位置，则攻击者可以提交恶意主机标头以导致应用程序执行恶意脚本：Go1scriptURL:=fmt.Sprintf("https://%s/script.js",2request.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)Cross-siterequestforgeryCross-siterequestforgery(CSRF)是一种客户端技术，用于攻击Web应用程序的其他用户。使用跨站点请求伪造(CSRF)，攻击者可以发送假装来自受害者的HTTP请求，代表受害者执行不需要的操作。例如，攻击者可以在未经许可的情况下更改密码或将钱转入银行账户。与开放重定向不同，有一种万无一失的方法可以防止CSRF：将CSRF令牌与SameSitecookie结合起来，并避免使用GET请求进行状态更改操作。(26)服务器端请求伪造服务器端请求伪造(SSRF)或服务器端请求伪造是当攻击者能够代表服务器发送请求时发生的漏洞。它允许攻击者从易受攻击的服务器“伪造”请求签名，从而占据网络上的特权位置，绕过防火墙控制并获得对内部服务的访问权限。根据授予易受攻击服务器的权限，攻击者可能能够读取敏感文件、进行内部API调用以及访问内部服务，例如隐藏的管理面板。防止SSRF漏洞的最简单方法是永远不要根据用户输入发出出站请求。但是，如果您确实需要根据用户输入发出出站请求，则需要在发出请求之前验证这些地址。(27)违反信任边界“信任边界”是不受信任的用户输入进入受控环境的点。例如，HTTP请求在被服务器验证之前被认为是不受信任的输入。用户存储、传输和处理可信和不可信输入的方式应该有明确的区别。当不尊重这种区别并且将可信和不可信数据相互混淆时，就会发生信任边界违规。例如，如果受信任和不受信任的数据存储在相同的数据结构或数据库中，则应用程序可能会混淆这两者。在这种情况下，不受信任的数据可能会被错误地认为是经过身份验证的。防止违反信任边界的一个好方法是永远不要在验证之前将不受信任的输入写入会话存储。原标题：GoApplicationVulnerabilityCheatsheet，作者：VickieLi链接：https://dzone.com/articles/go-applications-vulnerability-cheatsheet
