Sete Hábitos para Escrever Aplicativos PHP Seguros

Aumente a Segurança de seus Aplicativos da Web

A segurança em um aplicativo PHP inclui preocupações de segurança remotas e locais. Descubra os hábitos que os desenvolvedores de PHP devem obter para implementar aplicativos da Web que têm ambas as características.

Nathan A. Good, Senior Information Engineer, Freelance Developer

Nathan A. Good mora na área Twin Cities em Minnesota. Profissionalmente, ele realiza desenvolvimento de software, arquitetura de software e administração de sistemas. Quando ele não está desenvolvendo software, ele gosta de montar PCs e servidores, ler sobre e trabalhar com novas tecnologias e tentar convencer seus amigos de começarem a usar software livre. Ele escreveu e coescreveu muitos livros e artigos, incluindo Professional Red Hat Enterprise Linux 3, Regular Expression Recipes: A Problem-Solution Approach, Regular Expression Recipes for Windows Developers: A Problem-Solution Approach, PHP 5 Recipes: A Problem-Solution Approach e Foundations of PEAR: Rapid PHP Development.



30/Set/2008

Em relação à segurança, lembre-se de que além de problemas de segurança reais da plataforma e do sistema operacional, é necessário assegurar que você escreva seu aplicativo para que seja seguro. Ao escrever aplicativos PHP, aplique estes sete hábitos para assegurar que seus aplicativos sejam o mais seguro possível:

  • Valide a entrada
  • Proteja seu sistema de arquivos
  • Proteja seu banco de dados
  • Proteja seus dados de sessão
  • Proteja contra vulnerabilidade de Cross-Site Scripting (XSS)
  • Verifique postagens de formulários
  • Proteja contra Cross-Site Request Forgeries (CSRF)

Validar a Entrada

A validação dos dados é o hábito mais importante que você pode possivelmente adotar com relação à segurança. E, com relação à entrada, é simples: não confie nos usuários. Seus usuários são provavelmente boas pessoas e a maioria, provavelmente, usa seu aplicativo exatamente conforme sua intenção. No entanto, sempre que houver chance de entrada, há também chance para uma entrada realmente inválida. Como um desenvolvedor de aplicativos, você deve proteger seu aplicativo contra entrada inválida. Considerar cuidadosamente aonde irá a entrada de seu usuário e o que deverá ser permitido para que você construa um aplicativo robusto e seguro.

Apesar de o sistema de arquivos e a interação com o banco de dados serem cobertos posteriormente, há dicas de validação gerais que cobrem todo tipo de validação:

  • Use valores incluídos na lista de desbloqueio
  • Sempre revalide seleções limitadas
  • Use funções de escape integradas
  • Valide para tipos de dados corretos, como números

Os valores incluídos na lista de desbloqueio são valores válidos, em oposição aos valores incluídos na lista de bloqueio que são inválidos. A distinção é que, frequentemente, ao realizar a validação, a lista ou intervalo de possíveis valores é menor do que a lista de valores inválidos, muitos dos quais podem ser desconhecidos ou inesperados.

Quando estiver realizando validação, lembre-se de que é frequentemente mais fácil determinar e validar o que o aplicativo permite em vez de tentar proteger contra todos os valores desconhecidos. Por exemplo, para limitar valores em um campo para todos os números, escreva uma rotina que assegure que a entrada seja somente números. Não escreva a rotina para procurar valores não-numéricos e marcá-los como inválidos se forem encontrados.

Proteger seu Sistema de Arquivos

Em julho de 2000, um Web site deixou vazar dados de clientes que se encontravam em arquivos em um servidor da Web. Um visitante do Web site manipulou a URL para visualizar arquivos que continham os dados. Apesar de os arquivos terem sido colocados em local indevido, este exemplo destaca a importância de proteger seu sistema de arquivos contra atacadores.

Se seu aplicativo PHP fizer alguma coisa com arquivos e tiver dados de variável que um usuário pode inserir, tome cuidado em limpar a entrada do usuário para assegurar que os usuários não possam fazer nada com o sistema de arquivos que você não queira que eles façam. A Lista 1 mostra um exemplo de um site PHP que faz download de uma imagem fornecendo-se um nome.

