As senhas são o principal meio de proteção das informações e são utilizadas em todos os lugares do computador - desde o login em uma conta até a autorização em páginas de redes sociais. Um usuário ativo possui tantas chaves de segurança diferentes que é impossível mantê-las todas na memória. É aqui que a função de salvar senhas nas configurações do navegador vem em socorro.

Funciona assim:

Na próxima vez que você abrir este site, não será necessário inserir nada; mesmo se você sair da sua conta, todas as linhas do formulário de autorização serão preenchidas. Mas aqui uma séria desvantagem é revelada - vamos descobrir como visualizar uma senha oculta com asteriscos e se é possível fazer isso.

Então, você acessa o site e vê a senha abaixo dos asteriscos. Pareceria algo conveniente - você clica em “Login” e não precisa inserir mais nada, e outros usuários não veem sua senha.

Uma senha coberta com asteriscos é um alvo fácil para hackers.

Confira no seu computador. Como exemplo, usamos o navegador Google Chrome:

Da mesma forma, você pode visualizar as chaves de acesso a contas em outros navegadores - Mozilla Firefox, Opera, Internet Explorer. Vamos ver como isso é feito no Mozilla para fixar material:

Aliás, não é necessário alterar o valor novamente para “senha”. Se você fechar a página e voltar a ela, verá que as estrelas retornaram. No entanto, agora você sabe como eles são protetores de dados pessoais não confiáveis.

Se você pensa que este é o fim da exposição das estrelas, está profundamente enganado. Todos os navegadores possuem uma maneira ainda mais conveniente de visualizar a senha que você salvou ao fazer login no site pela primeira vez. Desta vez, vamos pegar o navegador Opera como exemplo:

Uma janela aparecerá contendo vários endereços de sites e dados de diferentes contas. À primeira vista está tudo bem: os logins, claro, são exibidos, mas em vez de senhas, há asteriscos que nos são familiares. No entanto, se você clicar em uma linha, verá um botão Mostrar aparecer próximo às estrelas.

Um clique e você verá a chave de segurança do site. Você pode revelar todas as senhas, fazer uma captura de tela e nem perceberá que suas páginas protegidas por senha estão em perigo. Não apenas o Opera, mas também outros navegadores compartilham essas informações. No Google Chrome, por exemplo, tal sinal pode ser chamado da seguinte forma:

No Mozilla Firefox, uma tabela com todas as chaves de acesso salvas é aberta na seção “Segurança” das configurações.

Em outros navegadores a situação é semelhante - todos os dados que você concorda em armazenar devem estar disponíveis publicamente.

Mas não são apenas os navegadores que armazenam dados sobre os usuários, que o usuário gentilmente fornece e armazena.

Qualquer programa que exija a digitação de senha e login também oferece a lembrança desses dados para não inseri-los toda vez que for iniciado.

Assim, existem utilitários especiais que permitem visualizar esses dados salvos. Esses utilitários funcionam com o mesmo princípio, então tomemos o programa Password Cracker como exemplo. É distribuído gratuitamente e pesa ridículos 45 KB.

Na linha “Senha” da janela do utilitário Password Cracker, a chave de segurança salva aparecerá em display alfanumérico.

Como você pode ver agora, descobrir a senha escondida no navegador, escondida com asteriscos, não é difícil. Basta ter acesso a um computador e alguns minutos para que os dados de suas contas cheguem às mãos de pessoas não autorizadas.

Claro que neste caso você corre o risco de esquecer sua senha e não entrar no perfil desejado. No entanto, isso não é assustador: já escrevemos sobre como recuperar a senha do Gmail, como descobrir a senha do Wi-Fi, como recuperar o acesso à sua conta no jogo WarFace, etc. Se você conseguir fazer login na caixa de correio na qual a conta está registrada ou vincular um número de telefone ao seu perfil, então, se necessário, você poderá recuperar facilmente uma senha esquecida.

Mas o que fazer com aquelas chaves de segurança que você já salvou nas configurações do seu navegador? A resposta correta é excluir. Ao visualizar as senhas por meio das configurações, você deve ter percebido que o recurso de salvar códigos pode ser desativado. Limpe as tabelas com chaves armazenadas, removendo todas as linhas e, em seguida, desative a própria função.

Não existem artigos semelhantes.

Portanto, nossa tarefa é definir uma senha para acessar uma determinada página. Vamos começar com o método mais primitivo, por assim dizer, de proteção - algumas linhas em JavaScript:

Var pass = prompt("Digite a senha:", ""); if (pass == null) window.location = "wrong.html"; senão if (pass.toLowerCase() == "wwvsfc") window.location = "temp.html"; senão janela.localização = "errado.html"; Truques como ocultar um script em um arquivo separado usando uma construção não mudam nada fundamentalmente.

Um sistema semelhante implementado em Java:

Importar java.applet.*; importar java.awt.*; importar java.net.*; classe pública Senha estende miniaplicativo( TextField login, senha; String Login = "login"; String Senha = "Senha"; public Password() ( ) public void init() ( Panel panel = new Panel(); panel.setLayout(new GridLayout(2,2)); login = new TextField(20); painel.add(novo rótulo:)); painel.add(novo) Label("Senha:")); new Button("Ok")); public boolean action(Event evt, Object obj) ( if(evt.target instanceof Button) ( String s; if(login.getText().equals(Login) && password.getText() .equals(Senha)) ( s = "http://www.hackzone.ru/articles/ok.html" ; ) else ( s = "http://www.hackzone.ru/articles/bad.html"; ) try ( getAppletContext().showDocument(new URL(s)); ) catch(Exception e) ( password.setText (e.toString()); return true; return false)

Ao incluir este miniaplicativo em uma página, você pode obter algo assim (todos os exemplos subsequentes usam ok.html e bad.html):

Pode ser mais inteligente, criar uma página separada para cada usuário, forçá-lo a ler dados de um arquivo, etc. A desvantagem fundamental é que, uma vez que uma pessoa acessa a página que procura, ninguém pode impedi-la de se lembrar desse URL, portanto, esta é uma ferramenta única. Claro, você pode ocultar a página dentro de um quadro para que a URL não apareça na barra de endereço, mas você entende de quem é essa proteção. Novamente, o applet vai inteiramente para o cliente e está, em princípio, totalmente disponível para pesquisa.

A solução baseada no uso de CGI não apresenta a última desvantagem. Um script Perl simples se parece com isto:

#!/usr/bin/perluse CGI qw(:padrão); $query = novo CGI;$ok = "ok.html";$address = "bad.html"; $login = "login";$senha = "senha"; $l = $query->param("login"); $p = $query->param("senha"); if(($p eq $senha) && ($l eq $login))( $endereço = $ok;)print $query->redirect($endereço);

Exemplo de uso:

Para lidar com a primeira desvantagem, você pode gerar dinamicamente uma nova página com base naquela escondida em algum lugar dentro, sem fornecer a URL.

Código modificado:

#!/usr/bin/perluse CGI qw(:padrão); $consulta = novo CGI; $ok = "ok.html"; $endereço = "ruim.html"; $docroot = $ENV("DOCUMENT_ROOT"); $localpath = "/artigos/"; $login = "login";$senha = "senha"; $l = $query->param("login"); $p = $query->param("senha"); if(($p eq $senha) && ($l eq $login))( $endereço = $ok;) print $query->header(); open(FL, $docroot.$localpath.$endereço); while())(# Aqui, ao mesmo tempo, você pode modificar o código HTML instantaneamente# Por quê? Bem, nunca se sabe... :) print $_;) close (FL);

Exemplo de uso:

Como você pode ver, o URL do arquivo não é mais exibido, embora às custas do SSI (no entanto, eles podem ser capturados apenas durante a saída e processados ​​​​manualmente). Mas aqui também permanece a possibilidade teórica de adivinhar o URL e). não devemos esquecer que todos os tipos de imagens incluídas podem prejudicar as páginas - ao usar caminhos relativos, é claro.

Por fim, a maneira mais confiável de definir uma senha de acesso é usar ferramentas de servidor – afinal, não é à toa que as pessoas fazem isso. Vou me concentrar em dois: Apache como o mais popular e IIS como também popular :)

Com o IIS, tudo é bastante simples - a proteção é realizada usando NTFS, o que, é claro, limita um pouco as capacidades dos administradores que não são servidores. A ideia é a seguinte: ao usuário IUSR_xxxx, sob cuja conta todos os visitantes do site trabalham por padrão, é negado o acesso ao arquivo/diretório desejado. Depois disso, apenas os usuários para os quais isso está explicitamente especificado em Propriedades->Segurança terão acesso a esses arquivos. É claro que é muito mais conveniente combiná-los em grupos. Existem algumas sutilezas aqui. Em primeiro lugar, os usuários especificados devem receber o direito de Logon local (Políticas->Direitos do Usuário no Gerenciador de Usuários). Em segundo lugar, se você não selecionar o serviço WWW Autenticação básica (Texto não criptografado) nas configurações da WWW, apenas os usuários do Internet Explorer terão acesso. permitido em.

No Apache, tudo é feito de forma um pouco diferente. A proteção é definida no nível do diretório. As diretivas correspondentes podem ser colocadas tanto no arquivo de configuração geral php.ini quanto nos arquivos .htaccess. O conjunto de diretivas em ambos os casos é o mesmo, e para a maioria das pessoas que alugam espaço para um site/página no servidor de outra pessoa, a primeira opção não está disponível. Portanto, você cria um arquivo .htaccess no diretório ao qual planeja restringir o acesso e insere as seguintes diretivas nele:

Tipo de autorização tipo de controle- Geralmente é usado o básico.

Autenticação Nome- especifica o nome da área na qual os nomes de usuário e senhas são válidos. Este é o mesmo nome que o navegador mostra na caixa de diálogo de senha. Ao definir um desses nomes para diretórios diferentes, você pode poupar aos usuários o tempo de inserir uma senha extra.

AuthGroupFile Nome- especifica o nome do arquivo no qual os nomes dos grupos e seus membros são armazenados. Seu formato:
grupo1: membro1 membro2 ...
grupo2: membro3 membro4 ...

AuthUserFile Nome- especifica o nome do arquivo com senhas. Em geral, para gerá-lo você precisa usar o utilitário htpasswd da distribuição Apache. Mas pelo menos para algumas versões do servidor, este formato é:
usuário1: senhahash1
usuário2: senhahash2

O Passwordhash pode ser facilmente obtido usando a função Perl padrão:
$hash=cripta($pass,$sal);
onde $pass é a senha, $salt é uma string de dois caracteres envolvida na geração do hash.

Assim é bem possível automatizar o processo de adição de novos usuários, alteração de senhas através de formulários html, etc.

requer usuário usuário1 usuário2 e requer grupo usuário1 usuário2 permitem que você especifique quais usuários e grupos terão acesso a um determinado diretório.

require valid-user permite acesso a todos os usuários especificados no arquivo de senha do sistema.

... , onde método eu define um método HTTP. Por exemplo, limita o uso de não diretivas aninhadas aos casos de uso dos métodos GET e POST (geralmente isso é mais que suficiente. As diretivas aninhadas podem ser require, order,allow e deny).

Outras diretivas úteis são negar e permitir - negar e permitir acesso, respectivamente. Elas são usadas mais ou menos assim:
negar de todos
permitir de 192.168

Por padrão, todas as negações são executadas primeiro e depois todas as permissões, portanto, permitir de todos permitirá o acesso a todos os usuários, independentemente de qualquer negação. A ordem pode ser alterada com a diretiva order: order permitir, negar .

negar de tudo funciona bem com o segundo método de proteção de páginas via CGI; é esta diretiva que é melhor para cobrir todos os tipos de senhas para livros de visitas, etc. Ao tentar acessar páginas deste diretório, o usuário receberá uma mensagem sobre uma página inexistente.

Aliás, aqui, de passagem, é demonstrado o tratamento independente de erros: neste caso, código 403, Proibido. Os amados 404 - Not Found e 401 - Unauthorized são processados ​​de forma semelhante. Para fazer isso, basta adicionar a diretiva ErrorDocument ao .htaccess código de URL:
Documento de erro 404 /cgi-bin/bad.pl
Documento de erro 403 /cgi-bin/badaccess.pl
Documento de erro 401 /cgi-bin/badaccess.pl

Tudo o que o script faz é gerar uma mensagem de erro usando a variável de ambiente REQUEST_URI, então você pode simplesmente apontar para alguma página adequada.

Para o exemplo final, usamos um arquivo .htaccess com o seguinte conteúdo:

