Jean Delefrati

Oi, boa tarde, tudo bem. Meu nome é Jean. Eu sou programador PHP. Eu sei que isso soa, assim meio como se fosse, um alcoólatras anônimos, porque eu sei que o PHP tem uma certa... às vezes eu uso essa frase assim, porque eu sei que o PHP tem uma certa, vamos dizer assim, reputação de quem é programador PHP, às vezes, costuma fazer muita gambiarra, costuma ser um programador às vezes não tão bom.

Eu queria falar um pouco sobre mim, que eu na verdade comecei na área de programação, assim, quando eu ainda era adolescente, em 1995, ainda brincando com programação. Aí, em 2001, na época de quando “Webmaster” era “a palavra”, vamos dizer assim, “da moda” e foi quando eu comecei a mexer mesmo, a trabalhar profissionalmente com programação e eu entrei no PHP, nesse mundo do PHP em 2003. Depois eu trabalhei em várias empresas, já peguei todo o tipo de código, conheço bastante vários tipos de sistema e, hoje em dia, desde 2015 eu trabalho para a Sucuri. Bom, eu queria falar um pouco sobre o PHP.

O PHP, ele... um dos motivos, na verdade, dessa reputação dele, o PHP inicialmente, ele foi chamado de Personal Home Page quando ele foi criado. Ele foi criado como uma linguagem para o criador dele, ele queria realmente fazer as páginas pessoais dele. Então, ele não era um projeto assim para desenvolver um sistema muito grande, muito complexo. Inicialmente, ele não era assim. Ele foi crescendo, foi crescendo organicamente e atualmente ele já não se chama mais PHP por causa de Personal Home Page. O nome atual dele é PHP Hypertext Preprocessor, que é na verdade, o que significa a sigla hoje em dia.

Bom, o PHP ele tem algumas coisas bem legais assim, ele é gratuito, ele é open source, ele tem uma comunidade muito ativa. Então, assim, tem muita gente que se você tiver alguma dúvida, você pode procurar na Internet, você encontra basicamente tudo o que você tem dúvida, você encontra em fóruns, em todo quanto é tipo de lugar na Internet. Ele é-- a partir do PHP7, ganhou um desempenho bem legal assim, porque até então ele não tinha um desempenho muito bom e é uma linguagem que muita gente começa inclusive a programar pelo PHP, porque é uma linguagem de fácil aprendizagem.

Ela é simples e ela é similar a C ou C++ e Perl também, então tem muita gente que, às vezes, começa a desenvolvendo para o desktop, quando quer partir para a Web é mais fácil você já partir direto para o PHP porque é uma linguagem fácil de aprender e ela é multi-plataforma, você tem portabilidade, de você poder colocar o PHP em qualquer Webserver ou por exemplo, você pode rodar ele também na Dash, Standalone PHP, você tem até o Webserver do próprio PHP e é uma linguagem também que ela permite muita coisa.

Você consegue fazer praticamente tudo com o PHP, você manipular dados, manipular arquivos, você consegue conectar outros sistemas por APIs e é uma linguagem que também é muito maleável, com uma tipagem dinâmica, então, você quase tudo no PHP é o objeto ou array ou matriz. Então, o PHP tem essa, vamos dizer assim, muita gente nova entrando no PHP, muita gente que às vezes não conhece muito de programação, você acaba encontrando todo o tipo de código por causa disso, desde pessoas que conhecem muito, que manjam muito de PHP até pessoas que acabaram de iniciar a programar e o PHP, por ele ter, vamos dizer assim, por ele ter essas facilidades ele é muito utilizado.

Hoje em dia, segundo algumas pesquisas, mais de 80% dos sites da Web usam PHP. Então, é uma linguagem amplamente utilizada e mesmo esses 80% ainda crescem ano a ano, ou mês a mês inclusive e--- só o que acontece? O PHP tem essa maleabilidade de você conseguir fazer basicamente tudo de várias formas diferentes e fazer a mesma coisa em PHP. E o resultado disso é que você acaba com uma coisa parecida com isso daqui. Um canivete suíço que tem basicamente tudo o que você precisa, você consegue fazer tudo com ele só que é difícil de usar. Você já nem sabe.

