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
| [reply] |
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". ;-)
| [reply]
[d/l]
[select] |
% 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...)
| [reply]
[d/l] |
| [reply] |
Is it possible to show the code as it would be put in to this line :
if ($ENV{REMOTE_ADDR} eq '180.76.6.175') {
| [reply]
[d/l] |
You mean for the "Easy answer" .. yes ..
if ($ENV{REMOTE_ADDR} =~ /^180\.0?76\.0{0,2}6\.\d{1,3}$/) {
(Untested).
"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
| [reply]
[d/l] |
So...
if ($ENV{REMOTE_ADDR} eq '180.76.6.175') {
works as
if ($ENV{REMOTE_ADDR} =~ /^180\.0?76\.0{0,2}6\.\d{1,3}$/) {
what would a wild card for :
if ($ENV{REMOTE_ADDR} eq '180.76.6.') {
and
if ($ENV{REMOTE_ADDR} eq '180.76.') {
look like ?
Sorry if the question sounds so noobish, but the use of wildcards for this particular circumstance is beating up my brain. Technically all I am trying to do is put some code in to my program to keep out various IPs that are able to run my progs in the cgi-bin directory EVEN though their IP is totally banned in the .htaccess file. God only knows why the cgi-bin directory does not benefit from the same protection as all other directories under the .htaccess file as it leaves the progs open to abusive bandwidth consumption. | [reply]
[d/l] |
