Segurança é 99%

[d.eleete 0]

Se você tiver algum sistema de login, tente digitar isso nos campos: ' or 'a'='a . . . se não houver tratamento você terá acesso ao sistema.. mesmo não conhecendo a senha...

é eu já entrei no administrador de alguns sites devido esse erro!no meu caso eu defino um login e uma senha no proprio codigo, mas se eu quiser gravar o login e a senha de cada usuario no banco, como faço pra protege-lo, pra que não ocorra esse erro, e alguem acabe entrando onde não deve????

Se você procurar um outro reply meu neste topico, ele tem a explicação de como tratar este erro...

[Aeglos 0]

Nada como o bom e velho Server.HTMLEncode(dados do form). Não têm erro.

[WLJ 0]

Nada como o bom e velho Server.HTMLEncode(dados do form). Não têm erro.

resumidamente d q c trata essa parada...

[Salgado 4]

Transforma os caracteres especiais em códigos HTML.

[Pensa 0]

Uma dica.... em todos os campos que vão entrar em banco de dados ou fzer pesquisas em BDs substitua a aspa simples (') por duas aspa simples ('')... importante... não é uma aspa dupla e sim duas aspa simples...

 

Por algum motivo que desconheço o sistema em ASP substitui essas 2 aspa simples por apenas 1 não dando problemas de o usuário forçar a quebra da string de SQL para entrar no sistema... e assim o usuário pode continuar digitando ' para consultas... imagina se ele quer consultar por Rock'n Roll e a string dele é substituida por Rock++n Roll... não é legal....

 

Exemplo:

campo= replace(request.form("campo"),"'","''")

Se alguém souber algum motivo para não usar esse script... postem.....

 

Gostei do tópico... vamos falar mais sobre encriptação....

[diego_sl 0]

issoo aeeeeeeeeeee,pessoal c puxando...to preparando um tópico explicando melhor sobre como evitar ataques via "bug´s" de SQL :D B)

[d.eleete 0]

Uma dica.... em todos os campos que vão entrar em banco de dados ou fzer pesquisas em BDs substitua a aspa simples (') por duas aspa simples ('')... importante... não é uma aspa dupla e sim duas aspa simples...Por algum motivo que desconheço o sistema em ASP substitui essas 2 aspa simples por apenas 1 não dando problemas de o usuário forçar a quebra da string de SQL para entrar no sistema... e assim o usuário pode continuar digitando ' para consultas... imagina se ele quer consultar por Rock'n Roll e a string dele é substituida por Rock++n Roll... não é legal....Exemplo:

campo= replace(request.form("campo"),"'","''")

Se alguém souber algum motivo para não usar esse script... postem.....Gostei do tópico... vamos falar mais sobre encriptação....

Não entendi.. se ao inves de ++ fosse colocado @@ o retorno da string depois de tratada seria aspas simples do mesmo jeito..

[Cable 0]

Aqui eu sempre do um replace(Xalala,"'","''") nos meus campos de texto...acho q ja viro mania. Eu sempre faço isso. Mas pelo menos é uma mania boa....deve ser... B)

[d.eleete 0]

Aqui eu sempre do um replace(Xalala,"'","''") nos meus campos de texto...acho q ja viro mania. Eu sempre faço isso. Mas pelo menos é uma mania boa....deve ser... B)

Se um dia você esquecer essa mania.. ai sim você vai ver que gostoso... eheheh

[WebASP 0]

Oque ocorre patricia e que muito nao trata a aspas simplesOu sejaWhere Login = '" & Request.Form("Login") & "' AND Senha = '" & Request.Form("Senha") & "'ou seja se o cara colocar 'or''=' vai ficarWhere Login = ''or''='' AND Senha = ''or''=''Ou seja se O Login for igual a '' OR " for igual a ''And a senha a mesma coisa então ira dar como trueExistem alguams formas a Principal é Login = Replace(Request.Form("Login"),"'","")Senha = Replace(Request.Form("Senha"),"'","")Para tirar a aspa simplesE depoisSelect Senha From tabela where login = '" & Login & "';IF Not Rs.EOFou seja existe este usuarioai dentro deste if você poeIF Rs("Senha") = SenhaJa era ele ira verificar se a senha seleciona para aquele usuario e a mesma senha que foi digitadaSimples né ?

[Pensa 0]

Aqui eu sempre do um replace(Xalala,"'","''") nos meus campos de texto...acho q ja viro mania. Eu sempre faço isso. Mas pelo menos é uma mania boa....deve ser... ;)

Se um dia você esquecer essa mania.. ai sim você vai ver que gostoso... eheheh