Lista 1. Fazendo Download de um Arquivo
<?php if ($_POST['submit'] == 'Download') {
    $file = $_POST['fileName'];
    header("Content-Type: application/x-octet-stream");
    header("Content-Transfer-Encoding: binary");
    header("Content-Disposition: attachment; filename=\"" . $file . "\";" );
    $fh = fopen($file, 'r');
    while (! feof($fh))
    {
        echo(fread($fh, 1024));
    }
    fclose($fh); } else {
    echo("<html><head><");
        echo("title>Guard your filesystem</title></head>");
    echo("<body><form id=\"myFrom\" action=\"" . $_SERVER['PHP_SELF'] .
        "\" method=\"post\">");
    echo("<div><input type=\"text\" name=\"fileName\" value=\"");
    echo(isset($_REQUEST['fileName']) ? $_REQUEST['fileName'] : '');
    echo("\" />");
    echo("<input type=\"submit\" value=\"Download\" name=\"submit\" /></div>");
    echo("</form></body></html>"); }

Como pode ver, o script relativamente perigoso na Lista 1 fornece qualquer arquivo ao qual o servidor da Web tenha acesso de leitura, incluindo arquivos no diretório da sessão (consulte " Proteger seus Dados de Sessão") e até mesmo alguns arquivos do sistema, como /etc/passwd. Este exemplo tem uma caixa de texto na qual o usuário pode digitar o nome do arquivo para propósitos de exemplo, mas o nome do arquivo poderia ser fornecido tão simplesmente na string de consulta.

Configurar o acesso ao sistema de arquivos juntamente com entrada do usuário é perigoso, portanto, é melhor evitar isso como um todo, projetando seu aplicativo para usar um banco de dados e nomes de arquivos gerados ocultos. No entanto, isso nem sempre é possível. A Lista 2 fornece um exemplo válido de uma rotina que valida nomes de arquivos. Usa expressões regulares para assegurar que somente caracteres válidos sejam usados no nome do arquivo e verifica especificamente a ocorrência de caracteres ponto ponto: ...

Lista 2. Verificando Caracteres Válidos de Nomes de Arquivos
function isValidFileName($file) {
    /* não permita .. e permita qualquer caractere de "palavra" \ / */
    return preg_match('/^(((?:\.)(?!\.))|\w)+$/', $file); }

Proteger seu Banco de Dados

Em abril de 2008, o Departamento de Correções de um estado dos EUA deixou vazar dados sigilosos como resultado dos nomes das colunas de SQL serem usados na string de consulta. Esse vazamento permitiu que usuários maliciosos selecionassem quais colunas queriam exibir, enviassem a página e obtivessem os dados. Esse vazamento mostra como usuários podem descobrir maneiras para fazer com que sua entrada faça coisas que os desenvolvedores de aplicativos definitivamente não previram e destaca a necessidade de uma defesa cuidadosa contra ataques de injeção de SQL.

A Lista 3 mostra um exemplo de um script que executa uma instrução SQL. Neste exemplo, a instrução SQL é uma instrução dinâmica que permitiria o mesmo ataque. Os proprietários desse formulário podem ficar tentados a pensar que estão seguros, pois limitaram os nomes das colunas a listas de seleção. No entanto, o código negligencia atenção ao último hábito referente a spoofing de formulário — simplesmente porque o código limita a seleção a caixas suspensas não significa que alguém não possa postar um formulário com o que quiserem no mesmo (inclusive um asterisco [*]).

Lista 3. Executando uma Instrução SQL
<html> <head> <title>SQL Injection Example</title> </head> <body>
<form id="myFrom" action="<?php echo $_SERVER['PHP_SELF']; ?>"
    method="post"> <div><input type="text" name="account_number"
    value="<?php echo(isset($_POST['account_number']) ? 
        $_POST['account_number'] : ''); ?>" /> <select name="col"> <option
value="account_number">Account Number</option> <option value="name">Name</option>
<option value="address">Address</option> </select> <input type="submit" value="Save"
name="submit" /></div> </form> <?php if ($_POST['submit'] == 'Save') {
    /* realize o processamento do formulário */
    $link = mysql_connect('hostname', 'user', 'password') or
        die ('Could not connect' . mysql_error());
    mysql_select_db('test', $link); 		 		$col = $_POST['col'];
    $select = "SELECT " . $col . " FROM account_data WHERE account_number = "
        . $_POST['account_number'] . ";" ;
    echo '<p>' . $select . '</p>';
    $result = mysql_query($select) or die('<p>' . mysql_error() . '</p>');
    echo '<table>';
    while ($row = mysql_fetch_assoc($result)) {
        echo '<tr>';
        echo '<td>' . $row[$col] . '</td>';
        echo '</tr>';
    }
    echo '</table>';
    mysql_close($link); } ?> </body> </html>

