Второй подход

О чём речь

Итак, secureshare.pw — сервис одноразовых ссылок. Т.е. это средство безопасной передачи конфиденциальных данных другому человеку. Суть в том, что секретные данные пользователя сохраняются в базе данных сервера, а пользователю даётся одноразовая ссылка, по которой доступны эти самые данные. Ссылка действительна только один раз и сразу после первого просмотра данные уничтожаются. Можно не бояться того, что ссылка останется в истории сообщений вашего IM-сервера, в списке отправленных писем, в access-логах сервера, на скриншотах мониторов. К тому времени, когда злоумышленник доберётся до этой ссылки, она будет уже бессмысленна.

Первый подход

Базовый функционал системы очень прост. Всё, что нужно — сохранить данные из формы в базу данных, и выдать юзеру ссылку, однозначно идентифицирующую эти данные. Например, добавить в get-параметр primary key. После показа данных выполнить элементарный DELETE-запрос, и готово. После первого подхода система в точности так и работала.

Но как-то это несерьёзно, не так ли?

Второй подход

Ну, давайте подумаем, что тут не так. Первое, что бросается в глаза — primary key прямо в get-параметрах запроса. То есть, если перебирать все числа по очереди, можно насобирать много чужих секретов (была в январе история со взломом файлов ICQ). Решение достаточно очевидно — использовать вместо числа что-то большое и неподбираемое. Скажем, sha1-хеш (в md5 нашли коллизии и его уже не рекомендуется использовать). Отлично, добавляем в БД новое поле, делаем по нему UNIQUE индекс, и генерируем его случайным образом для каждого нового пользовательского секретика. Уже лучше.