Você, às vezes, com uma faquinha você resolveria tudo o que você precisa, só que você tem essa ampla gama de ferramentas que podem acabar te confundindo, especialmente, se você é um programador iniciante ou se você não manja muito do PHP. Por isso, o PHP às vezes tem essa reputação de ter muito código com gambiarra porque às vezes você só precisa resolver alguma coisa, precisa só de passar, resolver um problema simples, você dá uma volta enorme, acha uma ferramenta que não era exatamente aquela que você queria, que era mais simples, mais fácil de usar. Então, acontece muito isso.

E o que são gambiarras? Gambiarras também são chamadas de improviso, ou de algo feito sem planejamento ou método alternativo ou ajuste técnico, engenharia alternativa, uma lógica diferenciada. Na verdade, esse aqui eu gosto muito que é a solução inteligente por tempo indeterminado para um problema aparentemente sem solução ou não previsto. Também tem algumas siglas que são ligadas a PHP, que é o DADA - Deixa Assim, Depois Arrumo, lembrando que tudo o que é temporário pode se tornar permanente e esses aqui também, o pessoal usa muito que é POG que é Programação Orientada à Gambiarra e o extreme Go Horse Process, seriam digamos assim, algumas piadas em relativo a pessoas que têm, que programam usando muito a gambiarra, fazendo muita gambiarra, mas quais são os tipos e quais são os motivos das pessoas fazerem gambiarra.

Muitas vezes, você tem códigos com muita gambiarra, você pode fazer gambiarra no próprio código, na configuração do servidor, na configuração da linguagem, na configuração, enfim, você pode também usar no próprio modelo de programação, às vezes por você não usar o modelo de programação, às vezes por você usar um modelo de programação orientada a gambiarra, você tem também na própria estrutura de como os arquivos são organizados, a estrutura interna dos arquivos, muitas formas de você fazer uma gambiarra.

Muitas vezes elas acontecem porque são feitas, às vezes, por usuários que não têm experiência ou, às vezes, você não tem experiência especificamente daquilo que você precisa, daquela solução que você precisa ou, ás vezes, por falha de lógica mesmo, às vezes você não pensou direito, às vezes você nem pensou, você só copiou de um lugar colou no outro e fez assim. Entendeu? Foi propagando a gambiarra. às vezes você não está seguindo nenhuma metodologia. às vezes você está tentando seguir uma metodologia mais de um jeito errado, às vezes é preguiça ou às vezes é pressa, porque ás vezes acontece. Você às vezes tem que entregar algum projeto na sexta-feira às cinco horas da tarde ou às seis horas da tarde precisa lançar para o ar e o chefe te falando no seu ouvido ali, você tem que acelerar, tentar resolver e aí você não consegue fazer aquilo do jeito certo, então você acaba, "Ah, é só copiar esse código aqui, colar aqui e, está bom". Isso aí é uma gambiarra que às vezes você faz.

às vezes também é por questão de código legado, de você pegar algum sistema muito antigo, com alguma solução que não era a ideal para o momento ou às vezes você também tem o chamado código Frankenstein, que é quando a pessoa tem muitos programadores, sem seguir uma lógica igual todos eles e cada um seguindo um modelo diferente, modelo de programação e aí, cada um deles pensando numa coisa e acaba, para você juntar tudo, você faz umas gambiarras, faz um ajuste técnico aqui e vai acertando para conseguir colocar tudo e poder atender o seu cliente ou o seu próprio patrão.

Eu separei alguns exemplos, lembrando que não são todos os exemplos, assim, vamos dizer assim, tem milhões de formas, é praticamente infinito a quantidade de gambiarras que você pode fazer, mas eu separei alguns aqui só para vocês terem uma ideia de alguns tipos de exemplos de gambiarra que as pessoas às vezes fazem e são encontrados inclusive em sites que estão-- ou poderiam ser encontrados em sites que estão no ar.

