 Bom dia. Bom dia. Só para ter uma ideia aqui, eu costumo fazer uma pesquisa demográfica antes de começar a palestra, porque é uma palestra com um tema como esse. Tem dois caminhos que a gente pode seguir. A gente pode tanto levar um pouco para o lado um pouco mais técnico, quanto levar para o lado um pouco mais prático do usuário. Então, quem aqui é desenvolvedor e trabalha com horteprés no dia a dia. Beleza. Acho que é a maioria, então. Beleza, galera. Como foi dito aqui, a proposta da palestra a gente conversar um pouco sobre segurança no horteprés, mais em específico a questão dos plugins e dos temas. Eu já fui apresentado, mas vou apresentar um pouquinho novamente. Meu nome é Arindo Duque. Eu sou lá de Juiz de Fora, Minas Gerais, internacionalmente conhecido como a Cidade da Facada. Eu sou o fundador da Nexpress. A gente desenvolve um plugin para a multi-site que chama WP Último, o admin.press.pro. E a gente também coordena o Meetup de horteprés lá de Juiz de Fora. Foi falado aqui na introdução do evento e tal, mas em 2017 a gente foi no nosso primeiro WordCamp lá em São Paulo e a gente viu uma palestra sobre como organizar um Meetup local. E a gente ficou tão animada que a gente foi lá e fez o nosso Meetup em Juiz de Fora. Então eu não sei se a maioria da galera que é daqui de Porto Alegre mesmo, mas se vocês forem de fora, corram atrás de organizar Meetups na cidade de vocês porque é bem legal, a comunidade é bem maneira, sejam junto uma galera, faz o network. Bem massa. Beleza, estou apertando muito forte. Beleza, então acho que um 60% aqui é desenvolvedor, eu trabalho com horteprés no dia a dia, ponto de vista de desenvolvimento. E eu, pelo menos, quando eu trabalhava agora, a gente foca mais no desenvolvimento dos plugins e dos produtos, então eu acabo não lidando tanto com os clientes no dia a dia. Mas quando eu fazia fríla ou desenvolvia site para cliente normalmente, às vezes o cliente chegava com a ideia, o cliente não é técnico, então ele não sabe que plataforma a gente vai estar usando. E aí a gente falava, pô, legal, não, a gente faz isso aí com horteprés. E aí mesmo cliente não técnico que não faz ideia do que é um CMS, ele falava, mas no horteprés não é aquela parada que não é tão segura assim? Aí a gente tem que se dar todo aquele trabalho de explicar que isso não é verdade, que provavelmente nunca foi verdade, mas é uma das lendas urbanas que o desenvolvedor de horteprés tem que ali lutar todo dia contra e no dia a dia. Mas, afinal de contas, então, o horteprés é seguro ou não? A verdade é que ele depende. O horteprés em si, o software open source, que é desenvolvido por gente do mundo um todo, que começou lá em 2003, que fez 16 anos agora e que tem release de, pô, agora eles estão lançando release nova, tipo, quase a cada três meses. Tem um monte de gente colaborando. O horteprés core é super, super, super seguro, super seguro. O problema é que a gente instala o horteprés e como foi falado na primeira palestra da Marcelli e o Fernando comentou um pouco também, um dos grandes poderes do horteprés que o horteprés te dá é a extensibilidade. Então, o horteprés, o software base, ele faz bastante coisa, mas é uma lista limitada de coisas. O grande poder que ele te dá é que você consegue instalar temas e plugins que fazem praticamente tudo. Então, você quer ter um e-commerce, você consegue com o e-commerce com outras opções, você quer instalar um plugin que faça a maior parte do trabalho pesado para você no SEO. Você tem várias opções, mais de uma opção. Você quer transformar o site dinâmico de horteprés em um site estático para a velocidade. Tem dezenas de opções de plugins de cache. E tem plugins muito doidos que fazem coisas muito mais malucas ainda. Você quer fazer uma rede social, você consegue. Você quer fazer um fórum, você consegue. Então, o grande poder do horteprés, no meu ponto de vista pelo menos, é o ecossistema. Então, a gente tem lá o repositorio de horteprés.org, eu não lembro do número exato, mas o ano passado, quando eu dei um olhado, acho que eram 54 mil plugins disponíveis no repositorio, já deve ter crescido bastante de lá para cá. Então, é aí que a questão da segurança começa a se tornar relevante, porque a gente não está usando só o horteprés. A gente está usando o horteprés, que é desenvolvido por toda essa galera, com um monte de plugins que são desenvolvidos por uma série de outras pessoas. Então, a gente está adicionando funcionalidades extras. Então, a nossa instalação específica do horteprés, ela pode não ser tão segura assim, se a gente não tomar os devidos cuidados. Aqui, só por exemplo, ficar, porque a gente pega o horteprés bonitinho, o menu do ladinho bonitinho com alguns itens, começa a instalar plugins, começa essa aberração de admin-notes no topo, e o menu, você não consegue rolar mais e fica cheio de coisa aí, cheio de notificação, o iost coloca um milhão de coisas lá em cima, etc. Então, uma corrente é tão forte quanto o seu elo mais fraco, e isso é muito verdade quando a gente está falando do horteprés e da instalação de plugins em específico. Então, a sua instalação, por mais cuidado que você tenha, mais eloso que você seja, ela sempre vai ser tão segura quanto o seu plugin menos seguro. E cada plugin novo que você instala é um novo elo nas correntes, é um novo potencial ponto de falha que você está adicionando. Então, é aquele negócio. O grande poder do horteprés é que existem milhares de plugins, mas com grandes poderes ou em grandes responsabilidades. Então, é importante a gente tomar cuidado cada vez que a gente toma essa decisão de adicionar um plugin novo. É porque é tão fácil instalar um plugin que a gente faz quase que automaticamente. Eu preciso aqui de mostrar uma pop-up na home porque estou fazendo uma promoção. Você pesquisa dois minutos no repositório, tem dez opções ali, você instala a primeira, ativou, não quebrou o site, para você estar tudo certo. O que a gente tem que começar a criar é um mindset de que instalar um plugin num site em produção é uma decisão muito importante, cara. É como a gente falou, você está literalmente adicionando um novo elo nessa corrente, mais um potencial ponto de falha, mais um plugin para você cuidar de se certificar que está sendo mantido atualizado, etc. Então, é bom tomar muito cuidado quando você toma essa decisão. Aí, beleza, agora a gente vai contar uma historinha para a gente ver por que isso é importante ou não. Imagina um belo dia, você está em casa, e aí você decide entrar no seu site para ver como é que ele está, e aí você dá de cara com uma tela dessa. Um site oficial da Microsoft, obviamente, falando que seu computador está infectado e que quer para você ligar para a Microsoft gratuitamente. Quem vai te atender é provavelmente alguém que vai querer te cobrar uns 300 dólares para limpar o seu computador, e a sua vozinha se der de cara com essa mensagem, provavelmente vai fazer essa ligação no computador dela. Outro exemplo também de página, essa é um pouco mais amadora. Eu acho que essa aqui é mais a credibilidade maior. Mas imagina, por exemplo, um dia, se acordar e o seu cliente te ligando a direcionar desesperado, porque toda vez que ele tenta entrar no site dele, ele é redirecionado para uma tela dessa. Mas foi exatamente isso que aconteceu com grande parte dos mais de 60 mil usuários desse plug-in que está lá no repositório, que é o social warfare, que é um plug-in muito bobinho. A única coisa que ele faz é adicionar botões de compartilhar a postagem em mídia social. Só isso que ele faz. Só que ele tinha uma vulnerabilidade. E tinham mais de 60 mil pessoas com esse plug-in instalado, um plug-in bobinho, que só adiciona botões para compartilhamento em rede social. Muitos sites grandes caíram nessa vulnerabilidade. Então às vezes você entrava num site grande, relativamente grande, que você estava acostumado a entrar todos os dias e dava de cara com a tela dessa. Alguns redirects eram ainda pior. Você caía em sites de pornografia, etc., etc. Beleza. Esses usuários, os usuários desse plug-in, eles foram vítimas do que a gente chama de uma vulnerabilidade dia zero, que é quando alguém acha uma vulnerabilidade num pedaço de um programa específico, e ao invés dele notificar o desenvolvedor, ele vai lá e às vezes ele lança uma prova de conceito, ou ele usa ativamente essa vulnerabilidade para ganhar alguma vantagem elicita, e o desenvolvedor não fica sabendo. Então nessa janela de oportunidade, entre o momento que a vulnerabilidade foi descoberta e o momento que o desenvolvedor ficou sabendo, você pode infectar um número N de sites, porque essa vulnerabilidade se espalha muito rápido. Então é isso que aconteceu aqui. Alguém descobriu essa vulnerabilidade, criou uma prova de conceito, publicou a prova de conceito e num intervalo de 12 horas em que essa prova de conceito estava no ar, uma parcela significativa desses 60 mil sites aí começaram a apresentar esse problema. Mas qual era a vulnerabilidade em questão? Aqui a gente tem o pedaço do código do plug-in que causava essa vulnerabilidade. Em primeiro lugar, como desenvolvedor, eu acho que esse código existir dentro de um plug-in já é um absurdo, mas aí a gente vai passar por ele mais ou menos passo a passo para a gente entender o que está acontecendo. Basicamente, o que esse pedaço de código faz é permitir que as configurações do plug-in sejam reescritas de forma remota. Então você passa uma URL para o seu site, linkando para onde as configurações estão, aí é um arquivo, é um formato JSON, e ele verifica se você tem as permissões para fazer isso e reescreve as configurações do plug-in. Tudo isso remotamente, você consegue fazer remotamente. Beleza, só que se a gente olhar aqui com carinho, a gente vê que a primeira linha ali, a segunda linha, na verdade, de código, ele está fazendo uma checagem de segurança. E se você não passa nessa checagem de segurança, é o que aquele ponto de exclamação fala, ele é o não, lógico, ele dá uma mensagem de erro, você não tem autorização para ver essa página. Então, em tese, a gente está seguro. Beleza? O problema é que esse trecho de código aqui tem uma falha monstruosa, e que é muito comum e que desenvolvedores cometem o tempo todo. Alguém que não é desenvolvedor, se eu te perguntar o que é que a função isadmin do Wordprefs faz? Qual seria o chute de vocês? Alguém quer dar um chutezinho? É uma função que chega, o nome da função é isadmin, a tradição literal seria eadministrador. O que é que essa função faz? Assim, o meu chute, se eu estivesse chegando no Wordprefs, seria dizer que essa função me diz se o usuário logado é um admin ou não. Concordo? É essa checagem que o cara está fazendo aqui, e esse cara não é um desenvolvedor novo, ele é um desenvolvedor experiente. Ele está perguntando ali, o if é o si, se o usuário não for admin, é lógico, você até lê de forma lógica a frase. Você mostra uma mensagem de erro para sair. Qual que é o problema? O problema é que o Wordprefs tem 16 anos, e muita gente mexeu nesse código durante esses 16 anos, muita gente mesmo. E assim, nem sempre escolhas sábias foram feitas quando criando nomes de funções. Esse é o exemplo clássico, inclusive. A função isadmin não checa se o usuário é administrador. Ela só checa se você está no painel de administração, ponto. Ela te diz se você está no front-end ou não, ou no painel de admin ou não. Se você tiver em qualquer URL que é barra wpadmin, isadmin volta true, volta verdadeiro. E lá na documentação Wordprefs, isso é um erro tão comum, que na própria documentação Wordprefs, ele fala que na descrição não checa se o usuário é um administrador. Você tem que usar uma outra função para fazer isso. Então tudo o que o cara que achou essa vulnerabilidade ele precisava fazer, ele basicamente leu o código, ele viu que estava lá, ele viu que tinha como executar de forma remota. Ele sobreescrevia as configurações do plugin no seu Wordprefs com as configurações que ele queria. E aí, nas configurações de rediracionamento, ele colocava o link que ele quisesse. E aí, alguns usavam para mandar para aquela tela de golpe lá do suporte da Microsoft. Alguns os mais jocosos mandavam para sites pornográficos. Alguns redirecionavam o tráfico do concorrente para o seu próprio site. E isso aí ficou rodando. E eu acho que demorou 5 ou 6 horas para o desenvolvedor corrigir, que em vez de corrigir ele simplesmente removeu essa pedaça de código inteiro. E eu acho que foi uma decisão sábia. Mas nesse meio tempo foi uma farra da nada, porque esses sites todos foram vítimas da vulnerabilidade. Desde então, um monte de site, um monte de plugin vazou com vulnerabilidade similar. Agora que o pessoal sabe o que procurar, muita coisa vazou. Então, alguns exemplos são esse Alopencil, que ele deixa você customizar o CSS do seu front-end de forma mais ou menos dinâmica. O WPiS e SMTP, que é um plugin muito usado para você usar outros serviços de envio de e-mail. Você usar o negócio da Amazon, o SendGrid, o MailGam, da Vida. E todos eles tinham vulnerabilidades similares. E muito fáceis de fazer hoje. Aí a gente entra numa discussão sobre quem é a responsabilidade. Quando acontece um ataque desse, quem são os responsáveis, quem a gente deve culpar, quem a gente deve correr atrás e pedir a cabeça? Na minha opinião, existe uma responsabilidade compartilhada. A gente tem dois jogadores nessa equação. A gente tem o desenvolvedor de um lado e a gente tem o usuário do outro lado. É impossível desenvolver software sem introduzir bug, sem introduzir uma vulnerabilidade aqui ou ali. A gente lá, nós somos em três, a gente desenvolve o software. Toda vez que a gente lança uma feature nova, uma funcionalidade nova, a gente introduz no mínimo cinco bugs novos. Então, é muito difícil. Qual é a nossa responsabilidade, no entanto? Em primeiro lugar, testar sempre o máximo possível para a gente garantir que a gente não está liberando nada com uma vulnerabilidade grave. Mas também a nossa responsabilidade, que a partir do momento em que a gente saiba que existe uma vulnerabilidade, corrigir e avisar o mais rápido possível. Assumir o erro e falar, não, galera, beleza, a gente errou aquele pedaço de código era burro, foi mal escrito, ou estava voltando a dor de cana quando eu escrevi. Então, é a responsabilidade do desenvolvedor tomar este tipo de cuidado e corrigir esse tipo de vulnerabilidade o mais rápido possível. Porém, de nada adianta que o desenvolvedor libere uma versão nova corrigida três horas depois da vulnerabilidade ter sido descoberta. Se você não checa o seu painel de administração dor de prez com regularidade para certificar que os seus plugins estão atualizados. Então, nessa parte, existe uma responsabilidade ativa por parte do usuário também. O usuário, ele precisa ter consciência que manter o site dele no ar também é um pouco a responsabilidade dele. Então, é interessante e é necessário que você mantenha os seus plugins em temas atualizados. E é por isso que é interessante você tentar manter o menor número de plugins instalados possíveis porque é menos coisa para você tomar conta, basicamente. Então, aí eu preparei um resumão para como a gente lidar com esse tipo de vulnerabilidade dos dois pontos de vista. Do ponto de vista do desenvolvedor, do ponto de vista do usuário final. Do ponto de vista do desenvolvedor, é aquilo que a gente viu. Não se deixe enganar pelo nome de algumas funções. O nosso exemplo clássico é a Isa de Min, que é o exemplo que todo mundo dá quando fala disso. Mas existem outros exemplos dentro do código dor de prez. A gente trabalha muito, por exemplo, com o código de prez multi-site, cara, e aí a nomenclatura das funções é uma loucura absurda. Nada faz sentido, nada faz o que você acha que faz. Tem coisa que chama site, tem coisa que chama blog, mas dependendo do contexto, o que é blog a site, dependendo do contexto que a site é network, aí é uma loucura. E a gente direto introduz bug por causa disso. Em segundo lugar, sempre que você for fazer uma tarefa crítica, que o seu plugin for performar algo crítico, como, por exemplo, limpar uma tabela no banco de dados, ou limpar, resetar as opções, as configurações do plugin. Você tem que se certificar que o usuário que está fazendo isso tem as permissões corretas para fazer isso. Sempre, como é que você faz isso? Não é com o Isadmin, é com essa corrente user-can. E aí você passa a capacidade e no WordPress, quando ele está instalado sem ser multi-site, numa single install, você vai provavelmente querer passar essa manage options para ser testado. Aquele código que a gente viu, então, anteriormente, com a vulnerabilidade, corrigido, a gente só trocou ali na segunda linha de código mesmo o Isadmin pelo corrente user-can ali, e aquilo já certifica que o usuário logado precisa ter as permissões para fazer isso. Eu ainda iria além e colocaria uma série de outras checagens de segurança que o WordPress oferece, que são os nonces lá, para a gente justificar que o cara está vindo de uma tela de administração, quando ele está performando essa tarefa, esse tipo de coisa. Na real, esse código aqui em particular eu removeria completamente. Beleza. Outra coisa que você precisa fazer se você é desenvolvedor e, principalmente, você está trabalhando com temas e trabalhando com o front-end do tema. Se informar sobre como escapar conteúdo corretamente, conteúdo que vem do banco de dados e conteúdo que foi imputado pelo seu usuário. WordPress oferece uma série de funções para fazer isso. Quando você vai, por exemplo, dar display em uma URL, você tem que usar o SQL, o URL e no HTML. É a mesma coisa. Tem funções análogas para atributos dentro do WordPress e você certifica que se o seu usuário tenta fazer um input errado ali, colocar alguma coisa errada em um campo, você não vai quebrar o display do front-end inteiro. Beleza. Para o usuário, isso aqui, cara, não devia ser nem falado mais, mas a gente sempre fala, e toda vez que eu estou dando palestra, eu costumo falar, você tem que manter o WordPress atualizado e os plugins também, porque tem muita gente trabalhando ali para certificar que aquilo está o mais seguro possível. Então, cada dia que você está atrás de uma atualização tanto do WordPress em si quanto de um plugin, você pode estar ali abrindo uma janela de oportunidade para alguma vulnerabilidade que você não ficou sabendo. Beleza. Aí, uma coisa que é legal de fazer e que pouca gente faz também. Quando algum plugin ou algum tema, ele lança uma versão nova, ele te fala a mensagem de que tem uma mensão nova e tem um linkzinho ali para você ver os detalhes da versão. E esse link, ele te leva direto para o changelog, que é basicamente uma lista de todas as mudanças que em escreve essa lista, é o desenvolvedor do plugin, e você consegue ver se tem alguma coisa grave ali que o cara corrigiu e que seja urgente para você fazer a atualização do plugin ali na hora mesmo. Outra coisa, não está ali plugins que não estejam sendo ativamente mantidos. Agora, o WordPress.org, ele te avisa, ele mostra essa mensagem de erro, fala que o plugin não foi testado com a sua versão atual do WordPress, mas ali do lado você sempre foi capaz de ver qual foi a última atualização que o desenvolvedor lançou do plugin. Se o desenvolvedor, cara, ele não está mexendo... Olha para o Brasil, olha quanta coisa que aconteceu nos últimos dois anos. Tem dois anos que esse desenvolvedor não lança nada novo para esse plugin. Eu não me sentiria confortável instalando um plugin desse na minha instalação do WordPress. E por mais que seja o único plugin que faça exatamente aquilo que você precisa, se ele não está sendo ativamente mantido, e se você não tem como, não tem as capacidades de pegar e dar uma olhada no código-fonte para ver se está tudo certinho, eu recomendo que vocês não estalem. Certifiquem-se que vocês estão instalando plugins que tem gente ali trabalhando por trás para garantir que está seguro e tal. Outra coisa, só mantenha instalados plugins que realmente estão em uso. Não tem porque você ter aquela lista, aquela tabela gigante de plugins, instalados com dois ou três ativos. Se não está ativo, você não precisa, deleta, se eventualmente você precisar, você instala de novo. Por quê? Porque o plugin instalado está na sua pasta plugins. Os arquivos PHP dele estão lá. Então se o seu servidor está mal configurado, ou se existe alguma vulnerabilidade nesses arquivos PHP e eles conseguem ser acessados porque o servidor está mal configurado, a vulnerabilidade continua estando lá. O plugin está não ativado ou não. Então se você não está usando, não tem porque você correr esse risco. Deleta, que é o melhor que você faz. Show. Quarto ponto. Evite instalar versões Nulled, ou versões que você acha gratuitas de plugins pagos na internet. Isso aqui às vezes é difícil. E parece que eu estou advogando em causa própria, porque eu ganho a vida vendendo plugins. Mas qual é o esquema dessa galera que desenvolve, que disponibiliza esses plugins gratuitamente na internet, em sites de compartilhamento e tal? Eles vão lá, eles compram um plugin, adicionam alguma vulnerabilidade, alguma backdoor que vai dar acesso ao seu site, vai criar uma conta de admin para eles e disponibilizam. Aí você vai lá, acha que está se dando bem. Pô, achei esse plugin aqui, ele custa 200 dólares, achei de graça, vou instalar aqui. E na verdade, você está instalando uma backdoor no seu sistema e provavelmente está mandando por e-mail um login sem a de admin para o cara acessar o seu site depois. Então é bom evitar fazer isso, sempre possível. Em quinto, é se manter informado, cara. Então o Silver Tipresa representa uma parte significativa do que você faz para ganhar dinheiro, se ele é parte expressiva da sua vida profissional, você tem que fazer um esforço para se manter informado com o que está acontecendo no mundo do Wordpress. E isso vocês todos já estão fazendo só pelo fato de terem vindo ao WordCamp, né? Mas então é legal você ler alguns blogs especializados, media especializada, tem muito conteúdo em português, muito bom também. Mas quando o assunto é vulnerabilidade, eles costumam sair um pouco antes, tanto no blog do WordFence, do Sucuri e no WP Tavern também. São os lugares em que eu vejo que, tipo assim, logo que a vulnerabilidade sai, eles já publicam alguma coisa. Então é bom sempre dar uma olhadinha, pelo menos uma vez por semana, você checa se seus plugins estão atualizadinhos, dá uma lidinha ver se não aconteceu nada bizarro e o seu site vai continuar funcionando por anos e anos, se Deus quiser. Era isso que eu tinha para dividir com vocês, galera. Valeu. Valeu.