Spring Security
  1. Spring Security
  2. SEC-1543

IpAddressMatcher does not act like expected

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 3.0.2
    • Fix Version/s: 3.0.4, 3.1.0.M2
    • Component/s: Web
    • Labels:
      None

      Description

      When configuring a constraint like "hasIpAddress('X.X.X.X')", Spring-Security usees the class org.springframework.security.web.util.IpAddressMatcher to compare the given IP with the IP from the request.

      Unfortunatly, IpAddressMatcher throws an IllegalArgumentException, when the given IP and the IP from the request are of different type. This happens for example, when the request uses an IPv6-Address, but the Address used in "hasIpAddress()" was an IPv4-Address. The unexpected outcome of this behavior is, that any IPv6-request matching the resource will only see an error-page!

      I suggest, that IpAddressMatcher responds with "false", if the given Address and the Address in the Request are of different type. That would solve this issue and is also the behavior I would expect: two IP-Addresses of different type are simply always not equal!

        Activity

        Hide
        Luke Taylor added a comment - - edited

        The original intention was that it is considered an error to configure a security contraint with an IPv4 address on an IPv6 network. Do you actually have a dual-IP setup where you are using both simultaneously? If that's the case then your suggestion would make sense to me, but if it is a choice between one or the other then I would say it is a configuration issue which should be flagged up as such. (Disclaimer - I don't know a great deal about Ipv6 networks ).

        Show
        Luke Taylor added a comment - - edited The original intention was that it is considered an error to configure a security contraint with an IPv4 address on an IPv6 network. Do you actually have a dual-IP setup where you are using both simultaneously? If that's the case then your suggestion would make sense to me, but if it is a choice between one or the other then I would say it is a configuration issue which should be flagged up as such. (Disclaimer - I don't know a great deal about Ipv6 networks ).
        Hide
        Kai Moritz added a comment -

        I also do not know much about IPv6.
        But I think, nowadays it is a very common situation,
        that both protocol versions are enabled in parallel – especially, if you are on your local
        test-machine (all linux distrbutions I am working with
        now act like this)!

        But clearly you are right: making it configurable would
        be the best solution! Nevertheless, if you take tjat path,
        I would suggest, that throwing the error would not become
        the default behaviour.

        Show
        Kai Moritz added a comment - I also do not know much about IPv6. But I think, nowadays it is a very common situation, that both protocol versions are enabled in parallel – especially, if you are on your local test-machine (all linux distrbutions I am working with now act like this)! But clearly you are right: making it configurable would be the best solution! Nevertheless, if you take tjat path, I would suggest, that throwing the error would not become the default behaviour.
        Hide
        Andrew Rawnsley added a comment -

        I will second Kai's suggestion that this isn't an exceptional situation. Part of the issue is that, as Kai suggested, that it is a common now. Both protocols are active in OS X by default, and localhost on OS X comes through as ::1 and not 127.0.0.1.

        More importantly, this behavior dictates that I can only deploy an application on IPv4 or 6 networks based on my choice of hasIpAddress filters, without maintaining multiple versions of said filters. That shouldn't be making the choice for me.

        (Our situation is like that - our production systems (linux) only have 4 active, but test machines (OS X) have both, and due to the aforementioned localhost issue...)

        There is a workaround - add -Djava.net.preferIPv4Stack=true to thejvm startup, and everything comes through ipv4. But I feel the proper solution is as Kai suggested - that a protocol mismatch return false and not an exception.

        Show
        Andrew Rawnsley added a comment - I will second Kai's suggestion that this isn't an exceptional situation. Part of the issue is that, as Kai suggested, that it is a common now. Both protocols are active in OS X by default, and localhost on OS X comes through as ::1 and not 127.0.0.1. More importantly, this behavior dictates that I can only deploy an application on IPv4 or 6 networks based on my choice of hasIpAddress filters, without maintaining multiple versions of said filters. That shouldn't be making the choice for me. (Our situation is like that - our production systems (linux) only have 4 active, but test machines (OS X) have both, and due to the aforementioned localhost issue...) There is a workaround - add -Djava.net.preferIPv4Stack=true to thejvm startup, and everything comes through ipv4. But I feel the proper solution is as Kai suggested - that a protocol mismatch return false and not an exception.
        Hide
        Luke Taylor added a comment -

        I think this makes sense too, so I've changed the code to return false for different address types.

        Show
        Luke Taylor added a comment - I think this makes sense too, so I've changed the code to return false for different address types.

          People

          • Assignee:
            Luke Taylor
            Reporter:
            Kai Moritz
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: