Cross-Site Request Forgery (CSRF) e abordagens para mitigá-lo \| TreinaWeb Promoção no ar Matricule-se agora e garanta **54% de desconto** Termina em Tempo restante da oferta: 05 Horas 15 Min 55 Seg Tempo restante da oferta: 05 15 55 [Assinar →](https://www.treinaweb.com.br/checkout/pagamento/plano/anual?cupom=TW-SCLIENTE26) [ ](https://www.treinaweb.com.br) Explorar [ Quanto custa? ](#assinatura) [ FAQ ](https://www.treinaweb.com.br#faq) [Matricule-se](#assinatura) [ Entrar ](https://www.treinaweb.com.br/login) [ Início ](https://www.treinaweb.com.br) [ Artigos ](https://www.treinaweb.com.br/blog) Cross-Site Request Forgery (CSRF) e abordagens para mitigá-lo [ Segurança da Informação ](https://www.treinaweb.com.br/blog/categoria/seguranca-da-informacao) # Cross-Site Request Forgery (CSRF) e abordagens para mitigá-lo Entenda o que é Cross-Site Request Forgery (CSRF) e conheça abordagens para mitigá-lo, incluindo a mais moderna delas, que é o atributo SameSite para cookies. [ Kennedy Tedesco ](https://www.treinaweb.com.br/blog/autor/kennedy-tedesco) 9 anos atrás ![](https://dkrn4sk0rn31v.cloudfront.net/uploads/2018/06/28145950/security-csrf.jpg) CSRF é um dos ataques mais conhecidos, existe desde a “fundação” da Web. Ele ocorre quando uma requisição [HTTP](https://www.treinaweb.com.br/blog/o-que-e-http-request-get-post-response-200-404/ "HTTP") é feita entre sites na tentativa de se passar por um usuário legítimo. Quem se utiliza desse tipo de ataque normalmente foca em fazê-lo esperando que usuário alvo esteja autenticado no site onde a requisição fraudulenta será realizada, a fim de se ter mais privilégios e acessos à operações. E a razão de todo o problema está em como os navegadores lidam com os Cookies. [ ![Django - Banco de dados com Django ORM](https://d2knvm16wkt3ia.cloudfront.net/assets/svg-icon/django.svg) Curso Django - Banco de dados com Django ORM Conhecer o curso ](https://www.treinaweb.com.br/curso/django-banco-de-dados-com-django-orm) É mais simples entender se imaginarmos esse clássico cenário: **1)** Você loga no site do seu banco usando o seu navegador preferido: ![Diagrama autenticação](https://dkrn4sk0rn31v.cloudfront.net/2018/06/27175135/login.png) A credencial do usuário é validada, um cookie é enviado na resposta da requisição HTTP. A partir desse momento, o navegador tem salvo no disco o cookie que te mantém autenticado. **2)** Você recebe um e-mail (engenharia social) que te convence a clicar em um link que abre um site arbitrário; **3)** Ao entrar nesse site, no corpo dele, tem um formulário assim: ```html ``` Esse formulário no site do atacante emula exatamente como o seu banco faz para realizar uma transferência de dinheiro. Em seguida, em algum momento, esse site arbitrário submete o formulário usando JavaScript: ```javascript document.getElementById("meuFormSacana").submit(); ``` É daí que vem o nome “Cross-Site Request Forgery”. Foi forjada uma requisição Cross-Site, de um site para outro. A requisição forjada não é exatamente o problema, mas sim o fato de o seu navegador ter enviado junto com ela aquele cookie da autenticação e o site do seu banco achará que foi você quem solicitou a transferência. O envio do cookie é feito automaticamente pelo navegador. Quando um cookie é criado, ele possui alguns atributos e um deles é o **domain** que fala ao navegador o domínio onde esse cookie pode ser transacionado. Uma vez que o site do atacante fez uma requisição ao domínio do seu banco através do seu navegador, o cookie disponível para esse domínio é enviado. Obviamente esse é um exemplo hipotético e simplista, apenas com o intuito de ilustrar um caso de ataque, ademais, há muitas formas do seu banco mitigar esse tipo de ataque e certamente ele o faz. Há de ressaltar, ainda, que esse exemplo é apenas uma das formas de ataques de CSRF. Outra muito importante e explorada é quando se tem alguma vulnerabilidade de XSS onde, por exemplo, o atacante consegue injetar um JavaScript malicioso na página do seu site a partir de um formulário de comentário que não trata os dados recebidos, muito menos escapa na hora de imprimir no HTML. Não entraremos em todas as variantes possíveis para se explorar CSRF, focaremos nessa que é a principal. A ideia é, ao final desse artigo, oferecer soluções que resolvam de uma vez por todas esse problema em suas aplicações web. [Outro exemplo](https://blogs.dropbox.com/tech/2017/03/preventing-cross-site-attacks-using-same-site-cookies/ "Outro exemplo") de um hipotético ataque de CSRF, esse dado pela equipe de engenharia do Dropbox: ![Diagrama dropbox CSRF](https://dkrn4sk0rn31v.cloudfront.net/2018/06/28102837/csrf-dropbox1.png) ## Como se defender de CSRF? Se o seu site usa [SSL](https://www.treinaweb.com.br/blog/para-que-serve-o-certificado-ssl/ "Para que serve o certificado SSL?") (e deveria!) você já está naturalmente protegido de algumas variantes possíveis de se explorar CSRF. Veja bem, isso é muito importante: [HTTPS Everywhere](https://www.eff.org/https-everywhere "HTTPS Everywhere"). Essa é uma recomendação e um padrão que está sendo adotado pelos navegadores. Recomendo também a leitura de nosso artigo sobre [HTTPS](https://www.treinaweb.com.br/blog/termos-comuns-de-seguranca-https/ "HTTPS"). O Google Chrome na versão 68 já marca sites **HTTP** como sendo **inseguros**: ![Marcação de sites http inseguros chrome](https://dkrn4sk0rn31v.cloudfront.net/2018/06/27192744/chrome-http.png) Mas, usar SSL não é a única ação necessária. Abaixo listaremos a proteção clássica que utiliza tokens e a mais nova forma de se proteger junto aos navegadores modernos, que refere-se ao atributo **SameSite** que pode ser especificado na criação dos cookies. ### CSRF Tokens A proteção classicamente utilizada nos formulários é a de criar um campo oculto com um token único por usuário. Esse token fica salvo na sessão do usuário no servidor e, quando o formulário é postado, o token enviado pelo formulário é comparado com o que se tem na sessão, lá no servidor. Sendo iguais, a requisição é aceita. Caso contrário, é recusada. Você já deve ter visto formulários assim: ```html ``` Quando o formulário é postado, é comparado: ```php // Se não forem iguais if ( ! hash_equals(request('_token'), session('_token'))) { // Throw an exception } ``` Aquele site do primeiro exemplo que fez a falsa requisição não consegue, por exemplo, requisitar o site do seu banco e extrair esse token para então utilizá-lo, isso deve à proteção de *Same Origin Policy (SOP)* que os navegadores implementam. E, lembre-se: o token enviado pelo formulário precisa bater com o token salvo para a sessão do usuário. Portanto, não é trivial explorar uma vulnerabilidade nessa parte. Por esse motivo, o uso de tokens sempre foi bastante efetivo para esse tipo de ataque. Ainda é, dependendo do seu caso. A maioria dos frameworks web das linguagens de programação implementam essa proteção de forma bastante transparente para o desenvolvedor, ainda assim, é preciso se preocupar em quando usar o token ou não, em qual rota usar ou não etc. E se pudéssemos resolver esse problema sem precisar implementar tokens e tudo mais? Pois bem, os navegadores modernos implementaram uma nova diretiva para cookies que resolve de uma vez por todas os problemas com CSRF. Ela se chama *SameSite*. Com essa diretiva, especificamos em qual circunstância o browser deve enviar o cookie em uma requisição. Ademais, essa sempre foi a raiz do problema. Lembra que comentamos lá em cima? O site malicioso só conseguiu fazer a transferência no banco pelo fato de o navegador ter enviado o cookie do usuário (autenticado) junto à requisição. ## O método mais moderno: atributo SameSite para cookies *SameSite* é um atributo de cookie relativamente novo. Ele foi colocado como [recomendação da IETF](https://tools.ietf.org/html/draft-west-first-party-cookies-07 "recomendação da IETF") em 2016. Esse atributo é suportado pelo Chrome desde a versão 59. O suporte completo dos navegadores você pode conferir [aqui](http://caniuse.com/#search=samesite "aqui"). Ele resolve a maioria dos ataques de CSRF. É a forma mais moderna que se tem para resolver esse tipo de ataque. Um ótimo case é do Dropbox, a equipe de engenharia deles [explica aqui](https://blogs.dropbox.com/tech/2017/03/preventing-cross-site-attacks-using-same-site-cookies/ "explica aqui") como aplicaram e como ele resolveu os problemas que tinham com essa vulnerabilidade. É muito fácil configurar o atributo *SameSite*. Basta adicioná-lo na criação do Cookie. O Laravel (um Framework Web PHP) já suporta a [configuração desse atributo](https://github.com/laravel/laravel/blob/5.5/config/session.php#L195 "configuração desse atributo"). Basta especificar qual modo se deseja usar (**Strict** ou **Lax**) e então o próprio framework já trata de especificá-lo na criação do cookie. Quando acessamos um site que necessita criar algum cookie, na resposta HTTP temos: ```txt set-cookie: treinaweb-site=...; path=/; secure; httponly; ``` Quando o site especifica o atributo **SameSite**, ele é adicionado junto aos outros atributos: ```txt set-cookie: treinaweb-site=...; path=/; secure; httponly; samesite=lax ``` Pronto. Isso é tudo. Você já estará protegido. Sem preocupação com tokens, verificações etc. Esse atributo indicará ao navegador para restringir o envio do cookie para algumas situações específicas. O atributo **SameSite** pode ter dois valores possíveis: **Strict** e **Lax**, a depender de quão estrito você quer que seja. Quando o valor for **Strict**, o navegador não enviará o cookie em nenhuma requisição cross-site sob nenhuma hipótese. Quando for **Lax**, ele apenas não enviará o cookie em requisições “inseguras” (aquelas que usam o método **POST**, por exemplo), mas ele enviará o cookie nas requisições cross-site “seguras”, como as que usam os métodos **GET**, **HEAD**, **OPTIONS** e **TRACE**. **Devo usar o modo Strict ou Lax no atributo SameSite?** Se você envia pro seu usuário algum link no e-mail para que ele acesse algum recurso da aplicação (uma rota que use o método GET, por exemplo) e você deseja que ele seja autenticado usando o cookie já existente no navegador, então o melhor modo pra você é o **Lax**. Ele permite isso. No entanto, se você usar o modo **Strict**, o usuário pode estar logado, ter o cookie no navegador, mas se a requisição vier de fora do site, o navegador não vai enviar esse cookie. O modo **Strict** é o mais estrito possível, mas pode ser que ele tire alguma usabilidade da sua aplicação, como no caso acima, que você espera que o seu usuário seja autenticado ao clicar em um link que você enviou no e-mail pra ele. Mas, em termos gerais, ambos os modos vão te proteger do principal vetor do ataque. Não existe o “melhor” modo. Existe o que mais faz sentido para a sua aplicação e para a usabilidade dela. ## Concluindo Algumas questões e dúvidas que podem ter sido levantadas: **Devo parar de usar a estratégia de CSRF Tokens e passar a usar apenas o atributo SameSite?** Depende. Se você tem uma aplicação crítica e que possui uma base de usuários muito grande que ainda usa navegadores legados (IE10 etc), talvez deixar de usar CSRF Tokens pode não ser a melhor pedida. Nesse caso, talvez seja melhor que você use tanto os tokens quanto o atributo SameSite (já que os navegadores modernos conseguirão entendê-lo). Mas, fato é: a tendência é em poucos anos o uso desses navegadores legados não ser mais viável. Quando isso acontecer, essa questão nem entrará em pauta. **SameSite** será um atributo obrigatório na definição dos parâmetros de segurança de um site que usar Cookies e que lidar com informações sensíveis. Agora, se a maioria dos seus usuários utilizam navegadores modernos e se sua aplicação não tem nada tão crítico que possa comprometê-los, você já poderia desde já adotar a estratégia de usar apenas o atributo **SameSite**. Vai depender da sua percepção sobre o tema. **Além de usar o atributo SameSite o que mais devo fazer?** Você deve: - Usar HTTPS em todo lugar; - Tratar os dados recebidos e escapar o que será impresso nos seus arquivos de visão (aqueles que geram HTML); - Cuidar da sua programação defensiva para mitigar Cross-Site Scripting (XSS); - Vale a pena pesquisar e estudar um pouco mais sobre “Content Security Policy”, que os navegadores modernos implementam. Com esses pontos bem avaliados, você estará quase que integralmente protegido de ataques de CSRF. ### Checklist de segurança para autenticação Recomendo que você também leia o artigo [Checklist de segurança para autenticação](https://www.treinaweb.com.br/blog/checklist-de-seguranca-para-autenticacao/ "Checklist de segurança para autenticação") onde eu enumero as principais recomendações e estratégias para se desenvolver uma para autenticação segura. [ ![Desenvolvedor PHP Sênior](https://d2knvm16wkt3ia.cloudfront.net/assets/svg-icon/php.svg) Formação Desenvolvedor PHP Sênior Conhecer a formação ](https://www.treinaweb.com.br/formacao/desenvolvedor-php-senior) Autor ![Kennedy Tedesco](//secure.gravatar.com/avatar/236c86e9469327ba7a9250ff15fef424?d=mm) ## Kennedy Tedesco Head de desenvolvimento. Vasta experiência em desenvolvimento Web com foco em PHP. Graduado em Sistemas de Informação. Pós-graduando em Arquitetura de Software Distribuído pela PUC Minas. Zend Certified Engineer (ZCE) e Coffee Addicted Person (CAP). [@KennedyTedesco](https://twitter.com/KennedyTedesco) [Todos os artigos](https://www.treinaweb.com.br/blog/autor/kennedy-tedesco) ## Continue estudando Transforme leitura em prática com os cursos e formações da TreinaWeb. [Ver cursos](https://www.treinaweb.com.br/cursos) Continue lendo ## Artigos relacionados - ![](https://dkrn4sk0rn31v.cloudfront.net/uploads/2018/07/31174205/vulnerabilidade-redirecionamento-400x280.png) [ Segurança da Informação ](https://www.treinaweb.com.br/blog/categoria/seguranca-da-informacao) 8 anos atrás ## [ Open Redirect - Vulnerabilidade de redirecionamento aberto ](https://www.treinaweb.com.br/blog/open-redirect-vulnerabilidade-de-redirecionamento-aberto) Saiba o que é a vulnerabilidade de redirecionamento aberto (Open Redirect) e ações que podem ser desempenhadas para mitigá-la. Ler artigo - ![](https://dkrn4sk0rn31v.cloudfront.net/uploads/2019/07/15153304/ATAQUES-APLICAÇÕES-WEB-400x280.png) [ Tecnologia ](https://www.treinaweb.com.br/blog/categoria/tecnologia) 7 anos atrás ## [ Principais tipos de ataques a aplicações web ](https://www.treinaweb.com.br/blog/principais-tipos-de-ataques-a-aplicacoes-web) Neste artigo veremos os três tipos de ataques mais comuns a aplicações web. Ler artigo - ![](https://dkrn4sk0rn31v.cloudfront.net/uploads/2017/07/checklist-de-seguranca-para-autenticacao-400x280.png) [ Segurança da Informação ](https://www.treinaweb.com.br/blog/categoria/seguranca-da-informacao) 9 anos atrás ## [ Checklist de segurança para autenticação ](https://www.treinaweb.com.br/blog/checklist-de-seguranca-para-autenticacao) Cuidar da segurança é um dos pilares para a sustentação de qualquer aplicação na web. Sem o mínimo não é possível nem mesmo garantir uma razoável disponibilidade. Ler artigo - ![](https://dkrn4sk0rn31v.cloudfront.net/uploads/2025/03/Sem-Titulo-2-400x280.png) [ Desenvolvimento ](https://www.treinaweb.com.br/blog/categoria/desenvolvimento) 2 anos atrás ## [ Vantagens de utilizar frameworks no desenvolvimento de software ](https://www.treinaweb.com.br/blog/vantagens-de-utilizar-frameworks-no-desenvolvimento-de-software) Usar frameworks no desenvolvimento de software significa mais eficiência e padronização. Confira neste artigo como eles podem otimizar seu trabalho e acelerar seus projetos. Ler artigo - ![](https://dkrn4sk0rn31v.cloudfront.net/uploads/2021/04/o-que-e-o-spring-security-400x280.png) [ Java ](https://www.treinaweb.com.br/blog/categoria/java) 6 anos atrás ## [ O que é o Spring Security? ](https://www.treinaweb.com.br/blog/o-que-e-o-spring-security) Neste artigo veremos o que é o Spring Security, quais suas funcionalidades e como ele pode aumentar a segurança de nossas aplicações Java. Ler artigo - ![](https://dkrn4sk0rn31v.cloudfront.net/uploads/2020/08/o_que_e_drupal-400x280.png) [ Drupal ](https://www.treinaweb.com.br/blog/categoria/drupal) 6 anos atrás ## [ O que é Drupal? ](https://www.treinaweb.com.br/blog/o-que-e-drupal) Veja neste artigo o que é o Drupal. Ler artigo - ![](https://dkrn4sk0rn31v.cloudfront.net/uploads/2020/03/18200426/XAMARIN-MARYLENE-400x280.png) [ Desenvolvimento Mobile ](https://www.treinaweb.com.br/blog/categoria/desenvolvimento-mobile) 7 anos atrás ## [ O que é Xamarin? ](https://www.treinaweb.com.br/blog/o-que-e-xamarin) Aplicações mobile sempre estão em alta. Conheça mais sobre o Xamarin, a plataforma open source para criação de aplicações mobile da Microsoft. Ler artigo - ![](https://dkrn4sk0rn31v.cloudfront.net/uploads/2019/11/12071214/front-end-motion-graphics-400x280.png) [ Desenvolvimento Front-end ](https://www.treinaweb.com.br/blog/categoria/desenvolvimento-front-end) 7 anos atrás ## [ Começando com SVG no Front-End - Parte 3 - Animações com mo.js (Motion Graphics) ](https://www.treinaweb.com.br/blog/comecando-com-svg-no-front-end-parte-3-animacoes-com-mo-js-motion-graphics) Aprenda a criar animações incríveis e interativas de forma bem simples para a web utilizando o mo.js Ler artigo - ![](https://dkrn4sk0rn31v.cloudfront.net/uploads/2020/04/13172051/CORS-400x280.png) [ Javascript ](https://www.treinaweb.com.br/blog/categoria/javascript) 7 anos atrás ## [ O que é CORS e como resolver os principais erros ](https://www.treinaweb.com.br/blog/o-que-e-cors-e-como-resolver-os-principais-erros) Nesse artigo vamos entender o que é CORS, quais os principais erros relacionados com ele, suas principais causas e como resolve-los corretamente. Ler artigo - ![](https://dkrn4sk0rn31v.cloudfront.net/uploads/2020/06/ANGULAR-400x280.png) [ Desenvolvimento Front-end ](https://www.treinaweb.com.br/blog/categoria/desenvolvimento-front-end) 7 anos atrás ## [ O que é o Angular e para que serve? ](https://www.treinaweb.com.br/blog/o-que-e-o-angular-e-para-que-serve) Frameworks SPA atualmente são um padrão de mercado quando falamos sobre desenvolvimento front-end. Neste artigo, vamos abordar o Angular, um dos mais populares. Ler artigo - ![](https://dkrn4sk0rn31v.cloudfront.net/uploads/2017/07/13150455/aplicacoes-self-contained-com-o-net-core-400x280.jpg) [ C# ](https://www.treinaweb.com.br/blog/categoria/csharp) 8 anos atrás ## [ ASP.NET Core: Compreendendo AddMvc(), AddMvcCore(), AddControllers(), AddControllersWithViews() e AddRazorPages() ](https://www.treinaweb.com.br/blog/asp-net-core-compreendendo-addmvc-addmvccore-addcontrollers-addcontrollerswithviews-e-addrazorpages) Aprenda quando utilizar os métodos AddMvc(), AddMvcCore(), AddControllers(), AddControllersWithViews() e AddRazorPages() em uma aplicação ASP.NET Core. Ler artigo - ![](https://dkrn4sk0rn31v.cloudfront.net/uploads/2018/01/17123855/IMG-MARYLENE-3-1-400x280.png) [ Carreira ](https://www.treinaweb.com.br/blog/categoria/carreira) 9 anos atrás ## [ Qual linguagem devo aprender primeiro? ](https://www.treinaweb.com.br/blog/qual-linguagem-devo-aprender-primeiro) Há muitas dúvidas sobre qual o primeiro passo para se iniciar na carreira de desenvolvedor. Veja nesse artigo algumas dicas. Ler artigo ## Um ano de acesso total para você viver de programação. Todos os cursos e formações da TreinaWeb numa única assinatura, com professores que atuam no mercado, suporte direto e certificados. Do primeiro `console.log` ao mercado de trabalho. - **1 ano** de acesso a **todos os cursos** - Cursos novos **toda semana** - Suporte **direto com professores** - Plano de carreira **personalizado** - **Certificados digitais** inclusos - **Aplicativos** para Android e iOS, com **acesso offline** **Garantia incondicional de satisfação** Teste por 7 dias e, se não fizer sentido para você, devolvemos seu dinheiro. ### Acesso completo a todos os cursos e dezenas de Formações. 12 meses Economize R$ 840,00 54% OFF de 12x R$ 129,00 por apenas 12x R$ 59,00 sem juros no cartão de crédito ou R$ 599,00 à vista Oferta termina em **05h 15min 55s** - Acesso imediato e ilimitado durante 1 ano. - Plano de carreira personalizado. - Suporte direto com professores. - E muito mais! [Matricule-se agora](https://www.treinaweb.com.br/checkout/pagamento/plano/anual?cupom=TW-SCLIENTE26) [ ](https://www.treinaweb.com.br) Escola online de programação, tecnologia e IA. - [ ](https://www.facebook.com/TreinaWeb/) - [ ](https://www.instagram.com/treinaweb/) - [ ](https://www.youtube.com/user/TreinaWeb) - [ ](https://twitter.com/treinaweb) - [ ](https://www.linkedin.com/company/treinaweb) - [ ](https://github.com/treinaweb) ## Inscreva-se em nossa newsletter Receba lançamentos, promoções e novidades. Seu nome Seu WhatsApp Seu melhor e-mail Inscrever-se ## Cursos - [ Base para Devs ](https://www.treinaweb.com.br/categoria/base-para-devs) - [ Front-end ](https://www.treinaweb.com.br/categoria/desenvolvimento-front-end) - [ Back-end ](https://www.treinaweb.com.br/categoria/desenvolvimento-back-end) - [ Mobile ](https://www.treinaweb.com.br/categoria/desenvolvimento-mobile) - [ Bancos de Dados ](https://www.treinaweb.com.br/categoria/bancos-de-dados) - [ Cloud ](https://www.treinaweb.com.br/categoria/cloud-computing) - [ IA ](https://www.treinaweb.com.br/categoria/ia) - [ E mais ](https://www.treinaweb.com.br/categoria/e-mais) - [ Ver todos os cursos ](https://www.treinaweb.com.br/cursos) ## Conteúdo - [ Formações ](https://www.treinaweb.com.br/formacoes) - [ Projetos práticos ](https://www.treinaweb.com.br/projetos-praticos) - [ Direto ao ponto ](https://www.treinaweb.com.br/direto-ao-ponto) - [ Planos ](https://www.treinaweb.com.br#assinatura) - [ Depoimentos ](https://www.treinaweb.com.br#depoimentos) - [ Comunidade ](https://www.treinaweb.com.br#comunidade) - [ Corpo docente ](https://www.treinaweb.com.br#docente) ## A empresa - [ Sobre a TreinaWeb ](https://www.treinaweb.com.br#sobre) - [ Perguntas frequentes ](https://www.treinaweb.com.br#faq) - [ Vantagens de estudar na TreinaWeb ](https://www.treinaweb.com.br/vantagens-de-estudar-na-treinaweb) - [ Cursos para empresas ](https://www.treinaweb.com.br/empresas) - [ Sugira um novo curso ](https://www.treinaweb.com.br/sugerir-curso) - [ Trabalhe conosco ](https://www.treinaweb.com.br/trabalhe-conosco) - [ Artigos ](https://www.treinaweb.com.br/blog) - [ Desenvolvedores e agentes ](https://www.treinaweb.com.br/developers) - [ Contato ](https://www.treinaweb.com.br/contato) - [ Política de privacidade ](https://www.treinaweb.com.br/politica-de-privacidade) - [ Termos de uso ](https://www.treinaweb.com.br/termos-de-uso) ## Baixe nosso aplicativo [ Disponível na **App Store** ](https://apps.apple.com/us/app/treinaweb/id1322729447) [ Disponível no **Google Play** ](https://play.google.com/store/apps/details?id=br.com.treinaweb.mobile) Av. Paulista, 1765, Conj 71 e 72 · Bela Vista · São Paulo · SP · 01311-200 © 2004 – 2026 TreinaWeb Tecnologia LTDA · CNPJ 06.156.637/0001-58