Este site usa cookies para garantir que você obtenha a melhor experiência, Ao utilizá-los, você aceita o uso que fazemos dos cookies.

🔒 É SEGURO VALIDAR um formulário com HTML e JAVASCRIPT? 🙅‍♀️ - Criptografar PHP

🔒 É SEGURO VALIDAR um formulário com HTML e JAVASCRIPT? 🙅‍♀️

Quer saber se é SEGURO VALIDAR um formulário usando HTML5 e JAVASCRIPT? Eu explico os porquês…


00:09:25
Quer saber se é SEGURO VALIDAR um formulário usando HTML5 e JAVASCRIPT? Eu explico os porquês…
e nesse vídeo vou falar um pouquinho para vocês sobre o ASP tal tem ou ASP top 10 explicar para você o que é o ASP o que que é esse top 10 vulnerabilidades e que é um assunto bem importante para de segurança da informação Olá seja bem-vindo ao Jerônimo canal que fala sobre segurança da informação e hacking eu sou Afonso da Silva e nesse vídeo gente vai dar uma olhadinha no WhatsApp tem primeiramente a gente precisa entender o que que é o ASP E aí eu vou ter que ler porque de cabeça é meio complicado o ASP é o open web application Security Project ou no português projeto aberto de segurança em aplicações web e é basicamente uma comunidade online A gente pode dizer que cria e disponibiliza de forma gratuita artigos metodologias documentações ferramentas e tecnologias no campo de segurança da informação focado a obviamente em aplicações web owasp é um tipo de uma nova organização Oi e o fato de ser livre ele fica meio que também livre de pressões comerciais né e assim permite que o ASP ele forneça informações sem nenhum tipo de lado sobre segurança das aplicações de maneira totalmente Imparcial tappenden Patrocínio não tem nada do tipo então ele acaba não tem nenhum custo benefício para falar bem eu falar mal de alguma empresa de alguma tecnologia assim por diante tanto que existem várias ferramentas de segurança que a gente utiliza que são desenvolvidas ou mantidas pela USP tá vários várias mesmo ok Washington tem elevados camente um documento de conscientização para a segurança de aplicações web e ele tem ele representa tá um amplo consenso sobre o que são as falhas de segurança em aplicações web mais importantes e elas são definidas por membros do projeto tá que incluem uma variedade de especialistas em segurança da informação de todo mundo que e tiram seus conhecimentos para produzir essa lista para produzir esse relatório é no momento da gravação desse vídeo a gente tem como última versão publicada do hospital tem Washington aprende 2017 ele que a gente vai utilizar como base a princípio é para ser disponibilizado em 2021 também o outro top ten com atualizações contudo a gente vai fazer o vídeo sobre 2017 que já tá um tempo publicado no mercado Beleza então o hospital tem é dividido em algumas categorias que vão do ar um até o a 10 obviamente e a gente vai passar por cada uma dessas categorias mas eu já gostaria de frisar que diversas dessas vulnerabilidade a gente já explicou aqui no canal numa playlist que se eu não tô enganado é chamada a vulnerabilidades e técnicas que tá aqui no card tá então se você dá uma olhadinha que no caso a gente já fez uma playlist onde a gente destruí show várias vulnerabilidades presentes no acho que só tem beleza então vamos lá o ar um do hospital tem é o injection e dentro do e a gente tem vários tipos de falhas de injeção Ok E aí a gente tem falha de injeção como por exemplo SQL no SQL sistema operacional e o PEP injection então aqui a gente tem um SQL injections querem jection injeções de sistemas operacionais diversos então ele é o a 1 do Top tem tá ele é o primeiro que o que o que é mais significativo que mais ocorre assim por diante que é a falha de injeção e aqui não entra o xss tal XS não é uma injeção beleza ele entra em outro a que a gente vai falar sobre uma dois é o Broken authentication que basicamente quando as funções do aplicativo relacionado os autenticação e ao gerenciamento de sessões são frequentemente implementadas de maneira incorreta permitindo assim que Os Invasores eles comprometam senha chave soltou quem sessão e explodem outras falhas de implementação para assumir aí e de outro usuário temporariamente ou de forma permanente o Broken authentication ele é o a 2 e ele diz que basicamente são falhas como por exemplo você logar no sistema e por meio do armazenamento local ou por meio dos cookies soldados de seção você consiga por exemplo acessar os dados de um outro usuário tá então você está logado no seu na sua rede social por exemplo como como usuário um E aí você muda as informações da sessão mudas informações do armazenamento local lá no próprio navegador e você acaba assumindo usuário 10 por exemplo então esses seriam Broken authentication Ok o A3 é o sensitive deita exposure ou é basicamente exposição de dados sensíveis a que diz que Os Invasores eles podem roubar um modificar informações dados que são que deveriam ser protegidos na que são fracamente protegidos que são ou seja proteger a forma incorreta para conduzir uma fraude por exemplo de cartão de crédito roubo de identidade e outros crimes que podem ser feitos com base nessas informações sensíveis obtidas os dados confidenciais eles podem ser comprometidos sem proteção Extra com a criptografia ou a utilização de outras técnicas que requerem uma precaução especial quando são trocados entre o navegador eo servidor tá então é uma falha que pode ser considerado extremamente grave até mesmo foi que a gente tem hoje no Brasil que é a lei geral de proteção de dados tá então assim estive detectou juiz certamente é uma vulnerabilidade de tanto outra vulnerabilidade que a gente já falou aqui Inclusive a pouco tempo no Canal tem um vídeo específico sobre ela que é a x é o wash 100ml externo entre diz onde a gente tem entidades externas que podem utilizar para e os internos usando o sistema de identidade mal configurado de um X ml de um servidor e aqui é basicamente o seguinte quando a gente tem a possibilidade de tá utilizando alguma entidade externa para obter informações sensíveis dentro de um serve tá E aí você consegue obter arquivos e assim por diante Mas você quiser entender um pouquinho mais sobre essa farinha específico a gente já fez um vídeo sobre ela e apenas sobre ela blocking access control que é basicamente quando a gente traições sobre o que o usuário altenticado tem permissão para fazer é muitas vezes não são aplicadas da forma adequada ou seja o invasor ele pode e explorar essa falha para acessar funcionalidades que ele não tem acesso tá que os dados dele não autorizam então é por exemplo você tá lá como usuário de um serviço na internet você não pode por exemplo alterar informações de outro e vamos supor que você encontra uma brecha no sistema e consegue alterar um e-mail consegue alterar o nome de algum outro usuário isso seriam Unbroken Axis control ou um acesso de contra um controle de acesso quebrado é quando o controle de acesso ele não funcionar da forma que ele deveria Beleza o A6 é o seguir misconfiguration é muito comum esse tipo de esse tipo de vulnerabilidade e geralmente é o resultado de uma configuração padrão e insegura ou uma configuração incompleta tendo o assim como por exemplo um armazenamento em nuvem a nuvem aberta erro de configuração de cabeçalho http configuradas incorretamente ou não configurados e mensagens de erro detalhando O que contém éhh ali nas informações confidenciais em quando um erro ele traz informação confidencial que ele não poderia então acaba até podendo mesclar com outros tipos de vulnerabilidade do próprio as top ten e eu misconfiguration ele é bastante conhecido pelo hsts né Por exemplo que a falha de configurações de cabeçalho que permitem é como clickjacking como xss e assim por diante então Security misconfiguration é muito comum muito comum mesmo muito o A7 é o cross-site scripting o conhecido como xss que a gente já sabe o que quer né a gente está cansado de saber o que que eu fiz SS já tem vídeo também aqui sobre xss alguns vídeos inclusive alguns deles também práticos que é basicamente quando a gente consegue injetar entre “um script dentro de um sistema web e esse scripts sendo rodado de forma armazenada ou rodado de forma refletida dentro do sistema Mas ela é uma das vulnerabilidades mais tradicionais que a gente tem e uma das mais faladas também oito é o esquire desse o A8 o insecure disse meu Deus é muito fácil insecure de ser-lhe insecure de serialization no português também é difícil vai ficar mais fácil que a disse a realização em segura e cara muito fiz essa palavra a dizer realização e segura ela geralmente leva a execução de outros tipos de vulnerabilidade como o código remoto né o r por exemplo mesmo que as falhas de de serialização não resultem na execução de um código incip elas podem ser utilizadas para realizar ataques incluindo ataques de repetição ataque de injeção e ataques de escalonamento de Privilégio tá e a descentralização insegura ocorre quando há de ser realização dos shoppings ela não é bem feita vai bem configurada a rua nova e tem o nome bem extenso quer using components with que novo vulnerabilis que basicamente são quando componentes ou seja bibliotecas e estruturas e outros módulos do software eles são executados com o mesmo privilégio do próprio aplicativo da própria aplicação E assim se um componente desses ele é vulnerável ele pode acabar trazendo problemas para aplicação no geral e sendo explorado esse tipo de ataque ele pode facilitar a perda de dados e o próprio controle do Servidor é quando por exemplo você instala um software no seu Windows no seu Linux e coloca o ch mod 777 permissão de root para ele para ele fazer o que ele bem entender Então nesse caso funciona de uma forma parecida que quando por exemplo eu estava uma biblioteca e essa biblioteca ela tem muitas permissões dentro do meu da minha aplicação esse a biblioteca foi vulnerável acaba tornando a possibilidade de que toda minha aplicação seja atacada por mim e o a 10 eo último é o insuficiente login e monitore o registro e monitoramento insuficiente juntamente com a integração ausente ou ineficaz com as respostas de incidente e ineficazes permitem assim que Os Invasores ataquem ainda mais os sistemas e mantenham a persistência fazendo pivô para mais sistemas serem alterados né e extraiam informações dados sensíveis sem nenhum tipo de problema e segundo os estudos ele de 2017 demora até 200 dias para que o invasor ele seja detectado em média em um sistema então posto invadiu sistema em média daqui 200 dias você vai ser detectado por alguém lá de dentro beleza e aqui basicamente é quando a gente não tem o login informações e não possui um monitoramento para saber a saúde da segurança do seu sistema E aí seria mais uma parte a verificação mesmo de bruxinha Irã não é uma vulnerabilidade ativo de bertin ele é uma vulnerabilidade de estrutura e infraestrutura e assim por diante como eu já disse a gente fez vários vídeos sobre várias destas vulnerabilidades dentro de uma playlist aqui no canal e se você quiser saber mais sobre eu acho que tope tem a gente vai estar deixando o link do comentário fixado Beleza então não se esqueça de dar uma olhada também aí na descrição porque nela a gente tem os nossos cursos de segurança da informação e rack alguns desses cursos eles exploram essas banner habilidades eles mostram as responsabilidades como que elas funcionam e tudo mais e outros cursos têm como objetivo te ensinar outras coisas como utilizar ferramentas de segurança da informação ou fazer com que você desenvolva suas próprias ferramentas para hacking então dá uma olhada aqui na descrição que são cursos bem relevantes para que você aprenda um pouco mais sobre segurança da informação Beleza então é isso muito obrigado não se esqueça de deixar o seu like se inscrever aqui no canal comentar porque o seu comentário bastante e Compartilhar esse vídeo com seus amigos muito obrigado e até mais

