Mesmo que você tenha seguido vagamente os eventos dos grupos de hackers Anonymous e LulzSec, você provavelmente já ouviu falar sobre sites e serviços sendo invadidos, como os famosos hacks da Sony. Alguma vez você já se perguntou como eles fazem isso?

Existem várias ferramentas e técnicas que esses grupos usam, e embora não estejamos tentando te dar um manual para fazer isso, é útil entender o que está acontecendo. Dois dos ataques que você ouviu consistentemente sobre eles usando “Negação de serviço (distribuída)” (DDoS) e “SQL Injections” (SQLI). Veja como eles funcionam.

Imagem por xkcd

Ataque de negação de serviço

O que é?

Uma “negação de serviço” (às vezes chamada de “negação de serviço distribuída” ou DDoS) O ataque ocorre quando um sistema, neste caso um servidor da Web, recebe tantas solicitações ao mesmo tempo que os recursos do servidor estão sobrecarregados, o sistema simplesmente é bloqueado e desligado. A meta e o resultado de um ataque DDoS bem-sucedido é que os sites no servidor de destino não estão disponíveis para legitimar solicitações de tráfego.

Como funciona?

A logística de um ataque DDoS pode ser melhor explicada por um exemplo. > Imagine que um milhão de pessoas (os atacantes) se juntam com o objetivo de prejudicar os negócios da Empresa X derrubando o seu call center. Os atacantes coordenam para que, na terça-feira, às 9 horas, todos eles liguem para o número de telefone da empresa X. O mais provável é que o sistema telefônico da Empresa X não consiga lidar com um milhão de chamadas de uma só vez, então todas as linhas de entrada serão amarradas pelos atacantes. O resultado é que chamadas de clientes legítimas (ou seja, aquelas que não são os invasores) não passam porque o sistema de telefonia está preso ao tratamento das chamadas dos invasores. Então, em essência, a Empresa X está potencialmente perdendo negócios devido a solicitações legítimas não serem atendidas.

Um ataque DDoS em um servidor da Web funciona exatamente da mesma maneira. Como praticamente não há como saber qual tráfego é originado de solicitações legítimas vs. invasores até que o servidor da Web esteja processando a solicitação, esse tipo de ataque é normalmente muito eficaz.

Execução do ataque

Devido à “bruta forçar ”a natureza de um ataque DDoS, você precisa ter muitos computadores todos coordenados para atacar ao mesmo tempo. Revisitando o nosso exemplo de call center, isso exigiria que todos os invasores saibam ligar às 9h e realmente liguem naquele momento. Embora este princípio certamente funcione quando se trata de atacar um servidor web, torna-se significativamente mais fácil quando computadores zumbis, em vez de computadores tripulados, são utilizados.

Como você provavelmente sabe, existem muitas variantes de malware e trojans que , uma vez no seu sistema, fica dormente e ocasionalmente “telefona para casa” para obter instruções. Uma dessas instruções poderia, por exemplo, enviar solicitações repetidas para o servidor da Web da Empresa X às 9h. Assim, com uma única atualização para o local de origem do respectivo malware, um único invasor pode coordenar instantaneamente centenas de milhares de computadores comprometidos para executar um ataque DDoS em massa.

A beleza de utilizar computadores zumbis não é apenas sua eficácia, mas também em seu anonimato, já que o invasor não precisa realmente usar seu computador para executar o ataque

SQL Injection Attack

O que é?

Um ataque “SQL injection” (SQLI) é um exploração que tira proveito de técnicas de desenvolvimento da Web insatisfatórias e, normalmente combinadas com a segurança de banco de dados com falhas. O resultado de um ataque bem-sucedido pode variar de representar uma conta de usuário a um comprometimento completo do respectivo banco de dados ou servidor. Ao contrário de um ataque DDoS, um ataque SQLI é completamente e facilmente evitável se um aplicativo da Web for adequadamente programado

Executando o ataque

Sempre que você fizer login em um site e digitar seu nome de usuário e senha, para testar seu credenciais o aplicativo da Web pode executar uma consulta como a seguir:

SELECT UserID FROM Usuários WHERE UserName = "myuser" AND Password = "mypass";

Nota: valores de string em uma consulta SQL devem ser colocados entre aspas simples, e é por isso que eles aparecem em torno dos valores inseridos pelo usuário.

Assim, a combinação do nome de usuário (myuser) e senha (mypass) deve corresponder a uma entrada Tabela de usuários para que um UserID seja retornado. Se não houver correspondência, nenhum UserID será retornado, portanto, as credenciais de login serão inválidas. Embora uma implementação específica possa diferir, a mecânica é bastante padrão.

Agora, vamos examinar uma consulta de autenticação de modelo que podemos substituir os valores inseridos pelo usuário no formulário da Web:

SELECT UserID FROM Usuários WHERE UserName = " [user] "AND Password =" [pass] "

À primeira vista, isso pode parecer um passo direto e lógico para validar facilmente os usuários, no entanto, se uma substituição simples dos valores inseridos pelo usuário for executada neste modelo, é suscetível a um ataque de SQLI.

Por exemplo, suponha que “myuser'-” seja inserido no campo de nome de usuário e “wrongpass” seja inserido na senha. Usando substituição simples em nossa consulta de modelo, obteríamos isso:

SELECT UserID FROM Usuários WHERE UserName = "myuser" - 'AND Password = "wrongpass"

Uma chave para essa declaração é a inclusão dos dois traços

(-). Este é o token de comentário inicial para instruções SQL, portanto, qualquer coisa que apareça após os dois traços (inclusive) será ignorada. Essencialmente, a consulta acima é executada pelo banco de dados como:SELECT UserID FROM Usuários WHERE UserName = "myuser"

A omissão gritante aqui é a falta da verificação de senha. Ao incluir os dois traços como parte do campo do usuário, ignoramos completamente a condição de verificação de senha e conseguimos fazer o login como "myuser" sem saber a respectiva senha. Esse ato de manipular a consulta para produzir resultados não intencionais é um ataque de injeção de SQL.

Quais danos podem ser causados?

Um ataque de injeção SQL é causado por codificação de aplicativo negligente e irresponsável e é completamente evitável (o que abordaremos por um momento), no entanto, a extensão do dano que pode ser feito depende da configuração do banco de dados. Para que um aplicativo da Web se comunique com o banco de dados de back-end, o aplicativo deve fornecer um login ao banco de dados (observe que isso é diferente de um login de usuário no próprio site). Dependendo das permissões que o aplicativo da Web requer, essa conta do banco de dados pode exigir qualquer coisa, desde a permissão de leitura / gravação em tabelas existentes, até o acesso total ao banco de dados. Se isso não estiver claro agora, alguns exemplos devem ajudar a fornecer alguma clareza.

Com base no exemplo acima, você pode ver isso digitando, por exemplo,

"youruser '-", "admin'- - "ou qualquer outro nome de usuário, podemos instantaneamente acessar o site como esse usuário sem saber a senha. Uma vez que estamos no sistema, não sabemos que não somos realmente aquele usuário, então temos acesso total à respectiva conta. As permissões de banco de dados não fornecerão uma rede de segurança para isso, porque, normalmente, um site deve ter pelo menos acesso de leitura / gravação ao seu respectivo banco de dados. Agora vamos supor que o site tenha controle total de seu respectivo banco de dados para excluir registros, adicionar / remover tabelas, adicionar novas contas de segurança, etc. É importante observar que alguns aplicativos da Web podem precisar desse tipo de permissão, portanto, não é automaticamente uma coisa ruim que o controle total seja concedido.Para ilustrar o dano que pode ser feito nessa situação, usaremos o exemplo fornecido na história em quadrinhos acima, digitando o seguinte no campo de nome de usuário:

"Robert '; DROP TABLE Users; -".

Depois substituição simples a consulta de autenticação se torna:SELECT UserID FROM Usuários WHERE UserName = "Robert"; DROP TABLE Usuários; - 'AND Password = "wrongpass"Nota: o ponto-e-vírgula está em uma consulta SQL é usado para significar o final de uma instrução específica e o início de uma nova instrução.

o banco de dados como:

SELECT UserID FROM Usuários WHERE UserName = "Robert"

DROP TABLE Usuários

Então, assim, usamos um ataque SQLI para excluir toda a tabela Users.

Naturalmente, muito pior pode ser feito pois, dependendo das permissões SQL permitidas, o invasor pode alterar valores, despejar tabelas (ou o próprio banco de dados inteiro) em um arquivo de texto, criar novas contas de login ou até mesmo seqüestrar toda a instalação do banco de dados. > Prevenindo um ataque de injeção de SQL

Como mencionamos várias vezes anteriormente, um ataque de injeção de SQL é facilmente evitável. Uma das regras principais do desenvolvimento web é que você nunca confia cegamente na entrada do usuário como fizemos quando fizemos uma substituição simples em nossa consulta de modelo acima

Um ataque SQLI é facilmente frustrado pelo que é chamado de saneamento (ou escape) de suas entradas. O processo de higienização é realmente bastante trivial, pois tudo o que ele faz essencialmente é manipular qualquer caractere de aspas simples embutidas (') apropriadamente, de forma que elas não possam ser usadas para encerrar prematuramente uma string dentro de uma instrução SQL.

Por exemplo, se você quiser lookup “O'neil” em um banco de dados, você não poderia usar a substituição simples porque a aspa simples após o O causaria o fim prematuro da string. Em vez disso, você limpa usando o caractere de escape do respectivo banco de dados. Vamos supor que o caractere de escape para uma aspa simples embutida esteja precedendo cada aspas com um símbolo . Então, "O'Neal" seria higienizado como "O 'neil".

Esse simples ato de saneamento praticamente impede um ataque de SQLI. Para ilustrar, vamos revisitar nossos exemplos anteriores e ver as consultas resultantes quando a entrada do usuário for desinfetada

myuser '-

/

wrongpass

: SELECT ID do usuário FROM Usuários WHERE UserName = " myuser "- 'AND Password =" wrongpass " Como a aspa simples após myuser é de escape (significando que é considerada parte do valor de destino), o banco de dados literalmente procurará pelo UserName de " myuser " - ".

Além disso, como os traços são incluídos no valor da string e não na própria instrução SQL, eles serão considerados parte do valor de destino em vez de serem interpretados como um comentário SQL.

Robert '; DROP TABLE Usuários; -/wrongpass

: SELECT Usuario FROM Usuários WHERE UserName = "Robert "; DROP TABLE Usuários; - 'AND Password = "wrongpass" Simplesmente escapando da aspas simples depois de Robert, tanto o ponto e vírgula quanto os traços estão contidos na string de pesquisa UserName para que o banco de dados procure literalmente por "Robert' ; DROP TABLE Usuários; - "

em vez de executar a exclusão da tabela.

Em ResumoEnquanto os ataques da Web evoluem e se tornam mais sofisticados ou focalizam um ponto de entrada diferente, é importante lembrar-se de proteger contra ataques testados e verdadeiros que foram a inspiração de várias “ferramentas de hacker” disponíveis gratuitamente para serem exploradas.Certos tipos de ataques, como o DDoS, não podem ser facilmente evitados, enquanto outros, como o SQLI, podem. No entanto, os danos que podem ser causados ​​por esses tipos de ataques podem variar de inconvenientes a catastróficos, dependendo das precauções tomadas.

Como transferir arquivos de um dispositivo Android para o seu Mac

Se você usa um Mac quase exclusivamente, mas ainda é um Android, pode gerenciar o armazenamento do dispositivo usando um prático aplicativo gratuito chamado Android File Transfer. Ao contrário do Windows, você não pode simplesmente conectar seu dispositivo Android ao seu Mac e acessar seu sistema de arquivos.

(how-to)

Compartilhe benefícios da Amazon Prime com amigos e familiares

O Amazon Prime é um desses recursos incrivelmente úteis da Amazon que facilitam a compra de itens do site. Eu percebi depois de usar a Amazon durante anos para comprar coisas que eu iria recuperar o custo de US $ 99 em nenhum momento. De todas as coisas que eu compro, 80% é encomendado online e 80% disso é da Amazon. A

(How-to)