AuthType BasicAuthName TestAuthGroupFile /my/local/path/tgroupAuthUserFile /my/local/path/tuserequire teste de grupo

Existe apenas uma linha no arquivo tgroup - teste: teste de login, no arquivo tuser - senhas criptografadas para login (senha) e teste (teste). Observe que ao acessar esta página novamente, o navegador entende que acabou de acessar esta área e não incomoda o usuário com uma solicitação de senha desnecessária.

Este é, em resumo, o conjunto mínimo de informações necessárias para proteger páginas web. Como mostra a prática, você deve confiar mais ou menos apenas em soluções baseadas nas ferramentas fornecidas pelo servidor (e até que outra falha seja descoberta no servidor), portanto, se possível, é melhor escolhê-las.

São discutidas maneiras simples de bloquear um diretório ou arquivos com uma senha. Como autorizar um usuário através de cookies. Identificação do usuário através do mecanismo de sessão embutido no PHP4.

Decidi descrever maneiras de proteger parte do site com uma senha. O tópico é bastante extenso, então pela primeira vez vou me limitar à autorização php+mysql.

A primeira dúvida que geralmente surge é como fechar o diretório com scripts de administração com senha. Nesse caso, não são necessários frescuras - um ou mais administradores têm os mesmos direitos e as personalidades raramente mudam. A maneira mais fácil nesta situação é usar a autorização de servidor padrão - coloque os arquivos .htaccess e .htpasswd e escreva neles os parâmetros necessários.

Acrescentarei duas coisas. A primeira é onde colocar o arquivo .htpasswd. Experimentalmente, descobri que se, por exemplo, o caminho para um documento com mensagem de erro (ErrorDocument) for escrito em relação à variável de sistema DocumentRoot. Mas o caminho para o arquivo de senha (UserFile) é escrito em relação ao ServerRoot. Pelo que entendi, você não pode colocar .htpasswd acima do ServerRoot - "../" não é percebido. Tudo isso é feito para que você possa colocar um arquivo com senhas, por exemplo, um nível acima do diretório raiz do site, para que não haja nenhum acesso ao arquivo pela rede.

A segunda é que o script consegue descobrir quem está abrindo ele e a senha: as variáveis ​​$PHP_AUTH_USER e $PHP_AUTH_PW.

A principal desvantagem desse método é que o servidor não pode bloquear a adivinhação de senha (após várias tentativas malsucedidas de login, o usuário é solicitado a esperar uma ou duas horas e, durante esse tempo, as chamadas de seu endereço IP são ignoradas). Isso está escrito na documentação oficial do Apache.

Outra desvantagem é a necessidade de reescrever arquivos com senhas ao excluir um usuário ou introduzir um novo. Mas se isso acontecer com pouca frequência, este método é suficiente e você não terá que se preocupar em escrever um mecanismo de autorização.

Isso é necessário não apenas para simplificar o trabalho com um grande número de usuários e sua alta rotatividade. Se você precisar manter informações adicionais sobre os usuários ou precisar de diferenciação flexível de direitos, é melhor transferir a autorização para o banco de dados.

Cada página de um território fechado inclui um arquivo com o seguinte código:

$resultado = mysql_query(" SELECT * FROM person WHERE login="". preg_replace("/[^\\w_-]/","",$PHP_AUTH_USER). "" AND pass="". md5($PHP_AUTH_PW) . """); if (@mysql_num_rows($result)!=1) ( header("WWW-Authenticate: Basic realm=\"Área do usuário\""); header("HTTP/1.0 401 Unauthorized"); print("Para fazer login no parte da área de usuário do site, você deve inserir seu nome de usuário e senha."); exit(); ); $user_row = mysql_fetch_array($resultado);

Na primeira linha, todos os caracteres, exceto letras, números, travessões e sublinhados, são removidos do login. O número de linhas recebidas é então verificado e somente se for uma linha o acesso é concedido. Em outros casos, o usuário verá uma janela no navegador solicitando que você insira um login e uma senha. Se o usuário efetuou login com sucesso, temos todas as informações sobre ele no array $user_row.

É claro que o exemplo que dei tem uma série de deficiências significativas. Não reescreva um a um, para não ser vítima de tentativas de adivinhação de senha, pois
1. não há proteção contra seleção aqui
2. Se a tabela do usuário for grande, ao adivinhar a senha, um invasor provavelmente sobrecarregará o banco de dados

E o último método hoje é armazenar dados criptografados em cookies.

Existe um script para login, o restante inclui um código que só permite continuar as ações em uma área fechada - se os cookies expirarem ou ele sair de lá, você terá que retornar à página de login.

O script de entrada verifica o login e a senha e emite dois cookies. No primeiro - o login, para identificar imediatamente o usuário (no banco de dados, o campo de login é, claro, único ou mesmo chave). O segundo cookie contém um hash do horário de login e da senha (para maior sigilo, adiciono a letra “Y” a essas linhas - então é quase impossível encontrar o hash :).

Todos os outros programas incluem código que faz o seguinte. Faz uma solicitação ao banco de dados - seleciona a linha com o login recebido. A partir desta linha ele pega o campo “log_time” e a senha e faz um hash a partir deles, conforme descrito acima. Compara com o que recebeu, e caso correspondam, emite um novo cookie hash, novamente, a partir da senha, hora e letra “Y” e faz uma consulta ao banco de dados “UPDATE user SET log_time="..." WHERE login = "$cookie_login"".

