Segurança de rede | Análise de caso de entrada de teste de penetração, desde a entrada básica zero até o domínio - métodos de detecção comuns para penetração rápida nas páginas da caixa de login

Índice

introdução

1. Senha fraca

2. Desvio de senha universal

editar

3. Ignorar autenticação de login

3.1. Configuração incorreta do terminal de atualização de token

3.2. Configuração incorreta do sso

 3.3. Problema de acesso ao caso do CMS

3.4. Erro ao analisar o token JWT

3.5. Modificação violenta da autenticação

4. O código gráfico de verificação não é inválido

5. O código de verificação por SMS não é inválido

6. Ataque de SMS

7. Ataque reflexivo de script cross-site

8. Injeção de SQL

9. Qualquer modificação/redefinição de senha do usuário

10. Vazamento de informações confidenciais

11. Passagem de diretório

12. Brechas na estrutura


introdução

Hoje, gostaria de compartilhar com vocês os métodos de infiltração comumente usados ​​na página de login do plano de fundo do site, para que todos possam prestar mais atenção à defesa em várias conveniências ao manter o site diariamente.

 

1. Senha fraca

Método de teste:
você pode testar manualmente algumas senhas fracas de alta frequência, como as seguintes, 2. De acordo com os componentes de terceiros usados ​​pelo site, procure senhas fracas específicas ou senhas padrão para fazer login. Ou vá diretamente para a BP. Leva apenas 3S para quebrar uma senha digital pura de 6 dígitos usando o Poly.

admin:123456
admin:admin
admin:admin@123
admin:12345
test:test

Em 2022, as 20 principais classificações de senhas fracas divulgadas pelas estatísticas do departamento de segurança:

2. Desvio de senha universal

Métodos de teste:

(1) 用户名输入: ‘ or 1=1 or ‘  密码:任意
(2)Admin’ - -(或‘ or 1=1 or ‘ - -)(admin or 1=1 --) (MS SQL)(直接输入用户名,不进行密码验证)
(3)用户名输入:admin   密码输入:’ or  ‘1’=’1 也可以
(4) 用户名输入:admin' or 'a'='a    密码输入:任意
(5) 用户名输入:‘ or 1=1 - -
(6) 用户名输入:admin‘ or 1=1 - -  密码输入:任意
(7) 用户名输入:1'or'1'='1'or'1'='1   密码输入:任意

 asp aspx senha universal
  1: "or"a"="a
   2: ')or('a'='a
   3: or 1=1--
   4: 'or 1=1--
   5: a'or' 1 =1--
   6: "ou 1=1--
   7: 'ou'a'='a
   8: "ou"="a'='a
   9: 'ou''='
   10: 'ou'=' ou'
   11: 1 ou '1'='1'=1
   12: 1 ou '1'='1' ou 1=1
   13: 'OR 1=1%00
   14: "ou 1=1%00
   15: 'xor
   16: nova senha de login universal
   nome de usuário' UNION Selecione 1,1,1 FROM admin Where ''=' (substitua o nome da tabela admin)
   password 1
   Username=-1%cf' union selecione 1,1,1 como senha, 1 ,1,1 %23
   Senha=1
   17..admin' ou 'a'='a Senha é opcional


   PHP master password
   'or'='or'
   'or 1=1/* Tipo de caractere GPC pode ser usado estando ativado ou não
   User: something
   Pass: ' OR '1'='1

   jsp master password
   1'or'1 '='1
   admin' OR 1=1/*
   Nome do usuário: admin só está disponível quando este usuário existe no sistema
   Senha: 1'or'1'='1

 

 

3. Ignorar autenticação de login

Métodos de teste:

