We couldn't load all Actvitity tabs. Refresh the page to try again.
If the problem persists, contact your Jira admin.
Uploaded image for project: 'camunda BPM'
  1. camunda BPM
  2. CAM-13051

Engine-rest maxResults has no default value which may cause DoS

    • Icon: Bug Report Bug Report
    • Resolution: None
    • Icon: L3 - Default L3 - Default
    • None
    • 7.13.0
    • engine

      Environment (Required on creation):

      Camunda BPM 7.13

      Description (Required on creation; please attach any relevant screenshots, stacktraces, log files, etc. to the ticket):

      Proper request to history REST API may cause server to go down.

      Steps to reproduce:

      1. Create a lot of process-instances
      2. Make an GET request to /engine-rest/history/process-instance without any parameters

      Observed Behavior:

      Server goes down.

      Expected behavior:

      Server successfully makes a response.

      Root Cause

      Almost all REST APIs has no default value for maxResults parameter, causing them to return all results by default. This can cause a huge response body for history API responses and, in some cases, for other APIs. Huge response body may lead to several java, http-server or http-protocol level errors causing engine service or the whole application eventually to go down.

      Solution Ideas:

      Provide reasonable default value for maxResults parameter in all REST APIs or make this parameter mandatory and return 400 if it is absent.

       

        This is the controller panel for Smart Panels app

            Loading...
            Uploaded image for project: 'camunda BPM'
            1. camunda BPM
            2. CAM-13051

            Engine-rest maxResults has no default value which may cause DoS

              • Icon: Bug Report Bug Report
              • Resolution: None
              • Icon: L3 - Default L3 - Default
              • None
              • 7.13.0
              • engine

                Environment (Required on creation):

                Camunda BPM 7.13

                Description (Required on creation; please attach any relevant screenshots, stacktraces, log files, etc. to the ticket):

                Proper request to history REST API may cause server to go down.

                Steps to reproduce:

                1. Create a lot of process-instances
                2. Make an GET request to /engine-rest/history/process-instance without any parameters

                Observed Behavior:

                Server goes down.

                Expected behavior:

                Server successfully makes a response.

                Root Cause

                Almost all REST APIs has no default value for maxResults parameter, causing them to return all results by default. This can cause a huge response body for history API responses and, in some cases, for other APIs. Huge response body may lead to several java, http-server or http-protocol level errors causing engine service or the whole application eventually to go down.

                Solution Ideas:

                Provide reasonable default value for maxResults parameter in all REST APIs or make this parameter mandatory and return 400 if it is absent.

                 

                  This is the controller panel for Smart Panels app

                        miklas.boskamp Miklas Boskamp
                        ov7a Vlad Chesnokov
                        Votes:
                        0 Vote for this issue
                        Watchers:
                        2 Start watching this issue

                          Created:
                          Updated:
                          Resolved:

                              miklas.boskamp Miklas Boskamp
                              ov7a Vlad Chesnokov
                              Votes:
                              0 Vote for this issue
                              Watchers:
                              2 Start watching this issue

                                Created:
                                Updated:
                                Resolved: