Conexões de Segurança

A segurança de seu servidor web 4D está baseada nos seguintes elementos:

• A combinação do sistema de gestão de senhas (modo BASIC ou modo DIGEST) e do On Web Authentication Database Method.
• A definição de um Usuário web genérico,
• A definição de uma pasta Root HTML por padrão,
• A definição da propriedade “Disponível através das etiquetas e os URLs 4D (4D ACTION...)” para cada método projeto da base.
• A opção para o suporte específico de petições de sincronização via HTTP.

Nota:

• a segurança da conexão mesma pode ser administrada pelo protocolo SSL. Para maior informação, consulte a seção Usar protocolo TLS.
• Para aprender as propriedades de segurança, veja o guia de Segurança 4D.

Pode definir nas preferências do banco, o sistema de controle de acesso que deseja aplicar a seu servidor web. São oferecidos dois modos de autenticação: Modo BASIC e modo DIGEST.
O modo autenticação se refere à maneira como se coleta e processa a informação relativa ao nome de usuário e senha.

• Em modo BASIC, o nome e a senha introduzidas pelo usuário são enviadas sem encriptar nas requisições HTTP. Este princípio não assegura uma segurança total ao sistema já que a informação pode ser interceptada e utilizada por terceiros.

• O modo DIGEST oferece um nível maior de segurança já que a informação de autenticação é processada por um processo unidirecional chamado dispersão (hashing) que faz com que seu conteúdo seja impossível de decifrar.

Para o usuário, o uso de um modo de autenticação ou outro é transparente.

Notas:

• Por razões de compatibilidade, o modo de autenticação BASIC é utilizado como o padrão automático das bases 4D convertidas a versão 11 (se a opção “Utilizar senhas” foi selecionada na versão anterior). Deve ativar explicitamente o modo Digest.

• A autenticação Digest é uma função de HTTP1.1 e não é suportada por todos os navegadores. Por exemplo, somente as versões 5.0 e superiores de Microsoft Internet Explorer aceitam este modo. Se um navegador que não suporta esta funcionalidade envia uma requisição a um servidor web, quando se ativa a autenticação Digest, o servidor negará a requisição e devolverá uma mensagem de erro ao navegador.

A escolha do modo de autenticação se realiza na página Web/Opções (I) da caixa de diálogo de Propriedades do banco:

Na área "Senhas web", há três opções disponíveis:

• Sem senhas: nenhuma autenticação é necessária para a conexão ao servidor web. Neste caso:

- Se existe On Web Authentication Database Method se executa e além de $1 e $2, somente as direções IP do navegador e do servidor ($3 e $4) são informadas, o nome de usuário e a senha ($5 y $6) estão vazios. Neste caso, pode filtrar as conexões em função da direção IP do navegador e/ou da direção IP pedida do servidor.

- Se o On Web Authentication Database Method não existe, as conexões são aceitas automaticamente.

• Senhas com protocolo BASIC: autenticação padrão em modo BASIC. Quando um usuário se conecta ao servidor, aparece uma caixa de diálogo em seu navegador permitindo que introduza seu nome e sua senha. Estes dois valores são enviados ao On Web Authentication Database Method junto com os outros parâmetros da conexão (direção e porta IP, URL...) de maneira que você os possa processar.
  Este modo oferece acesso à opção Incluir senhas 4D que permite utilizar o sistema 4D de senhas do banco (definido em 4D), seja em substituição ou de forma conjunta com seu próprio sistema de senhas,

• Senhas com protocolo DIGEST: autenticação no modo DIGEST. Como no modo BASIC, os usuários devem introduzir seu nome e senha quando se conectam. Estes dois valores são enviados criptografados ao On Web Authentication Database Method com os outros parâmetros da conexão. Deve autenticar um usuário utilizando o comando WEB Validate digest.

Notas:

• Deve reiniciar o servidor web para que as modificações efetuadas a estes parâmetros sejan levadas em conta

• Com o servidor web de 4D Client, recorde que todos os websites publicados pelas máquinas clientes 4D compartirão a mesma tabela de usuários. A validação dos usuários/senhas é levada a cabo pela aplicação 4D Server.

Quando se utiliza o modo BASIC, o sistema de filtro das conexões ao servidor web de 4D depende da combinação de dois parâmetros:

• As opções de senhas web na caixa de diálogo de Propriedades do banco,
• A existência do On Web Authentication Database Method.

Estas são as diferentes possibilidades de controle das conexões:

A opção “Senhas com protocolo BASIC” está selecionada e a opção “Incluir senhas 4D” não está selecionada.

• Se existir o On Web Authentication Database Method, ele é executado e todos os seus parâmetros são dados. Pode filtrar mais precisamente as conexões de acordo ao nome de usuário, senha, e/ou às direções IP do navegador e do servidor web.

• Se o On Web Authentication Database Method não existe, a conexão é negada automaticamente e é enviada uma mensagem ao navegador indicando que o método de autenticação não existe.

Nota: se o nome de usuário enviado é uma string vazía e se o On Web Authentication Database Method não existe, é enviada ao  navegador uma caixa de diálogo de pedido de senha.

As opções “Senhas com protocolo BASIC” e “Incluir senhas 4D” estão selecionadas.

• Se o nome de usuário enviado pelo navegador existe na tabela de usuários 4D e a senha é correta, a conexão é aceita. Se a senha é incorreta, a conexão é negada.

• Se o nome de usuário enviado pelo navegador não existe em 4D, dois resultados são possíveis:

- Se existir o On Web Authentication Database Method, se retornam os parâmetros $1, $2, $3, $4, $5, e $6. Portanto pode filtrar as conexões de acordo com o nome de usuário, senha, e/ou as direções IP do navegador e do servidor web.

- Se o On Web Authentication Database Method não existe, a conexão é negada.

Diferentemente do modo BASIC, o modo DIGEST não é compatível com as senhas 4D padrão: não é possível utilizar as senhas 4D como identificadores Web. A opção “Incluir senhas 4D” está desativada quando se seleciona este modo. Os identificadores dos usuários Web devem ser administrados de maneira personalizada (por exemplo, através de uma tabela).
Quando o modo DIGEST está ativo, o parâmetro $6 (senha) sempre é devolvido vazio no . Na realidade, quando se utiliza este modo, esta informação não passa pela rede como texto não criptografado. Portanto é imperativo neste caso avaliar a requisição de conexão com a ajuda do comando Validate Digest Web Password.

O funcionamento do sistema de acesso ao servidor Web 4D é resumido no seguinte diagrama:

Alguns robôs (motores de pesquisa, aranhas...) recorrem os servidores Web e as páginas estáticas. Se desejar que os robôs possam acessar a todo seu site, pode definir quais URLs não podem acessar.
Para isso, ponha o arquivo ROBÔS.TXT na raiz do servidor Web. Este arquivo deve estar estruturado da seguinte maneira:

User-Agent: <nombre>
Disallow: <URL> o <começo da URL>

Por exemplo:

User-Agent: *
Disallow: /4D
Disallow: /%23%23
Disallow: /GIFS/

“User-Agent: *” significa que todos os robôs estão afetados.
“Disallow: /4D” significa que os robôs não devem ser acessados aos URLs que começam por /4D.
“Disallow: /%23%23” significa que os robôs não devem acessar aos URLs que começam por /%23%23.
“Disallow: /GIFS/’ significa que os robôs não devem acessar a pasta /GIFS/ nem às subpastas.

Outro exemplo:

User-Agent: *
Disallow: /

Neste caso, os robôs no tem acesso a todo o site.

Pode designar um usuário, previamente definido na tabela de senhas de 4D, como “Usuário Web Genérico.” Neste caso, cada navegador que se conecta ao banco pode utilizar as autorizações de acesso e as restrições associadas com este usuário. Desta maneira pode controlar facilmente o acesso dos navegadores às diferentes partes do banco.

Nota: não se deve confundir esta opção, que permite restringir os acessos dos navegadores às diferentes partes da aplicação (métodos, formulários, etc.), com o sistema de controle de conexões ao servidor web, administrado pelo sistema de senhas e On Web Authentication Database Method

Para definir um Usuário web genérico:

1. No modo Desenho, criar ao menos um usuário com o editor de usuários da caixa de ferramentas.
    Se deseja pode associar uma senha com o usuário.
2. Nos diferentes editores de 4D, autorizar ou restringir o acesso a este usuário.
3. Na caixa de diálogo de Propriedades, escolher o tema Web, página Opções (I).
    Na área “Senhas Web” contém a lista pop-up Usuário web genérico. Como padrão, o Usuário web genérico é o Designer e os navegadores têm acesso completo a todas as partes do banco.
4. Escolher o usuário na lista pop-up e validar a caixa de diálogo.

Todos os navegadores web autorizados a conectar-se ao banco se beneficiarão das autorizações de acesso associadas ao Usuário web genérico (exceto quando o modo BASIC e a opção “Incluir senhas 4D” estão selecionadas e o usuário que se conecta não existe na tabela de senhas 4D, ver a continuação).

A opção "Senhas com protocolo BASIC" não influi em como funciona o Usuário Web genérico. Sem importar o estado desta opção, os privilégios e as restrições de acesso associadas ao “Usuário Web genérico” se aplicarão a todos os navegadores Web que estejam autorizados a se conectar ao banco.

Entretanto, quando a opção "Incluir senhas 4D" estiver selecionada podem apresentar-se dois possíveis resultados:

• o nome e a senha do usuário não existem na tabela de senhas de 4D. Neste caso, se a conexão foi aceita pelo On Web Authentication Database Method, os direitos de acesso do usuário Web genérico serão aplicados ao navegador.

• Se o nome de usuário e senha existem na tabela de senhas de 4D, o parâmetro “Usuário Web genérico” se ignora. O usuário se conecta com seus próprios direitos de acesso.

Esta opção das Propriedades do banco permite definir a pasta na qual 4D buscará as páginas HTML estáticas e semi-dinâmicas, as imagens, etc., a enviar aos navegadores.

Além disso, a pasta raíz HTML define, no disco rígido do servidor web, o nível hierárquico acima do qual os arquivos não serão acessíveis. Esta restrição de acesso aplica às URLs enviados aos navegadores web assim como aos comandos do servidor, por exemplo WEB SEND FILE. Se uma URL enviada ao banco por um navegador ou se um comando 4D tentar acessar a um arquivo localizado sobre a pasta raiz HTML, um erro é retornado indicando que o arquivo não foi encontrado.

Por padrão, 4D define uma pasta raiz HTML chamada WebFolder. Se esta pasta ainda não existir, a pasta raiz HTML é criada no disco no momento em que se lança o servidor web pela primeira vez.
Se conserva a localização padrão, a pasta raíz é criada:

• com 4D em modo local e 4D Server, ao mesmo nível que o arquivo de estrutura da banco.
• com 4D em modo remoto, na pasta local do banco 4D (ver o comando Get 4D folder).

Pode modificar o nome e a localização da pasta raíz HTML por padrão na caixa de diálogo de Propriedades (tema Web, página Configuração):

Na área “Raiz HTML por padrão”, introduza a nova rota de acesso da pasta que desejar utilizar.

A rota de acesso introduzida nesta caixa de diálogo é relativa: está estabelecida a partir da pasta que contiver a estrutura do banco (4D em modo local ou 4D Server) ou a pasta que contiver a aplicação ou o software 4D (4D em modo remoto).

