ts33 / nmap-app Goto Github PK

Risk: Critical

Code

Description

JavaScript variable scope can be particularly difficult to understand and get right. The situation gets even worse when you consider the accidental creation of global variables, which is what happens when you declare a variable inside a function or the for clause of a for-loop without using the let, const or var keywords.

let and const were introduced in ECMAScript 2015, and are now the preferred keywords for variable declaration.

Noncompliant Code Example

function f(){
  i = 1;         // Noncompliant; i is global
for (j = 0; j < array.length; j++) {  // Noncompliant; j is global now too

// ...

}

}

Compliant Solution

function f(){
  var i = 1;
for (let j = 0; j < array.length; j++) {

// ...

}

}

Recommendation

Add the "let", "const" or "var" keyword to this declaration of "functionList" to make it explicit.

Horangi detected this issue on 2019-03-26 16:58:23

Details

• ID: d808fc3cb1e37293cbb66c67a199f212
• Affected Hosts: ['https://uod-offroad.com/challenge?query=query%27+AND+%271%27%3D%271%27+--+']
• First seen: 2018-07-30 13:30:12

Description

SQL injection may be possible.

Recommendation:

Do not trust client side input, even if there is client side validation in place.
In general, type check all data on the server side.
If the application uses JDBC, use PreparedStatement or CallableStatement, with parameters passed by '?'
If the application uses ASP, use ADO Command Objects with strong type checking and parameterized queries.
If database Stored Procedures can be used, use them.
Do not concatenate strings into queries in the stored procedure, or use 'exec', 'exec immediate', or equivalent functionality!
Do not create dynamic SQL queries using simple string concatenation.
Escape all data received from the client.
Apply a 'whitelist' of allowed characters, or a 'blacklist' of disallowed characters in user input.
Apply the principle of least privilege by using the least privileged database user possible.
In particular, avoid using the 'sa' or 'db-owner' database users. This does not eliminate SQL injection, but minimizes its impact.
Grant the minimum database access that is necessary for the application.

• Name: Remote File Inclusion
• ID: 84f170de6b8af57dfc5517a59319afc2
• Affected Hosts: ['http://testphp.vulnweb.com/showimage.php?file=http%3A%2F%2Fwww.google.com%2F']
• Description: Remote File Include (RFI) is an attack technique used to exploit "dynamic file include" mechanisms in web applications. When web applications take user input (URL, parameter value, etc.) and pass them into file include commands, the web application might be tricked into including remote files with malicious code.

Almost all web application frameworks support file inclusion. File inclusion is mainly used for packaging common code into separate files that are later referenced by main application modules. When a web application references an include file, the code in this file may be executed implicitly or explicitly by calling specific procedures. If the choice of module to load is based on elements from the HTTP request, the web application might be vulnerable to RFI.
An attacker can use RFI for:
* Running malicious code on the server: any code in the included malicious files will be run by the server. If the file include is not executed using some wrapper, code in include files is executed in the context of the server user. This could lead to a complete system compromise.
* Running malicious code on clients: the attacker's malicious code can manipulate the content of the response sent to the client. The attacker can embed malicious code in the response that will be run by the client (for example, Javascript to steal the client session cookies).

PHP is particularly vulnerable to RFI attacks due to the extensive use of "file includes" in PHP programming and due to default server configurations that increase susceptibility to an RFI attack.

• First seen: 2018-06-29 04:18:47
• Recommendation: Phase: Architecture and Design
  When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.
  For example, ID 1 could map to "inbox.txt" and ID 2 could map to "profile.txt". Features such as the ESAPI AccessReferenceMap provide this capability.

Phases: Architecture and Design; Operation
Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by your software.
OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows you to specify restrictions on file operations.
This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise.
Be careful to avoid CWE-243 and other weaknesses related to jails.
For PHP, the interpreter offers restrictions such as open basedir or safe mode which can make it more difficult for an attacker to escape out of the application. Also consider Suhosin, a hardened PHP extension, which includes various options that disable some of the more dangerous PHP features.

Phase: Implementation
Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a whitelist of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. Do not rely exclusively on looking for malicious or malformed inputs (i.e., do not rely on a blacklist). However, blacklists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if you are expecting colors such as "red" or "blue."
For filenames, use stringent whitelists that limit the character set to be used. If feasible, only allow a single "." character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as "/" to avoid CWE-36. Use a whitelist of allowable file extensions, which will help to avoid CWE-434.

Phases: Architecture and Design; Operation
Store library, include, and utility files outside of the web document root, if possible. Otherwise, store them in a separate directory and use the web server's access control capabilities to prevent attackers from directly requesting them. One common practice is to define a fixed constant in each calling program, then check for the existence of the constant in the library/include file; if the constant does not exist, then the file was directly requested, and it can exit immediately.
This significantly reduces the chance of an attacker being able to bypass any protection mechanisms that are in the base program but not in the include files. It will also reduce your attack surface.

Phases: Architecture and Design; Implementation
Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly through API calls.
Many file inclusion problems occur because the programmer assumed that certain inputs could not be modified, especially for cookies and URL components.

• Source Link: https://staging.horangi.com/storyfier/detect/75ed6dc6-a6b8-4381-a856-26e4013cfc80/84f170de6b8af57dfc5517a59319afc2

Details

• ID: 4e8c8d0b607d35ef212e3040718672eb
• Affected Hosts: ['https://uod-offroad.com/']
• First seen: 2018-01-30 04:26:16

Description

X-Frame-Options header is not included in the HTTP response to protect against 'ClickJacking' attacks.

Recommendation:

Most modern Web browsers support the X-Frame-Options HTTP header. Ensure it's set on all web pages returned by your site (if you expect the page to be framed only by pages on your server (e.g. it's part of a FRAMESET) then you'll want to use SAMEORIGIN, otherwise if you never expect the page to be framed, you should use DENY. ALLOW-FROM allows specific websites to frame the web page in supported web browsers).

