mirror of
https://github.com/github/codeql.git
synced 2026-04-30 03:05:15 +02:00
Merge pull request #419 from xiemaisi/js/fix-mixed-whitespace
Approved by esben-semmle
This commit is contained in:
semmle-qlci
@@ -6,14 +6,14 @@
|
||||
<overview>
|
||||
<p>
|
||||
|
||||
Enabling Node.js integration in Electron web content renderers
|
||||
(<code>BrowserWindow</code>, <code>BrowserView</code> and
|
||||
<code>webview</code>) can result in remote native code execution
|
||||
attacks.
|
||||
Enabling Node.js integration in Electron web content renderers
|
||||
(<code>BrowserWindow</code>, <code>BrowserView</code> and
|
||||
<code>webview</code>) 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.
|
||||
|
||||
</p>
|
||||
</overview>
|
||||
@@ -21,18 +21,18 @@
|
||||
<recommendation>
|
||||
<p>
|
||||
|
||||
Node.js integration should be disabled when loading remote web
|
||||
sites. Always set <code>nodeIntegration</code> preference
|
||||
to <code>false</code> 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 <code>nodeIntegration</code> preference
|
||||
to <code>false</code> before loading remote web sites, and only enable
|
||||
it for whitelisted sites.
|
||||
|
||||
</p>
|
||||
|
||||
<p>
|
||||
|
||||
Note that the <code>nodeIntegration</code> property is enabled
|
||||
by default in Electron and needs to be set to <code>false</code>
|
||||
explicitly.
|
||||
Note that the <code>nodeIntegration</code> property is enabled
|
||||
by default in Electron and needs to be set to <code>false</code>
|
||||
explicitly.
|
||||
|
||||
</p>
|
||||
</recommendation>
|
||||
@@ -41,9 +41,9 @@
|
||||
|
||||
<p>
|
||||
|
||||
The following examples shows insecure and secure uses of
|
||||
<code>BrowserWindow</code> and <code>BrowserView</code> when loading
|
||||
remote web sites:
|
||||
The following examples shows insecure and secure uses of
|
||||
<code>BrowserWindow</code> and <code>BrowserView</code> when loading
|
||||
remote web sites:
|
||||
|
||||
</p>
|
||||
|
||||
|
||||
@@ -3,77 +3,77 @@
|
||||
"qhelp.dtd">
|
||||
<qhelp>
|
||||
|
||||
<overview>
|
||||
<p>
|
||||
<overview>
|
||||
<p>
|
||||
|
||||
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.
|
||||
|
||||
</p>
|
||||
</overview>
|
||||
</p>
|
||||
</overview>
|
||||
|
||||
<recommendation>
|
||||
<recommendation>
|
||||
|
||||
<p>
|
||||
<p>
|
||||
|
||||
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.
|
||||
|
||||
</p>
|
||||
</p>
|
||||
|
||||
</recommendation>
|
||||
</recommendation>
|
||||
|
||||
<example>
|
||||
<example>
|
||||
|
||||
<p>
|
||||
<p>
|
||||
|
||||
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
|
||||
<code>http.get(...)</code> is vulnerable since attackers can choose
|
||||
the value of <code>target</code> to be anything they want. For
|
||||
instance, the attacker can choose
|
||||
<code>"internal.example.com/#"</code> as the target, causing the URL
|
||||
used in the request to be
|
||||
<code>"https://internal.example.com/#.example.com/data"</code>.
|
||||
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
|
||||
<code>http.get(...)</code> is vulnerable since attackers can choose
|
||||
the value of <code>target</code> to be anything they want. For
|
||||
instance, the attacker can choose
|
||||
<code>"internal.example.com/#"</code> as the target, causing the URL
|
||||
used in the request to be
|
||||
<code>"https://internal.example.com/#.example.com/data"</code>.
|
||||
|
||||
</p>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<p>
|
||||
|
||||
A request to <code>https://internal.example.com</code> may
|
||||
be problematic if that server is not meant to be
|
||||
directly accessible from the attacker's machine.
|
||||
A request to <code>https://internal.example.com</code> may
|
||||
be problematic if that server is not meant to be
|
||||
directly accessible from the attacker's machine.
|
||||
|
||||
</p>
|
||||
</p>
|
||||
|
||||
<sample src="examples/RequestForgeryBad.js"/>
|
||||
<sample src="examples/RequestForgeryBad.js"/>
|
||||
|
||||
<p>
|
||||
<p>
|
||||
|
||||
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:
|
||||
|
||||
</p>
|
||||
</p>
|
||||
|
||||
<sample src="examples/RequestForgeryGood.js"/>
|
||||
|
||||
</example>
|
||||
</example>
|
||||
|
||||
<references>
|
||||
<references>
|
||||
|
||||
<li>OWASP: <a href="https://www.owasp.org/index.php/Server_Side_Request_Forgery">SSRF</a></li>
|
||||
<li>OWASP: <a href="https://www.owasp.org/index.php/Server_Side_Request_Forgery">SSRF</a></li>
|
||||
|
||||
</references>
|
||||
</references>
|
||||
</qhelp>
|
||||
|
||||
Reference in New Issue
Block a user