GET ou POST é mais seguro que o outro?

282

Ao comparar um HTTP GET com um HTTP POST, quais são as diferenças de uma perspectiva de segurança? Uma das opções é inerentemente mais segura que a outra? Se sim, por quê?

Sei que o POST não expõe informações na URL, mas há algum valor real nisso ou é apenas segurança através da obscuridade? Existe alguma razão para eu preferir o POST quando a segurança é uma preocupação?

Editar: em
HTTPS, os dados do POST são codificados, mas os URLs podem ser detectados por terceiros? Além disso, estou lidando com JSP; ao usar JSP ou uma estrutura semelhante, seria justo dizer que a melhor prática é evitar colocar dados confidenciais no POST ou GET completamente e usar o código do lado do servidor para manipular informações confidenciais?

James McMahon
fonte
1
Existe uma boa entrada de blog sobre isso no blog de Jeff, Coding Horror: Forges de solicitação entre sites e você .
fhe 13/10/08
Você não usaria o POST para a maioria das coisas. Por exemplo, para uma API, suponha que você precisava OBTER dados de um banco de dados, mas antes que o servidor retorne dados, você precisaria ser autenticado primeiro? Usando o post, você simplesmente passaria o ID da sessão + todos os parâmetros necessários para a solicitação. Se você usou um requisito GET para isso, seu ID da sessão pode ser facilmente encontrado no histórico do navegador ou em algum lugar no meio.
James111
Lembro-me dessa discussão antes da guerra (mais ou menos 99 ') quando https não era predominante.
precisa saber é o seguinte
@DavidTonhofer, a que guerra você está se referindo? A guerra dos navegadores?
DeltaFlyer 09/11/19
@DeltaFlyer Não, a Forever War on Stuff, também conhecida como GWOT. O que nos fizemos.
David Tonhofer

Respostas:

206

Quanto à segurança, eles são inerentemente iguais. Embora seja verdade que o POST não expõe informações via URL, ele expõe tantas informações quanto um GET na comunicação de rede real entre o cliente e o servidor. Se você precisar passar informações confidenciais, sua primeira linha de defesa seria passá-las usando HTTP Seguro.

As postagens GET ou string de consulta são realmente boas para as informações necessárias para marcar um item em particular ou para ajudar na otimização do mecanismo de pesquisa e na indexação de itens.

O POST é adequado para formulários padrão usados ​​para enviar dados únicos. Eu não usaria GET para postar formulários reais, a menos que talvez em um formulário de pesquisa em que você queira permitir que o usuário salve a consulta em um marcador ou algo nesse sentido.

stephenbayer
fonte
5
Com a ressalva de que, para um GET, o URL mostrado na barra de localização pode expor dados que seriam ocultos em um POST.
tvanfosson 13/10/08
93
Ele fica escondido apenas no mais ingênuo senso
davetron5000
7
verdade, mas você também pode dizer que o teclado é inseguro porque alguém pode estar olhando por cima do seu ombro ao digitar sua senha. Há muito pouca diferença entre segurança através da obscuridade e nenhuma segurança.
21135 stephenbayer
65
A visibilidade (e o cache) das strings de consulta na URL e, portanto, a caixa de endereço é claramente menos segura. Não existe segurança absoluta, portanto os graus de segurança são relevantes.
pbreitenbach
6
fica exposto mesmo se você usar uma postagem. no seu caso, a postagem seria um pouco mais segura. Mas, falando sério ... Eu posso alterar as variáveis ​​de postagem o dia inteiro, tão fácil quanto obter variáveis. Os cookies podem até ser visualizados e modificados. Nunca confie nas informações que o site está enviando de qualquer forma ou formato. Quanto mais segurança você precisar, mais métodos de verificação deverá ter.
21135 stephenbayer
428

A solicitação GET é marginalmente menos segura que a solicitação POST. Nenhum dos dois oferece "segurança" verdadeira por si só; o uso de solicitações POST não tornará magicamente seu site seguro contra ataques maliciosos em uma quantidade perceptível. No entanto, o uso de solicitações GET pode tornar um aplicativo seguro caso contrário.

O mantra que você "não deve usar solicitações GET para fazer alterações" ainda é muito válido, mas isso tem pouco a ver com códigos maliciosos comportamento . Os formulários de login são os mais sensíveis a serem enviados usando o tipo de solicitação errado.

Aranhas de pesquisa e aceleradores da Web

Essa é a verdadeira razão pela qual você deve usar solicitações POST para alterar dados. As aranhas de busca seguirão todos os links do seu site, mas não enviarão formulários aleatórios que encontrarem.

Os aceleradores da Web são piores que os spiders de pesquisa, porque são executados na máquina do cliente e "clicam" em todos os links no contexto do usuário conectado . Assim, um aplicativo que usa uma solicitação GET para excluir itens, mesmo que exija um administrador, obedecerá com satisfação às ordens do acelerador da web (não malicioso!) E excluirá tudo o que vê .

Vice-ataque confuso

Um ataque de deputado confuso (em que o deputado é o navegador) é possível, independentemente de você usar uma solicitação GET ou POST .

Em sites controlados por invasores, GET e POST são igualmente fáceis de enviar sem a interação do usuário .

O único cenário em que o POST é um pouco menos suscetível é que muitos sites que não estão sob o controle do invasor (por exemplo, um fórum de terceiros) permitem incorporar imagens arbitrárias (permitindo que o invasor injete uma solicitação GET arbitrária), mas evitam todas maneiras de injetar uma solicitação POST arbitrária, seja automática ou manual.

Pode-se argumentar que os aceleradores da Web são um exemplo de ataque confuso, mas isso é apenas uma questão de definição. De qualquer forma, um invasor mal-intencionado não tem controle sobre isso; portanto, dificilmente é um ataque , mesmo que o deputado seja confuso.

Logs de proxy

É provável que os servidores proxy registrem URLs GET na sua totalidade, sem retirar a string de consulta. Os parâmetros de solicitação POST normalmente não são registrados. É improvável que os cookies sejam registrados nos dois casos. (exemplo)

Este é um argumento muito fraco a favor do POST. Em primeiro lugar, o tráfego não criptografado pode ser totalmente registrado; um proxy malicioso já tem tudo o que precisa. Em segundo lugar, os parâmetros de solicitação são de uso limitado para um invasor: o que eles realmente precisam são os cookies; portanto, se a única coisa que eles têm são logs de proxy, é improvável que eles consigam atacar um URL GET ou POST.

Há uma exceção para solicitações de login: elas tendem a conter a senha do usuário. Salvar isso no log do proxy abre um vetor de ataque ausente no caso do POST. No entanto, o login através de HTTP simples é inerentemente inseguro de qualquer maneira.

Cache de proxy

Os proxies de armazenamento em cache podem reter respostas GET, mas não respostas POST. Dito isto, as respostas GET podem ser tornadas não armazenáveis ​​em cache com menos esforço do que converter a URL em um manipulador POST.

"Referenciador" HTTP

Se o usuário navegar para um site de terceiros a partir da página veiculada em resposta a uma solicitação GET, esse site de terceiros verá todos os parâmetros da solicitação GET.

Pertence à categoria "revela parâmetros de solicitação a terceiros", cuja gravidade depende do que está presente nesses parâmetros. As solicitações POST são naturalmente imunes a isso, no entanto, para explorar a solicitação GET, um hacker precisaria inserir um link para seu próprio site na resposta do servidor.

Histórico do navegador

Isso é muito semelhante ao argumento "logs de proxy": as solicitações GET são armazenadas no histórico do navegador, juntamente com seus parâmetros. O invasor pode obtê-los facilmente se tiver acesso físico à máquina.

Ação de atualização do navegador

O navegador tentará novamente uma solicitação GET assim que o usuário clicar em "atualizar". Isso pode ser feito ao restaurar as guias após o desligamento. Qualquer ação (por exemplo, um pagamento) será repetida sem aviso prévio.

O navegador não tentará novamente uma solicitação POST sem um aviso.

Esse é um bom motivo para usar apenas solicitações POST para alterar dados, mas não tem nada a ver com comportamento malicioso e, portanto, com segurança.

Então, o que eu deveria fazer?

  • Use apenas solicitações POST para alterar dados, principalmente por motivos não relacionados à segurança.
  • Use apenas solicitações POST para formulários de login; fazer o contrário introduz vetores de ataque.
  • Se o seu site realiza operações confidenciais, você realmente precisa de alguém que saiba o que está fazendo, porque isso não pode ser coberto em uma única resposta. Você precisa usar HTTPS, HSTS, CSP, mitigar injeção SQL, injeção de script (XSS) , CSRF e um bilhão de outras coisas que podem ser específicas para sua plataforma (como a vulnerabilidade de atribuição em massa em várias estruturas: ASP.NET MVC , Ruby on Rails , etc.). Não existe nada que faça a diferença entre "seguro" (não explorável) e "não seguro".

No HTTPS, os dados do POST são codificados, mas os URLs podem ser detectados por terceiros?

Não, eles não podem ser cheirados. Mas os URLs serão armazenados no histórico do navegador.

Seria justo dizer que a melhor prática é evitar a possível colocação de dados confidenciais no POST ou GET e usar o código do servidor para manipular informações confidenciais?

Depende de quão sensível é, ou mais especificamente, de que maneira. Obviamente, o cliente verá. Qualquer pessoa com acesso físico ao computador do cliente o verá. O cliente pode falsificá-lo ao enviá-lo de volta para você. Se isso for importante, mantenha os dados confidenciais no servidor e não deixe que eles saiam.

Roman Starkov
fonte
29
Portanto, o CSRF é o mais possível com o POST.
AviD
5
@ Lotus Notes, é um pouco mais difícil, mas você não precisa de nenhum tipo de XSS. As solicitações POST estão sendo enviadas o tempo todo e não se esqueça que o CSRF pode ser originado de qualquer site, XSS não incluído.
AviD
18
não, você precisa criar alguém com privilégios para digitá-lo, ao contrário de um GET que será buscado silenciosamente pelo navegador. considerando que todos os formulários POST devem ser protegidos com hash de origem verificável, e não existem meios para um link GET, seu argumento é tolo.
kibitzer
7
Bem, você pode adicionar um hash a todas as suas solicitações GET exatamente da mesma maneira que as adiciona aos formulários POST ... Mas você ainda não deve usar GET para qualquer coisa que modifique os dados.
Eli
13
O uso do POST sobre GET não impede nenhum tipo de CSRF. Isso as torna um pouco mais fáceis de fazer, já que é mais fácil levar as pessoas a um site aleatório que permite imagens de URLs do que a um site que você controla (o suficiente para ter javascript). Fazendo <body onload="document.getElementById('a').submit()"><form id="a" action="http://example.com/delete.php" action="post"><input type="hidden" name="id" value="12"></form>não é realmente difícil de enviar um post em algum lugar automaticamente, clicando em um link (que contém o html)
FryGuy
175

Você não tem maior segurança fornecida porque as variáveis ​​são enviadas por HTTP POST do que pelas variáveis ​​enviadas por HTTP GET.

O HTTP / 1.1 nos fornece vários métodos para enviar uma solicitação :

  • OPÇÕES
  • OBTER
  • CABEÇA
  • POSTAR
  • COLOCAR
  • EXCLUIR
  • VESTÍGIO
  • CONECTAR

Vamos supor que você tenha o seguinte documento HTML usando GET:

<html>
<body>
<form action="http://example.com" method="get">
    User: <input type="text" name="username" /><br/>
    Password: <input type="password" name="password" /><br/>
    <input type="hidden" name="extra" value="lolcatz" />
    <input type="submit"/>
</form>
</body>
</html>

O que o seu navegador pergunta? Ele pergunta o seguinte:

 GET /?username=swordfish&password=hunter2&extra=lolcatz HTTP/1.1
 Host: example.com
 Connection: keep-alive
 Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/ [...truncated]
 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) [...truncated]
 Accept-Encoding: gzip,deflate,sdch
 Accept-Language: en-US,en;q=0.8
 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

Agora vamos fingir que alteramos esse método de solicitação para um POST:

 POST / HTTP/1.1
 Host: example.com
 Connection: keep-alive
 Content-Length: 49
 Cache-Control: max-age=0
 Origin: null
 Content-Type: application/x-www-form-urlencoded
 Accept: application/xml,application/xhtml+xml,text/ [...truncated]
 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; [...truncated]
 Accept-Encoding: gzip,deflate,sdch
 Accept-Language: en-US,en;q=0.8
 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

 username=swordfish&password=hunter2&extra=lolcatz

Ambas as solicitações HTTP são:

  • Não criptografado
  • Incluído nos dois exemplos
  • Pode ser evesopiado e sujeito a ataques MITM.
  • Reproduzida facilmente por terceiros e robôs de script.

Muitos navegadores não suportam métodos HTTP que não sejam POST / GET.

Muitos navegadores comportamentos de armazenam o endereço da página, mas isso não significa que você possa ignorar qualquer um desses outros problemas.

Para ser específico:

Um é inerentemente mais seguro que outro? Sei que o POST não expõe informações na URL, mas há algum valor real nisso ou é apenas segurança através da obscuridade? Qual é a melhor prática aqui?

Isso está correto, porque o software que você está usando para falar HTTP tende a armazenar as variáveis ​​de solicitação com um método, mas outro não apenas impede que alguém olhe para o histórico do navegador ou algum outro ataque ingênuo de uma criança de 10 anos que pensa entender o h4x0r1ng , ou scripts que verificam seu repositório de histórico. Se você tem um script que pode verificar seu histórico, você pode facilmente ter um que verifique o tráfego da sua rede, de modo que toda essa segurança através da obscuridade está fornecendo obscuridade apenas para crianças de script e namoradas ciumentas.

Em https, os dados POST são codificados, mas os URLs podem ser detectados por terceiros?

Veja como o SSL funciona. Lembra dos dois pedidos que enviei acima? Aqui está a aparência deles no SSL: (alterei a página para https://encrypted.google.com/, como o example.com não responde no SSL).

POST sobre SSL

q5XQP%RWCd2u#o/T9oiOyR2_YO?yo/3#tR_G7 2_RO8w?FoaObi)
oXpB_y?oO4q?`2o?O4G5D12Aovo?C@?/P/oOEQC5v?vai /%0Odo
QVw#6eoGXBF_o?/u0_F!_1a0A?Q b%TFyS@Or1SR/O/o/_@5o&_o
9q1/?q$7yOAXOD5sc$H`BECo1w/`4?)f!%geOOF/!/#Of_f&AEI#
yvv/wu_b5?/o d9O?VOVOFHwRO/pO/OSv_/8/9o6b0FGOH61O?ti
/i7b?!_o8u%RS/Doai%/Be/d4$0sv_%YD2_/EOAO/C?vv/%X!T?R
_o_2yoBP)orw7H_yQsXOhoVUo49itare#cA?/c)I7R?YCsg ??c'
(_!(0u)o4eIis/S8Oo8_BDueC?1uUO%ooOI_o8WaoO/ x?B?oO@&
Pw?os9Od!c?/$3bWWeIrd_?( `P_C?7_g5O(ob(go?&/ooRxR'u/
T/yO3dS&??hIOB/?/OI?$oH2_?c_?OsD//0/_s%r

GET sobre SSL

rV/O8ow1pc`?058/8OS_Qy/$7oSsU'qoo#vCbOO`vt?yFo_?EYif)
43`I/WOP_8oH0%3OqP_h/cBO&24?'?o_4`scooPSOVWYSV?H?pV!i
?78cU!_b5h'/b2coWD?/43Tu?153pI/9?R8!_Od"(//O_a#t8x?__
bb3D?05Dh/PrS6_/&5p@V f $)/xvxfgO'q@y&e&S0rB3D/Y_/fO?
_'woRbOV?_!yxSOdwo1G1?8d_p?4fo81VS3sAOvO/Db/br)f4fOxt
_Qs3EO/?2O/TOo_8p82FOt/hO?X_P3o"OVQO_?Ww_dr"'DxHwo//P
oEfGtt/_o)5RgoGqui&AXEq/oXv&//?%/6_?/x_OTgOEE%v (u(?/
t7DX1O8oD?fVObiooi'8)so?o??`o"FyVOByY_ Supo? /'i?Oi"4
tr'9/o_7too7q?c2Pv

(nota: eu converti o HEX para ASCII, alguns deles obviamente não devem ser exibidos)

Toda a conversa HTTP é criptografada, a única parte visível da comunicação está na camada TCP / IP (ou seja, o endereço IP e as informações da porta de conexão).

Então deixe-me fazer uma grande declaração ousada aqui. Seu site não oferece maior segurança sobre um método HTTP do que outro, hackers e jornalistas de todo o mundo sabem exatamente como fazer o que acabei de demonstrar aqui. Se você deseja segurança, use SSL. Navegadores tendem a armazenar histórico, é recomendado pelo RFC2616 9.1.1 NÃO usar GET para executar uma ação, mas pensar que o POST fornece segurança é totalmente errado.

A única coisa que o POST é uma medida de segurança? Proteção contra seu ex ciumento, folheando o histórico do navegador. É isso aí. O resto do mundo está conectado à sua conta rindo de você.

Para demonstrar ainda mais por que o POST não é seguro, o Facebook usa solicitações POST em todo o lugar, então como podem existir softwares como o FireSheep ?

Observe que você pode ser atacado com CSRF, mesmo que use HTTPS e seu site não contenha vulnerabilidades XSS . Em resumo, esse cenário de ataque supõe que a vítima (o usuário do seu site ou serviço) já esteja logada e tenha um cookie adequado e, em seguida, o navegador da vítima seja solicitado a fazer algo com o site (supostamente seguro). Se você não tiver proteção contra o CSRF, o invasor ainda poderá executar ações com as credenciais das vítimas. O atacante não pode ver a resposta do servidor porque ela será transferida para o navegador da vítima, mas o dano já está feito nesse momento.

anônimo
fonte
1
Uma pena que você não falou sobre o CSRF :-). Existe alguma maneira de entrar em contato com você?
Florian Margaine
@FlorianMargaine Me adicione no twitter e eu vou te enviar meu e-mail. twitter.com/#!/BrianJGraham
Incognito
Quem disse que o Facebook é seguro? Boa resposta embora. +1.
Amal Murali
1
"[...] então toda essa segurança através da obscuridade está apenas fornecendo obscuridade para roteirizar crianças e namoradas ciumentas. [...]". isso depende inteiramente das habilidades do namorado ciumento. além disso, nenhum gf / bf deve ter permissão para visitar o histórico do navegador. sempre. ri muito.
turkishweb
34

Não há segurança adicional.

Os dados de postagem não aparecem no histórico e / ou nos arquivos de log, mas se os dados devem ser mantidos em segurança, você precisa de SSL.
Caso contrário, qualquer pessoa que cheire o fio pode ler seus dados de qualquer maneira.

Jacco
fonte
2
Se você receber um URL através de SSL, um terceiro não será capaz de ver a URL, por isso a segurança é a mesma
davetron5000
7
Informações GET só pode ser visto no início e no fim do túnel SSL
Jacco
1
E o sys admins quando eles grep através dos arquivos de log.
Tomalak
1
Eu diria que há alguma segurança adicional, pois os dados do POST não serão armazenados no histórico do navegador do usuário, mas os dados GET serão.
Kip
3
O HTTP sobre SSL / TLS (implementado corretamente) permite que o invasor cheirar a ligação (ou violar ativamente) veja apenas duas coisas: o endereço IP do destino e a quantidade de dados nos dois sentidos.
Aaron
29

Mesmo que POSTnão ofereça nenhum benefício real de segurança GET, para formulários de login ou qualquer outro formulário com informações relativamente confidenciais, verifique se você está usando POSTcomo:

  1. A informação POST ed não serão salvas no histórico do usuário.
  2. As informações confidenciais (senha, etc.) enviadas no formulário não serão visíveis posteriormente na barra de URL (usando GET, elas serão visíveis no histórico e na barra de URL).

Além disso, GETpossui um limite teórico de dados.POSTnão.

Para informações confidenciais reais, use SSL( HTTPS)

Andrew Moore
fonte
Nas configurações padrão, toda vez que insiro um nome de usuário e senha no firefox / IE, ele me pergunta se eu quero salvar essas informações, especificamente para não precisar digitá-las mais tarde.
Kibbee
Andrew: Acho que ele quer dizer preenchimento automático nos campos de entrada do usuário. Por exemplo, o Firefox se lembra de todos os dados inseridos no meu site, então, quando eu começar a digitar texto em uma caixa de pesquisa, ele oferecerá para completar o texto com minhas pesquisas anteriores.
James McMahon
Sim, bem, esse é o objetivo do preenchimento automático, não é? O que eu quis dizer foi a história, não o preenchimento automático.
Andrew Moore
Se o invasor puder acessar o histórico completo do navegador, ele também terá acesso aos dados de preenchimento automático do navegador.
Mikko Rantalainen
19

Nenhum GET e POST é inerentemente "mais seguro" que o outro, assim como nenhum fax e telefone é "mais seguro" que o outro. Os vários métodos HTTP são fornecidos para que você possa escolher o que for mais adequado ao problema que está tentando resolver. GET é mais apropriado para idempotente consultas enquanto o POST é mais adequado para consultas de "ação", mas você pode se dar bem com qualquer uma delas, se não entender a arquitetura de segurança do aplicativo que está mantendo.

Provavelmente, é melhor se você ler o Capítulo 9: Definições de método da RFC HTTP / 1.1 para obter uma idéia geral do que GET e POST foram originalmente previstos ou médios.

Mihai Limbășan
fonte
16

A diferença entre GET e POST não deve ser vista em termos de segurança, mas em suas intenções em relação ao servidor. O GET nunca deve alterar dados no servidor - pelo menos, exceto nos logs -, mas o POST pode criar novos recursos.

Os proxies agradáveis ​​não armazenam em cache os dados do POST, mas podem armazenar em cache os dados GET da URL, portanto, você pode dizer que o POST deve ser mais seguro. Mas os dados do POST ainda estariam disponíveis para proxies que não funcionam bem.

Como mencionado em muitas das respostas, a única aposta segura é via SSL.

Mas verifique se os métodos GET não confirmam alterações, como excluir linhas do banco de dados, etc.

ruquay
fonte
1
Eu concordo com isto. A questão não é segurança, é para isso que o POST e o GET são projetados.
pbreitenbach
6

Minha metodologia usual para escolher é algo como:

  • GET para itens que serão recuperados posteriormente pelo URL
    • Por exemplo, a pesquisa deve ser GET para que você possa pesquisar search.php? S = XXX mais tarde
  • POST para itens que serão enviados
    • Isso é relativamente invisível para GET e mais difícil de enviar, mas os dados ainda podem ser enviados via cURL.
Ross
fonte
Mas é mais difícil fazer um POST do que um GET. Um GET é apenas um URL na caixa de endereço. Um POST requer um <form> em uma página HTML ou cURL.
pbreitenbach 19/08/09
2
Portanto, uma postagem falsa leva o bloco de notas e 5 minutos ... não muito mais. Usei o bloco de notas para adicionar recursos a um sistema telefônico que não existia. Consegui criar uma cópia dos formulários de administração para o sistema que me permitia atribuir comandos a botões que "não eram possíveis" no que diz respeito ao fornecedor.
Matthew Whited
6

Isso não está relacionado à segurança, mas ... os navegadores não armazenam em cache as solicitações POST .

Daniel Silveira
fonte
6

Nenhum deles confere segurança magicamente a uma solicitação, no entanto, GET implica alguns efeitos colaterais que geralmente impedem que ela seja segura.

Os URLs GET aparecem no histórico do navegador e nos logs do servidor da web. Por esse motivo, eles nunca devem ser usados ​​para itens como formulários de login e números de cartão de crédito.

No entanto, apenas postar esses dados também não os torna seguros. Para isso você quer SSL. GET e POST enviam dados em texto sem formatação pela conexão quando usados ​​por HTTP.

Também existem outros bons motivos para os dados do POST - como a capacidade de enviar quantidades ilimitadas de dados ou ocultar parâmetros de usuários casuais.

A desvantagem é que os usuários não podem marcar os resultados de uma consulta enviada via POST. Para isso, você precisa de GET.

edebill
fonte
5

Considere esta situação: Uma API desleixada aceita solicitações GET como:

http://www.example.com/api?apikey=abcdef123456&action=deleteCategory&id=1

Em algumas configurações, quando você solicita esse URL e se houver um erro / aviso sobre o pedido, toda essa linha é registrada no arquivo de log. Pior ainda: se você esquecer de desativar as mensagens de erro no servidor de produção, essas informações serão exibidas simplesmente no navegador! Agora você acabou de entregar sua chave de API a todos.

Infelizmente, existem APIs reais funcionando dessa maneira.

Eu não gostaria da idéia de ter algumas informações confidenciais nos logs ou exibi-las no navegador. POST e GET não são os mesmos. Use cada um onde for apropriado.

Halil Özgür
fonte
3
  1. SEGURANÇA como segurança dos dados EM TRÂNSITO: nenhuma diferença entre POST e GET.

  2. SEGURANÇA como segurança dos dados NO COMPUTADOR: O POST é mais seguro (sem histórico de URL)

caxemira
fonte
2

A noção de segurança não tem sentido, a menos que você defina contra o que deseja se proteger.

Se você deseja se proteger contra o histórico armazenado do navegador, alguns tipos de registro e pessoas que olham para seus URLs, o POST é mais seguro.

Se você deseja se proteger contra alguém que cheira sua atividade de rede, não há diferença.

Taymon
fonte
1

Muitas pessoas adotam uma convenção (mencionada por Ross) de que solicitações GET apenas recuperam dados e não modificam nenhum dado no servidor, e solicitações POST são usadas para todas as modificações de dados. Enquanto um não é inerentemente mais seguro do que o outro, se fazer seguir essa convenção, você pode aplicar a lógica de segurança transversal (por exemplo, apenas as pessoas com contas pode modificar os dados, os postos de modo não autenticados são rejeitados).

Eric R. Rath
fonte
4
Na verdade, não é uma "convenção", faz parte do padrão HTTP. O RFC é muito explícito no que esperar dos diferentes métodos.
John Nilsson
De fato, se você permitir que as solicitações GET modifiquem o estado, é possível que um navegador que esteja buscando previamente as páginas que acha que você pode visitar acidentalmente executará ações que você não queria.
Jessta
1

É mais difícil alterar uma solicitação POST (requer mais esforço do que editar a cadeia de consulta). Edit: Em outras palavras, é apenas segurança pela obscuridade, e apenas isso.

ausência de pálpebra
fonte
3
Posso alterar solicitações POST tão facilmente quanto solicitações de string de consulta, usando alguns complementos para o Firefox. posso até modificar dados de cookies para o conteúdo do meu coração.
21138 stephenbayer
não diminui a velocidade das crianças, é exatamente o tipo de coisa que as crianças experimentam o tempo todo. O problema é que eles às vezes conseguem.
1113 Jacco
2
Uh Usando suplementos para o Firefox = mais esforço que a string de consulta.
Eyelidlessness 13/10/08
Sua resposta dará às pessoas uma falsa sensação de que elas estão sendo mais seguras ao usar uma postagem, quando na verdade não estão. Má resposta, homem mau.
Chris Marasti-Georg
Editei para tornar mais clara a intenção da minha resposta. Espero que ajude.
Eyelidlessness 13/10/08
1

Não vou repetir todas as outras respostas, mas há um aspecto que ainda não vi mencionado - é a história de dados desaparecendo. Não sei onde encontrá-lo, mas ...

Basicamente, trata-se de um aplicativo da Web que, misteriosamente, todas as noites perde todos os seus dados e ninguém sabe o porquê. Ao inspecionar os logs, mais tarde, foi revelado que o site foi encontrado pelo google ou por outra aranha arbitrária, que obteve (leia: GOT) todos os links encontrados no site, incluindo "excluir esta entrada" e "tem certeza?" links.

Na verdade - parte disso foi mencionada. Esta é a história por trás de "não altere dados no GET, mas apenas no POST". Os rastreadores seguirão felizmente GET, nunca POST. Mesmo o robots.txt não ajuda contra rastreadores que se comportam mal.

Olaf Kock
fonte
1

Você também deve estar ciente de que, se seus sites contiverem links para outros sites externos que você não controla usando GET, esses dados serão colocados no cabeçalho do refeerer nos sites externos quando eles pressionarem os links em seu site. Portanto, a transferência de dados de login pelos métodos GET é SEMPRE um grande problema. Uma vez que isso pode expor as credenciais de login para facilitar o acesso, basta verificar os logs ou procurar no Google analytics (ou similar).

3cho
fonte
1

RFC7231:

"Os URIs devem ser compartilhados, não protegidos, mesmo quando identificam recursos seguros. Os URIs geralmente são mostrados nos monitores, adicionados aos modelos quando uma página é impressa e armazenados em uma variedade de listas de favoritos não protegidas. Portanto, não é aconselhável incluir informações em um URI sensíveis, identificáveis ​​pessoalmente ou com risco de divulgação.

Os autores dos serviços devem evitar formulários baseados em GET para o envio de dados confidenciais, porque esses dados serão colocados no destino da solicitação. Muitos servidores, proxies e agentes de usuário existentes registram ou exibem o destino da solicitação em locais onde ele pode estar visível para terceiros. Esses serviços devem usar o envio de formulários baseados em POST ".

Essa RFC indica claramente que dados confidenciais não devem ser enviados usando GET. Devido a essa observação, alguns implementadores podem não manipular os dados obtidos da parte da consulta de uma solicitação GET com o mesmo cuidado. Estou trabalhando em um protocolo que garante a integridade dos dados. De acordo com esta especificação, eu não deveria ter que garantir a integridade dos dados GET (o que farei porque ninguém adere a essas especificações)

Prata
fonte
1

Como anteriormente algumas pessoas disseram, o HTTPS traz segurança.

No entanto, o POST é um pouco mais seguro que o GET, pois o GET pode ser armazenado no histórico.

Mais ainda, infelizmente, às vezes a eleição do POST ou do GET não depende do desenvolvedor. Por exemplo, um hiperlink é sempre enviado por GET (a menos que seja transformado em um formulário de postagem usando javascript).

Magallanes
fonte
0

GET é visível para qualquer pessoa (mesmo a que está no seu ombro agora) e é salva no cache, portanto, é menos seguro o uso de post, btw post sem alguma rotina criptográfica não é certo; por um pouco de segurança, você deve usar SSL ( https)

kentaromiura
fonte
0

Uma das razões pelas quais o POST é pior para a segurança é que GET é registrado por padrão, parâmetros e todos os dados são quase universalmente registrados pelo seu servidor da web.

O POST é o contrário , quase universalmente não é registrado , levando a atividades de invasor muito difíceis.

Eu não compro o argumento "é grande demais", não há razão para não registrar nada , pelo menos 1 KB, seria um longo caminho para as pessoas identificarem os invasores que trabalham em um ponto de entrada fraco até que ele apareça, e o POST um serviço duplo, permitindo que qualquer porta traseira baseada em HTTP passe silenciosamente quantidades ilimitadas de dados.

RandomNickName42
fonte
0

A diferença é que o GET envia dados abertos e POST ocultos (no cabeçalho http).

Portanto, get é melhor para dados não seguros, como cadeias de consulta no Google. Os dados de autenticação nunca serão enviados via GET - portanto, use POST aqui. Claro que o tema todo é um pouco mais complicado. Se você quiser ler mais, leia este artigo (em alemão).

Daniel
fonte
0

Recentemente, um ataque foi publicado , que permite ao homem revelar um corpo de solicitações de HTTPS compactado. Como os cabeçalhos e a URL da solicitação não são compactados pelo HTTP, as solicitações GET ficam mais protegidas contra esse ataque específico.

Existem modos em que as solicitações GET também são vulneráveis, o SPDY compacta os cabeçalhos das solicitações, o TLS também fornece uma compactação opcional (raramente usada). Nesses cenários, o ataque é mais fácil de evitar (os fornecedores de navegadores já forneceram correções). A compactação no nível HTTP é um recurso mais fundamental, é improvável que os fornecedores o desabilitem.

É apenas um exemplo que mostra um cenário em que GET é mais seguro que POST, mas não acho que seria uma boa ideia escolher GET sobre POST por esse motivo de ataque. O ataque é bastante sofisticado e requer pré-requisitos não triviais (o Attacker precisa poder controlar parte do conteúdo da solicitação). É melhor desativar a compactação HTTP em cenários onde o ataque seria prejudicial.

Jan Wrobel
fonte
0

Isenção de responsabilidade: os pontos a seguir são aplicáveis ​​apenas a chamadas de API e não aos URLs do site.

Segurança na rede : você deve usar HTTPS. GET e POST são igualmente seguros neste caso.

Histórico do Navegador : para aplicativos de front-end, como Angular JS, React JS, etc, as chamadas de API são chamadas AJAX feitas pelo front-end. Isso não se torna parte do histórico do navegador. Portanto, POST e GET são igualmente seguros.

Logs do servidor : Com o uso do conjunto de gravação de máscara de dados e do formato de logs de acesso, é possível ocultar todos ou apenas dados confidenciais da URL de solicitação.

Visibilidade dos dados no console do navegador: para alguém com intenções mal-intencionadas, são quase os mesmos esforços para exibir dados POST tanto quanto GET.

Portanto, com práticas corretas de registro em log, a API GET é tão segura quanto a API POST. Seguir o POST em todos os lugares, força definições de API ruins e deve ser evitado.

borato de kishor
fonte
-2

A postagem é a mais segura junto com o SSL instalado porque é transmitida no corpo da mensagem.

Mas todos esses métodos são inseguros porque o protocolo de 7 bits que ele usa embaixo dele é passível de hackers com escape. Mesmo através de um firewall de aplicativo da web nível 4.

Soquetes também não são garantia ... Embora seja mais seguro de certas maneiras.

drtechno
fonte
-3

Este é um post antigo, mas eu gostaria de contestar algumas das respostas. Se estiver transferindo dados confidenciais, convém usar SSL. Se você usar SSL com um parâmetro GET (por exemplo,? Userid = 123), esses dados serão enviados em texto sem formatação! Se você enviar usando um POST, os valores serão colocados no corpo criptografado da mensagem e, portanto, não serão legíveis para a maioria dos ataques MITM.

A grande distinção é onde os dados são passados. Só faz sentido que, se os dados forem colocados em uma URL, não puderem ser criptografados, caso contrário você não poderá rotear para o servidor, pois somente você poderá ler a URL. É assim que um GET funciona.

Em resumo, você pode transmitir dados com segurança em um POST sobre SSL, mas não pode fazê-lo com um GET, usando SSL ou não.

LVM
fonte
4
Isso é completamente falso. SSL é um protocolo de camada de transporte. Ele se conecta primeiro ao servidor e envia TODOS os dados do aplicativo como um fluxo de dados binário criptografado. Confira este tópico: answers.google.com/answers/threadview/id/758002.html
Simeon G
Faça um TCPDump e você verá que isso é 100% verdadeiro. Para se conectar ao servidor, você deve enviar sua solicitação sem criptografia. Se você fizer isso como um GET, seus argumentos serão adicionados à solicitação inicial e, portanto, não serão criptografados. Independentemente do que você vê na postagem que você vinculou, você pode testar isso com o TCPDump (ou similar).
LVM
1
Feito! Apenas executei o tcpdump no meu Mac. E sua resposta foi 100% falsa. Aqui está o comando que eu usei: sudo tcpdump -w ssl.data -A -i en1 -n dst port 443 Então, quando olhei em ssl.data, é claro, vi um gobly gook. Todos os dados HTTP foram criptografados. E para garantir que uma chamada não-SSL normal funcionasse, usei: sudo tcpdump -w clear.data -A -i en1 -n dst port 80 E com certeza, dentro do clear.data, todos os cabeçalhos e URIs foram exibidos . Eu testei isso no meu gmail e google plus (que são HTTPS) e em algumas páginas não SSL, como google.com.
Simeon G
Eu não sou um especialista em rede, portanto, se você acha que usei os comandos errados no tcpdump, sinta-se à vontade para me corrigir.
Simeon G
Não tenho o comando de imediato, mas você também pode verificá-lo com o Wireshark / Ethereal.
LVM
-3

Até o POST aceita solicitações GET. Suponha que você tenha um formulário com entradas como user.name e user.passwd, que devem suportar nome de usuário e senha. Se simplesmente adicionarmos? User.name = "meu usuário & user.passwd =" minha senha ", a solicitação será aceita por" ignorando a página de logon ".

Uma solução para isso é implementar filtros (filtros java como e) no lado do servidor e detectar que nenhuma consulta de string seja passada como argumento GET.

Sabre Chebka
fonte
2
Não é verdade! Isso depende inteiramente do seu back-end para saber se o código que aceita POSTs também aceita GETs.
Colin 't Hart