github.com/beego/beego known bugs

An issue was discovered in file profile.go. The MemProf and GetCPUProfile functions do not correctly check whether the created file exists. As a result attackers can launch attacks symlink attacks locally. Attackers can use this vulnerability to escalate privileges.

beego is an open-source, high-performance web framework for the Go programming language. An issue was discovered in file profile.go in function GetCPUProfile in beego through 2.0.2, allows attackers to launch symlink attacks locally.

An issue was discovered in the route lookup process in beego through 2.0.1, allows attackers to bypass access control.

Beego allows Reflected/Stored XSS in Beego's RenderForm() Function Due to Unescaped User Input in github.com/beego/beego

Beego has Collision Hazards of MD5 in Cache Key Filenames in github.com/beego/beego

An issue was discovered in the route lookup process in beego which attackers to bypass access control.

The leafInfo.match() function uses path.join() to deal with wildcard values which can lead to cross directory risk.

Routes in the beego HTTP router can match unintended patterns. This overly-broad matching may permit an attacker to bypass access controls. For example, the pattern "/a/b/:name" can match the URL "/a.xml/b/". This may bypass access control applied to the prefix "/a/".

The File Session Manager in Beego before 1.12.2 allows local users to read session files because of weak permissions for individual files.

The File Session Manager in Beego 1.10.0 allows local users to read session files because there is a race condition involving file creation within a directory with weak permissions.

In the context of using MD5 to generate filenames for cache keys, there are significant collision hazards that need to be considered. MD5, or Message Digest Algorithm 5, is a widely known cryptographic hash function that produces a 128-bit hash value. However, MD5 is no longer considered secure against well-funded opponents due to its vulnerability to collision attacks. ### Understanding Collisions A collision in hashing occurs when two different inputs produce the same hash output. For MD5, this means that it is theoretically possible, and even practical, to find two distinct cache keys that result in the same MD5 hash. This vulnerability has been well-documented and exploited in various security contexts. ### Implications for Cache Systems In a cache system where filenames are derived from the MD5 hash of cache keys, a collision could lead to several critical issues: Data Integrity Risks: If two different keys collide, they will map to the same filename. This could result in data being overwritten incorrectly, leading to data loss or corruption. Security Vulnerabilities: An attacker could potentially exploit collisions to manipulate cache data. For instance, by crafting a key that collides with another key, an attacker might gain unauthorized access to sensitive cached information or inject malicious data. Unpredictable Behavior: Collisions can cause the cache system to behave unpredictably, as it may retrieve or store data in unintended files, leading to system instability or incorrect behavior. ### Mitigation Strategies To mitigate these risks, consider the following strategies: Use a More Secure Hash Function: Replace MD5 with a more secure hash function like SHA-256, which has a significantly lower probability of collisions and is resistant to known attack vectors. code at:https://github.com/beego/beego/blob/bb72dc27ac3970e51d38ee52fc3dc1465ae25b9d/client/cache/file.go#L126

The route lookup process in beego prior to 1.12.9 and 2.x prior to 2.0.3 allows attackers to bypass access control. When a /`p1`/`p2`/`:name` route is configured, attackers can access it by appending .xml in various places (e.g., p1.xml instead of p1).

The `leafInfo.match()` function in Beego v2.0.3 and below uses `path.join()` to deal with wildcardvalues which can lead to cross directory risk.

### Summary A Cross-Site Scripting (XSS) vulnerability exists in Beego's `RenderForm()` function due to improper HTML escaping of user-controlled data. This vulnerability allows attackers to inject malicious JavaScript code that executes in victims' browsers, potentially leading to session hijacking, credential theft, or account takeover. The vulnerability affects any application using Beego's `RenderForm()` function with user-provided data. Since it is a high-level function generating an entire form markup, many developers would assume it automatically escapes attributes (the way most frameworks do). ### Details The vulnerability is located in the `renderFormField()` function in Beego's `templatefunc.go` file (around lines 316-356). This function directly injects user-provided values into HTML without proper escaping: ```go return fmt.Sprintf(`%v<input%v%v name="%v" type="%v" value="%v"%v>`, label, id, class, name, fType, value, requiredString) ``` None of the values (label, id, class, name, value) are properly HTML-escaped before being inserted into the HTML template. This allows attackers to break out of the attribute context or inject HTML tags directly. The vulnerability can be exploited in two main ways: - Attribute Injection: By injecting code into fields like DisplayName, an attacker can break out of the attribute context and execute JavaScript. - Content Injection: By injecting HTML tags into textarea content, an attacker can execute JavaScript. The `RenderForm()` function returns `template.HTML`, which bypasses Go's automatic HTML escaping, making this vulnerability particularly dangerous. ### PoC Retrieve the following (secret) gist: https://gist.github.com/thevilledev/8fd0cab3f098320aa9daab04be59fd2b To run it: ```go go mod init beego-xss-poc go mod tidy go run poc.go ``` Open your browser and navigate to http://localhost:8080/ The application demonstrates the vulnerability through several examples: - `/profile` - Shows a profile with malicious data in the Display Name and Bio fields - `/admin` - Shows multiple user profiles, including one with malicious data - `/submit` - Allows you to create your own profile with malicious data In addition, you may use this Go test in `templatefunc_test.go`. The test passes, validating the vulnerability. ```go func TestRenderFormXSSVulnerability(t *testing.T) { type UserProfile struct { DisplayName string `form:"displayName,text,Name:"` Bio string `form:",textarea"` } // Test case 1: Attribute injection in input field maliciousUser := UserProfile{ DisplayName: `" onmouseover="alert('XSS')" data-malicious="`, Bio: "Normal bio text", } output := RenderForm(&maliciousUser) // The vulnerable output would contain the unescaped JavaScript if !strings.Contains(string(output), `onmouseover="alert('XSS')"`) { t.Errorf("Expected XSS vulnerability in attribute, but got safe output: %v", output) } // Test case 2: Script injection in textarea maliciousUser2 := UserProfile{ DisplayName: "Normal Name", Bio: `</textarea><script>alert('XSS')</script><textarea>`, } output = RenderForm(&maliciousUser2) // The vulnerable output would contain the unescaped script tag if !strings.Contains(string(output), `</textarea><script>alert('XSS')`) { t.Errorf("Expected XSS vulnerability in textarea content, but got safe output: %v", output) } } ``` ### Impact This is a high-severity vulnerability with the following impacts: - Cross-Site Scripting (XSS): Allows execution of arbitrary JavaScript in the context of the victim's browser. - Session Hijacking: Attackers can steal session cookies and impersonate victims. - Credential Theft: Attackers can create fake login forms to steal credentials. - Account Takeover: Attackers can perform actions on behalf of the victim. - Data Exfiltration: Sensitive data visible in the browser can be stolen. This is particularly concerning in admin panels or user management interfaces where one user's data is displayed to another user (typically an administrator). ### Mitigation The vulnerability can be fixed by properly escaping all user-provided values before inserting them into HTML, for example: ```go // Convert value to string and escape it valueStr := "" if value != nil { valueStr = template.HTMLEscapeString(fmt.Sprintf("%v", value)) } // Escape the name and label escapedName := template.HTMLEscapeString(name) escapedLabel := template.HTMLEscapeString(label) escapedType := template.HTMLEscapeString(fType) return fmt.Sprintf(`%v<input%v%v name="%v" type="%v" value="%v"%v>`, escapedLabel, id, class, escapedName, escapedType, valueStr, requiredString) ```