É o seguinte cara... desse jeiito que falei colocando 2 aspa simples você não precisa tratar a varriável para aparecer na tela........

quer dizer... se você substituisse as aspa (') por (++) quando for voltar na tela você vai ter que substituir todos os ++ por aspa... e se o usuário tiver mesmo digitado ++ o texto dele vai ser modificado sem ele querer......

 

entendeu?

 

já substituindo por 2 aspa simples ('') você não precisa tratar a variavel.... ela simplesmente entra no BD como uma aspa simples comum, exatamente do jeito que o usuário escreveu...

 

é melhor e ainda não tem erro de o usuário digitar alguma coisa e aparecer outra....

 

por exemplo... antigamente eu substituia as aspa simples por [aspa]..... e tratava a string para quando aparecer na tela substituir todos os [aspa] por '

dava certo... mas e se o usuário realmente tivesse digitado [aspa] por algum motivo?! o texto dele iria ser modificado sem ele querer....

 

faça os testes.... comece a usar replace(variavel,"'","''")

 

[]s

[ricardovg 1]

Bom .. galera ... o assunto tá muito louco ....Porém vcs ficaram somente nos formulários, e sabemos que a segurança da aplicação não esta apenas nos Forms da vida.Existem ainda os cookies ( af.... )Parece um besteira .... mas a não definição do LCID pode gerar erros e uma chateação grande ... quem ja foi gravar um campo Lógico com TRUE ou FALSE e nã hora da erro pq aparece na string sql VERDADEIRO ( :D ) ou na data .... gravou no formato errado. Por isso o ideal mesmo é sempre utilizar flags numericos ( 1 para TRUE e 0 para FALSE ), data no formato americano.Outra coisa bacana é o tratamento de erros ... só o fato de você não mostrar o erro, o código o erro, a descrição e muitas vezes parte da string sql que aparece junto com esse pacote de invasão.Sem falar Request.QueryString que tabm precisam ser tratadas ( Aspas simples, Arroba, Caracteres Especiais , Vazio )Evitar nomenclaturas óbvias tbm auxilia ( strSQL, rsConn, Conn ... rs ;) ), tbm dificulta ....Uma programação bem estrutura conta muito;Tem a questão, de que, páginas podem ser clonadas e executadas de outro servidor fazendo um post de formulário com conteúdo malicioso ( Ex.: Banco Brasil, Itaú e outros bancos ).Por esse motivo, devemos aceitar requisições somente que possam ser identificadas pelo servidor.Definir uma política clara de segurança para os usuário ( sobre envio de senha, solicitação de informações sigilosas, Como usar o site, etc )Evitar usar strings SQL diretamente no código, o ideal seria utilizar procedimentos armazenados;Não fazer validação somente em javascript; Utilizar o Server.HTMLEncode("variavel"), Replace, UCase ou Lcase;Em campos que são somente números, tirar tudo caracter não numérico;Definir senha pro banco;Se possível, criptografar no banco dados sigilosos;Escolher um bom provedor de hospedagem;Temos q pensar que a segurança tbm esta na estabilidade da aplicação tbm, portanto : Fechar recordsets, conexões, destruir objetos, limpar variáveis, destruir sessions..... tudo isso conta.Marca d'água em fotos;Existem as medidas mais básicas, mas temos q pensar em muitas possibilidades.Como foi bem lembrado .... tomar cuidado com os FSO, Upload de arquivos para o serverTer um sistema de estatística ( Visitação, clicks, internauta ( ip, navegdor, sistema, remote addr ), cadastro), enquanto mais informações tivermos ... melhor ... Bom .. a segurança é muito mais complexa do que eu imaginava e praticava ,,,... na verdade ... a segurança começa no momento q você vai no cliente pra fechar contrato .... pq você tem que ter tudo isso em mente, mesmo pq isso pode valorizar seu serviço ..... Antes do desenvolvimento, a definição das regras do sistema tbm ajuda muito ..... e torna o trabalho mais agrádavel .. prático e produtivo ... pois você ja sabe o que tem q fazer ... e não fica perdendo tempo na hora do vamos ver da codificação.Bom ... espero ter ajudado. Valeu.Fuiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii B)

[Pensa 0]

Para fazer pesquisas de datas em BD usar sempre o formato: ano-mes-diadesse jeito mesmo com os tracinhos e tudo... #2003-10-19#não tem erro... mesmo que o servidor esteja configurado no padrão americano, japonês, finlandês, o que seja.... nesse formato não dá erro......-------Para armazenar senhas prefira sempre algum tipo de "encriptação destrutiva" ou "encriptação de uma só via".... assim as senhas são *impossíveis* de voltarem ao formato original....