Bug #16106
closed
Input validation issue with Alias network address
0%
Description
Hello,
I was advised to post here after inquiring on Reddit about an input validation issue.
Please see the attached screenshot. When adding an Alias network address, you are able to unintentionally add a period to the end of an address, this will save and not work as intended causing a hard to spot security issue as the entire rule does not seem to function.
Files
Updated by Jim Pingle 21 days ago
The problem is that when you add a trailing dot it's a valid hostname, not an IP address. Hostnames are allowed in aliases, but since that particular hostname doesn't exist in DNS, it can't be resolved, so it doesn't end up being added to the table.
We have no idea if the user intended to do that or not. We can't just reject that since it's technically not invalid input, so it's not clear what, if anything we should do here.
Forcing the user to declare whether input should specifically be a hostname as an extra step is about the only thing you could do but that puts a ton of extra burden on users to catch a very rare case of user error.
Updated by Andrew Almond 14 days ago
When Save is clicked, the system could compare the value with the trimmed value but display a yellow warning at the top of the page with a message similar to A trailing '.' was detected in entry <entry value>. Confirm that this is intentional.
The value would still be saved exactly as entered, so no functional changes there. It would just display the warning message.
I could see this error happening if something is copied and the IP address was the last word of the sentence (e.g. Please add aliases for 172.16.0.0 and 10.0.0.0. This is needed to allow service xyz.)
Updated by Steven C 13 days ago
Jim Pingle wrote in #note-1:
The problem is that when you add a trailing dot it's a valid hostname, not an IP address. Hostnames are allowed in aliases, but since that particular hostname doesn't exist in DNS, it can't be resolved, so it doesn't end up being added to the table.
We have no idea if the user intended to do that or not. We can't just reject that since it's technically not invalid input, so it's not clear what, if anything we should do here.
Forcing the user to declare whether input should specifically be a hostname as an extra step is about the only thing you could do but that puts a ton of extra burden on users to catch a very rare case of user error.
Thank you for looking at this.
I can understand the issue but as it's such a critical function I find it hard to agree with keeping it as is.
Would a semantic check work? A regex check for an ip address that contains a period?
^\d{1,3}(\.\d{1,3}){3}\.$
Updated by Marcos M 13 days ago
- Status changed from New to Not a Bug
The current behavior is intended (not a bug).
Additional input validation could be considered as a feature request. However I'm not convinced it's worth the effort given that 1) there are other scenarios where IP addresses and hostnames overlap and 2) the ability to support either on the same alias and input field is a feature which outweighs the risk for typos.