Как протокол HTTP может безопасно передавать информацию о пароле без HTTPS?
Протокол HTTP представляет собой обычный текстовый протокол без какого-либо шифрования. Данные, передаваемые по протоколу HTTP, можно полностью контролировать в сети. Если имя пользователя и пароль напрямую передаются в открытом виде по протоколу HTTP при входе в систему, пароль может быть украден хакерами. Одним из способов является использование асимметричного шифрования. Предоставьте открытый ключ браузеру как переменную Javascript, когда вы ПОЛУЧАЕТЕ страницу входа. Затем зашифруйте пароль пользователя с помощью открытого ключа, а затем отправьте зашифрованный текст пароля, имя пользователя и открытый ключ на сервер. Сервер будет хранить информацию о сопоставлении открытого ключа и закрытого ключа заранее, и соответствующий закрытый ключ можно узнать с помощью открытого ключа, отправленного клиентом, а затем открытый текст пароля может быть восстановлен путем расшифровки зашифрованного текста. . Чтобы усилить безопасность открытого ключа и закрытого ключа, сервер должен динамически генерировать пару открытого ключа и закрытого ключа и уничтожать ее сразу после использования. Однако динамическая генерация требует больших вычислительных ресурсов, поэтому общий сервер выберет метод пула, чтобы предоставить ограниченное количество пулов пар открытых и закрытых ключей, а затем каждый раз будет обновлять пул.
атака по пути к файлу
Многие операционные системы используют символ .. для обозначения верхнего каталога. Если хакер использует символ .. для ссылки на верхний каталог в пути URL-адреса, а сервер не принимает мер предосторожности, это может привести к тому, что хакер получит прямой доступ к файлам за пределами полномочий. Например, с помощью многоуровневого символа .. можно обратиться к корневому каталогу, а далее можно получить доступ к любому файлу. Так много серверов запрещают символ .. в пути URL, чтобы избежать атак. Атака по пути к файлу также является одним из методов атаки, которые любят использовать многие хакеры. Если ваш сервер имеет определенный объем трафика, откройте лог nginx, вы время от времени будете находить какие-то странные URL-адреса с кучей символов .. в них Появление таких URL-адресов указывает на то, что хакеры в сети пытаются атаковать ваш сервер. .
DNS-спуфинг
Протокол HTTP в значительной степени зависит от разрешения доменных имен DNS. Доступ к URL-адресу любого типа доменного имени должен получить IP-адрес целевой службы в процессе разрешения доменного имени, прежде чем он сможет успешно продолжиться. Если оператор, отвечающий за службу DNS, злонамеренно разрешает доменное имя в неверный IP-адрес, указывая на фишинговый веб-сервис. Если пользователи не знают, они могут отправить свою конфиденциальную информацию на поддельные серверы.
Используйте внешние HTTP-прокси с осторожностью
Будучи промежуточным узлом маршрутизации между клиентом и сервером, прокси-сервер HTTP выступает в роли мессенджера и транслятора. Если переводчик ненадежен, клиент получит неправильные возвращаемые данные. Это то же самое, что спуфинг DNS, который можно использовать для фишинговых атак на клиентов. Если переводчик небрежен, он может передать конфиденциальную информацию другим.
413 Request Entity Too Large
Когда клиент загружает изображение, которое слишком велико и превышает ограничение сервера, сервер возвращает ошибку 413.
414 Request-URI Too Long
URI, к которому обращается клиент, слишком длинный и превышает лимит, разрешенный сервером, и сервер возвращает ошибку 414.
202 Accepted
Часто используется для асинхронных запросов. Клиент отправляет запрос на сервер, и сервер немедленно возвращает 202 Accepted, указывающее, что запрос клиента был успешно получен. Сервер решает, как с этим поступить позже.Как правило, сервер резервирует интерфейс для клиента, чтобы запросить статус обработки.Клиент может выбрать обучение интерфейса, чтобы знать ход обработки и результат запроса.
POST-метод отправки данных
application/x-www-form-urlencoded
Он часто используется при отправке форм данных, а тело хранит перекодированные пары ключ-значение.
POST http://xyz.com HTTP/1.1
Content-Type: application/x-www-form-urlencoded;charset=utf-8
a=1&b=2&c=3&c=4
application/json
Используется при отправке структурированных форм, тело хранит строки JSON внутри. Протокол запросов ElasticSearch использует этот подход.
POST http://xyz.com HTTP/1.1
Content-Type: application/json;charset=utf-8
{"a": 1, "b": 2, "c": [3, 4]}
multipart/form-data
Часто используется при загрузке файлов. Этот формат более сложен, это специальный формат, предназначенный для поддержки многофайловой загрузки данных смешанной формы.
<form action="http://example.com/upload" method="post" enctype="multipart/form-data">
<p><input type="text" name="key1" value="value1">
<p><input type="text" name="key2" value="value2">
<p><input type="file" name="file1">
<p><input type="file" name="file2">
<p><button type="submit">Submit</button>
</form>
Пользователь заполняет форму и устанавливает файл для загрузки, нажимает «Отправить», и передаваемые данные выглядят примерно так:
POST /upload HTTP/1.1
Content-Length:xxxxx
Content-Type:multipart/form-data; boundary=----WebKitFormBoundaryKOThiwE6HubGib7j
Host:example.com
------WebKitFormBoundaryKOThiwE6HubGib7j
Content-Disposition: form-data; name="key1"
value1
------WebKitFormBoundaryKOThiwE6HubGib7j
Content-Disposition: form-data; name="key2"
value2
------WebKitFormBoundaryKOThiwE6HubGib7j
Content-Disposition: form-data; name="file1"; filename="file1name.png"
Content-Type: image/png
file1 content here
------WebKitFormBoundaryKOThiwE6HubGib7j
Content-Disposition: form-data; name="file2"; filename="file2name.jpeg"
Content-Type: image/jpeg
file2 content here
------WebKitFormBoundaryKOThiwE6HubGib7j--
Cookie
Файлы cookie, запрашиваемые браузерами, часто содержат конфиденциальную информацию. Сервер обычно сохраняет идентификатор сеанса текущего пользователя в файле cookie, а конкретное содержимое сеанса хранится на стороне сервера, а содержимое сеанса очень чувствительно.
Браузер будет передавать информацию о файлах cookie при запросе, а сервер найдет соответствующий контент сеанса в соответствии с идентификатором сеанса в информации о файлах cookie. Информация о разрешениях пользователя может храниться в содержимом сеанса.После получения этой части информации о разрешениях можно контролировать и изменять данные пользователя по желанию.
Из-за небезопасности протокола HTTP пакеты запросов легко перехватываются, а информация о сеансе в файлах cookie легко украдена. Одним из решений является запись информации о терминале пользователя и информации об IP-адресе в сеансе, и если эта информация внезапно изменится, пользователь должен будет принудительно пройти повторную аутентификацию.
Однако опытные хакеры могут подделывать пакеты, точно соответствующие реальному запросу пользователя. Наиболее тщательное решение — использовать протокол HTTPS.
Обычную информацию о файлах cookie можно получить с помощью сценариев Javascript. Если хакер каким-либо образом внедрит небезопасный скрипт на веб-страницу, получит файл cookie пользователя и отправит его на удаленный сторонний сервер, информация из файла cookie будет утеряна.
Два важных свойства файлов cookie
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly
Информация о файлах cookie, помеченная как «Безопасная», не будет передаваться в HTTP-запросах, она будет передаваться только в HTTPS-запросах во избежание утечки данных.
Информация о файлах cookie, помеченная как HttpOnly, не может быть получена через Javascript API, она будет отправлена только в запросе. Это может помешать хакерам украсть конфиденциальную информацию в файлах cookie через сценарии веб-страниц.
Файлы cookie (десерты) настолько вкусны, что хакеры всегда хотят делать всевозможные статьи с помощью файлов cookie.
CSRF(Cross-Site Request Forgery)
Подделка межсайтовых запросов CSRF имеет много псевдонимов, таких как One-Click Attack (атака одним щелчком мыши), например Session Riding (атака автостопом).
Если предположить, что на сайте блога сообщества для удаления отдельной статьи требуется только URL-адрес, информация о разрешении сеанса в файле cookie автоматически добавляется к запросу.
# 123456为文章的ID
http://example.com/blog/123456/delete
Затем, когда кто-то подделывает указанный выше адрес ссылки, чтобы соблазнить вас щелкнуть, например, через письма на сайте, частные чаты, комментарии в блогах, ссылки на изображения или ссылку, случайно созданную на каком-либо другом веб-сайте. Вы случайно нажали и потеряли свою статью. Итак, это называется атакой в один клик. Поскольку это заимствование вашей текущей информации о сеансе, вошедшей в систему, чтобы что-то сделать, это также известно как атака безбилетника.
Если в финансовой системе переводы также могут осуществляться через простой URL-адрес, опасность не является тривиальной.
Это требует, чтобы операции модификации не обрабатывались с помощью простых запросов GET. Но даже если в этом случае вы перейдете на POST-запрос, у хакеров все еще есть способ подделать запрос, то есть через iframe.
Хакеры подделали форму POST на каком-то другом сайте, чтобы соблазнить вас отправить ее. Если это обычная форма, встроенная в HTML-страницу, при ее отправке пользователем возникнут междоменные проблемы. Поскольку доменное имя текущего веб-сайта не соответствует целевому доменному имени, указанному в форме. Но если форма встраивается через iframe, междоменную проблему можно обойти, а пользователь и вовсе не подозревает.
Чтобы предотвратить атаки CSRF, форма POST умных веб-сайтов будет содержать скрытое поле CSRF_TOKEN. CSRF_TOKEN генерируется на основе информации о сеансе пользователя. При отправке формы токен сравнивается с информацией о сеансе пользователя. Если он совпадает, это действительный запрос на отправку.
<form method="POST" action="/blog/delete">
<label for="blog_id">博客ID</label>
<input type="text" name="blog_id" value="12345">
<input type="hidden" name="csrf_token" value="xxxxxxxxxxxx">
</form>
Хакеры должны получить CSRF_TOKEN, прежде чем они смогут использовать информацию о сеансе пользователя для реализации CSRF-атак, но CSRF_TOKEN должен быть сгенерирован на основе информации о сеансе пользователя. Хакеры не имеют информации о сеансе пользователя и, следовательно, не могут проводить CSRF-атаки.
XSS(Cross Site Scripting)
Если хакер сможет внедрить любой сценарий Javascript на вашу веб-страницу, он сможет взломать вашу учетную запись по своему желанию. Информацию о куках можно получить через Javascript, и вы можете использовать свою сессию для вызова каких-то секретных API, и эти действия выполняются тайно, и вы об этом даже не догадываетесь.
<div>
# 用户内容Start
<script>send_to_hacker(document.cookie)</script>
# 用户内容END
</div>
Этот тип атаки очень распространен на некоторых веб-сайтах с пользовательским контентом. Обычные веб-сайты блогов — это веб-сайты с пользовательским контентом. Пользователи могут создавать веб-страницы, редактируя контент.
Хакеры тоже пользователи. Он может отредактировать сценарий Javascript и отправить его в качестве контента. Если сервер плохо защищен, этот скрипт будет работать на сгенерированной веб-странице. Когда другие пользователи просматривают эту страницу, войдя в систему, это трагедия.
Предотвращение XSS обычно осуществляется путем замены содержимого выходного содержимого. В разных местах HTML-страницы будут действовать разные правила замены содержимого. Чаще всего используется кодирование объектов HTML для перекодирования некоторых специальных символов в содержимом между тегами HTML.
<div>
# safe now
<script>send_to_hacker(document.cookie)</script>
</div>
В атрибутах HTML-тегов, переменных Javascript, URL-адресов и кодов CSS также содержится некоторый пользовательский контент. Правила транскодирования отличаются. Конкретные методы можно найти в документации, связанной с Google.
перекрестный домен
Кросс-домен — это очень головная боль.
Если у вас есть несколько серверных служб, но только один интерфейс, и вы хотите разделить интерфейс и сервер, вы столкнетесь с междоменными проблемами. Когда вы обнаружите, что ваш интерфейс js вызывает серверные службы, консоль сообщает вам, что это не нормально. Потом мне пришлось повесить эти сервисы под одним доменным именем nginx и различать их по префиксу url.
В это время вы подумаете, что кросс-домены слишком раздражают. Поскольку междоменный доступ так раздражает, почему браузеры должны ограничивать междоменный доступ?
Или из соображений безопасности.
Давайте вернемся к описанному выше сеансу верховой езды, который заключается в том, чтобы выполнять какие-то действия на чужом сеансе.
Предположим теперь, что ваш браузер открывает сайт A и входит в систему, поэтому файл cookie записывает идентификатор сеанса. Затем вы случайно открываете другой сайт Б, который начинает выполнять какой-то вредоносный код, как только открывается страница этого сайта. Логика этих кодов заключается в том, чтобы вызвать API сайта А для получения данных сайта А, потому что можно использовать (Ride) файл cookie сеанса сайта А. И эти данные являются частными для пользователя. Таким образом, личная информация пользователя на сайте А украдена кодом на сайте Б. Это риск междоменного.
Но иногда мы хотим поделиться данными с разными сайтами, что нам делать?
ответJSONP & CORS
JSONP(JSON Padding)
JSONP реализует способ обмена данными между доменами с помощью тегов сценария HTML. JSONP определяет метод обратного вызова на веб-странице, а затем вставляет на страницу динамический тег сценария, указывающий на целевой вызывающий адрес. Сервер вернет кусок кода javascript, обычноsome_callback(data)Это форма обратного вызова. Этот фрагмент кода автоматически выполняется в браузере, поэтому веб-страница получает данные, возвращаемые междоменным сервером.
<script>
function some_callback(data) {
console.log(data)
}
</script>
<script src="http://example.com/someapi?callback=some_callback"></script>
Поскольку JSONP не содержит информации о файлах cookie, он может эффективно предотвращать атаки безбилетников. Чтобы JSONP мог получать данные, также требуется, чтобы сервер обеспечивал поддержку отображения для этого вызова.Сервер должен вернуть данные в виде кода javascript, прежде чем их можно будет передать в браузер.
CORS(Cross-Origin Resource Sharing)
Недостатком JSONP является то, что он может отправлять только запросы GET и не может передавать файлы cookie. CORS, с другой стороны, может отправлять запросы любого типа и при необходимости содержать файлы cookie.
CORS — это технология междоменных запросов, отправляемая через Ajax. Запросы CORS делятся на два типа: простой запрос и сложный запрос. Простой запрос — это запрос GET/HEAD/POST с несколькими очень простыми заголовками. Сложный запрос — это не простой запрос.
Когда браузер обнаружит, что запрос Ajax является междоменным, он добавит в заголовок запроса параметр Origin, указывающий источник исходного сайта текущего запроса. Сервер решает, следует ли авторизоваться в соответствии с параметром Origin.
Если это простой запрос, Ajax запрашивает сервер напрямую. Сервер вернет содержимое напрямую, как обычный запрос. Разница в том, что к заголовку ответа будет добавлено несколько важных заголовков.Access-Control-Allow-Origin: http://example.com.
Если браузер не прочитает этот заголовок в ответе, он сообщит, что запрос Ajax не удался. Хотя сервер возвращает данные, браузер не позволяет скрипту прочитать данные, что обеспечивает междоменную безопасность. Сервер решает, следует ли отвечать на заголовок Access-Control-Allow-Origin через параметр Origin запроса, чтобы решить, разрешить ли междоменный запрос указанного веб-сайта.
Если это сложный запрос, вам необходимо пройти процесс предварительной проверки. Предварительная проверка означает, что браузер сначала отправляет запрос с методом в качестве параметров на сервер.Если сервер разрешает междоменные запросы, браузер затем инициирует запрос Ajax. Таким образом, сложные запросы с CORS будут занимать дополнительное время TTL, чем простые запросы.
Для получения подробной информации о CORS, пожалуйста, обратитесь к сообщению в блоге «Подробности о междоменном совместном использовании ресурсов CORS» Руана Ифэна.
Читайте статьи по теме, обратите внимание на публичный номер【дворовая дыра】