Если Вы будете использовать HTTPS, то будет Ваши параметрические усилители URL быть безопасным от сниффинга? [дубликат]
Еще один способ переключения:
- (IBAction)signOnClick:(id)sender
{
if ([_signOnButton.titleLabel.text isEqualToString:@"Sign off"])
{
[sender setTitle:@"Sign on" forState:UIControlStateNormal];
}
else
{
[sender setTitle:@"Sign off" forState:UIControlStateNormal];
}
}
7 ответов
Да, ваш URL будет защищен от взлома; Однако есть одна дыра, которую легко упустить из виду: если ваша страница ссылается на какие-либо сторонние ресурсы, такие как Google Analytics, добавить контент, весь ваш URL-адрес будет отправлен третьей стороне в реферере. Если это действительно конфиденциально, то его нет в строке запроса.
Что касается второй части вопроса, вы не можете использовать SSL, если у вас нет сертификата на сервере.
http://answers.google.com/answers/threadview/id/758002.html
HTTPS Устанавливает базовый SSL соединение до того, как любые данные HTTP будут переведен. Это гарантирует, что все URL данные (за исключением имени хоста, который используется для установления подключение) осуществляется исключительно в это зашифрованное соединение, и защищен от человека посередине атакует так же, как любой HTTPS данные есть.
Все транзакции уровня HTTP в пределах HTTPS-соединение осуществляется в пределах установленный сеанс SSL, и нет данные запроса передаются до установлено безопасное соединение.
Извне только данные, которые видимым для мира является имя хоста и порт, к которому вы подключаетесь. Все остальное - просто поток двоичные данные, зашифрованные с использованием закрытый ключ предоставлен только вам и сервер.
В этом примере вы предоставляете браузер сделает это:
- Производные имя хоста (и порт, если есть) из URL.
- Подключиться к хосту.
- Проверить сертификат (он должен быть «подписан» известным авторитетом, применяется специально исправить IP-адрес и порт и быть ток).
- Браузер и сервер обмениваться криптографическими данными и браузер получает закрытый ключ.
- HTTP-запрос выполняется и зашифрован с помощью установила криптографию.
- Получен HTTP-ответ. Также зашифрованный.
HTTP - это «уровень приложения» протокол. Его носят поверх безопасный слой. Согласно SSL спецификация, составленная Netscape, это диктует, что никакой прикладной уровень данные могут быть переданы до безопасного соединение установлено - как изложены в следующем абзаце:
«На этом этапе изменение спецификации шифра сообщение отправлено клиентом, а клиент копирует ожидающий Cipher Spec в текущую спецификацию шифра. В затем клиент немедленно отправляет готовое сообщение под новым алгоритмы, ключи и секреты. В ответ, сервер отправит свой сообщение изменения спецификации шифра, передача ожидание текущего шифра Spec и отправьте свое готовое сообщение под новой Cipher Spec. В этот точка, рукопожатие завершено и клиент и сервер могут начать обмениваться данными прикладного уровня ". http://wp.netscape.com/eng/ssl3/draft302.txt
Так что да. Данные, содержащиеся в URL запрос по HTTPS-соединению зашифрованный . Однако очень плохая практика включать такие чувствительные данные как пароль в 'GET' запрос. Пока не может быть перехвачены, данные будут записаны в журналах сервера с открытым текстом на получение HTTPS-сервера и довольно возможно, также в истории браузера . Это вероятно, также доступен для браузера плагины и, возможно, даже другие приложения на клиентском компьютере. Максимальный URL-адрес HTTPS может быть разумно разрешено включать идентификатор сеанса или аналогичный одноразовый переменная. Он НИКОГДА не должен содержать токены статической аутентификации.
четко объяснено здесь: http://www.ourshop.com/resources/ssl_step1.html
Запрошенный URI (/ test? Abc = 123) отправляется на веб-сервер как часть заголовка HTTP-запроса и, таким образом, зашифрован.
Однако URL-адреса могут просачиваться другими способами, обычно панели инструментов веб-браузера, закладки и отправка ссылок друзьям. Публикация данных может быть более подходящей в зависимости от контекста / конфиденциальности данных, которые вы отправляете.
Я считаю, что для HTTPS-соединения требуется сертификат SSL, даже если вы не хотите его покупать. 1263] Надеюсь, это немного поможет!
зависит от того, что вы подразумеваете под безопасным
SSL шифрует весь HTTP-запрос / ответ, поэтому URL-адрес в части GET будет зашифрован. Это не останавливает атаки MITM и нарушение целостности самого сеанса SSL. Если используется неавторизованный сертификат, это упрощает потенциальные векторы атаки.
Зашифрованы ли заголовки запросов REST с помощью SSL?
Это аналогичный вопрос.
URL: s будет храниться как в журналах сервера, так и в истории браузера, поэтому даже если они не обнаруживаются, они далеко небезопасны.
На проводе, да. В конечных точках (браузере и сервере) не обязательно. SSL / TLS - это безопасность транспортного уровня . Он зашифрует ваш трафик между браузером и сервером. На стороне браузера можно просматривать данные (например, BHO ). Как только он достигает серверной стороны, он, конечно же, становится доступным для получателя и настолько безопасен, насколько он с ним обращается. Если данные необходимо безопасно переместить за пределы первоначального обмена и защитить от посторонних глаз со стороны клиента, вам также следует обратить внимание на безопасность уровня сообщений .
SSL / TSL - это безопасность транспортного уровня, да, данные могут быть получены с помощью BHO (как написал @JP) или любого дополнения, а также с помощью HTTP-снифферов "вне браузера". Они читают обмен сообщениями между winsock32 и приложением. Шифрование происходит в winsock32, а не в браузере.
Взгляните (эта часть была взята со страницы IEinspector): IEInspector HTTP Analyzer - такой удобный инструмент, который позволяет отслеживать, отслеживать, отлаживать и анализировать трафик HTTP / HTTPS в режиме реального времени.