SQL INJECT EM APLICATIVO
Realmente existe um aumento no processamento, sem dúvida.... mais instruções = mais processamento.
Entretando, acredito que você tem que pesar o que vale mais para a empresa... Hardware está cada dia mais barato mas os dados roubados podem valer muito...
Eu, certamente, sacrificaria esse processamente QUASE IMPERSEPTÃVEL a mais pela vantagem de ter segurança.
De qualquer forma, uma boa leitura sobre o assunto te ajudará a ter algumas soluções menos pesadas e mais frágeis e até soluções bem pesadas e quase à prova de [Ô]meliantes[Ô].
Citação:ALMARTI escreveu:
Olha, o que vc diz não faz nenhum sentido.
e depois posta uns nomes de uma linguagem de programação pra da força no que esta falando ou pra aparece.
Citação:ALMARTI escreveu:
Utilizamos esta técnica em Java, php e rails.
Citação:RCMRO escreveu:
Se me permitem [Ô]por o dedo[Ô]....
Realmente existe um aumento no processamento, sem dúvida.... mais instruções = mais processamento.
Entretando, acredito que você tem que pesar o que vale mais para a empresa... Hardware está cada dia mais barato mas os dados roubados podem valer muito...
Eu, certamente, sacrificaria esse processamente QUASE IMPERSEPTÃVEL a mais pela vantagem de ter segurança.
De qualquer forma, uma boa leitura sobre o assunto te ajudará a ter algumas soluções menos pesadas e mais frágeis e até soluções bem pesadas e quase à prova de [Ô]meliantes[Ô].
então cara ... de fato, o VB 6 por SI só é uma linguagem lenta por ser de alto nivel.
uma solução aparentemente o replace() funcionou, meu medo é um scape igual o hacker[ô]s/cracker/lamer usam no php como por exemplo: %27 pra escapa um [txt-color=#FF0000][ô][/txt-color]
De qualquer forma, o VB6 é uma das linguagens mais rápidas que existe, quando compilado direitinho.
Normalmente a lentidão do VB não é causada pelo VB e sim dos objetos instânciados pelo mesmo, baixa memória, etc...
Acredite, usar o ADO em VB6 ou em VC++ não causará diferença alguma ao acesso ao dado.
Com relação à segurança, pensa na seguinte situação:
. Compila uma dll em VB que cuide só de INJECT SQL e dentro dela faça todos os filtros com a string passada, retornando então a string já filtrada, sem os caracteres perigosos do INJECT SQL. Instala ela num servidor de COM+ se pretende alterá-la sempre ou se acha que instalar no CLIENT poderá gerar problemas de segurança (pessoalmente prefiro a abordagem com COM+).
Assim, vc não precisa criar sistemas muito complexos e, uma DLL pequena (e mais algumas outras que vc poderia instanciar), voce poderia reservar uma máquina nova dessas de no máximo R$ 1500 só para ser servidor de COM+. Novamente, tudo depende do volume de dados, do tamanho do cliente e principalmente, do valor do dado a ser protegido....
Citação:ALMARTI escreveu:
Senhor NOCOMMENTS, há algo pessoal contra minhas respostas? Todas as resposatas aqui dizem a mesma coisa. [txt-color=#FF0000]Se não sabe, uma função de replace pode consumir a mesma carga de memória de uma criptografia, conforme o modelo desta[/txt-color]. Afinal, todas são funções. Com relação a querer aparecer, fala sério. Não preciso disso. Tente reler seu próprio post e entenderá o que não faz sentido. Seja profissional e entenda que falamos de paradigmas, de técnicas, não de pessoas. Questiono o seu método, não a sua pessoa que nem conheço. Ou ponto, a dúvida é sua. Acha correto desdenhar as tentativas de respostas? Se sim, porque postou a dúvida?
kkkkkkkkkkkkkkkkkk campeão merece ganha ate pontinho