You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Ricardo Bayley <ri...@gmail.com> on 2011/10/31 17:16:35 UTC

Filter by HTTP_REFERER

Hi folks,

I am trying to filter access to my webapp by the HTTP_REFERER
I thought this could be achieved with the Valve Componenent using the
Remote Host Filter such as

<Valve className="org.apache.catalina.valves.RemoteHostValve" allow="
sub.mydomain.com"/>
<Valve className="org.apache.catalina.valves.RemoteHostValve" allow="
mydomain.com"/>

I am not have in success. Can this be achieved or should I use Apache httpd
to proxy requests?



Best regards


Ricardo

Re: Filter by HTTP_REFERER

Posted by Casper Schmidt <ka...@gmail.com>.
2011/11/2 André Warnier <aw...@ice-sa.com>

> Casper Wandahl Schmidt wrote:
>
>>
>>
>> Den 02-11-2011 10:17, André Warnier skrev:
>>
>>> Pid * wrote:
>>>
>>>> On 31 Oct 2011, at 18:25, Christopher Schultz
>>>> <ch...@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<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<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<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<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<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<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.

According to http://marc.info/?l=tomcat-user&m=132007885023069&w=2 he
himself mentioned hotlinking and tried to clarify what he ment :)

>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.org<us...@tomcat.apache.org>
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>


-- 
MVH.

Casper Schmidt
(Kalle)

Re: Filter by HTTP_REFERER

Posted by André Warnier <aw...@ice-sa.com>.
Casper Wandahl Schmidt wrote:
> 
> 
> 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
>>>>>> <ch...@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) :)
>>

Right. I was thinking of the following type of scenario, which we encounter frequently :
A large organisation has a large internal LAN, spread over multiple physical locations; 
all accesses to the WWW from workstations within that LAN, go over one of 3 HTTP 
firewalls/proxies. So to an external webserver, all accesses from workstations in that LAN 
appear as coming from only 3 distinct IP addresses (the external IP addresses of the 
proxies).  So it makes it easy to filter using the RemoteAddress filter.
(Not preventing hot-linking, but allowing only requests "coming from one site", with a 
certain meaning of "site").

One more thing, if Ricardo is still listening : no matter which filtering you want to do 
in the end, and in addition to the filters mentioned above, you may want to have a look at 
the UrlRewriteFilter, at http://www.tuckey.org.
It resembles, and is inspired by, the Apache httpd mod_rewrite module, and it provides /a 
lot/ of possibilities in terms of filtering requests.
It works as a servlet filter, not as a Valve. So it will not filter requests as soon as 
they come in Tomcat, but it will filter them at the level of one web application.
Depending on your needs, this may be an advantage or an inconvenient.



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Filter by HTTP_REFERER

Posted by Casper Wandahl Schmidt <ka...@gmail.com>.

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
>>>>> <ch...@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


Re: Filter by HTTP_REFERER

Posted by André Warnier <aw...@ice-sa.com>.
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
>>>> <ch...@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.




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Filter by HTTP_REFERER

Posted by André Warnier <aw...@ice-sa.com>.
Casper Wandahl Schmidt wrote:
> 
> 
> Den 02-11-2011 10:17, André Warnier skrev:
>> Pid * wrote:
>>> On 31 Oct 2011, at 18:25, Christopher Schultz
>>> <ch...@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.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Filter by HTTP_REFERER

Posted by Casper Wandahl Schmidt <ka...@gmail.com>.

Den 02-11-2011 10:17, André Warnier skrev:
> Pid * wrote:
>> On 31 Oct 2011, at 18:25, Christopher Schultz
>> <ch...@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?
>
>
>
>
> ---------------------------------------------------------------------
> 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


Re: Filter by HTTP_REFERER

Posted by André Warnier <aw...@ice-sa.com>.
Pid * wrote:
> On 31 Oct 2011, at 18:25, Christopher Schultz
> <ch...@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).




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Filter by HTTP_REFERER

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Pid,