Portanto, para criar o hábito de proteger seu banco de dados, evite código SQL dinâmico o máximo possível. Se não for possível evitar código SQL dinâmico, não use entrada diretamente para colunas. A Lista 4 mostra um exemplo do poder de incluir uma rotina de validação simples no campo do número da conta para assegurar que não possa ser diferente de um número além de usar colunas estáticas.

Lista 4. Protegendo com Validação e
<html>
<head>
<title>SQL Injection Example</title>
</head>
<body>
<form id="myFrom" action="<?php echo $_SERVER['PHP_SELF']; ?>"
    method="post">
<div><input type="text" name="account_number"
    value="<?php echo(isset($_POST['account_number']) ? 
        $_POST['account_number'] : ''); ?>" /> <input type="submit"
    value="Save" name="submit" /></div>
</form>
<?php
function isValidAccountNumber($number) 
{
    return is_numeric($number);
}

if ($_POST['submit'] == 'Save') {

    /* Remember habit #1--validate your data! */
    if (isset($_POST['account_number']) &&
    isValidAccountNumber($_POST['account_number'])) {

        /* do the form processing */
        $link = mysql_connect('hostname', 'user', 'password') or
        die ('Could not connect' . mysql_error());
        mysql_select_db('test', $link);

        $select = sprintf("SELECT account_number, name, address " .
		" FROM account_data WHERE account_number = %s;",
        mysql_real_escape_string($_POST['account_number']));
        echo '<p>' . $select . '</p>';

$result = mysql_query($select) or die('<p>' . mysql_error() . '</p>');

        echo '<table>';
        while ($row = mysql_fetch_assoc($result)) {
            echo '<tr>';
            echo '<td>' . $row['account_number'] . '</td>';
            echo '<td>' . $row['name'] . '</td>';
            echo '<td>' . $row['address'] . '</td>';
            echo '</tr>';
        }
        echo '</table>';

        mysql_close($link);
    } else {
        echo "<span style=\"font-color:red\">" .
    "Please supply a valid account number!</span>";

    }
}
?>
</body>
</html>

Este exemplo também mostra o uso da função mysql_real_escape_string() . Essa função limpa corretamente sua entrada de forma que não inclua caracteres inválidos. Se você vem dependendo de magic_quotes_gpc, fique avisado de antemão que está reprovada e será removida no PHP V6. Evite depender dela agora e escreva seus aplicativos PHP para que sejam seguros sem ela. Além disso, lembre-se de que se você estiver usando um ISP, há uma chance de que não tenha magic_quotes_gpc ativado.

Por fim, no exemplo aprimorado, você pode ver que a instrução SQL e a saída não incluem uma seleção de coluna dinâmica. Dessa forma, se você incluir colunas na tabela posteriormente que tenham informações diferentes, poderá imprimi-las. Se estiver usando uma estrutura para trabalhar com seu banco de dados, há uma chance de que sua estrutura já realize a validação de SQL. Certifique-se de verificar na documentação de sua estrutura para ter certeza; se ainda estiver inseguro, realize a validação para errar por segurança. Mesmo se estiver usando uma estrutura para interação com o banco de dados, ainda precisará executar a outra verificação.


Proteger sua Sessão

Por padrão, as informações da sessão em PHP são gravadas em um diretório temporário. Considere o formulário da Lista 5, que mostra como armazenar o ID e número da conta de um usuário em uma sessão.

Lista 5. Armazenando Dados na Sessão
<?php
session_start();
?>
<html>
<head>
<title>Storing session information</title>
</head>
<body>
<?php
if ($_POST['submit'] == 'Save') {
    $_SESSION['userName'] = $_POST['userName'];
    $_SESSION['accountNumber'] = $_POST['accountNumber'];
}
?>
<form id="myFrom" action="<?php echo $_SERVER['PHP_SELF']; ?>"
    method="post">
<div><input type="hidden" name="token" value="<?php echo $token; ?>" />
<input type="text" name="userName"
    value="<?php echo(isset($_POST['userName']) ? $_POST['userName'] : ''); ?>" />
<br />
<input type="text" name="accountNumber"
    value="<?php echo(isset($_POST['accountNumber']) ? 
    $_POST['accountNumber'] : ''); ?>" />
