Skip to content

Commit 5719eef

Browse files
kibanamachinekibanamachine
authored
Merge branch 'master' into k8_fix/font-family
2 parents 9a112bf + 4d474bf commit 5719eef

843 files changed

Lines changed: 14619 additions & 10076 deletions

File tree

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

‎.eslintrc.js‎

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -875,6 +875,16 @@ module.exports = {
875875
},
876876
},
877877

878+
/**
879+
* Cases overrides
880+
*/
881+
{
882+
files: ['x-pack/plugins/cases/**/*.{js,mjs,ts,tsx}'],
883+
rules: {
884+
'no-duplicate-imports': 'error',
885+
},
886+
},
887+
878888
/**
879889
* Security Solution overrides
880890
*/

‎dev_docs/best_practices.mdx‎

Lines changed: 133 additions & 32 deletions
Original file line numberDiff line numberDiff line change
@@ -241,35 +241,136 @@ There are some exceptions where a separate repo makes sense. However, they are e
241241

242242
It may be tempting to get caught up in the dream of writing the next package which is published to npm and downloaded millions of times a week. Knowing the quality of developers that are working on Kibana, this is a real possibility. However, knowing which packages will see mass adoption is impossible to predict. Instead of jumping directly to writing code in a separate repo and accepting all of the complications that come along with it, prefer keeping code inside the Kibana repo. A [Kibana package](https://github.com/elastic/kibana/tree/master/packages) can be used to publish a package to npm, while still keeping the code inside the Kibana repo. Move code to an external repo only when there is a good reason, for example to enable external contributions.
243243

244-
## Hardening
245-
246-
Review the following items related to vulnerability and security risks.
247-
248-
- XSS
249-
- Check for usages of `dangerouslySetInnerHtml`, `Element.innerHTML`, `Element.outerHTML`
250-
- Ensure all user input is properly escaped.
251-
- Ensure any input in `$.html`, `$.append`, `$.appendTo`, $.prepend`, `$.prependTo`is escaped. Instead use`$.text`, or don't use jQuery at all.
252-
- CSRF
253-
- Ensure all APIs are running inside the Kibana HTTP service.
254-
- RCE
255-
- Ensure no usages of `eval`
256-
- Ensure no usages of dynamic requires
257-
- Check for template injection
258-
- Check for usages of templating libraries, including `_.template`, and ensure that user provided input isn't influencing the template and is only used as data for rendering the template.
259-
- Check for possible prototype pollution.
260-
- Prototype Pollution - more info [here](https://docs.google.com/document/d/19V-d9sb6IF-fbzF4iyiPpAropQNydCnoJApzSX5FdcI/edit?usp=sharing)
261-
- Check for instances of `anObject[a][b] = c` where a, b, and c are user defined. This includes code paths where the following logical code steps could be performed in separate files by completely different operations, or recursively using dynamic operations.
262-
- Validate any user input, including API url-parameters/query-parameters/payloads, preferable against a schema which only allows specific keys/values. At a very minimum, black-list `__proto__` and `prototype.constructor` for use within keys
263-
- When calling APIs which spawn new processes or potentially perform code generation from strings, defensively protect against Prototype Pollution by checking `Object.hasOwnProperty` if the arguments to the APIs originate from an Object. An example is the Code app's [spawnProcess](https://github.com/elastic/kibana/blob/b49192626a8528af5d888545fb14cd1ce66a72e7/x-pack/legacy/plugins/code/server/lsp/workspace_command.ts#L40-L44).
264-
- Common Node.js offenders: `child_process.spawn`, `child_process.exec`, `eval`, `Function('some string')`, `vm.runIn*Context(x)`
265-
- Common Client-side offenders: `eval`, `Function('some string')`, `setTimeout('some string', num)`, `setInterval('some string', num)`
266-
- Check for accidental reveal of sensitive information
267-
- The biggest culprit is errors which contain stack traces or other sensitive information which end up in the HTTP Response
268-
- Checked for Mishandled API requests
269-
- Ensure no sensitive cookies are forwarded to external resources.
270-
- Ensure that all user controllable variables that are used in constructing a URL are escaped properly. This is relevant when using `transport.request` with the Elasticsearch client as no automatic escaping is performed.
271-
- Reverse tabnabbing - https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/HTML5_Security_Cheat_Sheet.md#tabnabbing
272-
- When there are user controllable links or hard-coded links to third-party domains that specify target="\_blank" or target="\_window", the `a` tag should have the rel="noreferrer noopener" attribute specified.
273-
- Allowing users to input markdown is a common culprit, a custom link renderer should be used
274-
- SSRF - https://www.owasp.org/index.php/Server_Side_Request_Forgery
275-
- All network requests made from the Kibana server should use an explicit configuration or white-list specified in the `kibana.yml`
244+
## Security best practices
245+
246+
When writing code for Kibana, be sure to follow these best practices to avoid common vulnerabilities. Refer to the included Open Web
247+
Application Security Project (OWASP) references to learn more about these types of attacks.
248+
249+
### Cross-site Scripting (XSS)
250+
251+
[_OWASP reference for XSS_](https://owasp.org/www-community/attacks/xss)
252+
253+
XSS is a class of attacks where malicious scripts are injected into vulnerable websites. Kibana defends against this by using the React
254+
framework to safely encode data that is rendered in pages, the EUI framework to [automatically sanitize
255+
links](https://elastic.github.io/eui/#/navigation/link#link-validation), and a restrictive `Content-Security-Policy` header.
256+
257+
**Best practices**
258+
259+
* Check for dangerous functions or assignments that can result in unescaped user input in the browser DOM. Avoid using:
260+
* **React:** [`dangerouslySetInnerHtml`](https://reactjs.org/docs/dom-elements.html#dangerouslysetinnerhtml).
261+
* **Browser DOM:** `Element.innerHTML` and `Element.outerHTML`.
262+
* If using the aforementioned unsafe functions or assignments is absolutely necessary, follow [these XSS prevention
263+
rules](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html#xss-prevention-rules) to ensure that
264+
user input is not inserted into unsafe locations and that it is escaped properly.
265+
* Use EUI components to build your UI, particularly when rendering `href` links. Otherwise, sanitize user input before rendering links to
266+
ensure that they do not use the `javascript:` protocol.
267+
* Don't use the `eval`, `Function`, and `_.template` functions -- these are restricted by ESLint rules.
268+
* Be careful when using `setTimeout` and `setInterval` in client-side code. If an attacker can manipulate the arguments and pass a string to
269+
one of these, it is evaluated dynamically, which is equivalent to the dangerous `eval` function.
270+
271+
### Cross-Site Request Forgery (CSRF/XSRF)
272+
273+
[_OWASP reference for CSRF_](https://owasp.org/www-community/attacks/csrf)
274+
275+
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
276+
their knowledge. Kibana defends against this by requiring [custom request
277+
headers](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#use-of-custom-request-headers)
278+
for API endpoints. For more information, see [API Request
279+
Headers](https://www.elastic.co/guide/en/kibana/master/api.html#api-request-headers).
280+
281+
**Best practices**
282+
283+
* Ensure all HTTP routes are registered with the [Kibana HTTP service](https://www.elastic.co/guide/en/kibana/master/http-service.html) to
284+
take advantage of the custom request header security control.
285+
* Note that HTTP GET requests do **not** require the custom request header; any routes that change data should [adhere to the HTTP
286+
specification and use a different method (PUT, POST, etc.)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods)
287+
288+
### Remote Code Execution (RCE)
289+
290+
[_OWASP reference for Command Injection_](https://owasp.org/www-community/attacks/Command_Injection),
291+
[_OWASP reference for Code Injection_](https://owasp.org/www-community/attacks/Code_Injection)
292+
293+
RCE is a class of attacks where an attacker executes malicious code or commands on a vulnerable server. Kibana defends against this by using
294+
ESLint rules to restrict vulnerable functions, and by hooking into or hardening usage of these in third-party dependencies.
295+
296+
**Best practices**
297+
298+
* Don't use the `eval`, `Function`, and `_.template` functions -- these are restricted by ESLint rules.
299+
* Don't use dynamic `require`.
300+
* Check for usages of templating libraries. Ensure that user-provided input doesn't influence the template and is used only as data for
301+
rendering the template.
302+
* Take extra caution when spawning child processes with any user input or parameters that are user-controlled.
303+
304+
### Prototype Pollution
305+
306+
Prototype Pollution is an attack that is unique to JavaScript environments. Attackers can abuse JavaScript's prototype inheritance to
307+
"pollute" objects in the application, which is often used as a vector for XSS or RCE vulnerabilities. Kibana defends against this by
308+
hardening sensitive functions (such as those exposed by `child_process`), and by requiring validation on all HTTP routes by default.
309+
310+
**Best practices**
311+
312+
* Check for instances of `anObject[a][b] = c` where `a`, `b`, and `c` are controlled by user input. This includes code paths where the
313+
following logical code steps could be performed in separate files by completely different operations, or by recursively using dynamic
314+
operations.
315+
* Validate all user input, including API URL parameters, query parameters, and payloads. Preferably, use a schema that only allows specific
316+
keys and values. At a minimum, implement a deny-list that prevents `__proto__` and `prototype.constructor` from being used within object
317+
keys.
318+
* When calling APIs that spawn new processes or perform code generation from strings, protect against Prototype Pollution by checking if
319+
`Object.hasOwnProperty` has arguments to the APIs that originate from an Object. An example is the defunct Code app's
320+
[`spawnProcess`](https://github.com/elastic/kibana/blob/b49192626a8528af5d888545fb14cd1ce66a72e7/x-pack/legacy/plugins/code/server/lsp/workspace_command.ts#L40-L44)
321+
function.
322+
* Common Node.js offenders: `child_process.spawn`, `child_process.exec`, `eval`, `Function('some string')`, `vm.runInContext(x)`,
323+
`vm.runInNewContext(x)`, `vm.runInThisContext()`
324+
* Common client-side offenders: `eval`, `Function('some string')`, `setTimeout('some string', num)`, `setInterval('some string', num)`
325+
326+
See also:
327+
328+
* [Prototype pollution: The dangerous and underrated vulnerability impacting JavaScript applications |
329+
portswigger.net](https://portswigger.net/daily-swig/prototype-pollution-the-dangerous-and-underrated-vulnerability-impacting-javascript-applications)
330+
* [Prototype pollution attack in NodeJS application | Olivier
331+
Arteau](https://github.com/HoLyVieR/prototype-pollution-nsec18/blob/master/paper/JavaScript_prototype_pollution_attack_in_NodeJS.pdf)
332+
333+
### Server-Side Request Forgery (SSRF)
334+
335+
[_OWASP reference for SSRF_](https://owasp.org/www-community/attacks/Server_Side_Request_Forgery)
336+
337+
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
338+
a vector for information disclosure or injection attacks.
339+
340+
**Best practices**
341+
342+
* Ensure that all outbound requests from the Kibana server use hard-coded URLs.
343+
* 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
344+
user input is escaped properly. Ideally, the allow-list should be set in `kibana.yml`, so only server administrators can change it.
345+
* This is particularly relevant when using `transport.request` with the Elasticsearch client, as no automatic escaping is performed.
346+
* Note that URLs are very hard to validate properly; exact match validation for user input is most preferable, while URL parsing or RegEx
347+
validation should only be used if absolutely necessary.
348+
349+
### Reverse tabnabbing
350+
351+
[_OWASP reference for Reverse Tabnabbing_](https://owasp.org/www-community/attacks/Reverse_Tabnabbing)
352+
353+
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
354+
for phishing attacks. Kibana defends against this by using the EUI framework, which automatically adds the `rel` attribute to anchor tags,
355+
buttons, and other vulnerable DOM elements.
356+
357+
**Best practices**
358+
359+
* Use EUI components to build your UI whenever possible. Otherwise, ensure that any DOM elements that have an `href` attribute also have the
360+
`rel="noreferrer noopener"` attribute specified. For more information, refer to the [OWASP HTML5 Security Cheat
361+
Sheet](https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/HTML5_Security_Cheat_Sheet.md#tabnabbing).
362+
* If using a non-EUI markdown renderer, use a custom link renderer for rendered links.
363+
364+
### Information disclosure
365+
366+
Information disclosure is not an attack, but it describes whenever sensitive information is accidentally revealed. This can be configuration
367+
info, stack traces, or other data that the user is not authorized to access. This concern cannot be addressed with a single security
368+
control, but at a high level, Kibana relies on the hapi framework to automatically redact stack traces and detailed error messages in HTTP
369+
5xx response payloads.
370+
371+
**Best practices**
372+
373+
* Look for instances where sensitive information might accidentally be revealed, particularly in error messages, in the UI, and URL
374+
parameters that are exposed to users.
375+
* Make sure that sensitive request data is not forwarded to external resources. For example, copying client request headers and using them
376+
to make an another request could accidentally expose the user's credentials.

0 commit comments

Comments
 (0)