diff --git a/app/views/tutorial/a1.html b/app/views/tutorial/a1.html index 2587ce97e..c289611f0 100644 --- a/app/views/tutorial/a1.html +++ b/app/views/tutorial/a1.html @@ -237,10 +237,8 @@
2. NoSQL Injection
true.

The same results can be achieved using other comparison operator such as $ne.

-

The demo application is vulnerable to the NoSQL Injection. For example, on the Allocations page, running a search with a malicious input `1'; return 1 == '1` retrieves allocations for all the users in the database.

-

SSJS Attack Mechanics

@@ -268,26 +266,8 @@
$where operator
stocks field as specified by threshold. The problem is that these parameters are not validated, filtered, or sanitised, and vulnerable to SSJS Injection.

- - -
-
NoSQL SSJS Injection
-

- An attacker can send the following input for the - threshold field in the requests query, which will create a valid JavaScript expression and satisfy the - $where query as well, resulting in a DoS attack on the MongoDB server: -

- - 
http://localhost:4000/allocations/2?threshold=5';while(true){};'
-

- You can also just drop the following into the Stocks Threshold input box: -

- 
';while(true){};'
-
- -

How Do I Prevent It?

@@ -299,9 +279,29 @@

How Do I Prevent It?

  • Input Validation: Validate inputs to detect malicious values. For NoSQL databases, also validate input types against expected types
  • Least Privilege: To minimize the potential damage of a successful injection attack, do not assign DBA or admin type access rights to your application accounts. Similarly minimize the privileges of the operating system account that the database process runs under.
    • - For the above NoSQL vulnerability, bare minimum fixes can be found in +
    +
    +
    +
    +

    Source Code Example

    +
    +
    +

    Note: These vulnerabilities are not present when using an Atlas M0 cluster with NodeGoat.

    +

    The Allocations page of the demo application is vulnerable to NoSQL Injection. For example, set the stocks threshold filter to:

    + 
    1'; return 1 == '1
    +

    This will retrieve allocations for all the users in the database.

    +

    An attacker could also send the following input for the + threshold field in the request's query, which will create a valid JavaScript expression and satisfy the + $where query as well, resulting in a DoS attack on the MongoDB server: +

    + 
    http://localhost:4000/allocations/2?threshold=5';while(true){};'
    +

    + You can also just drop the following into the Stocks Threshold input box: +

    + 
    ';while(true){};'
    +

    For these vulnerabilities, bare minimum fixes can be found in allocations.html and - allocations-dao.js + allocations-dao.js

    @@ -313,12 +313,12 @@

    How Do I Prevent It?

    - + A1 - 3 Log Injection

    -
    +
    @@ -360,7 +360,8 @@
    2. Log Injection Escalation

    An attacker may craft malicious input in hope of an escalated attack where the target isn't the logs themselves, but rather the actual logging system. For example, if an application has a back-office web app that manages viewing and tracking the logs, then an attacker may send an XSS payload into the log, which may not result in log forging on the log itself, but when viewed by a system administrator on the log viewing web app then it may compromise it and result in XSS injection that if the logs app is vulnerable.

    - +
    +

    How Do I Prevent It?

    @@ -387,9 +388,15 @@

    How Do I Prevent It?

    console.log('Error: attempt to login with invalid user: %s', ESAPI.encoder().encodeForJavaScript(userName)); console.log('Error: attempt to login with invalid user: %s', ESAPI.encoder().encodeForURL(userName)); - - For the above Log Injection vulnerability, example and fix can be found at - routes/session.js +
    +
    +
    +
    +

    Source Code Example

    +
    +
    +

    For the above Log Injection vulnerability, example and fix can be found at + routes/session.js