Project

General

Profile

Actions

Bug #13493

open

"id-assoc pd ID" allows non-numbers to be entered

Added by Flole Systems 3 months ago. Updated 9 days ago.

Status:
Feedback
Priority:
Very Low
Assignee:
Category:
Interfaces
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
23.01
Release Notes:
Default
Affected Version:
Affected Architecture:

Description

When entering "F" for example ad id-assoc pd ID in the interfaces Tab and saving it magically disappears without any error. Either an error should be shown or only numeric values should be accepted for that textbox.

Actions #1

Updated by Danilo Zrenjanin 3 months ago

  • Priority changed from Normal to Very Low

Yes, I can replicate this on the:

22.05-RELEASE (amd64)
built on Wed Jun 22 18:56:13 UTC 2022
FreeBSD 12.3-STABLE

https://www.freebsd.org/cgi/man.cgi?query=dhcp6c.conf&apropos=0&sektion=0&manpath=FreeBSD+10.3-RELEASE+and+Ports&arch=default&format=html#end

ID is a decimal number of IAID.  If omitted, the value 0 will be used by default.

The same issue appears when defining non-numerical ID in `na' (non-temporary address allocation) and `pd'(prefix delegation) filed.

Having input validation for these fields would be helpful.

Actions #2

Updated by Danilo Zrenjanin 3 months ago

  • Status changed from New to Confirmed
Actions #3

Updated by Jim Pingle about 2 months ago

  • Plus Target Version changed from 22.11 to 23.01
Actions #4

Updated by Jim Pingle 15 days ago

  • Assignee set to Jim Pingle

Looks like several fields get tested to ensure they are numeric ints before being stored, but don't have corresponding checks in places where they can generate input errors.

These are not all together in the code, this is just the fields I found collected together:

// Under a block of code that runs when $_POST['type6'] == "dhcp6" :
                if (is_numericint($_POST['adv_dhcp6_id_assoc_statement_address_id'])) {
                    $wancfg['adv_dhcp6_id_assoc_statement_address_id'] = $_POST['adv_dhcp6_id_assoc_statement_address_id'];
                }
                if (is_numericint($_POST['adv_dhcp6_id_assoc_statement_prefix_id'])) {
                    $wancfg['adv_dhcp6_id_assoc_statement_prefix_id'] = $_POST['adv_dhcp6_id_assoc_statement_prefix_id'];
                }
                if (is_numericint($_POST['adv_dhcp6_prefix_interface_statement_sla_id'])) {
                    $wancfg['adv_dhcp6_prefix_interface_statement_sla_id'] = $_POST['adv_dhcp6_prefix_interface_statement_sla_id'];
                }
                if (is_numericint($_POST['adv_dhcp6_prefix_interface_statement_sla_len'])) {
                    $wancfg['adv_dhcp6_prefix_interface_statement_sla_len'] = $_POST['adv_dhcp6_prefix_interface_statement_sla_len'];
                }

Actions #5

Updated by Jim Pingle 14 days ago

  • Status changed from Confirmed to Feedback
  • % Done changed from 0 to 100
Actions #6

Updated by Flole Systems 11 days ago

Wouldn't it be possible to limit the possible characters in the web interface aswell? Using the HTML5 attribute type="number" it should prevent any non-numbers to be entered. Or should it be put into a separate issue as this can most likely be added at multiple other places aswell?

Actions #7

Updated by Jim Pingle 9 days ago

Client-side validation in JS could probably be done to help guide users toward valid input, but that should be a separate issue if there isn't one already. Whether or not it works on that specific type of form field is the question. Ultimately we need the server-side validation in place first (this issue) because we can't trust client validation on its own, as clients themselves can be malicious.

Actions

Also available in: Atom PDF