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

Тема в разделе "PHP", создана пользователем Albert22, 8 ноя 2009.

Статус темы:
Закрыта.
Модераторы: latteo
  1. Albert22

    Albert22

    Регистр.:
    30 мар 2008
    Сообщения:
    270
    Симпатии:
    10
    Привет!
    Хотелось бы задать один вопрос на примере того, как это реализовано ВКонтакте. У них, при загрузке файла на удалённый сервер, в атрибуте 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), который в итоге (на конечном сервере) подвергаем тем же преобразованиям и смотрим, совпадают ли они.
    Но я догадываюсь, что это — не лучший вариант. Как минимум потому, что ВКонтакте используют сразу два хеша.
    Правильно ли это утверждение? Имеются ли готовые, общепринятые методики открытой и в то же время защищённой от подмены передачи параметров? Объясните, пожалуйста, как наиболее оптимально реализовать данную задачу?
    Заранее спасибо!
     
  2. afonya09

    afonya09

    Регистр.:
    31 янв 2009
    Сообщения:
    260
    Симпатии:
    18
    Ну захешируй во втором юзер_агента и еще чтонибудь так точно подмена не прокатит.
     
  3. Albert22

    Albert22

    Регистр.:
    30 мар 2008
    Сообщения:
    270
    Симпатии:
    10
    Я юзер агента в первом хешировал. А во втором думал перехешировать первый с ещё какой-то солью. Или как раз с юзер агентом... Но я по-прежнему не уверен в этом варианте.
     
  4. afonya09

    afonya09

    Регистр.:
    31 янв 2009
    Сообщения:
    260
    Симпатии:
    18
    Еще и имя сессии добавь. 100% уникальный хеш будет.
     
  5. Albert22

    Albert22

    Регистр.:
    30 мар 2008
    Сообщения:
    270
    Симпатии:
    10
    Спасибо за совет, но есть одно "но": запрос адресован на другой сервер, там же выполняется и проверка. Текущая сессия и все её данные там будут недоступны...
     
  6. a1ien.n3t

    a1ien.n3t Постоялец

    Регистр.:
    12 июл 2008
    Сообщения:
    52
    Симпатии:
    7
    А кто мешает сгенерировать хеш(пусть это будет кокраз 2 хеш,с первым вроде более менее понятно), согранить его в базе вмести с ид пользователя. и на том сервере проверить. Есть ли в базе запись такая если есть загружам нет пошол нафиг.
     
  7. Albert22

    Albert22

    Регистр.:
    30 мар 2008
    Сообщения:
    270
    Симпатии:
    10
    Спасибо, неплохая идея, но работа с базой данных усложняет процесс. Требуется время на запросы, их обработку, очистку от использованных хешей. Более того, пользователь может открыть страницу загрузки, хеш создастся. Пользователь уйдёт со страницы загрузки, а хеш останется висеть в БД. И как определить удалять его или нет? Делать json-запрос по событию onunload? А если он просто оставил её открытой и отошёл на час? Действительно всё усложняется, лучше просто сверить. Главное — знать как...
     
  8. afonya09

    afonya09

    Регистр.:
    31 янв 2009
    Сообщения:
    260
    Симпатии:
    18
    Если не сикрет зачем такая проверка??
     
  9. Albert22

    Albert22

    Регистр.:
    30 мар 2008
    Сообщения:
    270
    Симпатии:
    10
    Не секрет :)
    Какая "такая"? Как по мне — обычная. На то она и проверка чтобы обеспечить максимальную безопасность и защиту от подмены, и если она сделана тяп-ляп и через жопу, при этом не справляется с задачей, то проверкой это называть нельзя.
     
  10. bubchen

    bubchen Создатель

    Регистр.:
    7 окт 2006
    Сообщения:
    13
    Симпатии:
    4
    Не совсем понятна ваша проблема. Вы хотите, чтобы пользователи друг другу файлы не закачивали?

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

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

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

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