<br />
<input type="submit" value="Save" name="submit" /></div>
</form>
</body>
</html>

A Lista 6 mostra o conteúdo do diretório /tmp.

Lista 6. Os Arquivos da Sessão no Diretório /tmp
-rw-------  1 _www    wheel       97 Aug 18 20:00 sess_9e4233f2cd7cae35866cd8b61d9fa42b

Como pode ver, o arquivo da sessão, quando impresso (consulte a Lista 7), contém as informações em um formato bem legível. Como o arquivo precisa ser legível e gravável pelo usuário do servidor da Web, os arquivos da sessão podem criar um grande problema para qualquer pessoa em um servidor compartilhado. Alguém diferente de você pode escrever um script que leia esses arquivos para que possa tentar obter valores da sessão.

Lista 7. O Conteúdo de um Arquivo de Sessão
userName|s:5:"ngood";accountNumber|s:9:"123456789";

Armazenando Senhas

Senhas nunca, nunca mesmo, devem ser armazenadas em texto simples em lugar algum — em um banco de dados, sessão, sistema de arquivos ou de qualquer outra forma. A melhor maneira de manipular senhas é armazenando-as criptografadas e comparar as senhas criptografadas umas às outras. Apesar de isso parecer óbvio, armazená-las em texto simples parece ser feito bastante na prática. Toda vez que você usa um Web site que pode enviar a você sua senha em vez de reconfigurá-la significa que a senha está armazenada em texto simples ou que há código disponível para decriptografar a senha se estiver criptografada. Mesmo se for o segundo caso, o código para decriptografia pode ser localizado e explorado.

Você pode fazer duas coisas para proteger os dados de sua sessão. A primeira é criptografar qualquer coisa que você coloque na sessão. Mas simplesmente porque você criptografou os dados não significa que estão completamente seguros, portanto, tome cuidado ao depender disso como seu único meio de proteger sua sessão. A alternativa é armazenar seus dados da sessão em um local diferente, como um banco de dados. Você ainda precisa assegurar que está bloqueando seu banco de dados, mas essa abordagem soluciona dois problemas: primeiro, coloca seus dados em um local mais seguro do que em um sistema de arquivos compartilhado; segundo, permite que seu aplicativo escale por diversos servidores da Web mais facilmente com sessões compartilhadas por diversos hosts.

Para implementar sua própria persistência de sessão, consulte a função session_set_save_handler() em PHP. Com ela, é possível armazenar informações de sessão em um banco de dados ou implementar um manipulador para criptografar e decriptografar todos os seus dados. A Lista 8 fornece um exemplo do uso da função e funções estruturais para a implementação. Você também pode verificar exemplos de como usar um banco de dados na seção Recursos .

Lista 8. Exemplo da Função session_set_save_handler()
function open($save_path, $session_name) {
    /* código customizado */
    return (true); }
function close() {
    /* código customizado */
    return (true); }
function read($id) {
    /* código customizado */
    return (true); }
function write($id, $sess_data) {
    /* código customizado */
    return (true); }
function destroy($id) {
    /* código customizado */
    return (true); }
function gc($maxlifetime) {
    /* código customizado */
    return (true); }
session_set_save_handler("open", "close", "read", "write", "destroy", "gc");

Proteger Contra Vulnerabilidades de XSS

As vulnerabilidades de XSS representam uma grande parte de todas as vulnerabilidades documentadas de Web site em 2007 (consulte Recursos). Uma vulnerabilidade de XSS ocorre quando um usuário tem a capacidade de injetar código HTML em suas páginas da Web. O código HTML pode transportar código JavaScript nas tags de script, permitindo, assim, que JavaScript seja executado sempre que uma página for desenhada. O formulário na Lista 9 poderia representar um fórum, wiki, rede de relacionamento ou qualquer outro site onde é comum inserir texto.

Lista 9. Formulário para Inserir Texto
<html>
<head>
<title>Your chance to input XSS</title>
</head>
<body>
<form id="myFrom" action="showResults.php" method="post">
<div><textarea name="myText" rows="4" cols="30"></textarea><br />
<input type="submit" value="Delete" name="submit" /></div>
</form>
</body>
</html>

A Lista 10 demonstra como o formulário poderia imprimir os resultados, permitindo um ataque de XSS.

