From 5ffe45a80b18ba446753985e4d60a25f4221d0d2 Mon Sep 17 00:00:00 2001 From: Max Schaefer Date: Wed, 7 Nov 2018 07:40:51 +0000 Subject: [PATCH] JavaScript: Fix mixed tabs/spaces in qhelp. --- .../Electron/EnablingNodeIntegration.qhelp | 34 +++---- .../src/Security/CWE-918/RequestForgery.qhelp | 94 +++++++++---------- 2 files changed, 64 insertions(+), 64 deletions(-) diff --git a/javascript/ql/src/Electron/EnablingNodeIntegration.qhelp b/javascript/ql/src/Electron/EnablingNodeIntegration.qhelp index 34efea3b347..3fae592a788 100644 --- a/javascript/ql/src/Electron/EnablingNodeIntegration.qhelp +++ b/javascript/ql/src/Electron/EnablingNodeIntegration.qhelp @@ -6,14 +6,14 @@

- Enabling Node.js integration in Electron web content renderers - (BrowserWindow, BrowserView and - webview) can result in remote native code execution - attacks. + Enabling Node.js integration in Electron web content renderers + (BrowserWindow, BrowserView and + webview) can result in remote native code execution + attacks. - The attack is realized when the renderer uses content from an - untrusted remote web site or a trusted site with a cross site - scripting vulnerability. + The attack is realized when the renderer uses content from an + untrusted remote web site or a trusted site with a cross site + scripting vulnerability.

@@ -21,18 +21,18 @@

- Node.js integration should be disabled when loading remote web - sites. Always set nodeIntegration preference - to false before loading remote web sites, and only enable - it for whitelisted sites. + Node.js integration should be disabled when loading remote web + sites. Always set nodeIntegration preference + to false before loading remote web sites, and only enable + it for whitelisted sites.

- Note that the nodeIntegration property is enabled - by default in Electron and needs to be set to false - explicitly. + Note that the nodeIntegration property is enabled + by default in Electron and needs to be set to false + explicitly.

@@ -41,9 +41,9 @@

- The following examples shows insecure and secure uses of - BrowserWindow and BrowserView when loading - remote web sites: + The following examples shows insecure and secure uses of + BrowserWindow and BrowserView when loading + remote web sites:

diff --git a/javascript/ql/src/Security/CWE-918/RequestForgery.qhelp b/javascript/ql/src/Security/CWE-918/RequestForgery.qhelp index 356edf65c86..e077f72f4e0 100644 --- a/javascript/ql/src/Security/CWE-918/RequestForgery.qhelp +++ b/javascript/ql/src/Security/CWE-918/RequestForgery.qhelp @@ -3,77 +3,77 @@ "qhelp.dtd"> - -

+ +

- 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. + 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 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. + 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. + 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". + 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. + 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: + One way to remedy the problem is to use the user input to + select a known fixed string before performing the request: -

+

- + - + -
  • OWASP: SSRF
    • +
  • OWASP: SSRF
    • -     +