Em um artigo anterior, sugeri que o leitor saiba como a linguagem de consulta SQL está estruturada em detalhes, bem como o funcionamento do protocolo HTTP. Mas esse geralmente não é o caso. E lembrei-me imediatamente da história descrita em um dos meus livros favoritos, "Mentes Não Confiáveis", de Rob Brotherton. Ele descreve o seguinte experimento. A psicóloga Rebecca Lawson perguntou a um grupo de sujeitos se eles já haviam andado de bicicleta em suas vidas. A maioria respondeu que sim. Ela perguntou ainda se eles sabem como a bicicleta funciona. Já havia menos respostas afirmativas, mas ainda a grande maioria. E então ela sugeriu a seguinte imagem e pediu para complementá-la para que esta bicicleta pudesse andar.
E então a coisa mais interessante aconteceu - mais da metade das pessoas não pôde fazer isso. Essa tarefa enganosamente simples mostra que a maioria das pessoas simplesmente não consegue imaginar como uma bicicleta funciona. Mas o mais interessante é que eles não entendem que não sabem disso, mas começam a entender isso apenas no momento em que precisam demonstrar esse conhecimento.
Com HTTP e SQL, a mesma coisa acontece. 90% dos especialistas em TI escreviam consultas SQL, pelo menos em laboratórios de laboratório em suas instituições de ensino, as pessoas trabalham com HTTP todos os dias como usuários, e os mesmos especialistas de TI de tempos em tempos configuram servidores Web que realmente funcionam com HTTP. Mas quando você precisa responder a uma pergunta específica, um estupor ocorre regularmente.
Um analista de segurança da informação deve conhecer a tecnologia em detalhes, conhecendo as nuances e sutilezas. Se não sabemos como essa ou aquela tecnologia deve funcionar, como podemos descobrir o que há de errado com ela?
Também uma "injeção"
Mencionei que a verificação da entrada deve ocorrer no servidor, mas não no cliente. De tempos em tempos, pode-se encontrar formulários de entrada onde elementos individuais estão inativos. E supõe-se que eles se tornem ativos após certas condições serem atendidas. Ou, por exemplo, o campo de entrada do nome de usuário tem 7 caracteres, limitando assim o comprimento máximo do nome de usuário. Tudo isso é uma prática muito ruim, e eis o motivo: os elementos na página que já foram recebidos podem ser editados arbitrariamente antes de serem enviados, sem nenhum meio técnico especial. No OWASP Mutillidae II, isso pode ser visto no exemplo "Outros"> "Controles de" segurança "do lado do cliente".
Aqui está um formulário nos campos em que você precisa digitar um número aleatório, desta vez é 2056694312. A "dificuldade" aqui é que os campos têm limitações. Há um campo "Somente leitura" onde o número 42 não pode ser substituído, há um campo "Caixa de texto curto" muito curto, onde nosso número simplesmente não pode caber, há um campo "Caixa de texto desativado" desativado que está inativo e assim por diante.
De fato, a tarefa é resolvida de maneira muito simples. No navegador (no meu caso, é o Mozilla Firefox), acesse o console do desenvolvedor (F12) e comece a inspecionar os elementos do formulário.
Por exemplo, um campo somente leitura é assim:
<input HTMLandXSSInjectionPoint="1" type="text" name="readonly_textbox" id="id_readonly_textbox" size="15" maxlength="15" required="required" autofocus="autofocus" readonly="readonly" value="42" />
Exclua readonly = ”readonly” e voila: o formulário é gravável, podemos inserir nosso número.
Nosso valor simplesmente não se encaixa no próximo campo, vejamos este elemento:
<input HTMLandXSSInjectionPoint="1" type="text" name="short_textbox" id="id_short_textbox" size="3" maxlength="3" required="required" />
Aqui notamos maxlength = ”3 ″. Substitua 3 por 333, agora podemos inserir nosso número sem medo de que ele não caiba.
E, a propósito, não se trata apenas de campos de entrada. Da mesma forma, você pode alterar quaisquer elementos, como caixas de seleção. O código da página fica assim:
<input type="checkbox" name="checkbox" id="id_checkbox" value="2056694312" required="required" disabled="disabled" />
Aqui é bastante simples, substituiremos o valor pelo nosso número e agora será enviado quando o usuário clicar no botão.
No total, se você souber como o HTML está estruturado, não será difícil corrigir esse formulário para inserir todos os dados necessários. Basta reler a seção Síndrome da bicicleta =)
Não apenas SQL
A injeção nem sempre é sobre bancos de dados. Em geral, de qualquer formulário que não filtre os dados recebidos, você pode obter algumas informações adicionais. No exemplo "Injeção de log de aplicativo"> "Pesquisa de DNS", existe um formulário conveniente para consultas de DNS:
De fato, se você digitar o endereço, por exemplo, google.com, obteremos todas as informações necessárias:
No entanto, a vulnerabilidade é que, além do primeiro comando válido, podemos inserir outra coisa. Por exemplo, especifique:
google.com && dir
e agora a saída do comando é muito mais interessante:
Fizemos uma solicitação ao servidor DNS, mas, além disso, executamos o comando dir e analisamos o que estava na pasta com o nosso site. Não é difícil, combinando comandos diferentes, andar pelo disco rígido do servidor da web e procurar o que há de ruim.
Da próxima vez, analisaremos mais exemplos e também veremos como você pode automatizar seu trabalho.
Leia o blog do autor
neste link .