Com o fim de garantir a compatibilidade multiplataforma de seus bancos, o servidor Web 4D utiliza convenções de escritura particulares para descrever rotas de acesso. As regras de sintaxe são as seguintes:

• As pastas estão separadas por uma barra oblíqua (“/”)
• A rota de acesso não deve terminar com uma barra oblíqua (“/”)
• Para “subir” um nível na hierarquia das pastas, introduza “..” (dois pontos) antes do nome da pasta
• A rota de acesso não deve começar com uma barra oblíqua (“/”) (exceto se desejar que a pasta raiz HTML seja a pasta do banco ou de 4D Client, ver a continuação).

Se desejar que a pasta raiz HTML seja a pasta do banco ou de 4D Client, mas que o acesso às pastas dos níveis superiores esteja proibido, introduza “/” na área. Para que o acesso aos volumes seja total, deixe a área “Raiz HTML por padrão” vazia.

• Quando a pasta raiz HTML se modifica nas Propriedades do banco, a cachê se apaga para não conservar arquivos cujo acesso for restrito.
• Também é possível definir dinamicamente a pasta raiz HTML utilizando o comando WEB SET ROOT FOLDER. Neste caso, a modificação aplica a todos os processos web atuais para a sessão de trabalho. A cachê das páginas HTML é apagada.

A URL especial DACTION, as etiquetas 4DSCRIPT, 4DEVAL, 4DTEXT, 4DHTML (assim como as antigas etiquetas 4DVAR e 4DHTMLVAR) permitem ativar a execução de todo método projeto de um banco 4D publicada na Web. Por exemplo, a petição http://www.server.com/4DACTION/Erase_All e faz com que o método projeto Erase_All (se existir), seja executado.

Este mecanismo apresenta um risco para a segurança do banco, especialmente se um internauta intencionalmente (ou por erro) dispara um método não destinado para execução através de Web. Pode evitar este risco de três formas:

• Restringindo o acesso aos métodos projeto utilizando o sistema de senhas 4D. Inconvenientes: este sistema necessita utilizar as senhas 4D e proíbe todo tipo de execução do método (incluindo utilizar as etiquetas HTML).
• Filtrando os métodos chamados através de URLS utilizando o On Web Authentication Database Method. Inconvenientes: se o banco incluir um grande número de métodos, este sistema pode ser difícil de administrar.
•  Usar a opção Disponível através das etiquetas e os URLs 4D (4DATION.) mostrada na caixa de diálogo de Propriedades dos métodos projeto:

Esta opção está desmarcada por padrão ao criar um banco. Os métodos que podem ser executado utilizando a URL 4DACTION e as etiquetas 4D devem ser indicadas expressamente.

No Explorer, métodos de projeto com essa propriedade recebem um ícone específico:

Esta opção da página "Web/Configuração" das Propriedades da base permite controlar o suporte de petições que contém os URLs /4DSYNC. Estes URLs se utilizam para a sincronização de dados através de HTTP (para obter mais informação sobre este mecanismo, consulte o parágrafo URL 4DSYNC/).

Esta opção habilita ou desabilita o processamento específico das petições que contem /4DSYNC:

• Quando não está selecionada, as petições /4DSYNC são consideradas como petições padrão e não permitem o processamento específico (o uso de uma petição de sincronização provoca o envio da resposta tipo "404 - recurso não disponível").
• Quando se ativa, o mecanismo de sincronização está ativado; as petições /4DSYNC se consideram como petições especiais e são processadas pelo servidor HTTP de 4D.

Por padrão:

• esta opção não está selecionada no banco de dados criadas com 4D a partir da versão 13.
• esta opção não está selecionada no banco de dados convertidas de uma versão anterior a 4D v13, razões de compatibilidade. Lhe recomendamos que a desative se sua aplicação não utiliza a função de replicação  HTTP.

O alcance desta opção é local à aplicação e o servidor web deve ser reiniciado para ter ela em conta.