Por exemplo, eu separei um aqui que é clássico, que esse aqui é quando a pessoa começa a programar em PHP ou em qualquer outra linguagem Web ele percebe isso aqui, que faz um formulário, vamos dizer assim, por exemplo, a pessoa criou um formulário e descobre que, "Nossa, eu tenho o nome do campo, eu tenho o valor que está chegando. E se, ao invés de eu pegar e validar todos esses dados e se eu fizesse um loop aqui, um laço aqui que pegasse todos os valores automático e gravasse no meu Banco de Dados." Isso aqui é clássico. Tem muita gente que me pergunta isso.

Isso aqui é extremamente inseguro, especialmente, do jeito que está, sem nenhuma validação. Isso aqui, para você ter uma ideia, o hacker ou uma pessoa, vamos dizer assim, que estivesse tentando invadir o seu site, ele conseguiria fazer um SQL Injection até pelo nome do campo do formulário. Se ele criar um formulário pelo Chrome, por exemplo, ou pelo, vamos dizer assim, por uma Dash, por exemplo, um Shell, o cara conseguiria invadir o seu sistema pelo nome do campo.

Isso é absurdo e tem muita gente que ainda pergunta. Gente, isso daqui é clássico, ou seja, a pessoa pensa, "Você não precisa pensar se o código fizer tudo para você." Lógico que não.

Outro, hoje em dia, tem muita gente fala, "Bom programador não usa Else, programador faz tudo com if", mas e se a pessoa, por exemplo fizer uma coisa assim. Só para explicar mais ou menos o que está acontecendo aqui. O programador, nesse caso, ele criou ações, vamos dizer assim, pegando pela URL, pela querystring e aí ele pegou, está validando, por exemplo, se a ação é “inicio”, a ação é “sobre” ou a ação é “contato”, só que se o programador faz isso em PHP tem um probleminha e se você coloca dois iguais você não está validando o tipo de variável, você só está validando o valor dela.

Então, se você pegar duas variáveis de tipo diferente o PHP sempre dá Verdadeiro, sempre dá True, ou seja, nesse caso se você passasse uma coisa assim, por exemplo pela URL você passasse uma ação como uma matriz, o código não vai entender. Ele simplesmente vai jogar tudo para o ar e o usuário conseguiria pegar todos esses dados, vamos dizer assim, porque você não pensou, você não teve aquele momento simples para raciocinar, "Nossa e se o cara fizer assim".

Outro tipo, por exemplo, de gambiarra. Esse aqui também é clássico, a permissão por Blacklist ou por, vamos dizer assim, lista de bloqueio. Seria por exemplo, o cara faz uma permissão e aí ele só valida se aquela permissão, uma sessão se ela está em branco. Mas e se por exemplo essa sessão não existisse, não tivesse sido iniciada ou qualquer outra coisa, nesse caso, ele nunca ia entrar nesse if aí e ia passar todo o código, isso acontece muito. Esse aqui também é bem comum, da pessoa às vezes não fazer endentação, misturar PHP com HTML, com Javascript, colocar tudo junto num código só e, às vezes, vira uma paçoca que quando você olhar esse código, você fica, "Nossa, mas"-- quando o programador olhar essa, "Nossa mas aonde é que está?".

Por que às vezes não é nem uma gambiarra, é um código mal escrito mesmo, mas ela é propícia a você criar gambiarras, porque o programador vai olhar, isso aí e vai falar, "Mas espera aí onde é que está começando esse if, onde é que está terminando esse while, onde é que ele inicia, onde é que ele finaliza" e vai ficar calculando e aí faz uma gambiarra, ali resolve e passa para a frente, acontece. Então, é sempre importante. Você acha que endentação não é importante. é importante. Acontece muito de a pessoa fazer uma endentação ruim e depois ter que fazer uma gambiarra para corrigir isso.

