[squid-users] On what methods does url filtering needs to apply?

[Marcus Kool]

"content filtering" may filter only content while a generic filter may filter anything
including malware that uses PUT, OPTION and/or HEAD to upload credit card data.

So it depends on what you want to filter. If it is downloadable content only, you can stick with filtering GET POST CONNECT.

Marcus


On 09/28/2015 03:34 PM, Eliezer Croitoru wrote:
> Thanks for the insight.
>
> You are right, it is not well defined.
> I will try to rephrase or clear couple things.
> Mainly content filtering is for offensive content.
> This by definition is not the goal of a security related product that would not like to reveal the client attempts to reach the site using a HEAD request.
> The main issue is about offensive content in the presentation layer.
> Actually with squid it's not such a great issue but the main purpose of my question is to verify what would be allowed to be bypassed content filtering.
> I will do more to clarify the issue.
> A HEAD request will never include a body and will might contain offensive content in the HEADERS but it's not something that the user (unless he is an admin) will probably never see.
> So a HEAD cannot ever contain a body response and there for might not require filtering.
> A PUT request can contain a response body but it is not used and was not designed to send body content and else then that browsers do not really implement support for it.
>
> Basically the main HTTP methods that are being used by browsers to retrieve content and present it are GET and POST.
> I really have not seen a webpage that is built to work with PUT or OPTIONS only methods.
> So an OPTIONS method blocking is something that might worth checking in a security environment but if the content filtering is to block abusive content then I probably do not need to invest time on an
> OPTIONS request.
>
> So after defining that the main subject as abusive content in the body part of the message, POST and GET are a must to check but OPTIONS might not be required.
>
> I must say as a side note that for small setups it might not really be a big of a difference but for large setups, if there is no real need to inspect the content then I can just reduce the delays for
> such requests by a few 100s ms.
>
> The main reason I am asking this is due to the fact(not saying that they are right or wrong) that I have seen it being use in  the real world.
> I have seen something like this:
> icap_enable on
> icap_service service_req reqmod_precache icap://127.0.0.1:1344/service
> acl inspect_methods method GET POST CONNECT
> adaptation_access service_req allow inspect_methods
> adaptation_access service_req deny all
>
> Thanks,
> Eliezer
>
> On 27/09/2015 20:58, Alex Rousskov wrote:
>> Your question is impossible to answer correctly until you define
>> "unwanted content". In other words, you need to define what you want to
>> block (in general, non-HTTP terms) before it is possible to identify a
>> subset of HTTP messages that can deliver the corresponding content. What
>> is "desired" by some is "unwanted" by others, so we cannot guess what
>> _your_  blocking objectives are.
>>
>> Alex.
>
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users