Jump to content

PHP security under scrutiny


Recommended Posts

Posted

A search of the database, maintained by the National Institute of Standards and Technology (NIST), found that Web applications written in PHP likely account for 43 percent of the security issues found so far in 2006, up from 29 percent in 2005. While flaws in the language itself account for a very small percentage the total, the problems with PHP underscore the difficulty that developers--many of them amateurs--have in locking down applications written in the language, said Peter Mell, senior computer scientist for the NIST and the program manager for the National Vulnerability Database.

"In the dynamic programming language (and) scripting realm, we certainly have a problem," Mell said. "Any time a third or more of the vulnerabilities in a given year are attributed to a single language, you know you have a problem."

Ler mais: http://www.securityfocus.com/news/11430

Isto intrigou-me porque não tinha noção que o PHP tinha tantas vulnerabilidades. Sabia que, como todas as linguagens populares, existiam muitos pontos em que a segurança não era máxima, mas daí a representar mais de um terço das vulnerabilidades encontradas no ano que está a acabar... 😛

Posted

Sempre soube que era um pouco buggy e perigoso, register_globals e afins, mas daí até ser 43% ...

EDIT: Agora que li isso como deve ser, isto tem disputas pelo meio que quase de certeza estão ter muita influência nisto ... Vou esperar 😛

Não peças ajuda por PM! A tua dúvida vai ter menos atenção do que se for postada na secção correcta do fórum!

Posted

Como foi mencionado, suponho que o problema não seja da linguagem em si, mas sim de quem programa e não toma as devidas precauções para protejer as aplicações (assim de repente tou a pensar SQL Injection...). Um BMW M5 é um carro bastante seguro, mas nas mãos de um maçarico pode causar muitos estragos (sempre gostei das anologias informática <==> carros)!

"Pensa positivo: tudo pode piorar"

Posted

Penso que é um sinal que mostra que o php é uma linguagem de muito facil aprendizagem e super simples de usar e versátil.

Isto tem uma razão de acontecer, o php consegue cativar milhões de programadores amadores auto-didatas que dão os primeiros passos no mundo da programação, é natural que não tenham todas as preocupações de segurança.

A título de exemplo, esse tipo de vulnerabilidades que falaram nas respostas acima está completamente controlada, no entanto ainda muito noviço volta e mais lá se descuida.

Posted

Não é o PHP que é vulnerável, as pessoas que não sabem programar devidamente é que o tornam vulnerável.

Já tenho visto coisas que só mesmo visto, sites com algum impacto e sem a segurança adequada.

REGISTER_GLOBALS em ON é um buraco enorme na segurança, mas não se fica por ai.

É aqui que entram as expressões regulares, que são a grande preciosidade da segurança no PHP, pelo menos para mim.

Um pouco complicado de inicio, mas muito útil.

E mais, hoje em dia as pessoas já vão buscar tudo feito (de facto a palavra webmaster já não tem o mesmo valor que tinha aqui à uns anitos) e pronto la vão sendo detectadas umas coisas, lá se vão lançando uns upgrades, algumas vezes à custa de um ou dois com menos sorte, porque se não fosse assim,  certamente haveria muitos mais ataques com sucesso.

Portanto deixo aqui alguns conselhos:

- REGISTAR_GLOBALS sempre em OFF

- DAR PREFERENCIA AO MÉTODO $_POST em vez do $_GET

- CUIDADO COM SERVIÇOS DE UPLOADS, se permitirem que os utilizadores façam upload de ficheiros para o vosso servidor, validem sempre muito bem o tipo de ficheiro e de preferencia guardem os uploads numa pasta inacessivel por http e renomeiem sempre os ficheiros carregados.

- Validar SEMPRE toda a informação entrada pelos utilizadores.

- Proteger sempre ficheiros de configuração com .htaccess

Estas são apenas alguns cuidados a ter. Mas há outros muito importantes.

Deixo tambem o link para este site que gostei muito e que possui outras dicas úteis: http://www.ilovejackdaniels.com/security/

Posted

Só para acrescentar umas coisinhas ao que o IceBurn disse:

Não façam include ou require a um $_GET ou $_REQUEST (ex: include( $_GET['abc'] ); )

Caso façam include a $_GET ou $_REQUEST utilizem a função eregi() para verificarem se uma URL esta a ser inserida no $_GET. (ex: if(eregi( 'http:\/\/' )) die( 'ERRO' ); )  isso faz com que nenhuma URL seja incluída pelo site protegendo assim o site contra PHP Injection.

Utilizem sempre addslashes( $_GET['abc'] ); caso o magic quotes esteja OFF isso protege o site contra SQL Injection

  • 4 weeks later...
Posted

- DAR PREFERENCIA AO MÉTODO $_POST em vez do $_GET

Esta não entendi... cada um tem a sua utilidade mas em termos de segurança são os 2 "maus". Ok, é mais dificil adulterar os dados do POST mas com o Firefox e uma  extension isso é também bastt fácil...

Concordo com a opinião já dada: só prova que o PHP é muito simples de usar por "novatos" o que pode provocar estes problemas. Acho isto um aspecto bastante positivo. É bem melhor ter uma linguagem mais fácil de aprender e indo aprendendo aos poucos os aspectos de segurança e afins. O próprio manual do PHP dá ênfase à segurança pelo que até os novatos podem ter esse conhecimento.

Mesmo a verificar o get/request eu não o usaria para fazer includes 😄 Penso que é mais seguro algo do genero

if ($_GET['a'] == 'ss'){include "filea.php";}

elseif(xxxxx)

else{xxxx}

Pode dar código mais feio mas desta forma é impossível alguém incluir files que não os que programaste.

Posted

- DAR PREFERENCIA AO MÉTODO $_POST em vez do $_GET

Esta não entendi... cada um tem a sua utilidade mas em termos de segurança são os 2 "maus". Ok, é mais dificil adulterar os dados do POST mas com o Firefox e uma  extension isso é também bastt fácil...

Precisamente... O que está em causa é que o método GET suscita mais a curiosidade das pessoas para fazerem 'experiências' e mesmo sem más intenções é mais um factor de perigo num código mal programado de início. Isto já para não falar de $_SERVER['HTTP_REFERER']... Imagina um código que passa passwords com o método GET....

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site you accept our Terms of Use and Privacy Policy. We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.