Outra, por exemplo, esse aqui também, não é tão clássico, mas é bem perigoso. Isso aqui é uma coisa muito perigosa, que às vezes, especialmente hoje o pessoal, como eu disse lá no começo o PHP, ele permite você fazer quase tudo. Você poderia, por exemplo, listar as pastas de um endereço simplesmente pelo próprio PHP, mas você também pode chamar uma Shell, um Dash ali e executar e pegar os dados, mas nesse caso é o cara acha, "Eu estou protegido, coloquei ali um addslashes ali na linha de cima". Isso significa que ele vai colocar contra-barras em tudo, só que às vezes a pessoa não pensa que o addslashes não serve para tudo, ele serve para querystings ou para banco de dados, mas quando você vai executar alguma coisa na Shell não é a mesma coisa. um ecomercial, por exemplo, ele não adiciona slashes. Um pipe, por exemplo que é aquela barrinha de pé, vertical, ele não adiciona, ou seja, isso aqui, um código desse aqui com um programador um pouco mais experiente, às vezes que seja mais malicioso ele poderia simplesmente jogar, por exemplo, um código aí para apagar todo o seu sistema, todo o seu servidor, você perder tudo o que você fez e aí você está achando que está protegido, mas não está protegido. Como o pessoal diz, você nunca deve confiar no usuário.

Você não conhece o usuário e, nesse caso, está criando uma corrente toda segura do seu código e às vezes coloca ali um arinho de plástico para segurar o seu sistema inteiro, um problema de segurança assim gravíssimo e achando que você está se sentindo seguro, uma falsa segurança, na verdade.

Esse aqui também não é clássico, mas eu já vi acontecer, que é da pessoa às vezes colocar... a pessoa precisa validar alguma coisa e precisa mostrar a mensagem e aí ele está pegando lá um catch lá, para ele poder pegar o que está sendo executado e aí o cara faz uma exceção falsa para pegar, para mostrar uma mensagem para o usuário ou, mas isso aqui é absurdo, porque nesse caso, tudo isso aqui vai ficar gravado no log e na hora que o seu Sys Admin der algum problema, o Sys Admin precisar olhar o log ele não vai se achar lá, vai virar uma bagunça ele não vai ter noção aonde é que ele está. Ele vai perguntar, "O que é que eu estou fazendo aqui? Por que é que deu um erro gravado como sucesso? Como assim, um erro de sucesso?” é meio... acontece.

Esse aqui também é muito clássico hoje em dia, especialmente, quem está começando a querer fazer alguma coisa um pouco mais avançada. Por exemplo, fazer um auto-loader, para por exemplo fazer um MVC ou alguma coisa assim, um sistema diferente e a pessoa bota um auto-loader para ele carregar tudo, só o que acontece?

A pessoa imagina que o usuário vai estar usando um browser, que ele vai digitar as URLs todas certinhas e coisa e tal, mas se por exemplo passar o URL pelo, vamos dizer assim, por um curl e ele botar um ponto ali e se ele colocar um código ali no meio para executar no meio. Isso aí, ele poderia por exemplo pegar todas as suas senhas do seu banco de dados com um código desse ou todas as senhas do seu servidor, ou seja, você está deixando todos os seus dados vulneráveis.

Como eu disse, esses aí são só alguns exemplos de gambiarras assim que o programador às vezes faz, às vezes por aqueles motivos que eu disse, às vezes por falta de experiência, às vezes por falta de lógica.

E eu queria falar um pouquinho como evitar gambiarras. Primeira coisa é usar a cabeça. Você pensar antes de escrever e não simplesmente fazendo, copiando, colando e refazendo.

às vezes, se você pega um código que já está muito difícil de entender, já é muito complexo, em vez de você fazer uma gambiarra às vezes vale muito mais a pena você refatorar ou até reescrever um código, vale muito mais a pena deixar mais seguro o seu código e é manter também alguns, seguir alguns padrões, o KISS principle que é keep it simple, stupid seria o princípio de manter tudo simples, tudo fácil de entender, tudo fácil de ser processado, mais rápido de ser processado pelo servidor e você não precisar ficar tentando entender o código depois, ser mais simples de você entender, usar padrões, o PHP tem vários padrões, tem padrão, são os PSRs, você tem padrão para como fazer auto-loader de arquivo, como nomear arquivo, como colocar espaço, como endentar, tem quase todos os tipos de padrão.

Se você seguir isso aí você vai facilitar muito, para você ler o código e vai te ajudar muito evitar fazer gambiarras e você, vamos dizer assim, se perder no código e depois ter que fazer um ajuste técnico ali para acertar. Usar um CDN é uma forma de deixar o seu código mais seguro, seria uma rede, uma network de conteúdo distribuído que ele vai fazer cache, ou seja, a pessoa em vez de acessar seu site, ele acessa uma versão HTML, em vez de acessar o seu PHP direto. E lembrar que ataques são inevitáveis, o importante é ter backups e fazer monitoramento do seu servidor, do seu código, de tudo. E é claro também que é inclusive o assunto dessa palestra usar um WAF, que é um Web Application Firewall.

