Proponha uma correção, faça uma sugestão
25 asneiras da programação!
Peritos de segurança revelam 25 asneiras da programação. Um fórum de peritos liderado pela Agência de Segurança Nacional dos EUA acaba de revelar os 25 maiores erros de programação no que toca à segurança.
Mais do que os contornos caricatos, o relatório pretende apostar na prevenção de erros. «Com este Top 25, podemos despender menos tempo a trabalhar com a polícia a investigar um assalto às nossas instalações e focarmos a atenção na prevenção destes casos», refere Paul Kurtz, um dos autores do relatório US National Strategy to Secure Cyberspace, em declarações reproduzidas pela PC Pro.
O fórum contou com a participação de Oracle, Microsoft e Symantec, entre outras entidades públicas e privadas.
Os mentores deste projecto pretendem mesmo que os consumidores exijam o respeito pelas 25 falhas agora identificadas aquando da compra de software e outros produtos tecnológicos.
No primeiro lugar do Top 25 encontram-se as falhas no controlo de injecção de códigos, que têm sido explorados frequentemente por vírus e afins nos últimos 18 meses. Controlos de acesso impróprios e algoritmos de criptografia mal desenvolvidos são as outras duas “burrices” mais frequentes na programação. Exame Informática
Este artigo tem mais de um ano
Loading ...
Como programador que sou estou curioso para saber quais sao os erros em questao..
Desculpem o comentario mas…. acho que esta noticia é uma não noticia…
Pois para ser uma noticia falta pelo menos listar as 25 falhas… pois caso contrario estive a ler a “noticia” e fiquei a saber o mesmo….
Até porque como Analista Progamador até tinha algum interesse em saber as ditas “Burrices” como voçes comentam.
No texto tem os links para a lista dos erros.
Acho que é o link a negrito que diz Top25, eis o link por extenso:
http://cwe.mitre.org/top25/
ok, não é a negrito 😛
Já agora solicitava aos programadores que possam analisar os erros apontados, que deixassem a vossa opinião aqui nos comentários.
Desde já o meu agradecimento.
Um URL directo no final da noticia era simpático e bem ao estilo dos posts aqui no Pplware, mas também não precisam de ser assim, eu li a noticia e cliquei logo no link que dizia “Top 25”.
Anyway, respondendo ao pedido do Vítor, eu sou um programador e estive a ler (meio na diagonal, admito) a tal lista e tenho que admitir que fiquei impressionado. Estava à espera de algo “simples” com aqueles erros mais básicos, mas fiquei contente em ler falhas que realmente merecem a importância que lhes foi dada nesta lista, especialmente no que toca a falhas de segurança e má utilização de recursos de sistema.
SQL injection é o mais frequente, as pessoas não gostam de perder tempo a analisar variaveis lolol
@Jose Luis
Foi uma opurtunidade falhada de não ter saído o comentário que foi…
O link está no texto.
interessante…
vou dar uma olhada como estudante de programação 🙂
até ja mandei o link da noticia ao meu professor principal 😛
Abraco
bom trabalho pplware 😉
Ora bem, lá explica a “teoria” dos erros, não os erros em si.
Concordo com a lista, mas pelo que li, não concordo com alguns items naquela lista, por exemplo:
“Improper shutdown or release of resources”.
Não considero de forma alguma uma falha de segurança mas sim de performance.
Podem argumentar “ah e tal, se não tem performance, não é seguro”, mas são coisas diferentes, pois pode comprometer o funcionamento mas não a segurança.
De resto, MySQL Injection, XSS, são falhas que infelizmente costumo encontrar em muitos sites mesmo (sites mundialmente usados inclusive).
Eu tenho sempre muito cuidado ao programar e testo sempre tudo ao máximo a nível de segurança.
A segurança total é impossível de obter, mas é verdade que há quem se poderia esforçar mais 🙂
Ola , um off topic , tenho o vista e o ubuntu em dual boot , no outro dia estava no vista e deixei o portatil cair , ao reiniciar , o mesmo da erro de kernel ko , alguem sabe se da pra recuperar o kernel de forma a nao perder o que ja la tenho ? algum programa ?
@ricardo
Questões/Dúvidas não relacionadas com os artigos devem ser colocadas no Fórum (obténs mais respostas e melhores, tal como mais rápidas, provavelmente).
No entanto, quanto ao teu problema, não tens no Grub uma opção tipo “Ubuntu 8.10, kernel 2.6.27-9-generic (recovery mode)” ?
Bela lista…
Tem alguns mesmo básicos…
🙂
http://truquestelemoveis.blogspot.com/
As falhas apontadas são quase na sua totalidade para desenvolvimento web…
Aqui vai uma maneira de “fugir” ao SQL injection… uma maneira de tornar as nossas aplicações mais seguras!
Simples e eficaz.
[CODE]
Public Function SecureForSQL(ByVal SQL As String) As String
On Error Resume Next
SQL = Replace(SQL, “;”, “”)
SQL = Replace(SQL, “‘”, “”)
SQL = Replace(SQL, “%”, “”)
SQL = Replace(SQL, “*”, “”)
SQL = Replace(SQL, “–“, “”)
SecureForSQL = SQL
End Function
[/CODE]
“Never trust user input… 😉
@Jose Luis
A tua última frase é verídica sim 🙂
Quanto à tua função, apesar de em teoria remover SQL Injections, também pode remover dados importantes.
Imagina que eu uso na minha password um “;”… a password não “entrava” 🙂
A nível de PHP, existe uma função que se deve aplicar sempre em queries SQL com variáveis: mysql_real_escape_string() juntamente com stripslashes() antes, para “funcionar” em várias configurações de servidor.
@Jose Luis
A melhor forma de prevenir o SQL Injection não é remover a causa mas sim evita-la. Ou seja:
Em vez de se fazer isto:
query = “SELECT * FROM tabela WHERE id='” + id + “‘”
Deve fazer-se algo como isto:
query = “SELECT * FROM tabela WHERE id=@id”
e passar o parametro @id quando se for a executar a query
@ Bruno Bernardino
A lista refere-se a erros de programação no geral, não apenas a erros de programação que levam a falhas de segurança.
Para mim, esse erro faz todo o sentido… se não libertares recursos, como memória, quando não precisas deles ( aka “memory leaks” ) vai acontecer que o teu sistema, em algum ponto, vai chegar ao seu limite. Nesse momento, o teu serviço não consegue continuar em funcionamento e ocorre o Denial of Service. Se alguém, eventualmente, reparar nessa falha e detectar uma forma de a provocar, pode jogar com isso para te fazer DoS …
Pedro.
@Pedro Silva
“(…)revelar os 25 maiores erros de programação no que toca à segurança.(…)”.
Como disse em cima, realmente pode-se atingir um ponto em que se pode considerar um erro de segurança, mas se atribuirmos essa denominação de forma tão abrangente, todo o tipo de erros são de segurança.
Não deixa de ser verdade o que dizes, mas continuo a não considerar um erro de segurança.
Cumprimentos
@ Bruno Bernardino
“The 2009 CWE/SANS Top 25 Most Dangerous Programming Errors is a list of the most significant programming errors that can lead to serious software vulnerabilities. They occur frequently, are often easy to find, and easy to exploit. They are dangerous because they will frequently allow attackers to completely take over the software, steal data, or prevent the software from working at all.”
O que me parece é que esta lista não é apenas sobre segurança, quando eles próprios mencionam “prevent the software from working at all”.
Quem escreveu esse artigo interpretou como apenas se tratasse de falhas de segurança. Não subscrevo essa interpretação, apenas isso. 🙂
cumps
Pedro
@Pedro Silva
Ok, não me dei ao trabalho de ler no artigo original, pelos vistos tens razão então 🙂
Ya o Hugo Pires tem razão, isto para evitar a concatenação de strings numa query sql. Bem jogado Hugo
@Bruno Bernardino
Se não libertares os recursos como deve ser, um atacante pode tirar partido de outra falha para aceder a dados que já deveriam ter sido libertados…
Ex.: Não fechas um ficheiro. A função termina, perdes o apontador para o ficheiro, mas o file descriptor continua válido.
Trabalho numa multinacional que desenvolve software e confirmo que a falha “Error Message Information Leak” é o pão nosso de cada dia.
“If you use chatty error messages, then they could disclose secrets to any attacker who dares to misuse your software. The secrets could cover a wide range of valuable data, including personally identifiable information (PII), authentication credentials, and server configuration”
“Debugging information should not make its way into a production release. ”
Mesmo depois de insistirmos com as equipas de desenvolvimento acerca de falhas deste genero que foram detectadas muitas vezes eles não querem corrigir pois dificulta a análise de erros na aplicação quando há bugs reportados por clientes.
Um cenário análogo aos que acontecem é algo género:
Uma pessoa faz um pagamento por cartão de credito no nosso servidor ou aplicação, e o numero do cartão fica no log do servidor.
O system test diz: o numero do c.c. não pode aparecer no log porque é uma falha de segurança!
O development diz, pois mas se ocultarmos o numero do log, então o log não nos serve para nada e não podemos fazer o tracking da transacção para seguir os problemas de pagamento e saber que numero pertence a quem etc etc.