Lista 10. showResults.php
<html>
<head>
<title>Results demonstrating XSS</title>
</head>
<body>
<?php
echo("<p>You typed this:</p>");
echo("<p>");
echo($_POST['myText']);
echo("</p>");
?>
</body>
</html>

A Lista 11 fornece um exemplo básico no qual uma nova janela é aberta para a página inicial do Google. Se seu aplicativo da Web não proteger contra ataques de XSS, o único limite ao dano feito é a imaginação do atacador. Por exemplo, alguém poderia incluir um link que imite o estilo do site para propósitos de phishing (consulte Recursos).

Lista 11. Amostra de Texto de Entrada Malicioso
<script type="text/javascript">myRef = window.open('http://www.google.com','mywin',
'left=20,top=20,width=500,height=500,toolbar=1,resizable=0');</script>

Para proteger-se contra ataques de XSS, filtre sua entrada através da função htmlentities() sempre que o valor de uma variável for impresso na saída. Lembre-se de seguir o primeiro hábito de validação de dados de entrada com valores incluídos na lista de desbloqueio na entrada de seu aplicativo da Web para nomes, endereços de e-mail, número de telefone e informações de faturamento.

Uma versão muito mais segura da página que mostra a entrada de texto é mostrada abaixo.

Lista 12. Um Formulário Mais Seguro
<html> <head> <title>Results demonstrating XSS</title> </head> <body>
<?php echo("<p>You typed this:</p>"); echo("<p>"); echo(htmlentities($_POST['myText']));
echo("</p>"); ?> </body> </html>

Proteger Contra Postagens Inválidas

Spoofing de formulário ocorre quando alguém faz uma postagem em um de seus formulários de algum local inesperado. A maneira mais fácil de realizar spoof de um formulário é simplesmente criando uma página da Web que envie um formulário, passando todos os valores. Como os aplicativos da Web não têm estado, não há como ter certeza absoluta de que os dados postados estejam vindo de onde você deseja que estejam vindo. Tudo, de endereços IP a nomes de hosts, na final, podem passar por spoof. A Lista 13 mostra um formulário típico que permite inserir informações.

Lista 13. Um Formulário para Processar Texto
<html> <head> <title>Form spoofing example</title> </head> <body>
<?php if ($_POST['submit'] == 'Save') {
    echo("<p>I am processing your text: ");
    echo($_POST['myText']);
    echo("</p>"); } ?> </body> </html>

A Lista 14 mostra um formulário que será postado no formulário da Lista 13. Para tentar isso, você pode colocar o formulário em um Web site, em seguida, salvar o código na Lista 14 como um documento HTML em seu desktop. Quando tiver salvado o formulário, abra-o em um navegador. Em seguida, você pode preencher os dados e enviar o formulário, observando enquanto os dados são processados.

Lista 14. Um Formulário para Coletar seus Dados
<html> <head> <title>Collecting your data</title> </head> <body> <form
action="processStuff.php" method="post"> <select name="answer"> <option
value="Yes">Yes</option> <option value="No">No</option> </select> <input
type="submit" value="Save" name="submit" /> </form> </body> </html>

O impacto em potencial de spoofing de formulário, realmente, é que se você tiver um formulário que possui caixas suspensas, botões de opções, caixas de opção ou outra entrada limitada, esses limites não significam nada se ocorrer spoofing do formulário. Considere o código da Lista 15, que contém um formulário com dados inválidos.

<heading refname="listing15" type="code">Lista 15. Um Formulário com Dados Inválidos</heading>
<html>
<head>
<title>Collecting your data</title>
</head>
<body>
<form action="http://path.example.com/processStuff.php" 
    method="post"><input type="text" name="answer"
    value="There is no way this is a valid response to a yes/no answer..." />
<input type="submit" value="Save" name="submit" />
</form>
</body>
</html>

Pense nisso: Se você tiver uma caixa suspensa ou um botão de opções que limita o usuário a uma determinada quantidade de entrada, pode ficar tentado em não se preocupar com a validação da entrada. Apesar de tudo, seu formulário de entrada assegura que os usuários possam inserir somente determinados dados, certo? Para limitar spoofing de formulário, construa medidas para assegurar que as pessoas que estão fazendo as postagens são provavelmente quem dizem ser. Uma técnica que você pode usar é um token de uso único, que não impossibilita spoofing de seus formulários, mas torna bem difícil. Como o token é alterado toda vez que o formulário é desenhado, um possível atacador teria de obter uma instância do formulário de envio, remover o token e colocar em sua versão spoofing do formulário. Essa técnica torna muito improvável que alguém possa construir um formulário da Web permanente para postar pedidos indesejados em seu aplicativo. A Lista 16 fornece um exemplo de um token de formulário de tipo único.

