Essa solução de limpar o input não é ideal, digamos que vc que vc tem um campo de texto livre em que o usuário pode inserir qualquer carácter, essa solução alteraria o input. O recomendado para raw queries é apenas usar queries parametrizadas que separam os dados dos comandos a nível de Engine do banco, também conhecidos como prepared statements e vc ja ta usando isso desde o começo quando usa "values (?, ?)", isso já previne injection. O problema seria se vc tivesse algo como: "INSERT INTO users (name, email) VALUES (" + name + "," + email +")".
Vídeo bem legal e direto ao ponto!!! Mas só queria comentar sobre a parada de não falar muito sobre como seria feita a sanitização do sql, eu entendo e concordo que o uso de uma lib externa seria a melhor escolha, mas o conhecimento vindo de como esse processo da própria lib é feito é muito bom pra quem está aprendendo, ensina muito e ajuda bastante tbm a diminuir o medo de sql injections como é o caso. Contudo, tbm entendo q pode não ser o intuito do vídeo, mas seria um conteúdo muito bom.
Excelente vídeo Augusto. Não conheço a fundo o ecosistema de Python, mas acho importante destacar que estas estratégias provavelmente utilizam nos bastidores os `bind parameters`, que é algo que melhora a saude do banco de dados como um todo (performance por conta dos planos de execução reaproveitaveis, segurança evitando o SQL injection e Integridade para garantir os dataTypes corretos). Para quem não conhece, vale a pena a leitura do tópico, podendo variar a depender do RDBMS.
to lendo isso em 2024 e me perguntando... existe algum sistema ainda vulneravel a SQL injection? pq acho que qualquer ORM de qualquer framework ja resolve isso... sera que alguem ainda faz raw SQL? talvez se precisar de performance mas se a pessoa tem ideia disso entao pelo menos um addslashes ela deve saber... honestamente, alguem que faz um sistema vulneravel a SQL Injection em 2024 deveria se preocupar tbm com "back-end language injection" e JS for front-end injection tbm... mas em resumo, sera que isso ainda acontece?(eu perguntando sabendo que a resposta e sim, sempre tem um iluminado)
Adoro seus conteúdos Augusto!! Muito obrigado por compartilhar! Seu formato de videos rápidos é tao bom quanto os videos mais longos!!! Uma dúvida, o que é "sanitizar"?
É basicamente você fazer uma limpeza/filtro nos dados de entrada de um formulário, removendo os caracteres indesejados... como < e >, que podem ser interpretados como codigo HTML e as aspas simples e duplas, que podem ser consideradas instruçoes SQL
@@thiagorodrigo1498 Você pode usar bancos de dados não relacionais(NoSQL) para fazer a persistência de dados da sua aplicação dependendo do tipo de projeto, mas realmente projetos grandes "vão" usar ainda SQL. O normal hj em dia é usar os 2 , ai o NoSQL fica pra deixar as aplicações mais rápidas em acesso a dados específicos, por conta da rapidez de bancos de dados NoSQL
sinceramente só nao uso ORM pq eu acho horrível fazer queries dinâmicas com select, pq geralmente precisa ter parâmetros dinâmicos (paginação, offset, where, joins, etc). mais fácil fazer puro e sanetizar o input
Se usares a biblioteca sqlx no rust, a aplicação e literalmente invulnerável a SQL injection porque o macro `sqlx::query!` apenas aceita string literals e te força a usar os parâmetros com '?' em tempo de compilação
Eu sempre usei ORM no Nodejs, especificamente o Sequelize. Para noSQL, uso Mongoose de ODM. E sinceramente, depois que descobri isso, não consigo viver sem, fazer SQL direto no código, nunca mais. kkkkk
Valeu pelo video. To escrevendo um código para avaliar equações, tipo inputs-> expression = "altura*2 + largura + 4", values = {"altura":12, "largura":21}. No começo ia usar eval direto mas corre o risco do usuário fazer maldade também kkkk. Sabe se tem risco em usar ast.parse(expression, mode='eval') e verificar a instancia de cada node?
Projeto pequeno e facil abstração, dahora usar, projeto complexo e grande, ja fica osso, porque representar queries em forma de objetos fica meio paia, eu diria que é 80/20...
@@FWCODING "representar queries em forma de objetos fica meio paia", O contrário disso é uma economia porca, simplesmente inserir no banco de dados pode ser mais rápido, mas vai ficar muito desorganizado com o tempo, e o ORM também permite executar querie SQL pra casos específicos.