If (isset($HTTP_COOKIE_VARS[$cookie_login]) && isset($HTTP_COOKIE_VARS[$cookie_code])) ( $login = $HTTP_COOKIE_VARS[$cookie_login]; $code = $HTTP_COOKIE_VARS[$cookie_code]; $resultado = mysql_query("SELECT date_format(log_date,"%Y%m%d%H%i%s") as log_date1,pass,uid FROM usuário WHERE email="$login" AND log_date>"DATE_SUB(NOW(),INTERVAL 15 MINUTE)"" ); if (!mysql_error() && @mysql_num_rows($result)==1) ( $log_time0 = time(); $log_time1 = date("YmdHis", $log_time0); $log_time2 = date("Y-m-d H:i :s", $log_time0); $user_atual = mysql_fetch_array($resultado); if (md5($user_atual["pass"].$user_atual["log_date1"].$md5letter) == $code) ( mysql_query("UPDATE usuário SET log_date="$log_time2" WHERE uid=".$current_user["uid"]); setcookie($cookie_code, md5($current_user["pass"].$log_time1.$md5letter), time()+900, $site_path); $auth = true; senão não definido($user_atual);

Novamente, não há proteção aqui contra seleção e ataque ao servidor (aliás, aqui você pode escrever o endereço IP do usuário em vez da letra “Y” - para que, por exemplo, um vizinho do escritório não possa pegar um arquivo com um cookie e faça login em seu computador).

Quando postei esse problema da última vez, eles me chutaram na hora, dizendo que tal bloqueio poderia inviabilizar o servidor.

Mas primeiro, sobre o bloqueio de rebote. Banalidades, mas ainda assim. Uma senha de dez caracteres composta por letras e números latinos significa que há muitas opções. Se você adivinhar uma senha 1.000.000 de vezes por segundo, isso levará vários milhares de anos. Mas como essas bobagens são difíceis de lembrar, muitas vezes criamos senhas com palavras significativas. Há alguns anos, descobriu-se que a maioria das senhas pode ser adivinhada usando um dicionário de 10.000 palavras. Certa vez, apareceu na rede um worm (um vírus desses), que invadiu servidores Unix, usando suas falhas de segurança, e pegou senhas de usuários privilegiados usando... o dicionário ortográfico do sistema Unix. Não havia necessidade de carregar nada!

Cada usuário, até que insira o login e a senha corretos, é considerado um hacker malvado. Com o que lidamos quando o usuário digita algo incorretamente?

• esquecimento (para isso, sites decentes possuem um formulário “esqueci a senha” para enviar essa mesma senha para o e-mail informado nas configurações do sistema)
• mimos (“porque eu não me importo”)
• selecionando uma senha usando um dicionário (a probabilidade de uma seleção bem-sucedida é alta, então é necessário fechá-la, principalmente se o site for de natureza comercial)
• Ataque DoS (para não sobrecarregar o servidor, é necessário minimizar as ações que o script irá realizar neste caso)

  Pensei muito em como poderia causar uma sobrecarga no servidor se o mecanismo de proteção fosse baseado em arquivos. Acabou sendo fácil (quanto vai custar é outra questão). Então, digamos que o servidor não será capaz de lidar com isso se o script tentar abrir arquivos para gravação 1000 vezes por segundo e gravar dados neles. Como após 5 tentativas malsucedidas de login, o acesso do usuário será imediatamente negado (sem que nenhum dado seja gravado em um arquivo), você precisa encontrar 200 IPs únicos, dos quais deverá entrar em contato cinco vezes cada. É possível. Penduramos um banner html com cinco tags no scroller do banner:

  

  O usuário faz cinco solicitações instantaneamente; o servidor grava no arquivo cinco vezes (aliás, em alguns navegadores pode aparecer uma janela para inserir seu login e senha). Você pode criar uma página HTML com cinco dessas imagens e inserir a própria página por meio de um iframe no site que você está visitando (por meio de um iframe - para que o campo de referência não seja encontrado. É improvável que o serviço de suporte de um site gratuito a hospedagem lidará com coisas como vasculhar arquivos de log em busca de referenciadores). Os exemplos que dei são, obviamente, rebuscados, mas o próprio facto de se poder tirar partido de tal falha no sistema está comprovado. Aliás, algo semelhante já aconteceu.

  Mas ainda darei esse método - escrevi em vão ou o quê? Aliás, ele pode ser usado sem muito medo para um número limitado de endereços (por exemplo, para a rede local de uma empresa) colocando um arquivo .htaccess no diretório com o seguinte conteúdo:

  Solicitar negar, permitir negar de todos permitir de xxx.xxx.xxx

  E aqui está o código do programa:

  $erros = 0; $fn = "ignorar/". preg_replace("[^\d\.]", "", $REMOTE_ADDR. ".". $HTTP_FORWARDED_FOR); if (é_arquivo($fn)) ( if (filectime($fn)< time()-3600) unlink($fn); else $errors = fread(fopen($fn, "r"), 2); }; if ($errors>5) ( print("Acesso fechado. Volte em uma hora."); exit(); );

  // aqui é estabelecida a conexão com o servidor de banco de dados. para não tocar em vão se o usuário for imediatamente “espancado”.

  $resultado = mysql_query("SELECT * FROM usuário WHERE login="". preg_replace("/[^\w_\-]/", "", $PHP_AUTH_USER). "" AND pass="". md5($PHP_AUTH_PW) . """); if (@mysql_num_rows($result)!=1) ( header("WWW-Authenticate: Basic realm=\"secret area\""); header("HTTP/1.0 401 Unauthorized"); print("Autorização necessária") ; fwrite(fopen($fn, "w"), ++$erros); $usuário_atual = mysql_fetch_array($resultado); mysql_free_result($resultado);

  Porém, é pecado trabalhar com arquivos se houver um banco de dados. Piada. Para autorizações com falha, crie uma tabela:

  CREATE TABLE unauth (nome de usuário VARCHAR(64) NOT NULL, passe VARCHAR(64) NOT NULL, ip VARCHAR(255), logintime TIMESTAMP)

  E ao invés de acessar arquivos, trabalhamos com o banco de dados.

  $errors = @mysql_result(mysql_query("SELECT count(username) as false FROM unauth WHERE logintime>DATE_SUB(NOW(),INTERVAL 1 HOUR) AND ip="$REMOTE_ADDR""),0); if (mysql_error()) morrer(mysql_error()); if ($errors>5) ( print("Acesso fechado. Volte em uma hora."); exit(); ); $resultado = mysql_query("SELECT * FROM usuário WHERE login="". preg_replace("/[^\w_\-]/", "", $PHP_AUTH_USER). "" AND pass="". md5($PHP_AUTH_PW) . """); if (@mysql_num_rows($result)!=1) ( header("WWW-Authenticate: Basic realm=\"secret area\""); header("HTTP/1.0 401 Unauthorized"); print("Autorização necessária") ; mysql_query("INSERT INTO unauth (nome de usuário, senha, ip) VALORES ("$PHP_AUTH_USER", "$PHP_AUTH_PW", "$REMOTE_ADDR $HTTP_X_FORWARDED_FOR")"); $usuário_atual = mysql_fetch_array($resultado); mysql_free_result($resultado);

  Armazenar registros antigos para estatísticas ou não é uma decisão de negócios. Na verdade, eles podem ser excluídos executando a seguinte solicitação antes da autorização:

  DELETE FROM unauth WHERE logintimeDATE_SUB(NOW(), INTERVAL 30 MINUTE)"); if (!mysql_error() && @mysql_num_rows($login_result)==1) ( /* Obtenha uma linha da tabela e crie um hash dos campos obrigatórios. */ $ current_user = mysql_fetch_array($login_result); $hash_to_check =md5($current_user["passwd"]. "Y - para que ninguém adivinhe." $current_user == $HTTP_COOKIE_VARS[$COOKIE_HASH_NAME] ) ( $current_time = time(); /* Atualize o último campo de login e emita um novo cookie */ mysql_query("UPDATE user SET last_log="". date("Y-m-d H:i:s", $current_time). " " WHERE login=". $login""); ]), $current_time + 1800 , $COOKIE_PATH ) else ( /* Se o hash não corresponder, o usuário é redirecionado para a página de login. */ header ("Location: /login.php"); exit; ) elseif (!mysql_error() && @mysql_num_rows ($log_result)!=1) ( header("Local: /login.php"); saída;

  ) senão imprimir (mysql_error()); Claro"S - para que ninguém adivinhe"

  A propósito, sobre o endereço IP. É melhor verificar, mas não o endereço inteiro, mas apenas os dois primeiros (para IP começando com um número menor que 127) ou três (respectivamente, mais de 127) números do endereço. Isso evitará que os usuários de uma conexão discada incorreta e interrompida tenham que fazer login novamente após a perda da conexão e, ao mesmo tempo, não permitirá que um invasor que roubou o cookie faça login. Claro que ele não poderá ligar de volta e fazer login através de outro provedor - o endereço da piscina não é o mesmo, mas isso não é problema nosso (“com esse tempo eles ficam em casa”). O roubo de senhas dentro da empresa também não é problema nosso. Protegemos camaradas curiosos e hackers analfabetos, mas não podemos fazer nada contra Trojans e farejadores que possam ser instalados na vítima.

  É aqui que terminam os “sinos e assobios”. A proteção não pode ser mais confiável. Ninguém irá acessar o arquivo cookie em busca do hash e pegá-lo. Seria mais fácil colocar um sniffer entre o usuário e a interface web e usá-lo para encontrar a senha. Você pode instalar um Trojan que lembrará tudo o que o usuário digitou no teclado, mas isso não é mais problema nosso. Para se proteger contra espionagem de canal, você deve usar conexões SSL ou criptografia de dados.

  Senha da página. Parte 5. Sessões

  Por que escrevi uma nota sobre cookies? “Não entendo por que escrever sobre cookies quando o PHP tem sessões?!” Depois, para que os leitores não tenham uma imagem plana diante dos olhos. Nem todos os lugares possuem a versão 4 do PHP e a versão 3 não é suportada. Além disso, as sessões não são tão necessárias em todos os lugares - com raras exceções, o algoritmo de autorização verifica a exatidão do login/senha e a exatidão dos dados da sessão e, em seguida, retorna o cliente à página de login ou pega uma matriz (ou objeto ) com dados sobre o usuário.

  Os casos em que é necessário trabalhar em sessões não são tão frequentes. Por exemplo, no meu jogo “Monopolist” comecei imediatamente a usar sessões, pois o usuário pode jogar vários jogos e a mesma página na mesma sessão pode conter dados diferentes. Lá é melhor armazenar os dados de um dos jogos em que o usuário participa de uma sessão e criar uma página para alternar entre os jogos.

  Em geral, não estou dizendo que as sessões não devam ser utilizadas. É necessário, mas tudo tem o seu lugar. Voltarei à questão da aplicabilidade de três métodos de autorização - através do cabeçalho 401 ("reino"), cookies ou sessões - mais tarde. Agora vamos falar sobre sessões.

  Sessões em PHP não são na verdade um método de autorização (o conceito em si é incorreto, mas nos fóruns perguntam exatamente “como autorizar um usuário através de sessões?”). O mecanismo de sessão do usuário embutido no PHP apenas identifica esses usuários; a autorização é, novamente, trabalho do seu script.

  Não vou falar muito sobre o mecanismo das sessões - já foi dito. Na sua forma mais simples (ou melhor, na sua forma mais padrão), esse mecanismo funciona assim: o sistema mantém no servidor um arquivo de sessão, que contém suas variáveis. Ao iniciar uma sessão, o usuário recebe um identificador único (normalmente através de um cookie), e ao acessar outras páginas, ele o envia. Quando você inicia o mecanismo de sessão em seu script, o manipulador php verifica se existe um arquivo correspondente ao identificador da sessão de entrada - se existir, o script será capaz de ler os dados do arquivo, caso contrário, uma nova sessão será iniciada e o arquivo será criado. Claro, o nome desta variável é definido nas configurações do php.

  Agora sobre quais funções usamos.

  sessão_start(). Inicia o próprio mecanismo de sessão. O usuário deve ter uma variável e um arquivo correspondente. Se o arquivo não existir, ele será criado e a sessão será iniciada do zero. Se não houver arquivo nem variável, então uma variável é gerada (por exemplo, um cabeçalho com um cookie é enviado) e o arquivo é criado.

  session_register(nome1, nome2, nome3...) . Indicação de quais variáveis ​​lembrar no arquivo ao final do script. Após o usuário navegar para outra página, o mecanismo de sessão poderá ser lançado, e após chamar esta função, as variáveis ​​​​estarão disponíveis.

  session_destroy(). Exclui o arquivo de dados da sessão (ao usar cookies, você deve excluí-los manualmente definindo um cookie vazio: "setcookie(session_name())" ).

  session_set_cookie_params(vida, caminho, domínio) . Definir parâmetros de cookie com um identificador de sessão (por padrão, o cookie é definido na raiz do servidor e por 0 segundos - até que o navegador seja fechado).

  É tudo por agora. Haverá questões separadas sobre as sessões em detalhes. Por enquanto, descreverei o mecanismo de autorização e identificação do usuário por meio de sessões.

  Portanto, temos três arquivos – login, verificação (auth) e saída (logout).

  // elimina todos os caracteres indesejados $login = preg_replace("/[^\w_\.\-]/", "", $HTTP_POST_VARS["login"]); $pass = trim($HTTP_POST_VARS["pass"]); // verificando variáveis ​​if (strlen($login)==0 || strlen($pass)==0) $error = "Digite seu login e senha"; else ( // verificando login e senha $user_result = mysql_query("SELECT * FROM user WHERE login="$login" AND pass="". md5($pass). """); /* se ocorreu um erro no banco de dados (por exemplo, o usuário inseriu uma variável longa na sessão, que o banco de dados não queria digerir) ou mais de uma linha foi exibida, chutamos o usuário */ if (mysql_error()) die(mysql_error()) ; elseif (@mysql_num_rows($user_result) != 1) $error = "Nome de usuário ou senha inválidos."; // se estiver tudo bem, selecione os dados, inicie a sessão else ( $user = mysql_fetch_assoc($user_result); session_set_cookie_params (1800, "/"); session_start() ; // lembre-se das informações do usuário session_register("user"); // e envie-as para algum lugar if (isset($HTTP_POST_VARS["return"])) header("Location: ($HTTP_POST_VARS["return"]) "); else header("Local: /"); exit(); ); ); /* aqui o usuário não está mais autorizado, mas pode enviar um cookie de uma sessão fechada. vamos limpar isso. */ if (isset($HTTP_COOKIE_VARS)) setcookie(session_name()); // a seguir desenhamos a forma, isso não é interessante.

  Este script é um manipulador e um formulário de entrada de dados. Ao receber login e senha, ele os processa e, se estiverem corretos, para de funcionar, direcionando o usuário para a página desejada. Se os dados estiverem incorretos ou faltantes, desenha o formulário.

  /* elimina a variável do usuário para que após desenhar o formulário seja impossível enviar dados em uma pós-requisição. */ unset($usuário); // Sinalizador "erro de sessão" - se estiver habilitado, o trabalho será interrompido. $session_error = falso; // se não houver cookie com o ID da sessão, acione o sinalizador if (!isset($HTTP_COOKIE_VARS)) $session_error = true; // se existir, inicia o mecanismo de sessão e registra a variável $user. else ( session_start(); session_register("user"); /* se por acaso não houver login e senha no array, o trabalho também para (“não sabemos de nada, nós demos para você”) */ if (!isset($user["login"]) || !isset($user["pass"])) $session_error = true ); /* se o usuário conseguiu até agora evitar erros heroicamente, uma verificação é feita através do banco de dados da mesma forma que na entrada. */ if (!$session_error) ( $check_result = mysql_query("SELECT uid FROM usuário WHERE login="($user)" AND pass="($user)""); if (mysql_error() || @mysql_num_rows( $user_result) != 1) $session_error = true ); // se houve algum erro, então if ($session_error) ( // destrói os dados da sessão session_destroy(); // destrói o cookie se houver if (!isset($HTTP_COOKIE_VARS)) setcookie(session_name()," " ,"/"); /* envia o usuário para login, com a possibilidade de retornar ao endereço solicitado */ header("Location: /login.php?return=$REQUEST_URI"); // para de funcionar exit() ; mysql_free_result($check_result);

  O usuário é verificado e no array $user - todos os dados sobre ele, você pode, por exemplo, cumprimentá-lo pelo primeiro nome e patronímico:

  If(isset($HTTP_COOKIE_VARS)) ( // inicia o mecanismo de sessão session_start(); // exclui o arquivo session_destroy(); // exclui o cookie setcookie(session_name()); ); // sai do cabeçalho da página("Location: /login.php");

  Algumas notas: a parte protegida por senha neste exemplo é todo o servidor (por exemplo, service.firm.ru), para fechar o diretório é necessário corrigir os caminhos. Session_name() é usado em vez de PHPSESSID para que o nome do identificador possa ser alterado livremente. Aliás, em um servidor físico você pode criar nomes diferentes para identificadores de sessão - basta colocar o arquivo .htaccess na parte necessária com a linha php_value session.name "ABRACADABRA" .

  
  
  
  

  Se você tiver alguma outra dúvida ou algo não estiver claro - bem-vindo ao nosso

  Coloque uma senha na página

  Este artigo não pretende ser nenhuma revelação; todas essas coisas são bastante óbvias e amplamente conhecidas. Mas tendo recebido recentemente várias perguntas sobre a restrição de acesso a páginas da web, decidi reunir as respostas para elas.

  Portanto, nossa tarefa é definir uma senha para acessar uma determinada página. Vamos começar com o método mais primitivo, por assim dizer, de proteção - algumas linhas de JavaScript. O código é algo parecido.

  Var pass = prompt("Digite a senha:", ""); if (pass == null) window.location = "bad.html"; senão if (pass.toLowerCase() == "senha") window.location = "ok.html"; senão window.location = "bad..js"> não muda nada fundamentalmente.

  Num nível superior existe um sistema semelhante implementado em Java.

  Abaixo está o código-fonte simplificado.

  Importar java.applet.*; importar java.awt.*; importar java.net.*; classe pública Senha estende miniaplicativo ( TextField login, senha; String Login = "login"; String Password = "Senha"; public Password() ( ) public void init() ( Panel panel = new Panel(); panel.setLayout(new GridLayout(2,2)); login = new TextField(20); painel.add(novo rótulo:)); painel.add(novo) Label("Senha:")); new Button("Ok")); public boolean action(Event evt, Object obj) ( if(evt.target instanceof Button) ( String s; if(login.getText().equals(Login) && password.getText() .equals(Senha)) ( s = "http://www.webclub.ru/materials/ pagepsw/ok. html"; ) else ( s = "http://www.webclub.ru/materials/pagepsw/bad .html"; ) try ( getAppletContext().showDocument (novo(s) URL(s)); ) catch(Exception e) ( password.setText(e.toString()); ) return true; return false;

  Ao incluir este miniaplicativo em uma página, você pode obter algo assim:

  Verificação de senha

  Pode ser mais inteligente, criar uma página separada para cada usuário, forçá-lo a ler dados de um arquivo, etc. A desvantagem fundamental é que, uma vez que uma pessoa chega à página que procura, ninguém pode impedi-la de se lembrar desse URL, portanto, esta é uma ferramenta única. Claro, você pode ocultar a página dentro de um quadro para que a URL não apareça na barra de endereço, mas você entende de quem é essa proteção. Novamente, o applet vai inteiramente para o cliente e está, em princípio, totalmente disponível para pesquisa.

  A solução baseada no uso de CGI não apresenta a última desvantagem. Um script Perl simples se parece com isto:

  #!/usr/bin/perl use CGI qw(:standard); $consulta = novo CGI; $ok = "ok.html"; $endereço = "ruim.html"; $entrar = "entrar"; $senha = "senha"; $l = $query->param("login"); $p = $query->param("senha"); if(($p eq $senha) && ($l eq $login)) ( $endereço = $ok; ) imprimir $query->redirect($endereço);

  Exemplo de uso:

  Verificação de senha

  Para lidar com a primeira desvantagem, você pode gerar dinamicamente uma nova página com base naquela escondida em algum lugar dentro, sem fornecer a URL.

  Código modificado:

  #!/usr/bin/perl use CGI qw(:standard); $consulta = novo CGI; $ok = "ok.html"; $endereço = "ruim.html"; $docroot = $ENV("DOCUMENT_ROOT"); $localpath = "/materiais/pagepsw/"; $entrar = "entrar"; $senha = "senha"; $l = $query->param("login"); $p = $query->param("senha"); if(($p eq $senha) && ($l eq $login)) ( $address = $ok; ) print $query->header(); open(FL, $docroot.$localpath.$endereço); while() ( # Aqui você também pode modificar o código HTML instantaneamente # Por quê? Bem, nunca se sabe... :) print $_; )fechar(FL);

  Exemplo de uso:

  Verificação de senha

  Como você pode ver, o URL do arquivo não é mais exibido, embora às custas do SSI, se algo semelhante estiver presente (no entanto, isso pode ser capturado durante a saída e processado manualmente). Mas mesmo aqui permanece a possibilidade teórica de adivinhar a URL, e não devemos esquecer que todos os tipos de imagens incluídas nas páginas podem prestar um péssimo serviço - ao usar caminhos relativos, é claro.

  Por fim, a maneira mais confiável de definir uma senha de acesso é usar ferramentas de servidor – afinal, não é à toa que as pessoas fazem isso. Vou me concentrar em dois: Apache como o mais popular e IIS como também popular :)

  Com o IIS, tudo é bastante simples - a proteção é realizada usando NTFS, o que, é claro, limita um pouco as capacidades dos administradores que não são servidores. A ideia é a seguinte: o usuário IUSR_xxxx, sob cuja conta todos os visitantes do site trabalham por padrão, tem acesso negado ao arquivo/diretório desejado. Depois disso, apenas os usuários para os quais isso está explicitamente especificado em Propriedades->Segurança terão acesso a esses arquivos. É claro que é muito mais conveniente combiná-los em grupos. Existem algumas sutilezas aqui. Em primeiro lugar, os usuários especificados devem receber o direito de Logon local (Políticas->Direitos do Usuário no Gerenciador de Usuários). Em segundo lugar, se você não selecionar o serviço WWW Autenticação básica (Texto não criptografado) nas configurações da WWW, apenas os usuários do Internet Explorer terão acesso. permitido em "A.

  No Apache, tudo é feito de forma um pouco diferente. A proteção é definida no nível do diretório. As diretivas correspondentes podem ser colocadas tanto no arquivo de configuração geral (na seção) quanto nos arquivos .htaccess. O conjunto de diretivas em ambos os casos é o mesmo, e para a maioria das pessoas que alugam espaço para um site/página no servidor de outra pessoa, o segundo método é muito mais relevante. Então, você cria um arquivo .htaccess no diretório ao qual planeja restringir o acesso e, em seguida, insere nele as seguintes diretivas (vou listar as principais):

  Tipo de autorização tipo de controle- Geralmente é usado o básico.

  Autenticação Nome- especifica o nome da área na qual os nomes de usuário e senhas são válidos. Este é o mesmo nome que o navegador mostra na caixa de diálogo de senha. Ao definir um desses nomes para diretórios diferentes, você pode poupar aos usuários o tempo de inserir uma senha extra.

  AuthGroupFile Nome- especifica o nome do arquivo no qual os nomes dos grupos e seus membros são armazenados. Seu formato:
  grupo1: membro1 membro2 ...
  grupo2: membro3 membro4 ...

  AuthUserFile Nome- especifica o nome do arquivo com senhas. Em geral, para gerá-lo você precisa usar o utilitário htpasswd da distribuição Apache. Mas pelo menos para algumas versões do servidor, este formato é assim:
  usuário1: senhahash1
  usuário2: senhahash2

  O Passwordhash pode ser facilmente obtido usando a função Perl padrão:
  $hash=cripta($pass,$sal);
  onde $pass é a senha, $salt é uma string de dois caracteres envolvida na geração do hash.

  Assim é bem possível automatizar o processo de adição de novos usuários, alteração de senhas através de formulários html, etc.

  requer usuário usuário1 usuário2 e requer grupo usuário1 usuário2 permitem que você especifique quais usuários e grupos terão acesso a um determinado diretório.

  require valid-user permite acesso a todos os usuários especificados no arquivo de senha do sistema.

  ... , onde método eu define um método HTTP. Por exemplo, limita o uso de diretivas aninhadas aos casos de uso dos métodos GET e POST (geralmente isso é mais que suficiente). As diretivas podem ser aninhadas: exigir, ordenar, permitir e negar.

  Outras diretivas úteis são negar e permitir - negar e permitir acesso, respectivamente. Aplique algo assim:
  negar de todos
  permitir de 192.168

  Por padrão, todas as negações são executadas primeiro e depois todas as permissões, portanto permitir de todos permitirá o acesso a todos os usuários, independentemente de qualquer negação. A ordem pode ser alterada com a diretiva order: order permitir, negar.

  negar de tudo funciona bem com o segundo método de proteção de páginas via CGI; é esta diretiva que é melhor para cobrir todos os tipos de senhas para livros de visitas, etc.

  Aliás, aqui, de passagem, é demonstrado o tratamento independente de erros: neste caso, código 403, Proibido. Os amados 404, Not Found e 401, Unauthorized são processados ​​de forma semelhante. Para fazer isso, basta adicionar a diretiva ErrorDocument ao .htaccess código de URL:
  Documento de erro 404 /cgi-bin/bad.pl
  Documento de erro 403 /cgi-bin/badaccess.pl
  Documento de erro 401 /cgi-bin/badaccess.pl

  Tudo o que o script faz é gerar uma mensagem de erro usando a variável de ambiente REQUEST_URI, então você pode simplesmente apontar para alguma página adequada.

  Para o exemplo final, usamos um arquivo .htaccess com o seguinte conteúdo:

  AuthType Teste básico de AuthName AuthGroupFile /.../pagepsw/deny/tgroup AuthUserFile /.../pagepsw/deny/tuser requer teste de grupo

  Existe apenas uma linha no arquivo tgroup - teste: teste de login, no arquivo tuser - senhas criptografadas para login (senha) e teste (teste). Observe que ao acessar esta página novamente, o navegador entende que acabou de acessar esta área e não incomoda o usuário com uma solicitação de senha desnecessária.

  Este é, em resumo, o conjunto mínimo de informações necessárias para proteger páginas web. Como mostra a prática, você deve confiar mais ou menos apenas em soluções baseadas nas ferramentas fornecidas pelo servidor (e até que outra falha seja descoberta no servidor), portanto, se possível, é melhor escolhê-las.

  
  

  Um dos principais axiomas da segurança da informação afirma que “o conforto de um sistema é inversamente proporcional à sua segurança”. Isto significa que ao escolher um sistema de segurança, é necessário encontrar o equilíbrio ideal entre a complexidade da segurança e a conveniência da experiência do utilizador.

  
  

  Por outro lado, o desenvolvimento e a implementação da protecção requerem um certo esforço e dinheiro. Portanto, é necessário adotar uma abordagem razoável para projetar a proteção. Simplificando, não há necessidade de criar um sistema de segurança complexo e caro se nada de valor estiver armazenado no site. Nem um único invasor tentará invadir sua página inicial, o site do cartão de visita de uma pequena empresa ou o site de um jardim de infância.

  
  

  Na lição anterior, examinamos a autorização usando um servidor Web (autorização básica). Esta é provavelmente a maneira mais fácil e segura de restringir o acesso aos recursos. No entanto, a manutenção de tal mecanismo é bastante trabalhosa, especialmente com um grande número de utilizadores com direitos diferentes. Além disso, nem todos os servidores permitem autenticação HTTP.

  
  

  Uma alternativa mais popular é a proteção por senha. Seu significado é que o servidor armazena listas de usuários e seus correspondentes logins, senhas e direitos de acesso. Ao acessar o site pela primeira vez, o usuário digita um login/senha e ganha acesso aos recursos. O servidor “lembra” o usuário e não pede senha até que a próxima sessão seja aberta (reinicialização do navegador).

  A organização da proteção por senha recai inteiramente sobre os ombros do programador. O desenvolvedor deve garantir a segurança do armazenamento de listas de usuários, verificação de logins/senhas, salvamento de contextos de segurança e reutilização dos mesmos. O contexto de segurança aqui é entendido como um conjunto de parâmetros que identificam exclusivamente o usuário (no mínimo, é um login, senha e identificador de sessão).

  Considere um exemplo de implementação da proteção por senha mais simples. Vamos criar um arquivo logon.php

  Ao clicar no botão “login”, os dados do formulário serão enviados para o servidor, onde o script verificará o login e senha digitados e se forem iguais a “admin” e “megaPass”, respectivamente, exibirá um mensagem de que o login é permitido. Caso o login ou senha estejam incorretos, o usuário verá uma mensagem de aviso.

  A primeira desvantagem deste script: transmissão de dados usando o método GET. Ao utilizar este método, os dados são transmitidos diretamente no endereço e, portanto, visíveis até a olho nu. Por exemplo, se você digitou o nome de usuário e a senha corretos, verá na barra de endereço

  http://localhost/logon.php?login=admin&passwd=megaPass

  A segunda desvantagem: nomes de usuário e senhas são codificados diretamente no código. Isso significa que para adicionar novos usuários você precisará alterar constantemente o código do arquivo. Imagine o tamanho do arquivo se você tiver pelo menos mil usuários registrados em seu site... As listas de usuários são melhor armazenadas em um arquivo separado, ou melhor ainda, em um banco de dados, porque... É muito mais fácil para um invasor roubar um arquivo do que extrair algo de um banco de dados.

  A terceira desvantagem: os resultados de login do usuário não são lembrados, ou seja, Basta atualizar a página e você será solicitado a inserir sua senha novamente.

  Então, vejamos maneiras de eliminar essas deficiências.

  A maneira mais fácil de ocultar os dados transmitidos é usar o método de transmissão POST. Nesse caso, o próprio navegador (oculto do usuário) transferirá todos os dados necessários para o servidor e só poderá ser interceptado por programas especiais do arsenal de especialistas em TI, programadores ou hackers.

  Conforme mencionado acima, as listas de usuários devem ser armazenadas separadamente. Vamos criar uma tabela no banco de dados de teste:

  CRIAR TABELA `smplusers` (
  `user_id` int (11) NOT NULL auto_increment,
  `nome_usuário` varchar(50) NÃO NULO,
  `user_login` varchar (50) NÃO NULO,
  `user_password` varchar(50) NÃO NULO,
  `reg_date` data e hora NÃO NULO,
  CHAVE PRIMÁRIA (`user_id`)
  )

  e adicione vários registros de usuário a ele:

  INSERIR EM smplUsers
  (nome_do_usuário, login_do_usuário, senha_do_usuário, data_registrada)
  valores
  ("Ivanov I.I.", "ivanov-i-i", "pass1", AGORA()),
  ("Petrov P.P.", "petrovich", "pass2", AGORA()),
  ("Sidorov S.S.", "sidorov", "pass3", AGORA())
  

  Observe que o operador INSERT permite adicionar vários registros à tabela de uma só vez, e os dados são listados em blocos separados por vírgulas.

  Agora vamos alterar o logon.php para que o nome de usuário e a senha sejam verificados corretamente diretamente no banco de dados:

  
  
  
  
  
  
  

  Agora o login e a senha são transmitidos secretamente, sendo muito fácil alterar as credenciais editando a tabela no banco de dados. Resta a última etapa - ensinar o servidor a lembrar o fato do registro. A maneira mais fácil de fazer isso é usando o mecanismo de sessão. Vamos fazer as alterações necessárias:

  
  
  ...

  O servidor agora lembrará cada usuário que efetuou login com sucesso e exibirá uma mensagem de boas-vindas na próxima vez que a página for atualizada.

  Este script é apenas um exemplo de organização da proteção por senha, embora totalmente funcional. Você pode transformá-lo em uma amostra praticamente valiosa adicionando verificação de dados de entrada, funções de criptografia, recuperação de senha, encerramento de sessão, etc.