I came across a weird "IP address" trying to "hack" my site by means of wordpress in the url. The IP looks like "2oZnxW5sDpDwNchXRLfZ". This is the first time I'm seeing someone do that with an IP address in the 5 years I've been messing with OC. The Extension I'm building was able to partially fend it off, but because this isn't what was expected, it wasn't able to fully take care of it. What is that? How do I address it or future variations of it?
v3.0.4.0 php 8.1
I'm here for a reason, if your response is contact a/the developer, just don't reply.
Looking through the server logs and cpanel I found a "regular" IP address that corresponds with the time of this visit. Oddly, on other logs and cpanel I don't see a reference of this visit at this time. I would think all logs that take down IPs would have the same information. Anyway, assuming it is the same visit, is it possible that the php code garbled the IP address? Or is this a situation where it tricked the php code, but the server software was able to catch it...which leads me back to the original question of how do I address this. I'm capturing the ip address like this:
Code: Select all
if (!empty($_SERVER['HTTP_CLIENT_IP'])) {
$ip = $_SERVER['HTTP_CLIENT_IP'];
} elseif (!empty($_SERVER['HTTP_X_FORWARDED_FOR'])) {
$ip = $_SERVER['HTTP_X_FORWARDED_FOR'];
} else {
$ip = $_SERVER['REMOTE_ADDR'];
}
v3.0.4.0 php 8.1
I'm here for a reason, if your response is contact a/the developer, just don't reply.
Probably spoofed their IP address in the headers. I believe REMOTE_ADDR is more reliable.
Check out our ever-growing list of extensions for OpenCart here.
Some useful extensions for a better admin experience: Image File Manager Pro • Drag & Drop Sort Order
Reach out to us at hello@softmonke.com for your OpenCart web development needs or feedback for our extensions.
These ips are normaly set by proxies, load balancers,etc., might very well be that the proxy encodes the client ip address for "privacy" reasons.Joe1234 wrote: ↑Wed Nov 13, 2024 11:37 amLooking through the server logs and cpanel I found a "regular" IP address that corresponds with the time of this visit. Oddly, on other logs and cpanel I don't see a reference of this visit at this time. I would think all logs that take down IPs would have the same information. Anyway, assuming it is the same visit, is it possible that the php code garbled the IP address? Or is this a situation where it tricked the php code, but the server software was able to catch it...which leads me back to the original question of how do I address this. I'm capturing the ip address like this:Code: Select all
if (!empty($_SERVER['HTTP_CLIENT_IP'])) { $ip = $_SERVER['HTTP_CLIENT_IP']; } elseif (!empty($_SERVER['HTTP_X_FORWARDED_FOR'])) { $ip = $_SERVER['HTTP_X_FORWARDED_FOR']; } else { $ip = $_SERVER['REMOTE_ADDR']; }
So $_SERVER['REMOTE_ADDR'] would basically be the proxy ip address, that one you will also find in your server access logs making the request.
But the $_SERVER['HTTP_CLIENT_IP'] and $_SERVER['HTTP_X_FORWARDED_FOR'] may contain anything the proxy sees fit as long as they can relate it to the real client ip address.
So if you value to know the true client's ip address and the proxy will not provide it, block the proxy.
You can read more about the issue at https://github.com/opencart/opencart/issues/13927.
OpenCart should really only be using HTTP_CLIENT_IP and HTTP_X_FORWARDED_FOR if the store owner has configured it that way because they know they are using a proxy that sets those headers.
It's not so mush a problem with 3.0.x as they are only displayed. 4.x has bigger issues which haven't been completely fixed.
OpenCart should really only be using HTTP_CLIENT_IP and HTTP_X_FORWARDED_FOR if the store owner has configured it that way because they know they are using a proxy that sets those headers.
It's not so mush a problem with 3.0.x as they are only displayed. 4.x has bigger issues which haven't been completely fixed.
Even so, OC should check if any of those values, if present, contains valid public ip addresses (invalid and private addresses are useless) and even then one cannot be sure that those are indeed the ip addresses of the original requester as they can be set to anything.ADD Creative wrote: ↑Wed Nov 13, 2024 5:43 pmYou can read more about the issue at https://github.com/opencart/opencart/issues/13927.
OpenCart should really only be using HTTP_CLIENT_IP and HTTP_X_FORWARDED_FOR if the store owner has configured it that way because they know they are using a proxy that sets those headers.
It's not so mush a problem with 3.0.x as they are only displayed. 4.x has bigger issues which haven't been completely fixed.
With regard to the github discussion, ip actions like blocking or rate limiting etc. should only be undertaken when dealing with DOS attacks and then on the REMOTE_ADDR value, not on any forwarded ip value.
If the OC administrators themselves use a proxy, forward or reverse or both, they should be able to whitelist those proxies and trust the forwarding values.
Did it actually look exactly like that or was it just an IPv6 address?
UK OpenCart Hosting | OpenCart Audits | OpenCart Support - please email info@antropy.co.uk
Legendary Member
Bots just do that, it means that it does not know your site and is not "trying to hack your site" it is just automated to check for known vulnerabilities. It will have come to a 404. Thats it. Annoying as they are, try to take the view
a. It gives you things to work with to prevent them in the future.
b. It is not trying to hack the site
c. It provides information of who the bad actors are so you can build your own system of prevention.
DISCLAIMER:
You should not modify core files .. if you would like to donate a cup of coffee I will write it in a modification for you.
https://www.youtube.com/watch?v=zXIxDoCRc84
@paulfeakins, No it was not IP6
@mona, B/ Yes, I get it wasn't a "hack", but I figured that was the best way to label them. I'll use nefarious visitor next time unless I know it is actually a hack. A&C/ That's exactly what I'm doing.
I've been doing a little light reading on this now and came across a few things that stood out. Mainly this which I think sums it up pretty nicely:
Next question, if I switch the code around to use remote_addr first instead, should I also still look at the other two, and if they have different IP, flag the visitor as suspicious? Is there any legitimate reason that those will be different from remote_addr (I know I'm not behind a proxy or load balancer)?
@mona, B/ Yes, I get it wasn't a "hack", but I figured that was the best way to label them. I'll use nefarious visitor next time unless I know it is actually a hack. A&C/ That's exactly what I'm doing.
I've been doing a little light reading on this now and came across a few things that stood out. Mainly this which I think sums it up pretty nicely:
That along with the majority here saying stick with remote_addr I guess I have my answer.REMOTE_ADDR is the IP address established through a 3-way TCP/IP handshake. It is the IP the response will be sent back to. It is the only thing that your server has verified. Everything else is just arbitrary HTTP headers anyone could set.
Now, if you know that your server is running behind a proxy (e.g. a load balancer) which would mask the visitor's IP address (your server would only see the proxy's IP), but you know that the proxy is helpfully forwarding you the visitor's IP in an HTTP header (as workaround for this situation so your server can still see the visitor's IP), then and only then may you use one of these HTTP headers and only the one that you know your proxy is setting. If your server is not behind a proxy, use REMOTE_ADDR exclusively. Otherwise, consult your proxy's manual and implement according to the situation.
Next question, if I switch the code around to use remote_addr first instead, should I also still look at the other two, and if they have different IP, flag the visitor as suspicious? Is there any legitimate reason that those will be different from remote_addr (I know I'm not behind a proxy or load balancer)?
v3.0.4.0 php 8.1
I'm here for a reason, if your response is contact a/the developer, just don't reply.
They do seem to be legitimately set sometimes, I believe by some secure internet access services. If you look at the forwarded_ip column in the oc_order table you may see some set for legitimate orders. Probably more likely if you have business customers, as they will more likely use those services.
If you are just displaying it for reference there isn't really anything you need to change (doesn't apply to version 4.x). If you did want to test the value you can use filter_var($ip, FILTER_VALIDATE_IP) with some of the extra flags. https://www.php.net/manual/en/filter.co ... alidate-ip
If you are just displaying it for reference there isn't really anything you need to change (doesn't apply to version 4.x). If you did want to test the value you can use filter_var($ip, FILTER_VALIDATE_IP) with some of the extra flags. https://www.php.net/manual/en/filter.co ... alidate-ip
IPv6 uses hexadecimals. That gibberish string is definitely not IPv6.paulfeakins wrote: ↑Wed Nov 13, 2024 11:09 pmDid it actually look exactly like that or was it just an IPv6 address?
Anyway, found this (albeit rather old) answer on stackoverflow, which seems like it could be helpful: https://stackoverflow.com/a/7623231
Check out our ever-growing list of extensions for OpenCart here.
Some useful extensions for a better admin experience: Image File Manager Pro • Drag & Drop Sort Order
Reach out to us at hello@softmonke.com for your OpenCart web development needs or feedback for our extensions.
Who is online
Users browsing this forum: No registered users and 18 guests
