Lançado Adianti Framework 7.6!
Clique aqui para saber mais
Conheça Características Quem usa Galeria Cursos Docs Fórum
Downloads
Posts Fique por dentro Sobre o Fórum Minha conta
Segurança da aplicação Olá. Minha ferramenta de desenvolvimento é o Delphi e conheço pouquíssimo PHP, por isso meu interesse neste framework como entrada para aplicativos web. Muito se fala em segurança da aplicação na web e gostara de saber se as práticas neste sentido são seguidas pelo framework....
PP
Segurança da aplicação  
Fechado
Paulo Cesar Penatti 27/12/2014 (há 9 anos)
Olá. Minha ferramenta de desenvolvimento é o Delphi e conheço pouquíssimo PHP, por isso meu interesse neste framework como entrada para aplicativos web. Muito se fala em segurança da aplicação na web e gostara de saber se as práticas neste sentido são seguidas pelo framework.
Pacotão Dominando o Adianti Framework 7
O material mais completo de treinamento do Framework.
Curso em vídeo aulas + Livro completo + Códigos fontes do projeto ERPHouse.
Conteúdo Atualizado! Versão 7.4


Dominando o Adianti 7 Quero me inscrever agora!

Comentários (7)

BJ
Beto Frota Júnior       27/12/2014 (há 9 anos)

Olá Paulo, também sou novo no PHP, venho do Delphi, e com certeza tenho interesse em saber a resposta para a sua pergunta. E aproveitando o tópico segurança, gostaria de saber algo específico: No caso do sistema ser instalado em uma intranet, quais as providências que podem ser tomada para o código fonte não ser exposto?
FC
Felipe Cortez       29/12/2014 (há 9 anos)

Oi Pessoal, eu venho do VB também sou novo em PHP vou tentar contribuir com as dúvidas de vcs.

1- Segurança de aplicação WEB

Existe muitos tópicos a respeito na net essa pergunta abre um discursão imensa cada um com sua teoria seria como discutir a melhor linguagem ou religião por exemplo, porém cabe ao desenvolvedor entender o tamanho do projeto e a partir dai ver qual necessidade ou maior ou menor cuidado com a segurança. Mas qual segurança? sem dúvida dos dados backups são sempre necessários caba avaliar cada projeto para saber a periodicidade, e sempre que for fazer qualquer modificação na base de dados.

2- a grande diferença do VB/Delphi para o PHP é a geração de .exe onde acreditamos que nossos códigos estão seguros uma boa opção é vendermos o sistema pronto instalado em nosso host de confiança. para a intranet existe alguns métodos de Ofuscar o código PHP alguns pagos outros grátis porém a segurança é e será sempre questionável.

Abraços.
PP
Paulo Cesar Penatti - AUTOR DO POST       29/12/2014 (há 9 anos)

Na verdade minha preocupação principal é a possibilidade de acesso não autorizado ao banco de dados por falha de segurança no desenvolvimento da aplicação, também conhecida como 'programação insegura'. Minha dúvida é se este framework segue fortes padrões de segurança.
RR
Rafael Ramos       29/12/2014 (há 9 anos)

Paulo, acredito que sua preocupação maior deve ser com relação a "SQL Injection", pois é realmente uma preocupação que deve ser considerada hoje em dia. Eu tinha uma aplicação simples em PHP que estava toda "aberta" pra injeções de sql, um amigo meu que me ligou dando um toque (na verdade um esporro mesmo... hehehe) pra eu corrigir. Mas na época eu tinha pouca preocupação com isso... as funções da acesso à dados sequer usavam "Prepared Statement"...

Não conheço detalhes a fundo da implementação do Adianti, mas sei que usa PDO para acesso ao banco de dados. O PDO, por si só, já garante muito mais segurança no acesso ao banco (inclusive contra SQL Injection).

Mas acredito que só o Pablo poderá responder sobre as questões de segurança do Framework com maior propriedade...
BJ
Beto Frota Júnior       29/12/2014 (há 9 anos)

Agradeço pelas respostas de Felipe e Rafael, e pela paciência de Paulo. Agora vou googlar mais a cerca do assunto, pois já tenho base pra tal.
PD
Pablo Dall'Oglio       31/12/2014 (há 9 anos)

Oi Amigos,