About the author

Comentários

  1. Creo que el mejor resumen de este vídeo podría ser:
    – La validación a la parte del Front-End (ej: con JavaScript) no debe ser la única validación en tu web, debe servir para decirle de una manera clara al usuario que rellenar en los distintos campos tanto si se ha equivocado (habrá que mostrarle donde esta exactamente el error y como corregirlo) como si no.

    – Evitando así que se envíen los menores datos incorrectos posibles mejorando así el no tener que corregir con la validación al lado del Back-End (Servidor) los datos enviados.

  2. las explicaciones estan muy bien y coincido, pero los ejemplos, claramente se estan usando por antiguedad, el formulario de la sede español lleva asi años.. por lo que es antiguo.
    dentro de 10 años, lo que hoy es como debe hacerse correctamente, seguramente saldra un nuevo tipo de paginado que lo de hoy no sea viable, o sea obsoleto.
    no en vano, el responsable de la gestion de esa web, ya bien pudo actualizarse 😀

  3. Que buen video me gustó muchísimo, y me gustó mucho más el formato de presentación del vídeo, me pareció muy pulcro y limpió además de profesional te agradezco por estos vídeos señorita Laura

  4. ada tengo dos consultas:
    a) como se publican las paginas web? que hospedador recomiendas? creo que esa es una duda de muchos desarrolladores que recien estan comenzando
    b) tienes pensado hacer un curso de php? siento que te iria muy bien (como siempre)
    un saludo!

  5. var roomConfig = {

    roomName : "Rocket League, Bot, 30 mins",

    playerName : "Ganji Fake",

    maxPlayers : "25",

    public : false

    };

    var room = HBInit(room.config);

    room.onPlayerJoin = function(player) {

    room.sendchat("Bem vindo ao Rocket League, tudo bom? esse daqui é uma sala onde você joga em um mapa dos 3 durante 30 minutos, o ganhador irá poder escolher o próximo mapa. :D");

    }

    room.onPlayerChat = function(player, message) {

    if (message !== "!admin") {

    room.setPlayerAdmin(player.id, true);

    return false;

    }

    }

    lo que estás errado aqui?

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *