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.
ORM é essencial para projetos de grande porte, os problemas de performance, são causados por falta de conhecimento e mau uso, na maior parte das vezes, por mais que tabela e objeto sejam coisas diferentes, ambos tem estruturas compativeis, onde é possível realizar um de/para sem muitas dificuldades, o ponto é entender o que ela faz por de baixo dos panos, e modelar a estrutura de objetos de forma que as operações fiquem performaticas, fazer sem ORM custa bem mais a curto e longo prazo, se tratando de uma modelagem complexa. Fora isso, para coisas de pequeno porte, o ideal é o uso de prepared statement mesmo, sanitização acho gambi, até porque pode ser feira de forma incorreta, além disso você pode precisar aceitar caracteres diferentes. E mesmo que eu fosse sanitizar, nesse caso não seria onde eu capturo o Input, se essa sanitização tem objetivo de prevenir SQL Injection, deveria estar no "Service" ou "Component" que esta se comunicando com o banco, delegar isso pra camada que recebe o input faz ela ficar com responsabilidades que não são dela, além disso alguém pode criar um novo campo e esquecer de sanitizar com facilidade, pode montar um outro form que recebe o update por exemplo, do mesmo dado e também esquecer de sanitizar, é uma coisa que você teria que ficar repetindo consistentemente o que não é nada legal, e abre margem para esquecer e ter o SQL Injection. Mas concordo que é um problema de solução simples.
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
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)
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
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
@@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
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?
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
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.
![BabyChiefDoit - Too Slow (feat. STAR BANDZ) [Official Music Video]](http://i.ytimg.com/vi/zayaxws7RPg/mqdefault.jpg)
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 +")".
Tirei um print do seu comentário. 😂😂😂😂
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.
Trabalho com SQLAlchemy e gosto muito.
eu costumo usar ambos nos meus projetos, ORM e SQL. ORM quando eu quero coisas mais simples, e SQL quando eu preciso fazer um query mais complexa
Boa, aqui tb
0:24 Dei uma risada sincera
O caos que esse Oi tudo bem causou hahahahaah
Do nada né kkkkk
foi do 0 ao 100 mt rápido kkkkkk
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.
A ORM do Django é uma delicinha.
Tava pensando nisso quando ele reclamou do ORM hahahah
ORM é essencial para projetos de grande porte, os problemas de performance, são causados por falta de conhecimento e mau uso, na maior parte das vezes, por mais que tabela e objeto sejam coisas diferentes, ambos tem estruturas compativeis, onde é possível realizar um de/para sem muitas dificuldades, o ponto é entender o que ela faz por de baixo dos panos, e modelar a estrutura de objetos de forma que as operações fiquem performaticas, fazer sem ORM custa bem mais a curto e longo prazo, se tratando de uma modelagem complexa.
Fora isso, para coisas de pequeno porte, o ideal é o uso de prepared statement mesmo, sanitização acho gambi, até porque pode ser feira de forma incorreta, além disso você pode precisar aceitar caracteres diferentes.
E mesmo que eu fosse sanitizar, nesse caso não seria onde eu capturo o Input, se essa sanitização tem objetivo de prevenir SQL Injection, deveria estar no "Service" ou "Component" que esta se comunicando com o banco, delegar isso pra camada que recebe o input faz ela ficar com responsabilidades que não são dela, além disso alguém pode criar um novo campo e esquecer de sanitizar com facilidade, pode montar um outro form que recebe o update por exemplo, do mesmo dado e também esquecer de sanitizar, é uma coisa que você teria que ficar repetindo consistentemente o que não é nada legal, e abre margem para esquecer e ter o SQL Injection.
Mas concordo que é um problema de solução simples.
Fala mais sobre ORM =)
a ORM do Django é uma delicinha
Trabalhando com Rails, todos esses gaps de ORM ficam mais difíceis de acontecer.
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
Ótimo vídeo, poderia falar sobre Session Hijacking em um próximo?
Fala mais sobre ORMs!
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)
o pior de tudo é o zé DBA deixar o user com permissão DDL. Mas do jeito que as coisas estão, esse tipo de vídeo é necessário p ilustrar.
desculpa a palavra... existe pra caralho
os .gov infelizmente...
não só os gov, tem vários ambientes po..
Eu aprendendo d.s. pelo Senai sou muito capaz de fazer isso!
Fico feliz em descobrir que eu não sou o unico que detesta trabalhar com orms e prefere mil vezes escrever o sql na mão...
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
Sou dev iniciante, devs antigos concordam com não usar orm e apenas usar biblioteca para sanitizar?
Só usar Prepared Statement
O nome disso -> ' "
Cara, muito bom seus videos! Mas ajuda nois ai, da um up no volume do mic! kkkk Meu fone é ruim, mesmo tudo no max fica bem baixinho.
Seu canal me ajuda mto na facul irmão abbbcs
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
Otimo video, mano galeguinho !!!!
Monstro demais
Sabe o que um esqueleto caipira falou para o outro?
O ssô
como resolver sql injection: não usar sql
@@naf9392 que que o PHP tem a ver com SQL injection?
Como se cria um sistema que armazena dados sem SQL? Desculpa a pergunta, sou novo.
@@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
O NoSQL tbm tem esses problemas de injection?
@@thiagorodrigo1498 Existem vários bancos de dados NoSQL
Mano pode ensinar sobre rest api e como construir uma pra CRUD?
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?
Galeguinho, muito bom o vídeo. Qual app você tá usando pra gravar?
Fala meu amigo! Estou procurando a ferramenta que ele usa para deixar a câmera ao lado da gravação da tela. Sabe me dizer qual é?
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
não escrever SQL pode ser suficiente para um CRUD, pra fazer operações de ETL é outra história.
essa lib bleach foi descontinuada?
Qual software voce usa para essas apresentações?
Valeu! Otimo conteúdo
Excalidraw
@@marcoo-hg8he Valeuzão!
hj é dificil ter sql injection pq td mundo usa orm ou algum querybuioder
Quando você escrever sql, basta jogar água sanitária em cima. Entendi!
isso tinha mt no php kkkk
eu dps de ver esse vid: '-'
só da os chola defendendo ORM nesses comentários. deus me livre
SIM KKKKK
Ué, mas usar ORM ou não vai depender de cada projeto. Um bom arquiteto deve saber quando ou não usar
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 mas lembrando que ORM também permite executar queries mais complexas na mão
@@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.