Den 02-11-2011 10:50, André Warnier skrev:
> André Warnier wrote:
>> Casper Wandahl Schmidt wrote:
>>>
>>>
>>> Den 02-11-2011 10:17, André Warnier skrev:
>>>> Pid * wrote:
>>>>> On 31 Oct 2011, at 18:25, Christopher Schultz
>>>>> <chris@christopherschultz.net> wrote:
>>>>>
>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>> Hash: SHA1
>>>>>>
>>>>>> Richardo,
>>>>>>
>>>>>> On 10/31/2011 12:33 PM, Ricardo Bayley wrote:
>>>>>>> You are right. What I intend to do is prevent hot linking.
>>>>>> We get what you are trying to do: you'll just have to write your
own
>>>>>> code to do it. Tomcat ships with a Filter called RequestFilter that
>>>>>> you can subclass if you need that kind of flexibility. If you don't
>>>>>> need such flexibility, just write it yourself: it's pretty much a
>>>>>> one-liner.
>>>>>
>>>>> It'll still be fragile and open to exploitation. An AJAX call can set
>>>>> any request headers it likes. You be better off using authentication
>>>>> if you want anything more than a casual defence.
>>>>>
>>>>>
>>>>> p
>>>>>
>>>>>
>>>>>>> My webapp, is working as a REST webservice.
>>>>>>>
>>>>>>> So I would like to have tomcat reply only when requests come
from
>>>>>>> specific sites.
>>>>>> You mean when the requests are referred from specific sites, right?
>>>>>>
>>>>>> - -chris
>>>>
>>>> I think that a bit of clarification is in order now.
>>>>
>>>> 1) When receiving a request, Tomcat "knows" from which client IP
>>>> this request is coming.
>>>> This is because there is a TCP connection nbetween the client and
>>>> Tomcat, and the TCP/IP stack on the Tomcat machine "knows" the IP
>>>> address and TCP port from which the remote client is making this
>>>> connection.
>>>>
>>>> Tomcat can allow/block requests originating from specific IP
>>>> addresses, using the RemoteAddress filter (See
>>>> http://tomcat.apache.org/tomcat-7.0-doc/config/valve.html#Remote_Address_Filter)
>>>> or the Remote IP Valve (also mentioned there).
>>>> This is fairly efficient, because Tomcat already has the
>>>> information needed to make the decision.
>>>>
>>>> 2) Because Tomcat has the client's remote IP address, it can also
>>>> make a "reverse DNS lookup", to find out which domain name
>>>> corresponds to this IP address, and then allow/deny the request
>>>> based on the remote host's domain name. This is done via the
>>>> RemoteHost filter
>>>> (http://tomcat.apache.org/tomcat-7.0-doc/config/valve.html#Remote_Host_Filter).
>>>>
>>>> It is less efficient than option (1), because a DNS lookup has to
>>>> take place.
>>>> Furthermore, this DNS lookup is not guaranteed to succeed, because
>>>> not all IP addresses are mapped in reverse to a hostname.
>>>> I also wonder what happens exactly when the remote host's IP
>>>> address corresponds to multiple DNS names, as can happen.
>>>>
>>>> 3) the HTTP "Referer" header in a HTTP request is a different animal.
>>>>
>>>> First, as pointed out by Pid, it can be easily faked by a client.
>>>> (So anything based on this should certainly /not/ be considered as
>>>> any kind of security-enhancing feature).
>>>>
>>>> Second, it works as follows :
>>>>
>>>> Imagine a browser B, some website W, and the Tomcat web server T.
>>>> The browser B gets a web page from site W. This is now the
>>>> browser's "current page", and its origin is (to the browser)
>>>> something like : "http://website-W/some-document.html".
>>>>
>>>> In that page, there is a URL link to the Tomcat website on T, for
>>>> example something like :
>>>> <a href="http://website-T/some-REST-url">click here</a>.
>>>> When the user clicks on that link, the browser will send a HTTP
>>>> request to Tomcat on server T. And the browser, in this request,
>>>> will add a "Referer:" header containing
>>>> "http://website-W/some-document.html".
>>>> That is because the request originates from the current page, which
>>>> had been obtained from "http://website-W/some-document.html". That
>>>> is what "referrer" means.
>>>>
>>>> As you can see, this is different from cases (1) and (2), because
>>>> (1) and (2) refer to the client's own IP address or name, while (3)
>>>> refers to another server altogether.
>>>>
>>>> Now the point is to know exactly what Ricardo wants, as per this
>>>> phrase :
>>>> >>> So I would like to have tomcat reply only when requests come
from
>>>> >>> specific sites.
>>>>
>>>> Does that mean :
>>>> - Tomcat should reject requests coming from workstations that are
>>>> not themselves within a particular range of IP addresses ? (for
>>>> example, only from some customer LANs L1, L2, L3,..) of which the
>>>> IP addresses are known in advance ?
>>>> OR
>>>> - Tomcat should reject requests coming from clients whose own IP
>>>> addresses cannot be resolved to hostnames that are members of some
>>>> DNS domain (like "*.customer1.com" or "*.customer2.org") ?
>>>> OR
>>>> - Tomcat should reject requests (from any client), unless these
>>>> requests come from a link which itself appears only on some websites ?
>>>> (and the possibility of a malicious client "faking" such a
>>>> "Referer" can be ignored).
>>> According to OP he want's to avoid hot-linking which would be this
>>> last case or have I misunderstood something?
>>
>> Well, "hot-linking" is not a term he himself mentioned, it is a term
>> someone else mentioned, after interpreting the above phrase that he
>> wrote. It is not so clear to me what he really wants.
>>
> Sorry, I stand corrected. He did use "hot-linking". But then, the
> next phrase kind of contradicts that, because "request comes from a
> specific site" means something else (to me at least). When you get a
> page from google.com, and on that page is a link to your website,
> clicking it does not mean that the request "comes from google.com".
> It comes from your browser.
>
I guess that depends how you read the word "site" (I believe you read it
as like a building site, a psysical location - or well semi-psysical due
to the fact that LAN's can be spread to multiple psysical locations -
whereas I read it as website and then simply ignore the fact that he
does not have the full understanding of who and how requests are made) :)
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
|