docs/extend/security-best-practices.md
When writing code for {{kib}}, be sure to follow these best practices to avoid common vulnerabilities. Refer to the included Open Web Application Security Project (OWASP) references to learn more about these types of attacks.
XSS is a class of attacks where malicious scripts are injected into vulnerable websites. {{kib}} defends against this by using the React framework to safely encode data that is rendered in pages, the EUI framework to automatically sanitize links, and a restrictive Content-Security-Policy header.
Best practices
Check for dangerous functions or assignments that can result in unescaped user input in the browser DOM. Avoid using:
dangerouslySetInnerHtml.Element.innerHTML and Element.outerHTML.If using the aforementioned unsafe functions or assignments is absolutely necessary, follow these XSS prevention rules to ensure that user input is not inserted into unsafe locations and that it is escaped properly.
Use EUI components to build your UI, particularly when rendering href links. Otherwise, sanitize user input before rendering links to ensure that they do not use the javascript: protocol.
Don’t use the eval, Function, and _.template functions. These are restricted by ESLint rules.
Be careful when using setTimeout and setInterval in client-side code. If an attacker can manipulate the arguments and pass a string to one of these, it is evaluated dynamically, which is equivalent to the dangerous eval function.
CSRF is a class of attacks where a user is forced to execute an action on a vulnerable website that they’re logged into, usually without their knowledge. {{kib}} defends against this by requiring custom request headers for API endpoints. For more information, see API Request Headers.
Best practices
Ensure all HTTP routes are registered with the {{kib}} HTTP service to take advantage of the custom request header security control.
OWASP reference for Command Injection, OWASP reference for Code Injection
RCE is a class of attacks where an attacker executes malicious code or commands on a vulnerable server. {{kib}} defends against this by using ESLint rules to restrict vulnerable functions, and by hooking into or hardening usage of these in third-party dependencies.
Best practices
eval, Function, and _.template functions. These are restricted by ESLint rules.require.Prototype Pollution is an attack that is unique to JavaScript environments. Attackers can abuse JavaScript’s prototype inheritance to "pollute" objects in the application, which is often used as a vector for XSS or RCE vulnerabilities. {{kib}} defends against this by hardening sensitive functions (such as those exposed by child_process), and by requiring validation on all HTTP routes by default.
Best practices
Check for instances of anObject[a][b] = c where a, b, and c are controlled by user input. This includes code paths where the following logical code steps could be performed in separate files by completely different operations, or by recursively using dynamic operations.
Validate all user input, including API URL parameters, query parameters, and payloads. Preferably, use a schema that only allows specific keys and values. At a minimum, implement a deny-list that prevents __proto__ and prototype.constructor from being used within object keys.
When calling APIs that spawn new processes or perform code generation from strings, protect against Prototype Pollution by checking if Object.hasOwnProperty has arguments to the APIs that originate from an Object. An example is the defunct Code app’s spawnProcess function.
child_process.spawn, child_process.exec, eval, Function('some string'), vm.runInContext(x), vm.runInNewContext(x), vm.runInThisContext()eval, Function('some string'), setTimeout('some string', num), setInterval('some string', num)See also:
SSRF is a class of attacks where a vulnerable server is forced to make an unintended request, usually to an HTTP API. This is often used as a vector for information disclosure or injection attacks.
Best practices
Ensure that all outbound requests from the {{kib}} server use hard-coded URLs.
If user input is used to construct a URL for an outbound request, ensure that an allow-list is used to validate the endpoints and that user input is escaped properly. Ideally, the allow-list should be set in kibana.yml, so only server administrators can change it.
transport.request with the {{es}} client, as no automatic escaping is performed.OWASP reference for Reverse Tabnabbing
Reverse tabnabbing is an attack where a link to a malicious page is used to rewrite a vulnerable parent page. This is often used as a vector for phishing attacks. {{kib}} defends against this by using the EUI framework, which automatically adds the rel attribute to anchor tags, buttons, and other vulnerable DOM elements.
Best practices
href attribute also have the rel="noreferrer noopener" attribute specified. For more information, refer to the OWASP HTML5 Security Cheat Sheet.Information disclosure is not an attack, but it describes whenever sensitive information is accidentally revealed. This can be configuration info, stack traces, or other data that the user is not authorized to access. This concern cannot be addressed with a single security control, but at a high level, {{kib}} relies on the hapi framework to automatically redact stack traces and detailed error messages in HTTP 5xx response payloads.
Best practices