I agree with alex, the shortages of php Abdle listed exists on many other programming languages if you don't have a good architecture
Considerações Gerais
Um sistema completamente seguro é virtualmente impossível de se conseguir, então uma abordagem freqüentemente usada em segurança é um compromisso entre risco e usabilidade. Se cada variável enviada pelo usuário precias de duas formas de validação biométrica (como escaneamento de retina e impressão digital), você teria um nível de checagem extremamente alto. Demoraria meia hora para preencher um formulário mais ou menos complexo, o que incentivaria os usuários a achar maneiras de burlar a segurana.
A melhor segurança é frequentemente aquele preenche os requerimentos sem obstruir o usuário de fazer o seu trabalho, ou sobrecarregando o programador com complexidade excessiva. De fato, alguns ataques de segurança exploram esse tipo de segurança super-produzida, que tende a degradar com o tempo.
Uma frase que vale a pena lembrar: Um sistema é tão bom quanto o elo mais fraco na corrente. Se todas as transações são maciçamente registradas baseado no tempo, localização, tipo de transação, etc. mas o usuário só é verificado baseado em um único cookie, a validade de ligar os usuários ao registro de transação torna-se muito fraca.
Quando estiver testando, tenha em mente que você não será capaz de testar todas as possibilidades nem mesmo para as páginas mais simples. A entrada que você pode esperar será totalmente diferente da entrada dada por um empregado irritado, um cracker com meses livres para tentar quebrar o sistema, ou um gato andando pelo teclado. Por isso é melhor olhar ao código da perspectiva lógica, para discernir onde dados inesperados podem ser introduzidos, e depois seguir aonde o mesmo é modificado, reduzido ou amplificado.
A Internet está cheia de gente tentando fazer o próprio nome quebrando o código dos outros, derrubando sites, enviando conteúdo indevido e de outras formas fazendo seu dia interessante. Não importa se você tem um site grande ou pequeno, você é um alvo simplesmente por estar online, tendo um servidor que pode ser conectado. Muitos programas de cracking não discernem por tamanho, eles simplesmente vasculham blocos gigantes de IPs procurando por vítimas. Tente não se tornar um.
Considerações Gerais
23-Nov-2009 11:13
08-Apr-2008 03:53
well, if you're a skilled php programmer, you can avoid many of these dangers..
for example xss... as its the most common attack, filter all the input you gain from the user (not only with htmlspecialchars but also with more personalized string-checks for specific words and chars like document.location and so on).
or file injection (filter out ../ and so on).
i admit that php has its weakpoints (sessions...), but nothing is 100% secure (but you can use ssl for high security projects..)
30-Jul-2007 05:59
No doubt PHP is a strong language and it gain power during its evaluation.But there are too much security risks in PHP.Most common are :
1-Invalidated Input Errors
2-Access Control Flaws
3-Session ID Protection
4-Cross Site Scripting (XSS) Attacks
5-SQL Injection Vulnerabilities
6-Error Reporting
7-Data Handling Errors
8-PHP configuration settings
As PHP is open-sourse server-side scripting language, it is most often uses in web applications and database-driven web site which obviously have critical data.So malicious users always try to find holes in its security, in other word this open-source is in focus of attackers.Thus it becomes the responsiblity of developer to minimize the securiy risks in product.
11-Dec-2006 05:34
Emacs doesn't require an X server to run, you can use the command line option '-nw' to start emacs in that console. Also portmap isn't required by an X server nor emacs (except maybe for special optional packages).
25-Apr-2006 10:14
Important Security Note for emacs users
Many linux/unix developers like the emacs editor to write code. It's a great editor with many features for PHP/Perl developers. emacs by default creates a back up file ending with ~. Then when you create a file myprogram.php it creates a back up file myprogram.php~ . You can change this default behavoir to avoid emacs creates this file but many people prefer to keep this default. The problem is that through the webserver people can load this file ending with ~ and can see your php code because the webserver doesn't parser this file as php type due to the ~. This behavoir is a strong security hole, it permits to everybody to see and hack your code. i recommend to emacs users to deny access to files ending with ~ in general to avoid this problem.
In general PHP developers must check that the editor they are using is not creating a file beside the php source file without the end file name .php necessary for the webserver to parser it as php application.
in apache webserver you can deny access to these files with the following configure order
<File "*~">
Deny all
</File>
25-Dec-2005 08:53
A good tactic to employ is the "least privileged needed" aproatch. If a aplication is only reading from a particular table in a particular database, it should have a account that can do exactly that and no more.