1)直接访问内部URL。使用扫描工具找到含有admin、manager、administrator、login等词语的路径,尝试使用普通的登录用户访问这些URL。从而获得管理员的权限。
2)修改参数绕过认证。应用程序可能会会使用一个参数或一个隐藏的域表示一个用户是否经过验证了,通过修改这些参数,从而被认为是已经认证过的用户。例如:http://www.xxx.xom/userinfo.jsp?authenticated=no,通过修改authenticated参数为yes,http://www.xxx.xom/userinfo.jsp?authenticated=yes,然后就可以通过认证,直接访问内部页面。
3)可猜测的SessionID。利用规律,猜测到一个有效的SessionID,然后通过修改请求中的SessionID为一个预测到的有效的SessionID,从而冒充会话的真正拥有着,绕过认证环节。
4)CSRF。利用CSRF漏洞在用户不知情的情况下,利用用户的会话进行敏感操作,从而绕过认证。
5)前端验证绕过:修改返回码,一般可以尝试true、success、200、0、1等

3.1. Configuração incorreta do terminal de atualização de token

Nesse caso, quando um usuário efetua login no aplicativo com credenciais válidas, um token de autenticação é criado para autenticação. E esse token de autenticação expira após algum tempo. Um token de autenticação válido aparece no pacote de retorno endpoint/refresh/tokenlogin enviando uma solicitação ao servidor com parâmetros  antes de expirar  .username

3.2. Configuração incorreta do sso

Com a diversidade de plataformas e a melhoria contínua das necessidades do usuário, a fim de facilitar o login dos usuários em vários aplicativos e sites por meio de autenticação de usuário única, a maioria das plataformas usa sistemas SSO. Mas simplesmente usar o SSO não protege automaticamente o sistema: a configuração do SSO também deve ser segura.

Aqui, um aplicativo é autenticado usando o sistema Microsoft SSO. Ao visualizar internal.test.coma URL, o navegador é redirecionado para o sistema de logon único:

 3.3. Problema de acesso ao caso do CMS

CMSs como WordPress, Drupal e Hubspot também precisam ser configurados com segurança para evitar tais vulnerabilidades.

Aqui está um exemplo de Liferay, que também é baseado em um encontro por coincidência. O aplicativo possui uma página de login que pode ser acessada sem autenticação.

O Liferay usa um portlet como sso para o aplicativo, que possui um parâmetro no número id p _ p _ id. Para portlets, o portlet de login pode ser acessado alterando o parâmetro para um valor de 58. Em uma página de login normal, apenas a página de login é acessível. No entanto, acessando o portlet diretamente, é possível acessar Create Accounta função, que então permite self-registrationque a função acesse o conteúdo em segundo plano sem exigir autorização.

 

3.4. Erro ao analisar o token JWT

O token JWT ou JSON Web Token é amplamente utilizado na Web. No entanto, embora tenham um mecanismo de segurança por padrão, que é a chave, não é certo se o mecanismo de resolução do servidor back-end é seguro o suficiente.

Havia um site que estava usando JWT e, quando acessado diretamente, o aplicativo redirecionava o usuário para Microsoft SSO a página da web.

No entanto, alguns arquivos JS podem ser acessados ​​sem autenticação. Durante os testes foi constatado que a aplicação utiliza tokens JWT que são enviados pelo sistema após um login seguro Microsoft SSO. No mecanismo de back-end, havia uma configuração incorreta de segurança que não verificava se o token JWT foi gerado para um aplicativo específico - em vez disso, aceitava qualquer token JWT com uma assinatura válida. Aqui está um exemplo usando um token JWT do site da Microsoft:

 

3.5. Modificação violenta da autenticação

Nesse caso, uma solicitação XML codificada em base64 é enviada ao back-end para validação. No mecanismo de login, ele envia o nome de usuário e a senha separadamente. O valor no parâmetro Scode é o valor md5 da senha. . Há outro sinalizador interessante na solicitação: scode tem valor 2.

 Descobriu-se que a autenticação poderia ser ignorada simplesmente fornecendo um nome de usuário e uma senha vazia.

 

4. O código gráfico de verificação não é inválido

Métodos de teste:

输入用户名、密码、验证码后,点击登陆按钮同时将数据包使用burpsuite进行拦截,并使用Repeater模块或Intruder模块进行数据重放,重新发送五次观察页面变化,是否会提示验证码输入错误等信息

5. O código de verificação por SMS não é inválido

Métodos de teste:

