Using unsanitized untrusted data in an external API can cause a variety of security issues. This query reports +all external APIs that are used with untrusted data, along with how frequently the API is used, and how many +unique sources of untrusted data flow to this API. This query is designed primarily to help identify which APIs +may be relevant for security analysis of this application.
+ +An external API is defined as a call to a function that is not defined in the source code and is not
+modeled as a taint step in the default taint library. Calls made in test files are excluded.
+External APIs may be from the Go standard library, third party dependencies, or from internal dependencies.
+The query will report the fully-qualified method name, along with either [param x],
+where x indicates the position of the parameter receiving the untrusted data, or [receiver]
+indicating that the untrusted data is used as the receiver of the method call.
For each result:
+ +Otherwise, the result is likely uninteresting. Custom versions of this query can extend the SafeExternalAPIMethod
+class to exclude known safe external APIs from future analysis.
If the query were to return the API fmt.Fprintf [param 2] then we should first consider
+whether this a security relevant sink. In this case, this is writing to an HTTP response, so we should
+consider whether this is an XSS sink. If it is, we should confirm that it is handled by the "Reflected cross-site scripting" query (go/reflected-xss).
If the query were to return the API fmt.Sprintf [param 1], then this should be
+reviewed as a possible taint step, because tainted data would flow from the first argument to the return value
+of the call.
Note that both examples are correctly handled by the standard taint tracking library and the "Reflected cross-site scripting" query (go/reflected-xss).
+Sanitizing untrusted URLs is an important technique for preventing attacks such as request +forgeries and malicious redirections. Often, this is done by checking that the host of a URL +is in a set of allowed hosts. +
+
+If a regular expression implements such a check, it is easy to accidentally make the check too
+permissive by not escaping regular-expression meta-characters such as ..
+
+Even if the check is not used in a security-critical context, the incomplete check may still cause +undesirable behavior when it accidentally succeeds. +
+
+Escape all meta-characters appropriately when constructing regular expressions for security checks,
+paying special attention to the . meta-character.
+
+The following example code checks that a URL redirection will reach the example.com
+domain, or one of its subdomains.
+
+The check is however easy to bypass because the unescaped . allows for any character
+before example.com, effectively allowing the redirect to go to an attacker-controlled
+domain such as wwwXexample.com.
+
+Address this vulnerability by escaping . appropriately:
+
+URLs with the special scheme javascript can be used to encode JavaScript code to be
+executed when the URL is visited. While this is a powerful mechanism for creating feature-rich and
+responsive web applications, it is also a potential security risk: if the URL comes from an
+untrusted source, it might contain harmful JavaScript code. For this reason, many frameworks and
+libraries first check the URL scheme of any untrusted URL, and reject URLs with the
+javascript scheme.
+
+However, the data and vbscript schemes can be used to represent
+executable code in a very similar way, so any validation logic that checks against
+javascript, but not against data and vbscript, is likely
+to be insufficient.
+
+Add checks covering both data: and vbscript:.
+
+The following function validates a (presumably untrusted) URL urlstr. If its scheme is
+javascript, the harmless placeholder URL about:blank is returned to
+prevent code injection; otherwise urlstr itself is returned.
+
+While this check provides partial projection, it should be extended to cover data
+and vbscript as well:
+
+Sanitizing untrusted input with regular expressions is a common technique. However, it is
+error-prone to match untrusted input against regular expressions without anchors such as
+^ or $. Malicious input can bypass such security checks by embedding
+one of the allowed patterns in an unexpected location.
+
+Even if the matching is not done in a security-critical context, it may still cause undesirable +behavior when the regular expression accidentally matches. +
++Use anchors to ensure that regular expressions match at the expected locations. +
+
+The following example code checks that a URL redirection will reach the example.com
+domain, or one of its subdomains, and not some malicious site.
+
+The check with the regular expression match is, however, easy to bypass. For example, the string
+http://example.com/ can be embedded in the query string component:
+http://evil-example.net/?x=http://example.com/.
+
+Address these shortcomings by using anchors in the regular expression instead: +
+
+A related mistake is to write a regular expression with multiple alternatives, but to only anchor
+one of the alternatives. As an example, the regular expression
+^www\.example\.com|beta\.example\.com will match the host
+evil.beta.example.com because the regular expression is parsed as
+(^www\.example\.com)|(beta\.example\.com)/, so the second alternative
+beta\.example\.com is not anchored at the beginning of the string.
+
+
+ When a character in a string literal or regular expression
+ literal is preceded by a backslash, it is interpreted as part of an
+ escape sequence. For example, the escape sequence \n in a
+ string literal corresponds to a single newline character,
+ and not the \ and n characters.
+
+ There are two Go escape sequences that could produce surprising results.
+ First, regexp.Compile("\a") matches the bell character, whereas
+ regexp.Compile("\\A") matches the start of text and
+ regexp.Compile("\\a") is a Vim (but not Go) regular expression
+ matching any alphabetic character. Second, regexp.Compile("\b")
+ matches a backspace, whereas regexp.Compile("\\b") matches the
+ start of a word. Confusing one for the other could lead to a regular expression
+ passing or failing much more often than expected, with potential security
+ consequences.
+
+ Note this is less of a problem than in some other languages because in Go,
+ only valid escape sequences are accepted, both in an ordinary string
+ (for example, s := "\k" will not compile as there is no such
+ escape sequence) and in regular expressions (for example,
+ regexp.MustCompile("\\k") will panic as \k does not
+ refer to a character class or other special token according to Go's regular
+ expression grammar).
+
+
+ + Ensure that the right number of backslashes is used when + escaping characters in strings and regular + expressions. + +
+The following example code fails to check for a forbidden word in an input string:
+The check does not work, but can be fixed by escaping the backslash:
+
+ Alternatively, you can use backtick-delimited raw string literals.
+ For example, the \b in regexp.Compile(`hello\bworld`)
+ matches a word boundary, not a backspace character, as within backticks \b is not an
+ escape sequence.
+
Using unsanitized untrusted data in an external API can cause a variety of security issues. This query reports +external APIs that use untrusted data. The results have very little filtering so that you can audit almost all +examples. The query provides data for security reviews of the application. It can also be used to identify +external APIs that should be modeled as either taint steps, or sinks for specific problems.
+ +An external API is defined as a call to a function that is not defined in the source code and is not +modeled as a taint step in the default taint library. Calls made in test files are excluded. +External APIs may be from the Go standard library, third-party dependencies, or from internal dependencies. +The query reports uses of untrusted data in either the receiver or as one of the arguments of external APIs.
+ +For each result:
+ +Otherwise, the result is likely uninteresting. Custom versions of this query can extend the SafeExternalAPIMethod
+class to exclude known safe external APIs from future analysis.
In this first example, a request parameter is read from http.Request and then ultimately used in a call to the
+fmt.Fprintf external API:
This is an XSS sink. The "Reflected cross-site scripting" query (go/reflected-xss) should therefore be reviewed to confirm that this sink is appropriately modeled,
+and if it is, to confirm that the query reports this particular result, or that the result is a false positive due to
+some existing sanitization.
In this second example, again a request parameter is read from http.Request.
If the query reported the call to fmt.Sprintf, this would suggest that this external API is not currently
+modeled as a taint step in the taint tracking library. The next step would be to model this as a taint step, then
+re-run the query to determine what additional results might be found. In this example, an SQL injection vulnerability
+would be reported.
Note that both examples are correctly handled by the standard taint tracking library,
+the "Reflected cross-site scripting" query (go/reflected-xss),
+and the "Database query built from user-controlled sources" query (go/sql-injection).
Using unsanitized untrusted data in an external API can cause a variety of security issues. This query reports +external APIs that use untrusted data. The results have been filtered to only report unknown external APIs. The query provides data for security +reviews of the application. It can also be used to identify external APIs that should be modeled as either +taint steps, or sinks for specific problems.
+ +An external API is defined as a call to a function that is not defined in the source code and is not +modeled as a taint step in the default taint library. Calls made in test files are excluded. +External APIs may be from the Go standard library, third-party dependencies, or from internal dependencies. +The query reports uses of untrusted data in either the receiver or as one of the arguments of external APIs.
+ +An external API is considered unknown if it is not in a package which has already been modeled, it is not +a sink for an existing query, and it is not in a list of external APIs which have been examined and determined +to not be a possible source of security vulnerabilities.
+For each result:
+ +Otherwise, the result is likely uninteresting. Custom versions of this query can extend the SafeExternalAPIMethod
+class to exclude known safe external APIs from future analysis.
In this first example, a request parameter is read from http.Request and then ultimately used in a call to the
+fmt.Fprintf external API:
This is an XSS sink. The "Reflected cross-site scripting" query (go/reflected-xss) should therefore be reviewed to confirm that this sink is appropriately modeled,
+and if it is, to confirm that the query reports this particular result, or that the result is a false positive due to
+some existing sanitization.
In this second example, again a request parameter is read from http.Request.
If the query reported the call to fmt.Sprintf, this would suggest that this external API is not currently
+modeled as a taint step in the taint tracking library. The next step would be to model this as a taint step, then
+re-run the query to determine what additional results might be found. In this example, an SQL injection vulnerability
+would be reported.
Note that both examples are correctly handled by the standard taint tracking library,
+the "Reflected cross-site scripting" query (go/reflected-xss),
+and the "Database query built from user-controlled sources" query (go/sql-injection).
+Accessing files using paths constructed from user-controlled data can allow an attacker to access +unexpected resources. This can result in sensitive information being revealed or deleted, or an +attacker being able to influence behavior by modifying unexpected files. +
++Validate user input before using it to construct a file path, either using an off-the-shelf library +or by performing custom validation. +
++Ideally, follow these rules: +
++In the first example, a file name is read from an HTTP request and then used to access a file. +However, a malicious user could enter a file name which is an absolute path, such as +"/etc/passwd". +
+
+In the second example, it appears that the user is restricted to opening a file within the
+"user" home directory. However, a malicious user could enter a file name containing
+special characters. For example, the string "../../etc/passwd" will result in the code
+reading the file located at "/home/user/../../etc/passwd", which is the system's
+password file. This file would then be sent back to the user, giving them access to password
+information.
+
+Extracting symbolic links from a malicious zip archive, without validating that the destination file path
+is within the destination directory, can cause files outside the destination directory to be overwritten.
+This can happen if there are previously-extracted symbolic links or
+directory traversal elements and links (..) in archive paths.
+
+This problem is related to the ZipSlip vulnerability which is detected by the go/zipslip query;
+please see that query's help for more general information about malicious archive file vulnerabilities.
+This query considers the specific case where symbolic links are extracted from an archive, in which case
+the extraction code must be aware of existing symbolic links when checking whether it is about to extract
+a link pointing to a location outside the target extraction directory.
+
+Ensure that output paths constructed from zip archive entries are validated. This includes resolving any
+previously extracted symbolic links, for example using path/filepath.EvalSymlinks, to prevent writing
+files or links to unexpected locations.
+
+In this example, links are extracted from an archive using the syntactic filepath.Rel
+function to check whether the link and its target fall within the destination directory.
+However, the extraction code doesn't resolve previously-extracted links, so a pair of links like
+subdir/parent -> .. followed by escape -> subdir/parent/.. -> subdir/../..
+leaves a link pointing to the parent of the archive root. The syntactic Rel is ineffective
+because it equates subdir/parent/.. with subdir/, but this is not the case
+when subdir/parent is a symbolic link.
+
To fix this vulnerability, resolve pre-existing symbolic links before checking +that the link's target is acceptable: +
++Extracting files from a malicious zip file, or similar type of archive, +is at risk of directory traversal attacks if filenames from the archive are +not properly validated. +archive paths. +
+ +
+Zip archives contain archive entries representing each file in the archive. These entries
+include a file path for the entry, but these file paths are not restricted and may contain
+unexpected special elements such as the directory traversal element (..). If these
+file paths are used to create a filesystem path, then a file operation may happen in an
+unexpected location. This can result in sensitive information being
+revealed or deleted, or an attacker being able to influence behavior by modifying unexpected
+files.
+
+For example, if a zip file contains a file entry ..\sneaky-file, and the zip file
+is extracted to the directory c:\output, then naively combining the paths would result
+in an output file path of c:\output\..\sneaky-file, which would cause the file to be
+written to c:\sneaky-file.
+
+Ensure that output paths constructed from zip archive entries are validated +to prevent writing files to unexpected locations. +
+ +
+The recommended way of writing an output file from a zip archive entry is to check that
+".." does not occur in the path.
+
+In this example an archive is extracted without validating file paths.
+If archive.zip contained relative paths (for
+instance, if it were created by something like zip archive.zip
+../file.txt) then executing this code could write to locations
+outside the destination directory.
+
To fix this vulnerability, we need to check that the path does not
+contain any ".." elements in it.
+
+If a system command invocation is built from user-provided data without sufficient sanitization, +a malicious user may be able to run commands to exfiltrate data or compromise the system. +
++If possible, use hard-coded string literals to specify the command to run. Instead of interpreting +user input directly as command names, examine the input and then choose among hard-coded string +literals. +
++If this is not possible, then add sanitization code to verify that the user input is safe before +using it. +
+
+In the following example, assume the function handler is an HTTP request handler in a
+web application, whose parameter req contains the request object:
+
+The handler extracts the name of a system command from the request object, and then runs it without +any further checks, which can cause a command-injection vulnerability. +
++If a system command invocation is built from stored data without sufficient sanitization, and that +data is stored from a user input, a malicious user may be able to run commands to exfiltrate data or +compromise the system. +
++If possible, use hard-coded string literals to specify the command to run. Instead of interpreting +stored input directly as command names, examine the input and then choose among hard-coded string +literals. +
++If this is not possible, then add sanitization code to verify that the user input is safe before +using it. +
+
+In the following example, the function run runs a command directly from the result of a
+query:
+
+The function extracts the name of a system command from the database query, and then runs it without +any further checks, which can cause a command-injection vulnerability. A possible solution is to +ensure that commands are checked against a allow list: +
++Directly writing user input (for example, an HTTP request parameter) to an HTTP response +without properly sanitizing the input first, allows for a cross-site scripting vulnerability. +
++This kind of vulnerability is also called reflected cross-site scripting, to distinguish +it from other types of cross-site scripting. +
++To guard against cross-site scripting, consider using contextual output encoding/escaping before +writing user input to the response, or one of the other solutions that are mentioned in the +references. +
++The following example code writes part of an HTTP request (which is controlled by the user) +directly to the response. This leaves the website vulnerable to cross-site scripting. +
++Sanitizing the user-controlled data prevents the vulnerability: +
++ + Directly using externally-controlled stored values (for example, file names or database contents) to + create HTML content without properly sanitizing the input first, + allows for a cross-site scripting vulnerability. + +
++ + This kind of vulnerability is also called stored cross-site + scripting, to distinguish it from other types of cross-site scripting. + +
++ + To guard against cross-site scripting, consider using contextual + output encoding/escaping before using uncontrolled stored values to + create HTML content, or one of the other solutions that are mentioned + in the references. + +
++ + The following example code writes file names directly to an HTTP + response. This leaves the website vulnerable to cross-site scripting, + if an attacker can choose the file names on the disk. + +
++ Sanitizing the file names prevents the vulnerability: +
++If a database query (such as an SQL or NoSQL query) is built from user-provided data without +sufficient sanitization, a malicious user may be able to run commands that exfiltrate, tamper with, +or destroy data stored in the database. +
++Most database connector libraries offer a way of safely embedding untrusted data into a query by +means of query parameters or prepared statements. Use these features rather than building queries +by string concatenation. +
+
+In the following example, assume the function handler is an HTTP request handler in a
+web application, whose parameter req contains the request object:
+
+The handler constructs an SQL query involving user input taken from the request object unsafely
+using fmt.Sprintf to embed a request parameter directly into the query string
+q. The parameter may include quote characters, allowing a malicious user to terminate
+the string literal into which the parameter is embedded and add arbitrary SQL code after it.
+
+Instead, the untrusted query parameter should be safely embedded using placeholder parameters: +
++Code that constructs a string containing a quoted substring needs to ensure that any user-provided +data embedded in between the quotes does not itself contain a quote. Otherwise the embedded data +could (accidentally or intentionally) change the structure of the overall string by terminating +the quoted substring early, with potentially severe consequences. If, for example, the string is +later interpreted as an operating-system command or database query, a malicious attacker may be +able to craft input data that enables a command injection or SQL injection attack. +
++Sanitize the embedded data appropriately to ensure quotes are escaped, or use an API that does +not rely on manually constructing quoted substrings. +
+
+In the following example, assume that version is an object from an untrusted source.
+The code snippet first uses json.Marshal to serialize this object into a string, and
+then embeds it into a SQL query built using the Squirrel library.
+
+Note that while Squirrel provides a structured API for building SQL queries that mitigates against
+common causes of SQL injection vulnerabilities, this code is still vulnerable: if the JSON-encoded
+representation of version contains a single quote, this will prematurely close the
+surrounding string, changing the structure of the SQL expression being constructed. This could be
+exploited to mount a SQL injection attack.
+
+To fix this vulnerability, use Squirrel's placeholder syntax, which avoids the need to explicitly +construct a quoted string. +
+If unsanitized user input is written to a log entry, a malicious user may +be able to forge new log entries.
+ +Forgery can occur if a user provides some input with characters that are interpreted +when the log output is displayed. If the log is displayed as a plain text file, then new +line characters can be used by a malicious user. If the log is displayed as HTML, then +arbitrary HTML may be included to spoof log entries.
++User input should be suitably encoded before it is logged. +
+
+If the log entries are plain text then line breaks should be removed from user input, using
+strings.Replace or similar. Care should also be taken that user input is clearly marked
+in log entries, and that a malicious user cannot cause confusion in other ways.
+
+For log entries that will be displayed in HTML, user input should be HTML encoded using
+html.EscapeString or similar before being logged, to prevent forgery and
+other forms of HTML injection.
+
+In the following example, a user name, provided by the user, is logged using a logging framework without any sanitization. +
+
+In the next example, strings.Replace is used to ensure no line endings are present in the user input.
+
+Performing calculations involving the size of potentially large strings or slices can result in an +overflow (for signed integer types) or a wraparound (for unsigned types). An overflow causes the +result of the calculation to become negative, while a wraparound results in a small (positive) +number. +
++This can cause further issues. If, for example, the result is then used in an allocation, it will +cause a runtime panic if it is negative, and allocate an unexpectedly small buffer otherwise. +
++Always guard against overflow in arithmetic operations involving potentially large numbers by doing +one of the following: +
+uint64 instead of int), so that larger input
+values do not cause overflow.
+In the following example, assume that there is a function encryptBuffer that encrypts
+byte slices whose length must be padded to be a multiple of 16. The function
+encryptValue provides a convenience wrapper around this function: when passed an
+arbitrary value, it first encodes that value as JSON, pads the resulting byte slice, and then passes
+it to encryptBuffer.
+
+When passed a value whose JSON encoding is close to the maximum value of type int in
+length, the computation of size will overflow, producing a negative value. When that
+negative value is passed to make, a runtime panic will occur.
+
+To guard against this, the function should be improved to check the length of the JSON-encoded
+value. For example, here is a version of encryptValue that ensures the value is no
+larger than 64 MB, which fits comfortably within an int and avoids the overflow:
+
Software developers often add stack traces to error messages, as a +debugging aid. Whenever that error message occurs for an end user, the +developer can use the stack trace to help identify how to fix the +problem. In particular, stack traces can tell the developer more about +the sequence of events that led to a failure, as opposed to merely the +final state of the software when the error occurred.
+ +Unfortunately, the same information can be useful to an attacker. +The sequence of class names in a stack trace can reveal the structure +of the application as well as any internal components it relies on.
+Send the user a more generic error message that reveals less information. +Either suppress the stack trace entirely, or log it only on the server.
+In the following example, a panic is handled in two different +ways. In the first version, labeled BAD, a detailed stack trace is +written to a user-facing HTTP response object, which may disclose +sensitive information. In the second version, the error message is +logged only on the server. That way, the developers can still access +and use the error log, but remote users will not see the +information.
+ +
+The field InsecureSkipVerify controls whether a TLS client verifies the server's
+certificate chain and host name. If set to true, the client will accept any certificate
+and any host name in that certificate, making it susceptible to man-in-the-middle attacks.
+
+Do not set InsecureSkipVerify to true except in tests.
+
+The following code snippet shows a function that performs an HTTP request over TLS with +certificate verification disabled: +
++While this is acceptable in a test, it should not be used in production code. Instead, certificates +should be configured such that verification can be performed. +
++Sensitive information that is logged unencrypted is accessible to an attacker +who gains access to the logs. +
++Ensure that sensitive information is always encrypted or obfuscated before being +logged. +
+ ++In general, decrypt sensitive information only at the point where it is +necessary for it to be used in cleartext. +
+ ++Be aware that external processes often store the standard out and +standard error streams of the application, causing logged sensitive +information to be stored. +
++The following example code logs user credentials (in this case, their password) +in plain text: +
++Instead, the credentials should be encrypted, obfuscated, or omitted entirely: +
+
+ The ClientConfig specifying the configuration for establishing a SSH connection has a field HostKeyCallback that must be initialized with a function that validates the host key returned by the server.
+
+ Not properly verifying the host key returned by a server provides attackers with an opportunity to perform a Machine-in-the-Middle (MitM) attack. + A successful attack can compromise the confidentiality and integrity of the information communicated with the server. +
+ +
+ The ssh package provides the predefined callback InsecureIgnoreHostKey that can be used during development and testing.
+ It accepts any provided host key.
+ This callback, or a semantically similar callback, should not be used in production code.
+
+The HostKeyCallback field of ClientConfig should be initialized with a function that validates a host key against an allow list.
+If a key is not on a predefined allow list, the connection must be terminated and the failed security operation should be logged.
+
+When the allow list contains only a single host key then the function FixedHostKey can be used.
+
The following example shows the use of InsecureIgnoreHostKey and an insecure host key callback implementation commonly used in non-production code.
The next example shows a secure implementation using the FixedHostKey that implements an allow-list.
+ Incorrect uses of encryption algorithms may result in sensitive data exposure, + key leakage, broken authentication, insecure session, and spoofing attacks. +
+ ++ Ensure that you use a strong key with a recommended bit size. + For RSA encryption the minimum size is 2048 bits. +
+ ++ The following code uses RSA encryption with insufficient key size. +
+ ++ In the example below, the key size is set to 2048 bits. +
+ ++ The TLS (Transport Layer Security) protocol secures communications over the Internet. + The protocol allows client/server applications to communicate in a way that is designed + to prevent eavesdropping, tampering, or message forgery. +
++ The current latest version is 1.3 (with the 1.2 version still being considered secure). + Older versions are not deemed to be secure anymore because of various security vulnerabilities, + and tht makes them unfit for use in securing your applications. +
++ Unfortunately, many applications and websites still support deprecated SSL/TLS versions and + cipher suites. +
++ Only use secure TLS versions (1.3 and 1.2) and avoid using insecure cipher suites + (you can see a list here: https://golang.org/src/crypto/tls/cipher_suites.go#L81) +
++ The following example shows a few ways how an insecure TLS configuration can be created: +
++ The following example shows how to create a safer TLS configuration: +
++Using a cryptographically weak pseudo-random number generator to generate a security-sensitive value, +such as a password, makes it easier for an attacker to predict the value. +
++Pseudo-random number generators generate a sequence of numbers that only approximates the properties +of random numbers. The sequence is not truly random because it is completely determined by a +relatively small set of initial values, the seed. If the random number generator is +cryptographically weak, then this sequence may be easily predictable through outside observations. +
++Use a cryptographically secure pseudo-random number generator if the output is to be used in a +security sensitive context. As a rule of thumb, a value should be considered "security sensitive" +if predicting it would allow the attacker to perform an action that they would otherwise be unable +to perform. For example, if an attacker could predict the random password generated for a new user, +they would be able to log in as that new user. +
+
+For Go, crypto/rand provides a cryptographically secure pseudo-random
+number generator. math/rand is not cryptographically secure, and should be avoided in
+security contexts. For contexts which are not security sensitive, math/rand may be
+preferable as it has a more convenient interface, and is likely to be faster.
+
+The example below uses the math/rand package instead of crypto/rand to generate a password:
+
+Instead, use crypto/rand:
+
+ OAuth 2.0 clients must implement CSRF protection for the redirection URI, which is typically accomplished by including a "state" value that binds the request to + the user's authenticated state. The Go OAuth 2.0 library allows you to specify a "state" value which is then included in the auth code URL. That state is then provided back by the remote authentication server in the redirect callback, from where it must be validated. Failure to do so makes the client susceptible to an CSRF attack. +
+
+ Always include a unique, non-guessable state value (provided to the call to AuthCodeURL function) that is also bound to the user's authenticated state with each authentication request, and then validated in the redirect callback.
+
+ The first example shows you the use of a constant state (bad). +
++ The second example shows a better implementation idea. +
+
+Redirect URLs should be checked to ensure that user input cannot cause a site to redirect
+to arbitrary domains. This is often done with a check that the redirect URL begins with a slash,
+which most of the time is an absolute redirect on the same host. However, browsers interpret URLs
+beginning with // or /\ as absolute URLs. For example, a redirect to
+//example.com will redirect to https://example.com. Thus, redirect checks must
+also check the second character of redirect URLs.
+
+Also disallow redirect URLs starting with // or /\.
+
+The following function validates a (presumably untrusted) redirect URL redir. If it
+does not begin with /, the harmless placeholder redirect URL / is
+returned to prevent an open redirect; otherwise redir itself is returned.
+
+While this check provides partial protection, it should be extended to cover // and
+/\ as well:
+
+Directly incorporating user input into a URL redirect request without validating the input can +facilitate phishing attacks. In these attacks, unsuspecting users can be redirected to a malicious +site that looks very similar to the real site they intend to visit, but is controlled by the +attacker. +
++To guard against untrusted URL redirection, it is advisable to avoid putting user input directly into +a redirect URL. Instead, maintain a list of authorized redirects on the server; then choose from +that list based on the user input provided. +
++The following example shows an HTTP request parameter being used directly in a URL redirect without +validating the input, which facilitates phishing attacks: +
+ ++One way to remedy the problem is to validate the user input against a known fixed string +before doing the redirection: +
+ ++ Using untrusted input to construct an email can cause multiple security + vulnerabilities. For instance, inclusion of an untrusted input in an email body + may allow an attacker to conduct cross-site scripting (XSS) attacks, while + inclusion of an HTTP header may allow a full account compromise as shown in the + example below. +
++ Any data which is passed to an email subject or body must be sanitized before use. +
+
+ In the following example snippet, the host field is user controlled.
+
+ A malicious user can send an HTTP request to the targeted website, + but with a Host header that refers to their own website. This means the + emails will be sent out to potential victims, originating from a server + they trust, but with links leading to a malicious website. +
++ If the email contains a password reset link, and the victim clicks + the link, the secret reset token will be leaked to the attacker. Using the + leaked token, the attacker can then construct the real reset link and use it to + change the victim's password. +
++ One way to prevent this is to load the host name from a trusted configuration file instead. +
++If an XPath expression is built using string concatenation, and the components of the concatenation +include user input, a user is likely to be able to create a malicious XPath expression. +
++If user input must be included in an XPath expression, pre-compile the query and use variable +references to include the user input. +
+
+For example, when using the github.com/ChrisTrenkamp/goxpath API, you can do this by creating a function that takes an *goxpath.Opts structure.
+In this structure you can then set the values of the variable references.
+This function can then be specified when calling Exec(), Exec{Bool|Num|Node}(), ParseExec(), or MustExec().
+
+In the first example, the code accepts a username specified by the user, and uses this +unvalidated and unsanitized value in an XPath expression. This is vulnerable to the user providing +special characters or string sequences that change the meaning of the XPath expression to search +for different values. +
+ +
+In the second example, the XPath expression is a hard-coded string that specifies some variables,
+which are safely resolved at runtime using the goxpath.Opts structure.
+
+If a string is parsed into an int using strconv.Atoi, and subsequently that int
+is converted into another integer type of a smaller size, the result can produce unexpected values.
+
+This also applies to the results of strconv.ParseInt and strconv.ParseUint when
+the specified size is larger than the size of the type that number is converted to.
+
+If you need to parse integer values with specific bit sizes, avoid strconv.Atoi, and instead
+use strconv.ParseInt or strconv.ParseUint, which also allow specifying the
+bit size.
+
+When using those functions, be careful to not convert the result to another type with a smaller bit size than +the bit size you specified when parsing the number. +
+
+If this is not possible, then add upper (and lower) bound checks specific to each type and
+bit size (you can find the minimum and maximum value for each type in the math package).
+
+In the first example, assume that an input string is passed to parseAllocateBad1 function,
+parsed by strconv.Atoi, and then converted into an int32 type:
+
+The bounds are not checked, so this means that if the provided number is greater than the maximum value of type int32,
+the resulting value from the conversion will be different from the actual provided value.
+
+To avoid unexpected values, you should either use the other functions provided by the strconv
+package to parse the specific types and bit sizes as shown in the
+parseAllocateGood2 function; or check bounds as in the parseAllocateGood1
+function.
+
+In the second example, assume that an input string is passed to parseAllocateBad2 function,
+parsed by strconv.ParseInt with a bit size set to 64, and then converted into an int32 type:
+
+If the provided number is greater than the maximum value of type int32, the resulting value from the conversion will be
+different from the actual provided value.
+
+To avoid unexpected values, you should specify the correct bit size as in parseAllocateGood3;
+or check bounds before making the conversion as in parseAllocateGood4.
+
+ Including unencrypted hard-coded authentication credentials in source code is dangerous because + the credentials may be easily discovered. For example, the code may be open source, or it may + be leaked or accidentally revealed, making the credentials visible to an attacker. This, in turn, + might enable them to gain unauthorized access, or to obtain privileged information. +
++ Remove hard-coded credentials, such as user names, passwords and certificates, from source code. + Instead, place them in configuration files, environment variables or other data stores if necessary. + If possible, store configuration files including credential data separately from the source code, + in a secure location with restricted access. +
+
+ The following code example connects to a Postgres database using the lib/pq package
+ and hard-codes user name and password:
+
+ Instead, user name and password can be supplied through the environment variables
+ PGUSER and PGPASSWORD, which can be set externally without hard-coding
+ credentials in the source code.
+
+Directly incorporating user input into an HTTP request without validating the input can facilitate +different kinds of request forgery attacks, where the attacker essentially controls the request. + +If the vulnerable request is in server-side code, then security mechanisms, such as external +firewalls, can be bypassed. + +If the vulnerable request is in client-side code, then unsuspecting users can send malicious +requests to other servers, potentially resulting in a DDOS attack. +
++To guard against request forgery, it is advisable to avoid putting user input directly into a +network request. If a flexible network request mechanism is required, it is recommended to maintain +a list of authorized request targets and choose from that list based on the user input provided. +
+
+The following example shows an HTTP request parameter being used directly in a URL request without
+validating the input, which facilitates an SSRF attack. The request http.Get(...) is
+vulnerable since attackers can choose the value of target to be anything they want. For
+instance, the attacker can choose "internal.example.com/#" as the target, causing the
+URL used in the request to be "https://internal.example.com/#.example.com/data".
+
+A request to https://internal.example.com may be problematic if that server is not
+meant to be directly accessible from the attacker's machine.
+
+One way to remedy the problem is to use the user input to select a known fixed string before +performing the request: +
+ +