Details

• ID: 1ba90c349648e1c06b94c2ce3318fbf8
• Affected Hosts: ['https://uod-offroad.com/products/jk-hd-steering-kit-drag-link-over-knuckle.oembed?query=query+AND+1%3D1+--+']
• First seen: 2018-09-17 13:44:00

Description

SQL injection may be possible.

Recommendation:

Do not trust client side input, even if there is client side validation in place.
In general, type check all data on the server side.
If the application uses JDBC, use PreparedStatement or CallableStatement, with parameters passed by '?'
If the application uses ASP, use ADO Command Objects with strong type checking and parameterized queries.
If database Stored Procedures can be used, use them.
Do not concatenate strings into queries in the stored procedure, or use 'exec', 'exec immediate', or equivalent functionality!
Do not create dynamic SQL queries using simple string concatenation.
Escape all data received from the client.
Apply a 'whitelist' of allowed characters, or a 'blacklist' of disallowed characters in user input.
Apply the principle of least privilege by using the least privileged database user possible.
In particular, avoid using the 'sa' or 'db-owner' database users. This does not eliminate SQL injection, but minimizes its impact.
Grant the minimum database access that is necessary for the application.

Details

• ID: 64f25277527397d47e45d64474f4bcba
• Affected Hosts: ['https://uod-offroad.com/cart?query=query+AND+1%3D1+--+']
• First seen: 2018-07-23 13:28:57

Description

SQL injection may be possible.

Recommendation:

Do not trust client side input, even if there is client side validation in place.
In general, type check all data on the server side.
If the application uses JDBC, use PreparedStatement or CallableStatement, with parameters passed by '?'
If the application uses ASP, use ADO Command Objects with strong type checking and parameterized queries.
If database Stored Procedures can be used, use them.
Do not concatenate strings into queries in the stored procedure, or use 'exec', 'exec immediate', or equivalent functionality!
Do not create dynamic SQL queries using simple string concatenation.
Escape all data received from the client.
Apply a 'whitelist' of allowed characters, or a 'blacklist' of disallowed characters in user input.
Apply the principle of least privilege by using the least privileged database user possible.
In particular, avoid using the 'sa' or 'db-owner' database users. This does not eliminate SQL injection, but minimizes its impact.
Grant the minimum database access that is necessary for the application.

• Name: OS End Of Life Detection
• ID: 98e6383ed8df45fa6cfa3997f3db1c81
• Affected Hosts: ['176.28.50.165']
• Description: The "Ubuntu" Operating System on the remote host has reached the end of life.

CPE: cpe:/o:canonical:ubuntu_linux:10.04
Installed version,
build or SP: 10.04
EOL date: 2015-04-30
EOL info: https://wiki.ubuntu.com/Releases

• First seen: 2018-06-29 04:42:09
• Recommendation:
• Source Link: https://staging.horangi.com/storyfier/detect/75ed6dc6-a6b8-4381-a856-26e4013cfc80/98e6383ed8df45fa6cfa3997f3db1c81

Details

• ID: dd5423f8bff49264b8ddae31e119bf4f
• Affected Hosts: ['http://testphp.vulnweb.com/listproducts.php?cat=4+AND+1%3D1+--+']
• First seen: 2018-06-29 04:18:47

Description

SQL injection may be possible.

Recommendation:

Do not trust client side input, even if there is client side validation in place.
In general, type check all data on the server side.
If the application uses JDBC, use PreparedStatement or CallableStatement, with parameters passed by '?'
If the application uses ASP, use ADO Command Objects with strong type checking and parameterized queries.
If database Stored Procedures can be used, use them.
Do not concatenate strings into queries in the stored procedure, or use 'exec', 'exec immediate', or equivalent functionality!
Do not create dynamic SQL queries using simple string concatenation.
Escape all data received from the client.
Apply a 'whitelist' of allowed characters, or a 'blacklist' of disallowed characters in user input.
Apply the principle of least privilege by using the least privileged database user possible.
In particular, avoid using the 'sa' or 'db-owner' database users. This does not eliminate SQL injection, but minimizes its impact.
Grant the minimum database access that is necessary for the application.

Risk: Critical

Code

Description

JavaScript variable scope can be particularly difficult to understand and get right. The situation gets even worse when you consider the accidental creation of global variables, which is what happens when you declare a variable inside a function or the for clause of a for-loop without using the let, const or var keywords.

let and const were introduced in ECMAScript 2015, and are now the preferred keywords for variable declaration.

Noncompliant Code Example

function f(){
  i = 1;         // Noncompliant; i is global
for (j = 0; j < array.length; j++) {  // Noncompliant; j is global now too

// ...

}

}

Compliant Solution

function f(){
  var i = 1;
for (let j = 0; j < array.length; j++) {

// ...

}

}

Recommendation

Add the "let", "const" or "var" keyword to this declaration of "transposedElement" to make it explicit.

Horangi detected this issue on 2019-03-26 15:48:51

Details

• ID: a9171afba1f942993172523f39678d8d
• Affected Hosts:
  • http://testphp.vulnweb.com/cart.php
• First seen: 2018-06-29 04:18:47

Description

X-Frame-Options header is not included in the HTTP response to protect against 'ClickJacking' attacks.

Recommendation

Most modern Web browsers support the X-Frame-Options HTTP header. Ensure it's set on all web pages returned by your site (if you expect the page to be framed only by pages on your server (e.g. it's part of a FRAMESET) then you'll want to use SAMEORIGIN, otherwise if you never expect the page to be framed, you should use DENY. ALLOW-FROM allows specific websites to frame the web page in supported web browsers).