"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

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.

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

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

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

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.

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

Nada disso é menos seguro que um navegador usando HTTP.

— mckenzm
fonte