Чи безпечний рядок запиту HTTPS?

Я створюю захищений веб-API, який використовує HTTPS; однак, якщо я дозволю користувачам налаштувати його (включаючи відправлення пароля) за допомогою рядка запиту, це також буде захищено чи потрібно змусити це зробити через POST?

Так. Але використання GET для конфіденційних даних є поганою ідеєю з кількох причин:

• Переважно витік HTTP-реферала (зовнішнє зображення на цільовій сторінці може просочити пароль [1])
• Пароль буде зберігатися в журналах сервера (що, очевидно, погано)
• Історія кешує в браузерах

Тому, навіть якщо Querystring захищений, не рекомендується передавати конфіденційні дані через запити.

[1] Хоча мені потрібно зазначити, що RFC стверджує, що браузер не повинен надсилати посилань з HTTPS на HTTP. Але це не означає, що погана панель інструментів сторонніх веб-переглядачів або зовнішнє зображення / спалах із сайту HTTPS не просочуються.

З точки зору "нюхати мережевий пакет", запит GET є безпечним, оскільки браузер спочатку встановить захищене з'єднання, а потім відправить запит, що містить параметри GET. Але URL-адреси GET будуть зберігатися в історії / автозаповненні веб-переглядачів користувачів, що не є гарним місцем для зберігання, наприклад, даних про паролі. якщо ви отримуєте доступ до нього лише зі свого спеціального додатка, це не повинно бути проблемою.

Тому слід віддавати перевагу використанню публікації принаймні для діалогів паролів. Крім того, як зазначено у посиланні littlegeek, розміщеному GET URL, швидше за все, буде записано у журнали вашого сервера.

Так , ваші рядки запитів будуть зашифровані.

Причина полягає в тому, що рядки запитів є частиною протоколу HTTP, який є протоколом рівня додатків, а частина безпеки (SSL / TLS) надходить з транспортного рівня. Спочатку встановлюється з'єднання SSL, а потім параметри запиту (які належать до протоколу HTTP) надсилаються серверу.

Встановлюючи з'єднання SSL, ваш клієнт виконує наступні кроки в порядку. Припустимо, ви намагаєтесь увійти на сайт з назвою example.com і хочете надіслати свої облікові дані за допомогою параметрів запиту. Повна URL-адреса може виглядати наступним чином:

https://example.com/login?username=alice&password=12345)

1. Ваш клієнт (наприклад, браузер / мобільний додаток) спочатку вирішить ваше доменне ім’я example.comдо IP-адреси (124.21.12.31)за допомогою запиту DNS. При запиті до цієї інформації використовується тільки інформація, що стосується конкретного домену, тобто example.comвона буде використовуватися тільки.
2. Тепер ваш клієнт спробує підключитися до сервера з IP-адресою 124.21.12.31та спробує підключитися до порту 443 (порт служби SSL не порт HTTP за замовчуванням 80).
3. Тепер сервер example.comнадішле свої сертифікати вашому клієнту.
4. Ваш клієнт перевірить сертифікати і почне обмін загальним секретним ключем для вашого сеансу.
5. Після успішного встановлення захищеного з'єднання, лише тоді ваші параметри запиту будуть надіслані через захищене з'єднання.

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

Так. Весь текст сеансу HTTPS захищений SSL. Це включає запит та заголовки. У цьому відношенні POST та GET були б абсолютно однаковими.

Щодо безпеки вашого методу, то немає реального способу сказати без належної перевірки.

Спочатку SSL з'єднується з хостом, тому ім'я хосту та номер порту передаються як чіткий текст. Коли хост відповість і виклик буде успішним, клієнт зашифрує HTTP-запит фактичною URL-адресою (тобто будь-чим після третьої косої риси) та відправить його на сервер.

Існує кілька способів порушити цю безпеку.

Можна налаштувати проксі, щоб він виступав як "людина посередині". В основному браузер надсилає запит на підключення до реального сервера до проксі. Якщо проксі налаштовано таким чином, він підключиться через SSL до реального сервера, але браузер все одно буде спілкуватися з проксі. Тож якщо зловмисник може отримати доступ до проксі-сервера, він може бачити всі дані, що протікають через нього, у чіткому тексті.

Ваші запити також будуть видимі в історії браузера. Користувачі можуть спокуситись зробити закладку сайту. Деякі користувачі встановили інструменти синхронізації закладок, тому пароль може з’явитися на deli.ci.us або в іншому місці.

Нарешті, хтось, можливо, зламав ваш комп’ютер і встановив реєстратор клавіатури або скрепер екрану (і це роблять багато вірусів типу Trojan Horse). Оскільки пароль видно безпосередньо на екрані (на відміну від "*" у діалоговому вікні пароля), це ще одна дірка безпеки.

Висновок: Якщо мова йде про безпеку, завжди покладайтеся на прокладений шлях. Просто занадто багато, про що ви не знаєте, не будете думати, і що зламає вам шию.

Так, поки ніхто не дивиться через плече на монітор.

Я не згоден із твердженням про [...] витоку HTTP-реферала (зовнішнє зображення на цільовій сторінці може просочити пароль) у відповіді Слоу .

HTTP 1.1 RFC прямо заявляє :

Клієнти НЕ повинні включати поле заголовка Referer у HTTP-запит (незахищений), якщо перенаправлена ​​сторінка була перенесена із захищеним протоколом.

У будь-якому випадку, журнали серверів та історія браузера є більш ніж достатньою причиною не ставити конфіденційні дані в рядок запитів.

Так, з моменту встановлення HTTPS-з'єднання все працює в безпеці. Рядок запиту (GET) як POST надсилається через SSL.

Ви можете надіслати пароль у вигляді хеш-параму MD5 з додаванням солі. Порівняйте його на стороні сервера для авт.