E o que seria um Web Application Firewall e como ele pode te ajudar? Ele age como um serviço intermediário entre o aplicativo do seu site e o visitante que está acessando o seu site, ou seja, o usuário ele não vai acessar teu site direto, ele vai acessar o WAF, o WAF vai validar, vai interromper tudo quanto é pedido malicioso, ele vai já ter algumas assinaturas próprias que ele vai encontrar, que ele já vai apagar e depois pegar o Request bonitinho, limpinho e mandar para o teu site. Ele vai evitar payloads conhecidos, ele vai assim ajudar a proteger o seu trabalho, o seu servidor, o seu ambiente, os seus clientes.

Porque você tem que pensar que a maioria dos ataques, eles não acontecem porque os hackers eles estão focando no teu site. às vezes você fala, "Eu tenho um sitezinho de venda de sapatos aqui só para a região. Isso aqui não vale nada. Para que é que eu vou me preocupar em colocar um WAF ali, botar uma segurança, porque não tem nada de importante." O hacker não vai me encontrar aqui, só o que acontece é que a maior parte dos ataques não acontecem por causa disso, a maior parte dos ataques não são direcionados, eles são por hackers que estão procurando, vamos dizer assim, grandes volumes de sites, por exemplo, com plugins antigos, com sistemas desatualizados. E aí eles vão vasculhar, eles sabem alguns lugares que já vão encontrar.

Eles vão fazer uma lista automática, eles têm um bot já que vai ficar rodando os motores de pesquisa e pegando um bot e ligando todas as URLs, depois ele vai bater em todas vai ser milhões, às vezes milhares de sites de uma vez, vai testar todos eles e ver, "Esse aqui está vulnerável". E aí ele vai mesmo-- pode ir a fundo e encontrar o seu site, enfim, invadir o seu site. E o WAF na verdade é especialmente eficaz, especialmente se você não tem controle total do seu código, por exemplo, você usa um plugin com códigos de outra fonte, que às vezes, como eu disse, tem alguma vulnerabilidade neles ou às vezes você usa um framework ou CMS conhecido.

Por exemplo, você usa um WordPress, um Joomla!, um Magento e às vezes entrou uma vulnerabilidade lá e você não atualizou. Ou às vezes um 0 day e às vezes você não tempo de corrigir. Ou porque um código-- a pessoa criou uma vulnerabilidade ali e você não sabia. às vezes você não tem como corrigir automaticamente ou manualmente. Ou às vezes porque você prefere fazer tudo in-house. Você prefere fazer tudo-- ao invés de pegar coisas prontas, você faz tudo dentro da sua própria empresa ou dentro da sua própria casa. Voce faz tudo do zero. E às vezes você não tem a mesma experiência de uma equipe grande, que está se preocupando com a parte de segurança para você.

Ou às vezes você não pode ou não quer atualizar a versão do seu servidor ou da linguagem, acontece. "Eu preciso desse método Mysql que só roda no PHP 5.6 ou no PHP 5.4." Aí você não tem como atualizar, porque o sistema é muito grande, enfim, você vai perder muito tempo para corrigir. O WAF, ele já vai automaticamente saber os payloads próprios, ele já vai fazer toda a limpeza disso antes de chegar no seu site.

Ou você usa um código legado, não conhece totalmente o código. às vezes você tem um sistema muito antigo, você não sabe como ele está funcionando e às vezes tem alguma vulnerabilidade que já foi resolvida, hoje em dia você não conhece-- ou também se você tem dados sensíveis seus e de seus usuários. Lembrando que os dados sensíveis não são só, por exemplo, cartão de crédito ou a senha do banco da pessoa, muitas vezes um dado sensível é simplesmente uma senha do sistema que o usuário reutilizou, em todos os sistemas dele. Acontece.