Lista 16. Usando um Token de Formulário de Uso Único
<?php
session_start();
?>
<html>
<head>
<title>SQL Injection Test</title>
</head>
<body>
<?php

echo 'Session token=' . $_SESSION['token'];
echo '<br />';
echo 'Token from form=' . $_POST['token'];
echo '<br />';

if ($_SESSION['token'] == $_POST['token']) {
    /* cool, it's all good... create another one */

} else {
    echo '<h1>Go away!</h1>';
}
$token = md5(uniqid(rand(), true)); 
$_SESSION['token'] = $token; 
?>
<form id="myFrom" action="<?php echo $_SERVER['PHP_SELF']; ?>"
    method="post">
<div><input type="hidden" name="token" value="<?php echo $token; ?>" />
<input type="text" name="myText"
    value="<?php echo(isset($_POST['myText']) ? $_POST['myText'] : ''); ?>" />
<input type="submit" value="Save" name="submit" /></div>
</form>
</body>
</html>

Proteger contra CSRF

Cross-Site Request Forgeries (ataques CSRF) são explorações que tiram proveito de privilégios de usuários para realizarem um ataque. Em um ataque CSRF, seus usuários podem se tornar facilmente cúmplices insuspeitos. A Lista 17 fornece um exemplo de uma página que realiza uma determinada ação. Essa página consulta as informações de login do usuário a partir de um cookie. Desde que o cookie seja válido, a página da Web processa o pedido.

Lista 17. Um Exemplo de CSRF
<img src="http://www.example.com/processSomething?id=123456789" />

Ataques CSRF são frequentemente na forma de tags <img> porque o navegador involuntariamente chama a URL para obter a imagem. No entanto, a origem da imagem poderia tão facilmente ser a URL de uma página no mesmo site que realiza algum processamento baseado nos parâmetros passados na mesma. Quando essa tag <img> é colocada em um ataque XSS — que são os mais comuns dos ataques documentados — os usuários podem facilmente fazer algo com suas credenciais sem saber — assim, a falsificação.

Para se proteger contra CSRF, use a abordagem de token de uso único que você usa em seu hábito de verificar postagens de formulário. Além disso, use a variável $_POST explícita, em vez de $_REQUEST. A Lista 18 demonstra um exemplo ruim de uma página da Web que é processada de forma idêntica — seja a página chamada por um pedido GET ou tendo um formulário postado nela.

Lista 18. Obtendo os Dados de $_REQUEST
<html> <head> <title>Processes both posts AND gets</title> </head> <body>
<?php if ($_REQUEST['submit'] == 'Save') {
    echo("<p>I am processing your text: ");
    echo(htmlentities($_REQUEST['text']));
    echo("</p>"); } ?> </body> </html>

A Lista 19 mostra uma versão limpa dessa página que funciona somente com um POST de um formulário.

Lista 19. Obtendo os Dados Somente de $_POST
<html> <head> <title>Processes both posts AND gets</title> </head> <body>
<?php if ($_POST['submit'] == 'Save') {
    echo("<p>I am processing your text: ");
    echo(htmlentities($_POST['text']));
    echo("</p>"); } ?> </body> </html>

Conclusão

Começar com esses sete hábitos para escrever aplicativos da Web PHP mais seguros ajudará a evitar a se tornar uma vítima fácil de ataques maliciosos. Como muitos hábitos, eles podem parecer estranhos a princípio, mas tornam-se mais naturais à medida que o tempo passa.

Lembre-se de que o primeiro hábito é chave: validar sua entrada. Quando você assegura que sua entrada não possui valores inválidos, você pode seguir adiante para proteger seu sistema de arquivos, banco de dados e sessão. Por fim, certifique-se de que seu código PHP seja resiliente a ataques XSS, spoofs de formulário e ataques CSRF. Uma abordagem disciplinada para formar esses hábitos percorre um longo caminho para evitar ataques fáceis.

Recursos

Aprender

Obter produtos e tecnologias

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Software livre
ArticleID=382643
ArticleTitle=Sete Hábitos para Escrever Aplicativos PHP Seguros
publish-date=09302008