O Adianti Framework 2.0, que será lançado no dia 05/01/2014 foi melhorado no quesito segurança. Agora todas requisições que vão ao Banco de Dados utilizarão Prepared Statements por default, o que blinda e muito a possibilidade de SQL Injection. Para habilitar, será necessário abrir o INI de configuração de acesso ao banco de dados e adicionar:
prep = "1"


É isso, quem já utiliza as TRecord, TRepository, TCriteria, TFilter, etc, não precisa se preocupar que a mudança é transparente. Mais informações em:
en.wikipedia.org/wiki/Prepared_statement
php.net/manual/pt_BR/pdo.prepared-statements.php

Atenciosamente,
Pablo
RR
Rafael Ramos       03/01/2015 (há 9 anos)

Esse tema é bem interessante, pra não dizer importantíssimo...

Nos primórdios ignorava a existência de SQL Injection. A ignorância naquela época era uma dádiva, pois depois que você descobre que essa desgraça existe (e vê ao vivo e a cores em uma aplicação sua) aí começa a ficar meio paranóico... hehehe

Durante algum tempo cheguei a usar uma solução idêntica a essa (rs):
vidadeprogramador.com.br/2012/02/16/sistema-seguro/

Depois que li essa tirinha, vi que era péssima e dei uma melhoradinha pra ficar menos pior, criando uma função recursiva que varria várias vezes as strings até deixar ela completamente "limpa". Não tô achando mais o arquivo, mas era alguma coisa como isso:

  1. <?php
  2. function anti_injection($sql)
  3. {
  4.     $limpo = false;
  6.     do
  7.     {
  8.         $sql = preg_replace(sql_regcase("/(order by|union all|from|select|insert|delete|where|drop table|show tables|#|\*|--|\\\\)/"), "", $sql);
  9.         $sql = trim($sql);
  10.         $sql = strip_tags($sql);
  11.         $sql = addslashes($sql);
  13.         if
  14.         (
  15.             (stristr(strtolower($sql), "order by") == false) && 
  16.             (stristr(strtolower($sql), "union all") == false) && 
  17.             (stristr(strtolower($sql), "from") == false) && 
  18.             (stristr(strtolower($sql), "select") == false) && 
  19.             (stristr(strtolower($sql), "insert") == false) && 
  20.             (stristr(strtolower($sql), "delete") == false) && 
  21.             (stristr(strtolower($sql), "where") == false) && 
  22.             (stristr(strtolower($sql), "drop table") == false) && 
  23.             (stristr(strtolower($sql), "show tables") == false) && 
  24.             (stristr(strtolower($sql), "#") == false) && 
  25.             (stristr(strtolower($sql), "*") == false) && 
  26.             (stristr(strtolower($sql), "--") == false)
  27.         ) $limpo = true;
  28.     }
  29.     while ($limpo == false);
  31.     return $sql;
  32. }
  33. ?>


Usei essa opção acima durante um bom tempo, aparentemente (rs) sem problemas...

Pra parâmetros de ID pela URL com $_GET essa aqui sempre foi uma boa:

  1. <?php
  2. /Convertendo caracteres especiais para a realidade HTML
  3. 2    $varLimpa = htmlspecialchars($_POST[‘infoForm’], ENT_QUOTES,’UTF-8’);
  4. 3     
  5. 4    //voltando os caracteres originais
  6. 5    $varSuja = htmlspecialchars_decode($varLimpa );
  7. 6     
  8. 7    //filtros
  9. 8    $email = "clifton@example"; //Note the .com missing
  10. 9    if(filter_var($email, FILTER_VALIDATE_EMAIL)){
  11. 10        //válido
  12. 11    }
  13. 12    //recebendo um parâmetro GET, e validando se é inteiro
  14. 13    $id = filter_input('INPUT_GET', 'id', 'FILTER_VALIDATE_INT');
  15. ?>


Essa dica acima é uma das várias desse artigo bem interessante:
imasters.com.br/infra/seguranca/seguranca-em-aplicacoes-web-com-php/

E, por fim, o PDO e as Queries Parametrizadas acabaram com cerca de 99,99% das chances de Injection no PHP.

Acredito que nada esteja 100% livre de SQLInjection, pois até o site do MYSQL (!!!) já foi invadido com essa técnica.