2 added 7 characters in body
source | link

I'd say you're right! They don't seem to have kept in mind that the HTTP header X-FORWARDED-FOR might return '; DROP TABLE users;--.

They suggest this in order to also lock sessions for people behind proxies, and name Tor as example. This is sort of stupid; Tor never forwards the original IP for obvious reasons. Moreover, it doesn't (shouldn't?) even look at the packet itself; it merely forwards it until it's out of the network. What's the use of a proxy if the original IP is forwarded anyway? Just lock it to the remote address, that's the only safe bet. Even if you were to validate the x-forwarded-for header as valid IPv4 or IPv6 address, it might still contain an arbitrary IP.

Below the example code on that page, they do think of local IPs and IPv6 (even though the IPv6 examples contain invalid addresses):

Keep in mind that in local environments, a valid IP is not returned, and usually the string :::1 or :::127 might pop up, thus adapt your IP checking logic.

But they should also have thought about that the header can contain arbitrary data. Nice find!

Since it's a wiki, I guess anyone with an account could edit the page. If not, you should contact them. This is indeed bad practice, and many people might even insert $IP unescaped into a database. It's usually not possible to spoof the REMOTE_ADDR environmental variable, so it should be safe under normal circumstances (though I wouldn't insert it unescaped even if that were the case), but the X-forwarded-for header breaks it all here.

I'd say you're right! They don't seem to have kept in mind that the HTTP header X-FORWARDED-FOR might return '; DROP TABLE users;--.

They suggest this in order to also lock sessions for behind proxies, and name Tor as example. This is sort of stupid; Tor never forwards the original IP for obvious reasons. Moreover, it doesn't (shouldn't?) even look at the packet itself; it merely forwards it until it's out of the network. What's the use of a proxy if the original IP is forwarded anyway? Just lock it to the remote address, that's the only safe bet. Even if you were to validate the x-forwarded-for header as valid IPv4 or IPv6 address, it might still contain an arbitrary IP.

Below the example code on that page, they do think of local IPs and IPv6 (even though the IPv6 examples contain invalid addresses):

Keep in mind that in local environments, a valid IP is not returned, and usually the string :::1 or :::127 might pop up, thus adapt your IP checking logic.

But they should also have thought about that the header can contain arbitrary data. Nice find!

Since it's a wiki, I guess anyone with an account could edit the page. If not, you should contact them. This is indeed bad practice, and many people might even insert $IP unescaped into a database. It's usually not possible to spoof the REMOTE_ADDR environmental variable, so it should be safe under normal circumstances (though I wouldn't insert it unescaped even if that were the case), but the X-forwarded-for header breaks it all here.

I'd say you're right! They don't seem to have kept in mind that the HTTP header X-FORWARDED-FOR might return '; DROP TABLE users;--.

They suggest this in order to also lock sessions for people behind proxies, and name Tor as example. This is sort of stupid; Tor never forwards the original IP for obvious reasons. Moreover, it doesn't (shouldn't?) even look at the packet itself; it merely forwards it until it's out of the network. What's the use of a proxy if the original IP is forwarded anyway? Just lock it to the remote address, that's the only safe bet. Even if you were to validate the x-forwarded-for header as valid IPv4 or IPv6 address, it might still contain an arbitrary IP.

Below the example code on that page, they do think of local IPs and IPv6 (even though the IPv6 examples contain invalid addresses):

Keep in mind that in local environments, a valid IP is not returned, and usually the string :::1 or :::127 might pop up, thus adapt your IP checking logic.

But they should also have thought about that the header can contain arbitrary data. Nice find!

Since it's a wiki, I guess anyone with an account could edit the page. If not, you should contact them. This is indeed bad practice, and many people might even insert $IP unescaped into a database. It's usually not possible to spoof the REMOTE_ADDR environmental variable, so it should be safe under normal circumstances (though I wouldn't insert it unescaped even if that were the case), but the X-forwarded-for header breaks it all here.

1
source | link

I'd say you're right! They don't seem to have kept in mind that the HTTP header X-FORWARDED-FOR might return '; DROP TABLE users;--.

They suggest this in order to also lock sessions for behind proxies, and name Tor as example. This is sort of stupid; Tor never forwards the original IP for obvious reasons. Moreover, it doesn't (shouldn't?) even look at the packet itself; it merely forwards it until it's out of the network. What's the use of a proxy if the original IP is forwarded anyway? Just lock it to the remote address, that's the only safe bet. Even if you were to validate the x-forwarded-for header as valid IPv4 or IPv6 address, it might still contain an arbitrary IP.

Below the example code on that page, they do think of local IPs and IPv6 (even though the IPv6 examples contain invalid addresses):

Keep in mind that in local environments, a valid IP is not returned, and usually the string :::1 or :::127 might pop up, thus adapt your IP checking logic.

But they should also have thought about that the header can contain arbitrary data. Nice find!

Since it's a wiki, I guess anyone with an account could edit the page. If not, you should contact them. This is indeed bad practice, and many people might even insert $IP unescaped into a database. It's usually not possible to spoof the REMOTE_ADDR environmental variable, so it should be safe under normal circumstances (though I wouldn't insert it unescaped even if that were the case), but the X-forwarded-for header breaks it all here.