#CGI.REMOTE_ADDR# sql injection?

Azadi wrote:
> from what i have read, it is pretty trivial to fake cgi.remote_addr on a
> linux system using direct socket & tcp/ip programming.

Unless the attacker is on the web server this will not work because of
the TCP handshake (the TCP connection is not fully established until the
final ACK from the client to the server - if the client spoofs it's IP
address then the server will send the SYN-ACK packet to the wrong computer).

Spoofing Referer is trivial. Spoofing Remote_addr is not possible in
99.99% of the cases (one way to spoof REMOTE_ADDR is to custom build the
web server if you have access to the source - for example Apache).

--
Mack

Adam Cameron wrote:
>> Here's a quick test file (adapted from the link you provided) which
>> shows that you cannot spoof REMOTE_ADDR or REMOTE_HOST:
>
> .... using that technique, anyhow.
>
> One could manually construct or alter the TCP/IP packets and change the
> address they're coming from.

I'm pretty sure you can't spoof the source IP address when using the TCP
protocol in the general case because of the 3-way handshake of TCP. UDP
is pretty trivial to spoof (unless the ISP filters outbound packets with
incorrect IP source addresses).

> But, to be honest, if someone's that dedicated to hacking your system,
> there'll probably find a way.
>
> Personally, I would never trust the veracity of a HTTP_ prefixed CGI
> variables for the reasons under discussion here, but I don't really feel
> very concerned about the possibilities of someone hacking CGI.remote_addr.

That's basically my opinion also: HTTP_* should be treated as untrusted
input, CGI.REMOTE_ADDR is safe (unless the attacker has control of your
web server - but at this point you have bigger problems).

> For the purposes of securing forms, I'd just set a session variable on the
> form-display page, and check the session varibale on the form-action page.

This the one way to protect against CSRF attacks for example.

--
Mack

did i sense a bit of that "great minds" thing you had with Ian on that
other thread here?...

i surely hope so... :)

Azadi Saryev
Sabai-dee.com
http://www.sabai-dee.com/

from what i have read, it is pretty trivial to fake cgi.remote_addr on a
linux system using direct socket & tcp/ip programming.
not many people would go to even that extent because faking/spoofing
cgi.remote_addr was usually intended to hide the originating ip - and
with anonymous and real proxies abound now this has become redundant.

on the other hand, faking/spoofing remote_addr to gain access to an
application or to execute malicious code - that's different. but it is
known that not many software apps rely on remote_addr - it is used
mostly in allowing remote admin of hardware devices like router for
instance.

but i guess with the late increase in sqli attacks, and many posts on
the subject mentioning code to log remote ip, it may be the next thing
those &^$^$%# &^%^$^% employ now that every second app is going to be
inserting remote ip address into db....

to be on the side of caution maybe just log it to a text file instead...

sorry, a bit of a wild rant, but then again it is wednesday evening here
and the beer is flowing...


Azadi Saryev
Sabai-dee.com
http://www.sabai-dee.com/

> Here's a quick test file (adapted from the link you provided) which
> shows that you cannot spoof REMOTE_ADDR or REMOTE_HOST:

... using that technique, anyhow.

One could manually construct or alter the TCP/IP packets and change the
address they're coming from.

But, to be honest, if someone's that dedicated to hacking your system,
there'll probably find a way.

Personally, I would never trust the veracity of a HTTP_ prefixed CGI
variables for the reasons under discussion here, but I don't really feel
very concerned about the possibilities of someone hacking CGI.remote_addr.

For the purposes of securing forms, I'd just set a session variable on the
form-display page, and check the session varibale on the form-action page.

I situations that need to be very very secure, I'd secure the app at
operating system level, and consider what level of external access is
appropriate. The only truely secure server is one that's in a locked room
and not connected to anything, after all ;-)

--
Adam

Ian Skinner wrote:
> Mack wrote:
>> nikos101 wrote:
>>> Could #CGI.REMOTE_ADDR# be spoofed to do sql injection?
>>
>> No, I don't think CGI.REMOTE_ADDR can be spoofed as it's set by the web
>> server and not by the client (client set headers have HTTP_ as a prefix).
>>
>
> Yes it is set by the web server. The spoofing comes in that the hacker
> uses his own web server to set these variables as he desires to work
> over your site.
>
> http://www.12robots.com/index.cfm/2008/12/9/Spoofing-CGI-variables--Security-Series-11

CGI.HTTP_* variables are set by the client and their content should be
treated as untrusted input. CGI.REMOTE_ADDR (and others like
CGI.SCRIPT_NAME, CGI.PATH_INFO) are set by the web server that connects
to the CF application instance so I'm pretty sure that they cannot be
spoofed.

Here's a quick test file (adapted from the link you provided) which
shows that you cannot spoof REMOTE_ADDR or REMOTE_HOST:

<cfif StructKeyExists(Url, "g")>
<cfdump var="#CGI.REMOTE_ADDR#">
<cfdump var="#cgi#">
<cfdump var="#GetHTTPRequestData()#">
<cfelse>
<cfhttp method="get" url=" http://#CGI.SERVER_NAME#/#CGI.SCRIPT_NAME#?g"
result="myVar">
<cfhttpparam type="header" name="Referer"
value=" http://www.google.com/search?q=coming+from+google">

<cfhttpparam type="header" name="REMOTE_HOST" value="71.244.78.2">
<cfhttpparam type="header" name="HTTP_REMOTE_HOST"
value="71.244.78.2">
<cfhttpparam type="header" name="REMOTE_ADDR" value="71.244.78.2">
<cfhttpparam type="header" name="HTTP_REMOTE_ADDR"
value="71.244.78.2">
</cfhttp>

<cfoutput>#myVar.FileContent#</cfoutput>
</cfif>

--
Mack

Mack wrote:
> nikos101 wrote:
>> Could #CGI.REMOTE_ADDR# be spoofed to do sql injection?
>
> No, I don't think CGI.REMOTE_ADDR can be spoofed as it's set by the web
> server and not by the client (client set headers have HTTP_ as a prefix).
>

Yes it is set by the web server. The spoofing comes in that the hacker
uses his own web server to set these variables as he desires to work
over your site.

http://www.12robots.com/index.cfm/2008/12/9/Spoofing-CGI-variables--Security-Series-11

nikos101 wrote:
> Could #CGI.REMOTE_ADDR# be spoofed to do sql injection?

No, I don't think CGI.REMOTE_ADDR can be spoofed as it's set by the web
server and not by the client (client set headers have HTTP_ as a prefix).

--
Mack

for some reason i read the OP's question differently and didn't think of
that aspect of spoofing cgi.remote_address... your answer now makes the
original question make more sense to me...

Azadi Saryev
Sabai-dee.com
http://www.sabai-dee.com/

nikos101 wrote:
> Could #CGI.REMOTE_ADDR# be spoofed to do sql injection?

Yes, CGI variables can be spoofed. Anything received from another
computer can be spoofed. Yes it can be used to do sql injection if you
are using CGI variables inside of unparameterized SQL code. I.E.
without <cfqueryparam...> tags.