"Back" button is not working properly

[mauromalara]

Wazuh	Elastic	Rev	Security
4.3	7.x	4301-1	Basic, ODFE, Xpack

Browser
Firefox

Description The App redirects incorrectly when selecting the back button inside the rule's file.

Preconditions

1. Create a custom rule that may not have any related rules, e.g:

<var name="BAD_WORDS">error|warning|failure</var>

<group name="syslog,errors,">
  <rule id="100001" level="2">
    <match>$BAD_WORDS</match>
    <description>Error found.</description>
  </rule>
</group>

Steps to reproduce

1. Navigate to 'Management / Rules'
2. Select a rule
3. Click on the file inside the related rule (same rule)
4. Click on the back button

Expected Result

1. The App should show the content of the rule

Actual Result

1. The App redirects to another rule

Screenshots

https://user-images.githubusercontent.com/39094716/164049082-3bab7aa7-af7a-46a8-810a-16d92e94e82d.mp4

[Mayons]

Reproducible on RC6 Kibana 7.16.3

[gdiazlo]

There is already a rule with the ID 100001. The issue here is that the system allowed creating a rule with a duplicated ID. When the router goes back to the rule by ID, the query returns the first match, which in this case was the rule which was already present.

@wazuh/framework does the API check whether a rule ID exists before saving it?

[vicferpoy]

To confirm what @gdiazlo said, these are the Wazuh API requests that were done during the same steps showed in the video:

2022/04/27 11:58:29 INFO: wazuh-wui 172.31.21.140 "PUT /rules/files/testing_mauro.xml" with parameters {"overwrite": "false"} and body {} done in 0.013s: 200
2022/04/27 11:58:29 INFO: wazuh-wui 172.31.21.140 "GET /cluster/status" with parameters {} and body {} done in 0.014s: 200
2022/04/27 11:58:31 INFO: wazuh-wui 172.31.21.140 "GET /cluster/configuration/validation" with parameters {} and body {} done in 1.143s: 200
2022/04/27 11:58:31 INFO: wazuh-wui 172.31.21.140 "GET /cluster/status" with parameters {} and body {} done in 0.015s: 200
2022/04/27 11:58:34 INFO: wazuh-wui 172.31.21.140 "GET /rules" with parameters {"offset": "0", "limit": "15"} and body {} done in 0.793s: 200
2022/04/27 11:58:42 INFO: wazuh-wui 172.31.21.140 "GET /rules" with parameters {"offset": "0", "limit": "15", "search": "testing_mauro"} and body {} done in 0.870s: 200
2022/04/27 11:58:43 INFO: wazuh-wui 172.31.21.140 "GET /rules" with parameters {"offset": "0", "limit": "15", "search": "testing_mauro"} and body {} done in 1.315s: 200
2022/04/27 11:58:48 INFO: wazuh-wui 172.31.21.140 "GET /rules" with parameters {"filename": "testing_mauro.xml"} and body {} done in 0.760s: 200
2022/04/27 11:58:51 INFO: wazuh-wui 172.31.21.140 "GET /rules/files/testing_mauro.xml" with parameters {"raw": "true"} and body {} done in 0.017s: 200
2022/04/27 11:58:59 INFO: wazuh-wui 172.31.21.140 "GET /rules" with parameters {"rule_ids": "100001"} and body {} done in 0.775s: 200
2022/04/27 11:59:00 INFO: wazuh-wui 172.31.21.140 "GET /rules" with parameters {"offset": "0", "limit": "15", "search": "testing_mauro"} and body {} done in 1.626s: 200
2022/04/27 11:59:01 INFO: wazuh-wui 172.31.21.140 "GET /rules" with parameters {"filename": "local_rules.xml"} and body {} done in 1.464s: 200

This request in particular (GET /rules" with parameters {"rule_ids": "100001"} and body {}) returns both rules, ordered by files (local_rules.xml is read first):

In the WUI we are probably saving response['data']['affected_items'][0], leading to this issue.

However, adding a new rule with duplicated IDs should not be possible. That is the purpose of this endpoint:

2022/04/27 11:58:31 INFO: wazuh-wui 172.31.21.140 "GET /cluster/configuration/validation" with parameters {} and body {} done in 1.143s: 200

As we can see, that endpoint returns no invalid configurations:

We can even check it at a lower level:

[root@ip-172-31-19-111 ec2-user]# grep -R "100001" /var/ossec/etc/rules/
/var/ossec/etc/rules/local_rules.xml:  <rule id="100001" level="5">
/var/ossec/etc/rules/testing_mauro.xml:  <rule id="100001" level="2">

[root@ip-172-31-19-111 ec2-user]# service wazuh-manager restart
Restarting wazuh-manager (via systemctl):                  [  OK  ]

[root@ip-172-31-19-111 ec2-user]# service wazuh-manager status
wazuh-clusterd is running...
wazuh-modulesd is running...
wazuh-monitord is running...
wazuh-logcollector is running...
wazuh-remoted is running...
wazuh-syscheckd is running...
wazuh-analysisd is running...
wazuh-maild not running...
wazuh-execd is running...
wazuh-db is running...
wazuh-authd is running...
wazuh-agentlessd not running...
wazuh-integratord not running...
wazuh-dbd not running...
wazuh-csyslogd not running...
wazuh-apid is running...

[root@ip-172-31-19-111 ec2-user]#

This is by no means an API issue, but I do not think this should be allowed. Further testing and investigation is mandatory to evaluate if this is a bug with analysisd.