github-mirrors/kibana
1
0
Fork 0
mirror of https://github.com/elastic/kibana.git synced 2025-04-23 17:28:26 -04:00
Code Issues Projects Releases Packages Wiki Activity

Just needed to fix a couple references to bad links but my auto-fix prettier ended up adjusting a lot of lines (#108438)

Browse source
This commit is contained in:
Stacey Gammon 2021-08-12 17:00:19 -04:00 • committed by GitHub
parent e072409a0c
commit ce15c6e81d
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
2 changed files with 81 additions and 77 deletions
Download patch file Download diff file Expand all files Collapse all files

108
dev_docs/best_practices.mdx
View file

@ -22,8 +22,10 @@ Refer to [divio documentation](https://documentation.divio.com/) for guidance on
<DocLink id="kibDevDocsWelcome" text="Getting started" /> and
<DocLink id="kibPlatformIntro" text="Key concepts" /> sections are both _explanation_ oriented,
<DocLink id="kibDevTutorialBuildAPlugin" text="Tutorials" /> covers both _tutorials_ and _How to_, and
the <DocLink id="kibDevDocsApiWelcome" text="API documentation" /> section covers _reference_ material.
<DocLink id="kibDevTutorialDebugging" text="Tutorials" /> covers both _tutorials_ and _How to_, and the <DocLink
id="kibDevDocsApiWelcome"
text="API documentation"
/> section covers _reference_ material.
#### Location
@ -256,17 +258,17 @@ links](https://elastic.github.io/eui/#/navigation/link#link-validation), and a r
**Best practices**
* Check for dangerous functions or assignments that can result in unescaped user input in the browser DOM. Avoid using:
* **React:** [`dangerouslySetInnerHtml`](https://reactjs.org/docs/dom-elements.html#dangerouslysetinnerhtml).
* **Browser DOM:** `Element.innerHTML` and `Element.outerHTML`.
* If using the aforementioned unsafe functions or assignments is absolutely necessary, follow [these XSS prevention
rules](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html#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.
- Check for dangerous functions or assignments that can result in unescaped user input in the browser DOM. Avoid using:
- **React:** [`dangerouslySetInnerHtml`](https://reactjs.org/docs/dom-elements.html#dangerouslysetinnerhtml).
- **Browser DOM:** `Element.innerHTML` and `Element.outerHTML`.
- If using the aforementioned unsafe functions or assignments is absolutely necessary, follow [these XSS prevention
rules](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html#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.
### Cross-Site Request Forgery (CSRF/XSRF)
@ -280,10 +282,10 @@ Headers](https://www.elastic.co/guide/en/kibana/master/api.html#api-request-head
**Best practices**
* Ensure all HTTP routes are registered with the [Kibana HTTP service](https://www.elastic.co/guide/en/kibana/master/http-service.html) to
take advantage of the custom request header security control.
* Note that HTTP GET requests do **not** require the custom request header; any routes that change data should [adhere to the HTTP
specification and use a different method (PUT, POST, etc.)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods)
- Ensure all HTTP routes are registered with the [Kibana HTTP service](https://www.elastic.co/guide/en/kibana/master/http-service.html) to
take advantage of the custom request header security control.
- Note that HTTP GET requests do **not** require the custom request header; any routes that change data should [adhere to the HTTP
specification and use a different method (PUT, POST, etc.)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods)
### Remote Code Execution (RCE)
@ -295,11 +297,11 @@ ESLint rules to restrict vulnerable functions, and by hooking into or hardening
**Best practices**
* Don't use the `eval`, `Function`, and `_.template` functions -- these are restricted by ESLint rules.
* Don't use dynamic `require`.
* Check for usages of templating libraries. Ensure that user-provided input doesn't influence the template and is used only as data for
rendering the template.
* Take extra caution when spawning child processes with any user input or parameters that are user-controlled.
- Don't use the `eval`, `Function`, and `_.template` functions -- these are restricted by ESLint rules.
- Don't use dynamic `require`.
- Check for usages of templating libraries. Ensure that user-provided input doesn't influence the template and is used only as data for
rendering the template.
- Take extra caution when spawning child processes with any user input or parameters that are user-controlled.
### Prototype Pollution
@ -309,26 +311,26 @@ hardening sensitive functions (such as those exposed by `child_process`), and by
**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`](https://github.com/elastic/kibana/blob/b49192626a8528af5d888545fb14cd1ce66a72e7/x-pack/legacy/plugins/code/server/lsp/workspace_command.ts#L40-L44)
function.
* Common Node.js offenders: `child_process.spawn`, `child_process.exec`, `eval`, `Function('some string')`, `vm.runInContext(x)`,
`vm.runInNewContext(x)`, `vm.runInThisContext()`
* Common client-side offenders: `eval`, `Function('some string')`, `setTimeout('some string', num)`, `setInterval('some string', num)`
- 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`](https://github.com/elastic/kibana/blob/b49192626a8528af5d888545fb14cd1ce66a72e7/x-pack/legacy/plugins/code/server/lsp/workspace_command.ts#L40-L44)
function.
- Common Node.js offenders: `child_process.spawn`, `child_process.exec`, `eval`, `Function('some string')`, `vm.runInContext(x)`,
`vm.runInNewContext(x)`, `vm.runInThisContext()`
- Common client-side offenders: `eval`, `Function('some string')`, `setTimeout('some string', num)`, `setInterval('some string', num)`
See also:
* [Prototype pollution: The dangerous and underrated vulnerability impacting JavaScript applications |
portswigger.net](https://portswigger.net/daily-swig/prototype-pollution-the-dangerous-and-underrated-vulnerability-impacting-javascript-applications)
* [Prototype pollution attack in NodeJS application | Olivier
Arteau](https://github.com/HoLyVieR/prototype-pollution-nsec18/blob/master/paper/JavaScript_prototype_pollution_attack_in_NodeJS.pdf)
- [Prototype pollution: The dangerous and underrated vulnerability impacting JavaScript applications |
portswigger.net](https://portswigger.net/daily-swig/prototype-pollution-the-dangerous-and-underrated-vulnerability-impacting-javascript-applications)
- [Prototype pollution attack in NodeJS application | Olivier
Arteau](https://github.com/HoLyVieR/prototype-pollution-nsec18/blob/master/paper/JavaScript_prototype_pollution_attack_in_NodeJS.pdf)
### Server-Side Request Forgery (SSRF)
@ -339,12 +341,12 @@ a vector for information disclosure or injection attacks.
**Best practices**
* Ensure that all outbound requests from the Kibana 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.
* This is particularly relevant when using `transport.request` with the Elasticsearch client, as no automatic escaping is performed.
* Note that URLs are very hard to validate properly; exact match validation for user input is most preferable, while URL parsing or RegEx
validation should only be used if absolutely necessary.
- Ensure that all outbound requests from the Kibana 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.
- This is particularly relevant when using `transport.request` with the Elasticsearch client, as no automatic escaping is performed.
- Note that URLs are very hard to validate properly; exact match validation for user input is most preferable, while URL parsing or RegEx
validation should only be used if absolutely necessary.
### Reverse tabnabbing
@ -356,10 +358,10 @@ buttons, and other vulnerable DOM elements.
**Best practices**
* Use EUI components to build your UI whenever possible. Otherwise, ensure that any DOM elements that have an `href` attribute also have the
`rel="noreferrer noopener"` attribute specified. For more information, refer to the [OWASP HTML5 Security Cheat
Sheet](https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/HTML5_Security_Cheat_Sheet.md#tabnabbing).
* If using a non-EUI markdown renderer, use a custom link renderer for rendered links.
- Use EUI components to build your UI whenever possible. Otherwise, ensure that any DOM elements that have an `href` attribute also have the
`rel="noreferrer noopener"` attribute specified. For more information, refer to the [OWASP HTML5 Security Cheat
Sheet](https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/HTML5_Security_Cheat_Sheet.md#tabnabbing).
- If using a non-EUI markdown renderer, use a custom link renderer for rendered links.
### Information disclosure
@ -370,7 +372,7 @@ control, but at a high level, Kibana relies on the hapi framework to automatical
**Best practices**
* Look for instances where sensitive information might accidentally be revealed, particularly in error messages, in the UI, and URL
parameters that are exposed to users.
* Make sure that sensitive request data is not forwarded to external resources. For example, copying client request headers and using them
to make an another request could accidentally expose the user's credentials.
- Look for instances where sensitive information might accidentally be revealed, particularly in error messages, in the UI, and URL
parameters that are exposed to users.
- Make sure that sensitive request data is not forwarded to external resources. For example, copying client request headers and using them
to make an another request could accidentally expose the user's credentials.

50
dev_docs/kibana_platform_plugin_intro.mdx
View file

@ -4,7 +4,7 @@ slug: /kibana-dev-docs/platform-intro
title: Plugins and the Kibana platform
summary: An introduction to the Kibana platform and how to use it to build a plugin.
date: 2021-01-06
tags: ['kibana','onboarding', 'dev', 'architecture']
tags: ['kibana', 'onboarding', 'dev', 'architecture']
---
From an end user perspective, Kibana is a tool for interacting with Elasticsearch, providing an easy way
@ -23,11 +23,11 @@ developer tools. The Kibana platform is a blank canvas, just waiting for a devel
Plugins have access to three kinds of public services:
- Platform services provided by `core` (<DocLink id="kibPlatformIntro" section="core-services" text="Core services"/>)
- Platform services provided by plugins (<DocLink id="kibPlatformIntro" section="platform-plugins" text="Platform plugins"/>)
- Shared services provided by plugins, that are only relevant for only a few, specific plugins (e.g. "presentation utils").
- Platform services provided by `core` (<DocLink id="kibPlatformIntro" section="core-services" text="Core services"/>)
- Platform services provided by plugins (<DocLink id="kibPlatformIntro" section="platform-plugins" text="Platform plugins"/>)
- Shared services provided by plugins, that are only relevant for only a few, specific plugins (e.g. "presentation utils").
The first two items are what make up "Platform services".
The first two items are what make up "Platform services".
<DocCallOut title="What is the difference between services provided by platform plugins, and those by core?">
@ -46,24 +46,24 @@ In reality, we ended up with many platform-like services living outside of core,
them, so we consider them part of platform services.
When we built our platform system, we also thought we'd end up with only a handful of large plugins outside core. Users could turn certain plugins off, to minimize the code
footprint and speed up Kibana.
footprint and speed up Kibana.
In reality, our plugin model ended up being used like micro-services. Plugins are the only form of encapsulation we provide developers, and they liked it! However, we ended
up with a ton of small plugins, that developers never intended to be uninstallable, nor tested in this manner. We are considering ways to provide developers the ability to build services
with the encapsulation
they desire, without the need to build a plugin.
up with a ton of small plugins, that developers never intended to be uninstallable, nor tested in this manner. We are considering ways to provide developers the ability to build services
with the encapsulation
they desire, without the need to build a plugin.
Another side effect of having many small plugins is that common code often ends up extracted into another plugin. Use case specific utilities are exported,
that are not meant to be used in a general manner. This makes our definition of "platform code" a bit trickier to define. We'd like to say "The platform is made up of
every publically exposed service", but in today's world, that wouldn't be a very accurate picture.
that are not meant to be used in a general manner. This makes our definition of "platform code" a bit trickier to define. We'd like to say "The platform is made up of
every publically exposed service", but in today's world, that wouldn't be a very accurate picture.
We recognize the need to better clarify the relationship between core functionality, platform-like plugin functionality, and functionality exposed by other plugins.
It's something we will be working on!
It's something we will be working on!
</DocAccordion>
We will continue to focus on adding clarity around these types of services and what developers can expect from each.
</DocCallOut>
### Core services
@ -75,8 +75,10 @@ there are some plugins that provide platform functionality. We call these <DocLi
### Platform plugins
Plugins that provide fundamental services and functionality to extend and customize Kibana, for example, the
<DocLink id="kibDataPlugin" text="data"/> plugin. There is no official way to tell if a plugin is a platform plugin or not.
Platform plugins are _usually_ plugins that are managed by the Platform Group, but we are starting to see some exceptions.
<DocLink id="kibDataPlugin" text="data" /> plugin. There is no official way to tell if a plugin is a
platform plugin or not. Platform plugins are _usually_ plugins that are managed by the Platform Group,
but we are starting to see some exceptions.
## Plugins
@ -110,19 +112,19 @@ Any plugin that exports something from those files, or from the lifecycle method
## Lifecycle methods
Core, and plugins, expose different features at different parts of their lifecycle. We describe the lifecycle of core services and plugins with
specifically-named functions on the service definition.
specifically-named functions on the service definition.
Kibana has three lifecycles: setup, start, and stop. Each plugin’s setup function is called sequentially while Kibana is setting up
on the server or when it is being loaded in the browser. The start functions are called sequentially after setup has been completed for all plugins.
The stop functions are called sequentially while Kibana is gracefully shutting down the server or when the browser tab or window is being closed.
on the server or when it is being loaded in the browser. The start functions are called sequentially after setup has been completed for all plugins.
The stop functions are called sequentially while Kibana is gracefully shutting down the server or when the browser tab or window is being closed.
The table below explains how each lifecycle relates to the state of Kibana.
| lifecycle | purpose | server | browser |
| ---------- | ------ | ------- | ----- |
| setup | perform "registration" work to setup environment for runtime |configure REST API endpoint, register saved object types, etc. | configure application routes in SPA, register custom UI elements in extension points, etc. |
| start | bootstrap runtime logic | respond to an incoming request, request Elasticsearch server, etc. | start polling Kibana server, update DOM tree in response to user interactions, etc.|
| stop | cleanup runtime | dispose of active handles before the server shutdown. | store session data in the LocalStorage when the user navigates away from Kibana, etc. |
| lifecycle | purpose | server | browser |
| --------- | ------------------------------------------------------------ | ------------------------------------------------------------------ | ------------------------------------------------------------------------------------------ |
| setup | perform "registration" work to setup environment for runtime | configure REST API endpoint, register saved object types, etc. | configure application routes in SPA, register custom UI elements in extension points, etc. |
| start | bootstrap runtime logic | respond to an incoming request, request Elasticsearch server, etc. | start polling Kibana server, update DOM tree in response to user interactions, etc. |
| stop | cleanup runtime | dispose of active handles before the server shutdown. | store session data in the LocalStorage when the user navigates away from Kibana, etc. |
Different service interfaces can and will be passed to setup, start, and stop because certain functionality makes sense in the context of a running plugin while other types
of functionality may have restrictions or may only make sense in the context of a plugin that is stopping.
@ -141,4 +143,4 @@ plugins to customize the Kibana experience. Examples of extension points are:
## Follow up material
Learn how to build your own plugin by following <DocLink id="kibDevTutorialBuildAPlugin" />.
Learn how to build your own plugin by following <DocLink id="kibHelloWorldApp" />.