Não sei especificamente sobre o filtro HTTP da Malwarebytes, mas presumo que funcione de maneira semelhante ao Fiddler .
O Fiddler em si é um proxy HTTP que lida com solicitações. Ele funciona executando um servidor HTTP na porta 8888 que aceita conexões HTTP e HTTPS.
Quando você executa o Fiddler, ele reconfigura as configurações de conexão com a Internet em todo o sistema do Windows para se definir como um Proxy HTTP em todo o sistema. Você pode ver isso se você olhar no Painel de controle > Opções da Internet > Conexões > Configurações da LAN > Servidor proxy > Avançado > HTTP: 127.0.0.1:8888 . Quando você fecha o Fiddler, ele reverte as configurações de volta para os valores anteriores.
Essas configurações em Opções da Internet são usadas automaticamente por qualquer aplicativo que use WinINet e WinHTTP (esses são os componentes do Windows que lidam com solicitações HTTP para software aplicativo de usuário). Os softwares que não usam o WinINet ou o WinHTTP (como os programas Java e .NET que possuem suas próprias bibliotecas cliente HTTP) geralmente respeitam as configurações do sistema WinINet / WinHTTP de qualquer maneira ( na maioria dos casos, de qualquer maneira ) . O Chrome também tem sua própria pilha de clientes HTTP, mas também respeita as configurações do sistema. Eu acredito que o Firefox é o mesmo.
Estes proxies HTTP então recebem os pedidos que normalmente iriam diretamente para o site pretendido, eles podem então inspecionar o pedido e tratá-lo (por exemplo, rejeitá-lo) ou encaminhá-lo para o destino pretendido. O HTTPS pode ser tratado com um certificado X.509 privado que é confiável e válido para todos os hosts - ou pelo encaminhamento dessas solicitações. Observe que, se o seu certificado não for realmente privado e específico para sua máquina, isso é uma responsabilidade de segurança massiva e você deve remover o certificado imediatamente.
O violinista, e como funciona, é descrito neste artigo do blog: link
Além dos proxies HTTP e HTTPS, os proxies SOCKS também fornecem uma rota de injeção - embora eles sejam uma abordagem mais antiga que não vi muito nos dias (como o SOCKS é para todo o tráfego TCP e UDP, enquanto os proxies HTTP só tratam HTTP especificamente). p>
Atualização:
O Windows Vista introduziu um novo ponto de extensibilidade no Windows chamado a Plataforma de Filtragem do Windows (WFP) , que oferece uma API melhor do que uma configuração de proxy HTTP / HTTP manual e permite que o software filtre mais coisas do que apenas o tráfego HTTP. Ele também é incorporado diretamente à pilha de rede, o que significa que deve ser capaz de interceptar todo o tráfego HTTP, mesmo de aplicativos que não respeitem a configuração WinInet ou WinHTTP.
Esta API foi atualizada em versões sucessivas do Windows, por isso é ativamente suportada e parece que foi criada especificamente para produtos de segurança:
With the WFP API, developers can implement firewalls, intrusion detection systems, antivirus programs, network monitoring tools, and parental controls.
Windows Filtering Platform is a development platform and not a firewall itself. The firewall application that is built into Windows Vista, Windows Server 2008, and later operating systems – Windows Firewall with Advanced Security (WFAS) – is implemented using WFP.
Vale a pena ressaltar que o WFP é uma API no modo kernel - o que significa que será mais difícil de programar, e que se uma implementação do WFP tiver um bug e travar, ele terá o potencial de causar um BUGCHECK (Tela Azul). of Death), por isso é possível que os desenvolvedores prefiram usar um proxy HTTP em vez de um WFP, porque é mais fácil e menos provável que resulte em uma experiência ruim para o usuário.
Isso está documentado aqui: link