Será que usando bancos de dados não-SQL evitar a necessidade de se proteger contra “injeção de SQL”?

Question

Isto pode parecer uma pergunta óbvia (ou não tão óbvio), mas deixe-me explicar. Eu estou codificação um site do Google App Engine usando a tecnologia de banco de dados do Google, BigTable. Quaisquer programadores do Google App Engine vai saber que o Google tem a sua própria linguagem de consulta limitada chamada GQL. Como resultado, estou tentado a não fazer qualquer verificação de SQL (ou GQL) injeção em meu aplicativo desde que eu assuma o Google não está usando uma consulta corda cru em seus métodos de back-end para buscar dados.

Além disso, as bibliotecas para tecnologias DB como CouchDB, MongoDB, e outro objeto ou documento (aka NoSQL) bases de dados parecem evitar a necessidade de verificar se um usuário mal-intencionado está injetando comandos de manipulação de banco de dados. Eles têm muitas vezes bibliotecas que mapeiam diretamente os objetos no banco de dados para objeto no idioma de sua escolha. Eu sei que há muitas bibliotecas SQL que fazem isso bem, mas eu suponho que em algum nível, eles estão combinando parâmetros para executar uma consulta sobre uma corda, e desta forma eu ainda deve usar a proteção de injeção SQL, mesmo com esses quadros.

Am I a ser míope? Ou é apenas uma questão de tempo até o próximo sistema DB grande toma conta e depois vou ver injecção esses sistemas?

Answer 1

“injeção” buracos têm a ver com incompatibilidades de contexto do texto. Cada vez que você coloca uma cadeia de texto em outro contexto de corda que você precisa fazer a codificação para se encaixar no contexto alterado. Parece sedutoramente simples cegamente cordas coisas juntos, mas a dificuldade de processamento de string é enganosa.

bancos de dados com uma interface puramente baseada em objeto são imunes a vulnerabilidades de injeção, assim como consultas parametrizadas estão em SQL. Não há nada que um atacante pode colocar em sua corda para sair do contexto literal string em que você colocá-lo.

Mas GQL, especificamente, não é uma delas. É uma linguagem de consulta corda, e se você for concatenação material de unescaped não confiável em uma consulta como "WHERE title='%s'" % title, você é tão vulnerável como você estava com full-on SQL. Talvez as capacidades limitadas de GQL torná-lo mais difícil de explorar isso para comprometer completamente o aplicativo, mas certamente não é impossível, em geral, e no melhor caso do seu aplicativo ainda está errado e vai cair quando as pessoas tentam apóstrofos legitimamente utilizar.

GQL tem uma interface de ligação de parâmetro. Use-o. Resistir à sedução de corda hacking.

Answer 2

SQL-subconjuntos como GQL, obviamente, ainda se preocupar com isso -., mas os bancos de dados não-SQL puros como CouchDB, Voldemort, etc deve colocar e obter dados sem se preocupar com ataques de injecção de estilo SQL

Isso no entanto não é desculpa para você de fazer validação de conteúdo, porque enquanto ele não pode quebrar o banco de dados, ele pode quebrar a sua aplicação e permitir que coisas como XSS (se ele é um aplicativo web).

Answer 3

dados a qualquer momento que é de ou manipulados por entrada do utilizador é utilizado para controlar a execução de código, é necessário que haja sanitização. Já vi casos em que o código usado a entrada do usuário para executar um comando sem sanitização de entrada. Ele não tinha sido explorado, mas se tivesse sido, teria sido um vetor de ataque horrível.

Answer 4

SQL Injection é apenas um subconjunto de um tipo de falha de segurança no qual qualquer entrada descontrolada fica avaliada.

javascript

techincally, você pode "injetar", entre outros.