O usuário, às vezes, usa a mesma senha do e-mail, às vezes até a mesma no banco, às vezes no cartão de crédito. Ou seja, esses são dados sensíveis, e quanto que esses dados sensíveis valem para você e para o seu cliente. E quando você, por exemplo, o seu próprio código, quanto que ele vale para você, quanto que vale o seu tempo desenvolvendo ou corrigindo tudo depois que você chegou nesse-- depois que você perdeu seus dados. Como o WAF não consegue te ajudar, uma Web Application Firewall, ele não substitui todos os controles existentes, ele não vai, vamos dizer assim, "Eu coloquei um WAF, posso tirar todos os outros firewalls, todas as outras medidas de segurança que eu fiz, que eu estou tranquilo." Não.

Ele vai complementar e ajudar a proteger o seu site. Assim como ele também não vai ajudar você a escrever códigos mais simples, que vai ser mais fácil de outras pessoas entenderem. Ele também não vai te ajudar a escrever menos gambiarra. Ele não vai mexer no seu código. Ele vai na verdade ajudar a segurar, vamos dizer assim, os usuários mal-intencionados a entrar no teu sistema. Eu queria falar um pouquinho também agora, especificamente sobre o WAF da Sucuri, que ele é uma Web Application Firewall e ele é um sistema de prevenção de intrusão. Ele foi desenvolvido especificamente para enfrentar esses desafios de segurança de sites.

Ele emprega patching e harding virtual para atenuar os ataques antes de chegar no teu site. O firewall da Sucuri, ele é como se fosse proxy reverso. Quando a pessoa tenta-- na verdade ele é um proxy reverso. Antes da pessoa chegar no teu site, ele vai bater no firewall da Sucuri, a Sucuri vai limpar tudo para você, os requests todos e vai jogar o usuário depois para o seu servidor. E ele já tem o próprio CDN, que ele já vai fazer um cache do teu site, vai deixar o teu site ainda mais rápido. Vai deixar ainda melhor o teu sistema e mais protegido.

Seria mais ou menos assim que ele funciona. O usuário externo está tentando acessar o seu site, ele vai acessar o firewall da Sucuri, lembrando que ele não deve ser a única medida de segurança. E aí o firewall da Sucuri vai limpar o seu request e depois mandar o usuário para o teu servidor. Vai mandar um request para o seu servidor, pegar o request de volta e mandar para o usuário. E um bônus, eu queria colocar como não configurar um WAF, que acontece ás vezes da pessoa contratar um WAF, um Web Application Firewall e não usar, e não aponta o site, não configurar nada.

Ou às vezes nem ter um WAF, um Web Application Firewall, enfim, não ter segurança. Ou as vezes deixando pontas soltas, fazendo configuração parcial. às vezes você tem um site e você configura o firewall nele, mas junto com ele você tem uma outra URL que aponta para o mesmo servidor e você deixa uma ponta solta. Fez uma configuração parcial. Ou as vezes você tem vários sites no mesmo servidor e todos eles, você mandando pro mesmo, as vezes a pessoa mal intenciona entra por outro lado e ataca o teu site. Ou, por exemplo, colocando Whitelist, ou lista branca, permissão em tudo.

"Eu quero colocar um firewall para deixar seguro" Aí o cara vai lá, porque o firewall permite você configurar. Aí ele permite e a pessoa vai lá, "Vou colocar tudo como se fosse lista de permissão, tudo isso aqui a pessoa pode fazer" Aí para que ter WAF, não é? Apesar que ele ainda vai ajudar em outras coisas, ele vai ajudar você, por exemplo, contra ataques de DDOS, de outros tipos de ataque. Por exemplo, injeção de código. Ou colocando Blacklist em tudo. Quer dizer, você bloqueia tudo, tudo, tudo e a pessoa não pode acessar nada. Aí depois a pessoa vem reclamar, "Ninguém consegue acessar meu site" Se você bloquear a pessoa, a pessoa não acessa mesmo.

Ou dando Whitelist em código inseguro, em código que você sabe que é inseguro e mesmo assim você coloca ele na lista branca de permissão. Bom, isso são algumas formas, era mais ou menos o que eu queria falar com vocês. E também agradecer a vocês por terem vindo, por terem acompanhado essa palestra e é isso aí.