Чи захищено "curl -u ім'я користувача: пароль http://example.com"?


28

Є curl -u username:password http://example.com безпечно?

Якщо ні, чи можете ви дати короткий опис того, як хтось може отримати ваш пароль?


6
якщо ви використовуєте, що в терміналі ви маєте на увазі, що обидва облікові дані зберігаються в історії bash?
Francisco Tapia

14
Така команда не є захищеною, оскільки може використовувати інший користувач ps -ef щоб побачити, які процеси виконуються. Коли ви curl -u username:password http://example.com відображаються у списку, ваш пункт призначення, ім'я користувача та пароль скомпрометовані.
Lambert

Незважаючи на те, що питання на тему тут, ви також можете бути зацікавлені в Інформаційна безпека StackExchange
IQAndreas

Відповіді:


53

Це небезпечно, тому що cURL за замовчуванням для базової аутентифікації де протокол HTTP передає ваш пароль в прозорий текст. Коли ви вкажете username:password рядок, він перетворюється в a BASE64 рядок у заголовку HTTP:

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

Будь-хто, хто може перехопити ваш трафік HTTP (ваш провайдер, хто має доступ до тієї ж бездротової точки доступу, що і ви, тощо), зможуть відновити пароль, просто використовуючи онлайн конвертер BASE64 .

Протокол HTTPS покращить ситуацію шляхом встановлення зашифрованого з'єднання, перш ніж надсилати цей заголовок, запобігаючи виявленню пароля. Однак, це застосовується лише у випадку, якщо користувач звертає увагу на запит підтвердження невідомих сертифікатів, авторизації винятків безпеки тощо.

Зверніть увагу, що аргументи команд можуть бути доступні для інших користувачів на одній машині для перегляду, наприклад, ps -ef, / proc файлової системи, у вас історія bash, і у вашому терміналі log (спасибі за @ @ Lambert коментар, зазначивши це). cURL на деяких платформах намагається приховати пароль, наприклад, з ps -ef ймовірно, замість пароля ви побачите пробіл. Однак, замість того, щоб передавати пароль як аргумент командного рядка, краще, як було обговорено на cURL faq .


4
Навіть якщо ви знаходитесь на платформі, де curl успішно перезаписує власний argv, щоб приховати дані ps, існує період, коли він починає працювати перед тим, як перезапис виконується там, де цей вміст уразливий.
Charles Duffy

А як щодо дайджестної автентифікації? Чи не використовує це за замовчуванням?
rr-

2
Аутентифікація @rr Digest є трохи кращою, оскільки вона не заважає атакам man-in-the-middle, тому вам краще використовувати HTTPS.
Dmitry Grigoryev

1
@rr Як ви стверджуєте, що StartSSL не довіряє більшості браузерів ? Чи очікуєте ви багато користувачів Windows 95 або Firefox 1.5?
Hagen von Eitzen

1
@rr IMHO ви отримуєте недовіру, тільки якщо є проблема відсутні (або неправильні) проміжні сертифікати на сервері
Hagen von Eitzen

24

Це не є безпечним. Параметри командного рядка доступні для всіх користувачів.


4
Злиття з відповіді @ Дмитра Григор'єва могло б бути найточнішим.
Francisco Tapia

1
Так, я повністю пропустив велику частину проблеми, яку я повинен визнати.
Dmitry Grigoryev

команда може бути частиною скрипта, доступного для читання користувачем ...
Pete

2
Командний рядок @Pete виконуваних програм (запускається з скрипта або на терміналі) зазвичай видно всім користувачам через ps і команду /proc файлова система. Якщо команда швидко закінчується, ризик зменшується, але він все ще існує.
RBerteig

2
@Pete Відповіді не повинні бути ексклюзивними, вони доповнюють один одного. Отже, для другої відповіді все гаразд, щоб уникнути загрози, поясненої в першій, а не було б повторювати її. І я б не назвав цю заяву неправдивою, тому що це не вірно в кожному випадку.
Dmitry Grigoryev

1

Це можна зробити більш безпечним способом, використовуючи параметр --netrc-file.

  1. Створіть файл з 600 дозволом

Наприклад: vi / root / my-file

machine example.com

Увійти USERNAME

пароль PASSWORD

Збережіть і закрийте файл

  1. Щоб отримати доступ до URL-адреси з іменем користувача та паролем, скористайтеся нижче.

curl - netrc-файл / root / мій-файл http://example.com

  1. Виконано

0

Це небезпечно при використанні схеми HTTP. Щоб забезпечити безпеку, слід використовувати HTTPS.

Щоб приховати пароль від появи в історії команд, вкажіть лише ім'я користувача. Curl підкаже пароль, якщо не вказано в команді.


Не корисна відповідь, якщо HTTPS недоступна. cURL - це "клієнт".
mckenzm

0

Коротка відповідь немає ... але ....

Якщо немає опцій на стороні сервера, можна посилити безпеку.

  1. Якщо це локальна інтрамережа, то ізолюйте широкомовний домен і виконайте не використовувати WiFi або будь-яке радіо.
  2. Як говорить Шеймер, використовуйте файл .netrc, зберігайте значення з коду.
  3. Якщо ви сподіваєтеся, що пам'ять безпечна, використовуйте екологічні об'єкти. $ PSWD.
  4. Якщо це автоматизація, запускайте з crontab root.
  5. ... в контейнері.
  6. ... з VM із зашифрованим диском.

Жоден з них не є менш безпечним, ніж браузер, що використовує HTTP.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.