1)请求发送短信,填写任意验证码,然后提交其他操作请求,将验证码参数置空或删除,测试是否可绕过检测;
2)尝试特权验证码,如000000、111111等;
3)同一个短信验证码是否能使用多次;

6. Ataque de SMS

Métodos de teste:

1)手工找到有关网站注册页面,认证页面,是否具有短信发送页面,如果有,则进行下一步。
2)通过利用burp或者其它抓包截断工具,抓取发送验证码的数据包,并且进行重放攻击,查看手机是否在短时间内连续收到10条以上短信,如果收到大量短信,则说明存在该漏洞。

 

 

7. Ataque reflexivo de script cross-site

Métodos de teste:

1、GET方式跨站脚本:
在输入的参数后逐条添加以下语句,以第一条为例,输入http://www.exmaple.com/page.xxx?name=
文本输入框:需要对页面上所有可以提交参数的地方进行测试。具体跨站脚本的测试语句根据实际情况的不同而不同,可自行构造。
2、POST方式
例如:抓包对输入的参数进行构造语句触发XSS

8. Injeção de SQL

Métodos de teste:

1)通过web漏洞扫描工具进行对网站爬虫后得到的所有链接进行检测,或者手工判断是否存在注入点,一旦确认存在漏洞,可利用自动化工具sqlmap去尝试注入。几种常见的判断方法:
a、数字型。
http://host/test.php?id=100 and 1=1 返回成功
http://host/test.php?id=100 and 1=2 返回失败
b、字符型。
http://host/test.php?name=rainman ’ and ‘1’=‘1 返回成功
http://host/test.php?name=rainman ’ and ‘1’=‘2 返回失败
c、搜索型。
搜索型注入:简单的判断搜索型注入漏洞是否存在的办法是:
先搜索(’),如果出错,说明90%存在这个漏洞。
然后搜索(%),如果正常返回,说明95%有洞了。
然后再搜索一个关键字,比如(2006)吧,正常返回所有2006相关的信息。
再搜索(2006%‘and 1=1 and ‘%’=’)和(2006%‘and 1=2 and ‘%’=’)

Ou digite diretamente o nome de usuário na caixa de login e digite 'para ver se um erro de banco de dados é relatado

9. Qualquer modificação/redefinição de senha do usuário

Método de teste:
O procedimento para modificação de senha geralmente é primeiro verificar se a senha original do usuário está correta e, em seguida, solicitar que o usuário insira uma nova senha. Existem aproximadamente três maneiras de contornar o mecanismo de modificação de senha:

1)如果输入新密码的接口可以直接访问,那么在未知原始密码的的情况下即可直接修改密码,通常知道了他人的用户名即可任意修改他人的密码。
2)如果系统未校验修改密码的用户身份,那么在提交修改密码请求时,攻击者通过输入密码,将用户名或者用户ID修改为其他人的,即可成功修改他人的密码。
3)当修改密码时系统需要电子邮件或者手机短信确认,而应用程序未校验用户输入的邮箱和手机号,那么攻击者通过填写自己的邮箱或手机号接收修改密码的链接和验证码,以此修改他人的密码。

10. Vazamento de informações confidenciais

Métodos de teste:

1)如果比较有耐心的话可以找一下页面源码、JS文件,全局搜索password,userlogin等一些敏感词等可能存在意想不到的收获
2)查找URL信息是为了找到账号密码验证成功后跳转的URL地址,然后尝试访问此地址,看是否出现未授权访问漏洞
此处已显示账号密码验证成功后的跳转地址,直接访问此地址看是否可以未授权访问。

11. Passagem de diretório

Métodos de teste:

可以利用web漏洞扫描器扫描web应用进行检测,也可通过搜索,网站标题包含“index of”关键词的网站进行访问。

12. Brechas na estrutura

As vulnerabilidades comuns do framework são as seguintes: Não vou explicá-las uma a uma aqui.

Spring框架漏洞
Struts2框架漏洞
ThinkPHP 框架漏洞
shiro框架漏洞

Acho que você gosta

Origin blog.csdn.net/qq_22903531/article/details/131329832
Recomendado
Clasificación