Notícias

25 asneiras da programação!

24 Comentários

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

PUB
Autor: Vítor M.
Partilhar:
Tags:

PUB.

Questão Semanal

Deveria haver uma marca obrigatória em todas as imagens geradas por IA?

Ver Resultados

Loading ... Loading …
Arquivo de Questões

PUB.

Velocímetro Pplware

Teste a velocidade da sua Internet
Artigo anterior

Pidgin 2.5.4
Próximo artigo

jDownloader 0.4.132
PUB

Comentários

24

Deixe um comentário

O seu endereço de email não será publicado. Campos obrigatórios marcados com *

  1. Avatar de Nuno Lebreiro
    Nuno Lebreiro

    Como programador que sou estou curioso para saber quais sao os erros em questao..

    Responder
  2. Avatar de Jose Luis
    Jose Luis

    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.

    Responder
  3. Avatar de Vítor M.
    Vítor M.

    No texto tem os links para a lista dos erros.

    Responder
  4. Avatar de Cornolius
    Cornolius

    Acho que é o link a negrito que diz Top25, eis o link por extenso:

    http://cwe.mitre.org/top25/

    Responder
  5. Avatar de Cornolius
    Cornolius

    ok, não é a negrito 😛

    Responder
  6. Avatar de Vítor M.
    Vítor M.

    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.

    Responder
  7. Avatar de Hugo Sousa
    Hugo Sousa

    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.

    Responder
  8. Avatar de Antonio
    Antonio

    SQL injection é o mais frequente, as pessoas não gostam de perder tempo a analisar variaveis lolol

    Responder
  9. Avatar de Primax
    Primax

    @Jose Luis

    Foi uma opurtunidade falhada de não ter saído o comentário que foi…

    O link está no texto.

    Responder
  10. Avatar de TiagoKito
    TiagoKito

    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 😉

    Responder
  11. Avatar de Bruno Bernardino
    Bruno Bernardino

    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 🙂

    Responder
  12. Avatar de ricardo
    ricardo

    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 ?

    Responder
  13. Avatar de Bruno Bernardino
    Bruno Bernardino

    @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)” ?

    Responder
  14. Avatar de Blizard
    Blizard

    Bela lista…
    Tem alguns mesmo básicos…
    🙂

    http://truquestelemoveis.blogspot.com/

    Responder
  15. Avatar de Jose Luis
    Jose Luis

    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… 😉

    Responder
  16. Avatar de Bruno Bernardino
    Bruno Bernardino

    @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.

    Responder
  17. Avatar de Hugo Pires
    Hugo Pires

    @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

    Responder
  18. Avatar de Pedro Silva
    Pedro Silva

    @ 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.

    Responder
  19. Avatar de Bruno Bernardino
    Bruno Bernardino

    @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

    Responder
  20. Avatar de Pedro Silva
    Pedro Silva

    @ 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

    Responder
  21. Avatar de Bruno Bernardino
    Bruno Bernardino

    @Pedro Silva

    Ok, não me dei ao trabalho de ler no artigo original, pelos vistos tens razão então 🙂

    Responder
  22. Avatar de António
    António

    Ya o Hugo Pires tem razão, isto para evitar a concatenação de strings numa query sql. Bem jogado Hugo

    Responder
  23. Avatar de Edgar Sousa
    Edgar Sousa

    @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.

    Responder
  24. Avatar de Ar
    Ar

    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.

    Responder
Aviso:

Todo e qualquer texto publicado na internet através deste sistema não reflete, necessariamente, a opinião deste site ou do(s) seu(s) autor(es). Os comentários publicados através deste sistema são de exclusiva e integral responsabilidade e autoria dos leitores que dele fizerem uso. A administração deste site reserva-se, desde já, no direito de excluir comentários e textos que julgar ofensivos, difamatórios, caluniosos, preconceituosos ou de alguma forma prejudiciais a terceiros. Textos de caráter promocional ou inseridos no sistema sem a devida identificação do seu autor (nome completo e endereço válido de email) também poderão ser excluídos.