> years back where there was an issue with CFHTTP. Seems that
> you could forge what would show up in the CGI vars using it.
> That 'feature' was yanked really fast. There's 2 different
> things here. The first is the reported information and the
> second is the 'true' information. The reported information
> (i.e. coming from the external client) can never be trusted
> as it can be forged. The 'true' information is usually true
> except when its not. Sometimes its easy to forge the 'true'
> information and sometimes not.
Any HTTP client can send whatever strings it wants to as HTTP headers, but
this can't be used to "forge" an IP address. Web servers don't look within
the HTTP request itself to find the IP address from which a request
originated, they are provided that information by the TCP/IP stack of the
underlying OS, which is responsible for resolving these sorts of things.
When you examine the CGI scope within CF, the only variables that are
provided by the HTTP request are preceded by the prefix "HTTP_".
As for forging the "true" information, it is certainly possible to construct
IP packets which contain an IP address different from the originating
machine's IP address. However, in that case, the server will send its
response to that IP address, instead of the originating machine. In most
cases, that would be pretty useless for an attacker trying to brute-force a
password. If the outbound router of the attacker is configured to reject
"source-routed" packets, it won't pass them anyway.
Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
voice: (202) 797-5496
fax: (202) 797-5444
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
