Describe the bug IpAddressMatcher.matches(var) returns true when var is null
To Reproduce create a new IpAddressMatcher with an ip address or subnet to check against, afterwards check a variable with a null value against the IpAddressMatcher that just got created
Expected behavior the IpAddressMatcher.matches call should return false when checking against a null value
Comment From: sjohnr
@BeauTaapken, thanks for reaching out!
IpAddressMatcher uses the java.net.InetAddress under the covers to resolve the IP address. That class assumes that null means the loopback address. I believe this behavior has been in place for quite some time. Is there a reason that you believe it should be changed? Is there some place in Spring Security where null is being passed, or are you seeing this behavior when using the class in your own application (outside Spring Security)?
Comment From: BeauTaapken
I'm seeing this behaviour when implementing the IpAddressMatcher class from springboot security in my own application. The way the code I worked on was implemented, it grabbed a value that can be null when postman is used (possibly with curl as well, but I haven't tested that specifically). personally, I and the other people I talked with agree that a null value shouldn't return true when sent because no IP is given, meaning the IP address given does not match.
Comment From: sjohnr
@BeauTaapken thanks for the information about your use case.
I agree that this behavior is not intuitive. The IpAddressMatcher class is used internally in the framework in such a way that this is never a problem. Unfortunately, because the class is exposed as public, it can be used by applications such as yours for purposes outside the framework's control. This class has been in the framework with this behavior for over 12 years, so I don't believe we could make this change without impacting an unknown number of users. We could add a flag to make it optional, but the workaround (see below) makes this fairly unnecessary. In addition, this is the behavior of the java.net.InetAddress class, so it may be expected behavior for many applications even though it is not intuitive at first glance.
I'm sure you're aware, but you can work around this behavior in your own application, as in the following example:
public boolean ipAddressMatches(String ipAddress, String address) {
Assert.notNull(ipAddress, "ipAddress cannot be null");
return (address == null) ? false : new IpAddressMatcher(ipAddress).matches(address);
}
Considering all of this, I don't believe we would want to proceed with a fix to adjust this behavior, so I'm going to close this issue for now.