tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Casper Wandahl Schmidt <>
Subject Re: Filter by HTTP_REFERER
Date Wed, 02 Nov 2011 10:00:18 GMT

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
>>>>> <> wrote:
>>>>>> 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
>>>>>> 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
>>>>>>> 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 

>>>> 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 
>>>> (

>>>> 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
>>>> >>> 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 "*" or "*") ?
>>>> 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, and on that page is a link to your website, 
> clicking it does not mean that the request "comes from".  
> 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message