Безопасность при передаче параметров в открытую

Статус
В этой теме нельзя размещать новые ответы.

Albert22

Старатель
Регистрация
30 Мар 2008
Сообщения
270
Реакции
11
Привет!
Хотелось бы задать один вопрос на примере того, как это реализовано ВКонтакте. У них, при загрузке файла на удалённый сервер, в атрибуте action тега form указывается постоянное значение mid — это id загружающего файл юзера. Очевидно, что подменить его труда не составит, потому рядом передаются ещё и два хеша. Вот код:
HTML:
<form enctype="multipart/form-data" method="post" action="http://сs123.vkоntаktе.ru/uplоаd.рhр?асt=profile&mid=123456&hash=3c1976d177...&rhash=df83ed6771...&vk=" name="editPhoto" id="editPhoto">
Я столкнулся с необходимостью реализовать подобный алгоритм, однако я полностью понимаю только схему с одним хешем — например, в него загоняем текущий IP-адрес юзера, "соль", ещё что-то, хешируем посредством md5() и передаём это всё в виде хеша рядом с открытым номером (в примере это mid), который в итоге (на конечном сервере) подвергаем тем же преобразованиям и смотрим, совпадают ли они.
Но я догадываюсь, что это — не лучший вариант. Как минимум потому, что ВКонтакте используют сразу два хеша.
Правильно ли это утверждение? Имеются ли готовые, общепринятые методики открытой и в то же время защищённой от подмены передачи параметров? Объясните, пожалуйста, как наиболее оптимально реализовать данную задачу?
Заранее спасибо!
 
Ну захешируй во втором юзер_агента и еще чтонибудь так точно подмена не прокатит.
 
Я юзер агента в первом хешировал. А во втором думал перехешировать первый с ещё какой-то солью. Или как раз с юзер агентом... Но я по-прежнему не уверен в этом варианте.
 
Еще и имя сессии добавь. 100% уникальный хеш будет.
 
Еще и имя сессии добавь. 100% уникальный хеш будет.
Спасибо за совет, но есть одно "но": запрос адресован на другой сервер, там же выполняется и проверка. Текущая сессия и все её данные там будут недоступны...
 
А кто мешает сгенерировать хеш(пусть это будет кокраз 2 хеш,с первым вроде более менее понятно), согранить его в базе вмести с ид пользователя. и на том сервере проверить. Есть ли в базе запись такая если есть загружам нет пошол нафиг.
 
А кто мешает сгенерировать хеш(пусть это будет кокраз 2 хеш,с первым вроде более менее понятно), согранить его в базе вмести с ид пользователя. и на том сервере проверить. Есть ли в базе запись такая если есть загружам нет пошол нафиг.
Спасибо, неплохая идея, но работа с базой данных усложняет процесс. Требуется время на запросы, их обработку, очистку от использованных хешей. Более того, пользователь может открыть страницу загрузки, хеш создастся. Пользователь уйдёт со страницы загрузки, а хеш останется висеть в БД. И как определить удалять его или нет? Делать json-запрос по событию onunload? А если он просто оставил её открытой и отошёл на час? Действительно всё усложняется, лучше просто сверить. Главное — знать как...
 
Если не сикрет зачем такая проверка??
 
Если не сикрет зачем такая проверка??
Не секрет :)
Какая "такая"? Как по мне — обычная. На то она и проверка чтобы обеспечить максимальную безопасность и защиту от подмены, и если она сделана тяп-ляп и через жопу, при этом не справляется с задачей, то проверкой это называть нельзя.
 
Не совсем понятна ваша проблема. Вы хотите, чтобы пользователи друг другу файлы не закачивали?

Для этого надо просто передавать id пользователя и md5(id пользователя+соль).

На принимающей стороне делать проверку и всё. И тут не нужен ни ip, ни агент.

А в общем случае вариант с использованием бд и записью туда массива $_session самая правильная. У вас будет для маневра больше возможностей.

По поводу чистить: если пользователь отошел на час, пусть логиниться вновь, это нормальные правила игры, а вы будете спать спокойно.
 
Статус
В этой теме нельзя размещать новые ответы.
Назад
Сверху