Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

Re: Wildcard usage for REMOTE_ADDR comparison

by NetWallah (Abbot)
on Oct 20, 2012 at 03:47 UTC ( #1000084=note: print w/ replies, xml ) Need Help??


in reply to Wildcard usage for REMOTE_ADDR comparison

The easy answer is to use a regular expression like m/^180\.76\.6\./,
but the correct answer for production work is to use a module like NetAddr::IP to match tie IP/subnet (call the "contains" method, after first creating a subnet object).

One reason why is for the case where you are presented with an address text like "180.076.006.001", or an invalid address like "180.176.6.300"

             "By three methods we may learn wisdom: First, by reflection, which is noblest; Second, by imitation, which is easiest; and third by experience, which is the bitterest."           -Confucius


Comment on Re: Wildcard usage for REMOTE_ADDR comparison
Re^2: Wildcard usage for REMOTE_ADDR comparison
by afoken (Parson) on Oct 20, 2012 at 06:04 UTC
    One reason why is for the case where you are presented with an address text like "180.076.006.001", or an invalid address like "180.176.6.300".

    $ENV{'REMOTE_ADDR'} looks like CGI or a CGI emulation like FastCGI. In both cases, the source of this data is the web server, converting binary data from socket functions to a readable string. No webserver I know delivers IPv4 addresses with leading zeros in $ENV{'REMOTE_ADDR'}. Perhaps some embedded one does, to save some bytes in sprintf, but then it would be rather unlikely that you can use Perl there, on a machine where every byte has to be used carefully.

    Invalid addresses in $ENV{'REMOTE_ADDR'} can have only three sources:

    An intentionally malicious webserver
    Why are you running your code there?
    A hacked webserver
    Someone can control the webserver, or at least invoke your CGI with malicious data. Looks like the webserver was not properly administrated. So why are you running your code there?
    A bug in the webserver.
    The CGI routines in the major webservers should be stable, so it is very unlikely that you find such a bug there. So, your code must run under control of some pre-alpha-quality webserver. So once again, why are you running your code there?

    Of course, it does not hurt to validate all input, including the CGI environment variables. Validating $ENV{'REMOTE_ADDR'} as an IPv4 address has the nice side effect of not accepting IPv6 addresses. So the CGI program, written to support only IPv4 addresses, will fail early and securely instead of misreading an IPv6 address as an IPv4 address when called from an IPv6 client.

    Alexander

    --
    Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
Re^2: Wildcard usage for REMOTE_ADDR comparison
by fullermd (Curate) on Oct 20, 2012 at 09:21 UTC

    One reason why is for the case where you are presented with an address text like "180.076.006.001",

    Of note is that that isn't the same IP. v4 addresses by convention work like C-style numeric constants, so a leading 0 means it's in octal:

    % ping 180.076.006.001 PING 180.076.006.001 (180.62.6.1): 56 data bytes

    (just one of the many scary things you can do with v4 addresses...)

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1000084]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (8)
As of 2014-12-21 16:42 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (106 votes), past polls