security issue moduleservices/log does not require authentication
Question

Hi everybody,


As far as I know moduleservices/log is a platform endpoint used internally for logging.

Part of our security testing has highlighted that  this endpoint is not authenticated

So for example an unauthenticated post to 

curl -X POST "https://yourserver/yourmodule/moduleservices/log?clientTimeInMillis=1632103753732" -H "Content-Type: application/json" -d "{[\"instant\":\"2021-09-20T02:09:13.729Z\",\"logType\":\"error\",\"message\":\"anything\",\"moduleName\":null, \"stack\":\"stack trace \" }]"

actually hits the log file and could be used to write directly to the logs.


Has anyone come across this issue? or better still got a solution on how to restrict access to this?

Many thanks,

Andy

Solution

For anyone else with this issue, we raised a ticket with outsystems support for this issue, here is their response:

Context:

Our Security Office has analyzed this issue in the past and indeed found the same vulnerability that you are reporting. Below, I will share the rationale for this endpoint to be reachable as well as the mitigation that the platform has to minimize this.

The rationale for this endpoint not being authenticated is because it is necessary to be able to receive logs from applications while the user has not performed a login. If we waited for the user to log in, we would not be able to log eventual errors in the login procedure or in the application startup update, etc. Also, logs in applications where the user login is not required would not be possible.

Mitigation/Minimize this problem:

The log service contains a throttling mechanism to avoid flooding the server with requests. By default, it is configured to 200 logs per second, however, this value can be customized if necessary.
 

This can be achieved by changing or adding the following parameter "OutSystems.HubEdition.Log.MaxLogsPerSecondInLogsEndpoint" in the table "ossys_parameter" 

*Please note that there is no future patch that will mitigate the vulnerability (due to the reasons previously mentioned). The only way for us to minimize it is by configuring the above parameter in case we detect an abnormal log writing activity.


We hope that this message clarifies your questions and helped you understand the rationale behind this problem. Since we do not foresee any further action items from our end, we will proceed and mark this ticket as "Solved".

However, should you require further assistance, please do not hesitate to reach out to us or you can reopen this ticket simply by replying to this communication.

Once again thank you for the time you have waited. We are always looking forward to help you.

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.