On 11/2/11 4:24 AM, Pid * wrote:
> It'll still be fragile and open to exploitation. An AJAX call can 
> any request headers it likes. You be better off using
> authentication if you want anything more than a casual defence.

+1

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6xZxwACgkQ9CaO5/Lv0PBLdACglkeADazNPVUA1D6KZevNF/nk
mlAAnicfRb5cuwFytNgeGHvvE5Bz+FYY
=xpk6
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Filter by HTTP_REFERER

Posted by Pid * <pi...@pidster.com>.
On 31 Oct 2011, at 18:25, Christopher Schultz
<ch...@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
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk6u5+EACgkQ9CaO5/Lv0PAy+QCgxBUvXjXAcLcNR8MIOO6L4+0N
> J98AoJbIlVQG9a/IfgICHPi1gqIsR2y7
> =uQ+h
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> 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


Re: Filter by HTTP_REFERER

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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.

> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6u5+EACgkQ9CaO5/Lv0PAy+QCgxBUvXjXAcLcNR8MIOO6L4+0N
J98AoJbIlVQG9a/IfgICHPi1gqIsR2y7
=uQ+h
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Filter by HTTP_REFERER

Posted by Ricardo Bayley <ri...@gmail.com>.
You are right. What I intend to do is prevent hot linking.
My webapp, is working as a REST webservice.

So I would like to have tomcat reply only when requests come from specific
sites.

thanks

2011/10/31 André Warnier <aw...@ice-sa.com>

> Ricardo Bayley wrote:
>
>> Hi folks,
>>
>> I am trying to filter access to my webapp by the HTTP_REFERER
>> I thought this could be achieved with the Valve Componenent using the
>> Remote Host Filter such as
>>
>> <Valve className="org.apache.**catalina.valves.**RemoteHostValve" allow="
>> sub.mydomain.com"/>
>> <Valve className="org.apache.**catalina.valves.**RemoteHostValve" allow="
>> mydomain.com"/>
>>
>> I am not have in success. Can this be achieved or should I use Apache
>> httpd
>> to proxy requests?
>>
>>  What exactly do you want to filter on ?
> The "referrer" is one thing (it's the browser page currently displayed, in
> which the link was clicked to trigger the current request).
> The hostname from which the request comes is another.
> The host IP address from which the request comes is a third possibility.
> (and filtering on the hostname is "expensive", because it requires DNS
> lookups)
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.org<us...@tomcat.apache.org>
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

Re: Filter by HTTP_REFERER

Posted by André Warnier <aw...@ice-sa.com>.
Ricardo Bayley wrote:
> Hi folks,
> 
> I am trying to filter access to my webapp by the HTTP_REFERER
> I thought this could be achieved with the Valve Componenent using the
> Remote Host Filter such as
> 
> <Valve className="org.apache.catalina.valves.RemoteHostValve" allow="
> sub.mydomain.com"/>
> <Valve className="org.apache.catalina.valves.RemoteHostValve" allow="
> mydomain.com"/>
> 
> I am not have in success. Can this be achieved or should I use Apache httpd
> to proxy requests?
> 
What exactly do you want to filter on ?
The "referrer" is one thing (it's the browser page currently displayed, in which the link 
was clicked to trigger the current request).
The hostname from which the request comes is another.
The host IP address from which the request comes is a third possibility.
(and filtering on the hostname is "expensive", because it requires DNS lookups)

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Filter by HTTP_REFERER

Posted by Konstantin Kolinko <kn...@gmail.com>.
2011/10/31 Ricardo Bayley <ri...@gmail.com>:
> Hi folks,
>
> I am trying to filter access to my webapp by the HTTP_REFERER
> I thought this could be achieved with the Valve Componenent using the
> Remote Host Filter such as

No. This filter has different purpose (you have read the docs?).
You can always write your own.

> <Valve className="org.apache.catalina.valves.RemoteHostValve" allow="
> sub.mydomain.com"/>
> <Valve className="org.apache.catalina.valves.RemoteHostValve" allow="
> mydomain.com"/>
>
> I am not have in success.
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org