[
https://issues.apache.org/jira/browse/TS-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14079366#comment-14079366
]
Nikolai Gorchilov commented on TS-2954:
---------------------------------------
Oh, I see.
It makes sense to apply the new logic by default when using client target
address and the current insecure logic to be explicitly activated by using the
new value of 2.
After setting proxy.config.http.use_client_target_addr = 1 it seems to be
working as expected. At least in lab tests:
{noformat}
(http_trans) START HttpTransact::ModifyRequest
(http_trans) [ink_cluster_time] local: 1406732859, highest_delta: 0, cluster:
1406732859
(http_trans) END HttpTransact::ModifyRequest
(http_trans) Checking if transaction wants to upgrade
(http_trans) Next action SM_ACTION_API_READ_REQUEST_HDR;
HttpTransact::StartRemapRequest
(http_trans) START HttpTransact::StartRemapRequest
(http_trans) Before Remapping:
(http_trans) END HttpTransact::StartRemapRequest
(http_trans) Next action SM_ACTION_API_PRE_REMAP; HttpTransact::PerformRemap
(http_trans) Inside PerformRemap
(http_trans) Next action SM_ACTION_REMAP_REQUEST; HttpTransact::EndRemapRequest
(http_trans) START HttpTransact::EndRemapRequest
(http_trans) EndRemapRequest host is i.ytimg.com
(http_trans) After Remapping:
(http_trans) END HttpTransact::EndRemapRequest
(http_trans) Next action SM_ACTION_API_POST_REMAP; HttpTransact::HandleRequest
(http_trans) START HttpTransact::HandleRequest
(http_trans) [init_stat_vars_from_req] set req cont length to 0
(http_trans) [is_request_valid]no request header errors
(http_trans) [DecideCacheLookup] Will do cache lookup.
(http_trans) Next action SM_ACTION_CACHE_LOOKUP; __null
(http_trans) [HttpTransact::HandleCacheOpenRead]
(http_trans) CacheOpenRead -- miss
(http_trans) Next action SM_ACTION_DNS_LOOKUP; OSDNSLookup
(http_trans) [ink_cluster_time] local: 1406732859, highest_delta: 0, cluster:
1406732859
(http_trans) [HttpTransact::OSDNSLookup] This was attempt 1
(http_trans) [OSDNSLookup] DNS lookup for O.S. successful IP: 91.239.13.61
(http_trans) Next action SM_ACTION_API_OS_DNS; HandleCacheOpenReadMiss
(http_trans) [HandleCacheOpenReadMiss] --- MISS
(http_trans) [build_request] removing host name from url
(http_trans) [build_request] request like cacheable and conditional headers
removed
(http_trans) [ink_cluster_time] local: 1406732859, highest_delta: 0, cluster:
1406732859
(http_trans) [build_request] request_sent_time: 1406732859
(http_trans) Next action next; __null
(http_trans) [HttpTransact::HandleResponse]
(http_trans) [ink_cluster_time] local: 1406732859, highest_delta: 0, cluster:
1406732859
(http_trans) [HandleResponse] response_received_time: 1406732859
(http_trans) [is_response_valid] No errors in response
(http_trans) [handle_response_from_server] (hrfs)
(http_trans) [hrfs] connection alive
(http_trans) [handle_forward_server_connection_open] (hfsco)
(http_trans) [hfsco] cache action: CACHE_DO_WRITE
(http_trans) [handle_cache_operation_on_forward_server_response] (hcoofsr)
(http_trans) [is_response_cacheable] Lookup not validated. Possible DNS cache
poison. Don't cache
(http_trans) [hcoofsr] response is not cacheable
(http_trans) [hcoofsr] response code: 200
(http_trans) [handle_content_length_header] RESPONSE cont len in hdr is 5216
(http_trans) [Squid code generation] Hit/Miss: 49, Log: 51, Hier: 50
{noformat}
Planing for production trial tomorrow. Once done, will get back to you with
results.
Thanks!
> cache poisoning due to proxy.config.http.use_client_target_addr = 1
> -------------------------------------------------------------------
>
> Key: TS-2954
> URL: https://issues.apache.org/jira/browse/TS-2954
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache, DNS, Security, TProxy
> Reporter: Nikolai Gorchilov
> Assignee: Susan Hinrichs
> Priority: Critical
> Fix For: 5.1.0
>
> Attachments: ts-2954.patch
>
>
> Current implementation of proxy.config.http.use_client_target_addr opens a
> very simple attack vector for cache poisoning in transparent forwarding mode.
> An attacker (or malware installed on innocent end-user computer) puts a fake
> IP for popular website like www.google.com or www.facebook.com in hosts file
> on PC behind the proxy. Once an infected PC requests the webpage in question,
> a cacheable fake response poisons the cache.
> In order to prevent such scenarios (as well as [some
> others|http://www.kb.cert.org/vuls/id/435052]) Squid have implemented a
> mechanism known as [Host Header Forgery
> Detection|http://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery].
> In short, while requesting an URL from origin server IP as hinted by the
> client, proxy makes independent DNS query in parallel in order to determine
> if client supplied IP belongs to requested domain name. In case of
> discrepancy between DNS and client IP, the transaction shall be flagged as
> non-cacheable to avoid possible cache poisoning, while still serving the
> origin response to the client.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
