This defect can cause corrupted data to be stored and lead to errors and
vulnerabilities in parts of the code that assume the data is valid and use it
without verification.

== Why is this an issue?

The `ACCEPT` statement causes data entered at the console or provided by the
operating system to be made available to the program in a specific data
element, without any validation or sanitization.

Thus, if this data is accepted in a particular format and used by other
procedures, the system is vulnerable to attack or malfunction.

=== What is the potential impact?

The lack of data validation and error checking when using the ACCEPT keyword in
COBOL can lead to a number of security problems.

==== Data integrity problems

Without any form of validation, the ACCEPT keyword can store arbitrary input
data, even if it does not conform to the expected format or type. This can lead
to data corruption, causing the program to behave unpredictably, crash, or
corrupt customer data.

==== Injection attacks

Malicious users can enter data that contains commands or queries that are then
executed by other procedures. This can lead to unauthorized access, data leaks,
or intrusions.

==== Denial of Service (DoS) attacks

An attacker could exploit this vulnerability to overload the system with large
amounts of data or special characters, causing the program to slow down or even
stop working, resulting in a denial of service.

== Exceptions

This rule ignores the uses of ``++ACCEPT FROM++`` with date/time-related inputs.

== How to fix it

=== Code examples

In this specific example, `USER-INPUT` is expected to be numeric by the system.

==== Noncompliant code example

[source,cobol]
----
IDENTIFICATION DIVISION.
PROGRAM-ID. EXAMPLE.

DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-NUMERIC PIC X VALUE 'N'.
01 USER-INPUT PIC X(4).

PROCEDURE DIVISION.
EXAMPLE-PROCEDURE.
    MOVE 'N' TO WS-NUMERIC.
    PERFORM UNTIL WS-NUMERIC = 'Y'
        DISPLAY 'ENTER YOUR 4 DIGIT RECORD NUMBER: ' NO ADVANCING
        ACCEPT USER-INPUT FROM CONSOLE *> Noncompliant
        MOVE 'Y' TO WS-NUMERIC
    END-PERFORM
    STOP RUN.
----

=== How does this work?

To mitigate the risks associated with the ACCEPT keyword in COBOL, you should
implement data validation and error checking, or directly avoid using `ACCEPT`
altogether.

==== Data Validation Routines

Before using the data coming from ACCEPT, validate the data using custom
routines. These routines should check if the data meets the expected format and
type. For example, if you're expecting a number, the routine should check if the
input data is indeed a number.

==== Limit Data Size

To prevent potential DoS attacks, limit the size of the data that can be
accepted and make sure that the exact same size is assumed and expected while
the data transmitted from `ACCEPT` to other routines.

== Resources

* OWASP - https://owasp.org/Top10/A03_2021-Injection/[Top 10 2021 Category A3 - Injection]
* OWASP - https://owasp.org/www-project-top-ten/2017/A1_2017-Injection[Top 10 2017 Category A1 - Injection]


ifdef::env-github,rspecator-view[]

'''
== Implementation Specification
(visible only on this page)

=== Message

Remove this use of "ACCEPT".


=== Highlighting

the ``++ACCEPT++`` statement - so both ``++ACCEPT++`` and what the input is being accepted into.


'''
== Comments And Links
(visible only on this page)

=== on 3 Nov 2015, 20:23:13 Ann Campbell wrote:
\[~pierre-yves.nicolas], I wrote the exception based on http://supportline.microfocus.com/Documentation/AcucorpProducts/docs/v6_online_doc/gtman3/gt3678.htm[this] but suspect it should be expanded to include more cases.

=== on 5 Nov 2015, 12:05:30 Pierre-Yves Nicolas wrote:
\[~ann.campbell.2] The documentation you found is specific to AcuCobol which adds many extensions on top of "standard" COBOL. I suggest to keep only the exception about date/time and to not activate that rule by default.

=== on 5 Nov 2015, 14:28:13 Ann Campbell wrote:
Okay [~pierre-yves.nicolas]. Done

=== on 21 Mar 2017, 17:54:00 Pierre-Yves Nicolas wrote:
\[~ann.campbell.2] The scope of this rule changed completely: it used to be "ACCEPT should not be used" and is now "Track uses of forbidden statements". I don't see how we can keep the exception for ``++ACCEPT FROM++`` with the new scope.

=== on 22 Mar 2017, 09:04:25 Ann Campbell wrote:
\[~pierre-yves.nicolas] I've reverted this rule & created RSPEC-3938

endif::env-github,rspecator-view[]
