"Curl -u nome de usuário: senha http://example.com" é seguro?

30

É curl -u username:password http://example.comseguro?

Caso contrário, você pode dar uma breve explicação de como alguém poderia obter sua senha?

security curl JDiMatteo
fonte
6
se você estiver usando isso em um terminal, lembra-se de que ambas as credenciais são armazenadas no histórico do bash?
Francisco Tapia
15
Esse comando não é seguro porque outro usuário pode usar ps -efpara ver quais processos estão em execução. Quando você curl -u username:password http://example.comaparece na lista, seu destino, nome de usuário e senha são comprometidos.
Lambert
Embora a pergunta esteja no tópico aqui, você também pode estar interessado em Segurança da Informação StackExchange
IQAndreas

Respostas:

54

Não é seguro, porque o cURL assume como padrão a autenticação básica, onde o protocolo HTTP envia sua senha em texto não criptografado. Quando você especifica a username:passwordsequência, ela é convertida em uma sequência BASE64 no cabeçalho HTTP:

GET / HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Accept: text/html
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

Qualquer pessoa capaz de interceptar seu tráfego HTTP (seu provedor, qualquer pessoa acessando o mesmo ponto de acesso sem fio que você, etc) poderá recuperar a senha simplesmente usando um conversor BASE64 online .

O protocolo HTTPS melhorará as coisas estabelecendo uma conexão criptografada antes do envio desse cabeçalho, impedindo que a senha seja revelada. No entanto, isso só se aplica se o usuário prestar atenção quando solicitado a confirmar certificados desconhecidos, autorizar exceções de segurança e assim por diante.

Observe que os argumentos do comando podem estar disponíveis para outros usuários na mesma máquina verem, por exemplo ps -ef, sistema de arquivos / proc, no histórico do bash e no log do terminal (obrigado pelo comentário do @ Lambert, observando isso). O cURL em algumas plataformas tenta ocultar a senha. Por exemplo, ps -efé provável que você veja espaço em branco em vez de uma senha. No entanto, em vez de passar a senha como um argumento de linha de comando, o cURL solicita diretamente uma senha é melhor, conforme discutido no FAQ do cURL .

Dmitry Grigoryev
fonte
4
Mesmo se você estiver em uma plataforma na qual o curl substitui com êxito seu próprio argumento para ocultar os dados ps, há um período durante a inicialização antes que a substituição seja executada onde esse conteúdo é vulnerável.
Charles Duffy
E a autenticação Digest? O enrolamento não usa isso por padrão?
rr-
2
A autenticação @rr Digest é apenas um pouco melhor, pois não impede ataques man-in-the-middle, então você ainda está melhor usando HTTPS.
Dmitry Grigoryev
11
@rr Como você afirma que o StartSSL não é confiável para a maioria dos navegadores ? Você espera muitos usuários do Windows 95 ou Firefox 1.5?
Hagen von Eitzen
11
@rr IMHO você começa não confiável somente se há um problema com a falta (ou errado) certs intermediários no servidor
Hagen von Eitzen
24

Não é seguro. Os parâmetros da linha de comando são visíveis para todos os usuários.

Tronic
fonte
4
A fusão com a resposta do @Dmitry Grigoryev pode ser a mais precisa.
Francisco Tapia
11
Sim, perdi completamente a grande parte do problema que devo admitir.
Dmitry Grigoryev
comando poderia ser parte de um script só pode ser lido pelo usuário ...
Pete
2
As linhas de comando do @Pete dos programas em execução (iniciados a partir de um script ou em um terminal) geralmente são visíveis para todos os usuários por meio do pscomando e do /procsistema de arquivos. Se o comando terminar rapidamente, o risco é reduzido, mas ainda está lá.
RBerteig 26/05
2
As respostas do @Pete não devem ser exclusivas, elas se complementam. Portanto, não há problema em que a segunda resposta omita a ameaça explicada na primeira; seria redundante repeti-la. E eu não chamaria a declaração de falsa, porque não é verdadeira em todos os casos possíveis.
Dmitry Grigoryev 27/05
1

Isso pode ser feito de uma maneira mais segura usando o parâmetro --netrc-file.

  1. Crie um arquivo com permissão 600

Por exemplo: vi / root / my-file

machine example.com

Nome de usuário de login

senha PASSWORD

Salve e feche o arquivo

  1. Use o abaixo para acessar o URL com nome de usuário e senha.

curl --netrc-file / root / meu-arquivo http://example.com

  1. Feito
Shameer
fonte
0

É inseguro ao usar o esquema HTTP. Para torná-lo seguro, você deve usar HTTPS.

Para impedir que a senha apareça no histórico de comandos, forneça apenas o nome de usuário. A ondulação solicitará a senha, se não for fornecida no comando.

Mohnish
fonte
Não é uma resposta útil se o HTTPS não estiver disponível. cURL é um "cliente".
Mckenzm
0

Resposta curta é não ... mas ....

Se não houver opções do lado do servidor, você poderá reforçar a segurança.

  1. Se for a intranet local, isole o domínio de transmissão e não use Wi-Fi ou rádio.
  2. Como Shameer diz, use um arquivo .netrc, mantenha os valores fora do código.
  3. Se você acredita que a memória é segura, use vars ambientais. $ PSWD.
  4. Se isso é automação, execute a partir do crontab do root.
  5. ... em um recipiente.
  6. ... de uma VM com um disco criptografado.

Nada disso é menos seguro que um navegador usando HTTP.

mckenzm
fonte