Потенциальные уязвимости безопасности в реализации билетов

Question

Я пытаюсь провести мозговой штурм по потенциальным уязвимостям безопасности для этого сценария (кстати, я задал связанный вопрос несколько дней назад , однако из ответов я понял, что объясняю сценарий EXACT Это чрезвычайно важно, потому что многие ответы были (немного) неуместны из-за этого. Я также включил уязвимости, которые я определил до сих пор, и способы их устранения, поэтому отзывы о них будут оценены. Итак, мы идем :

a) Вся система будет представлять собой систему «билетов», но не обычный билет, а «систему пропусков». Значение: клиент идет и заказывает «пропускающий» билет, который дает ему доступ к определенным льготам в определенных местах (например, бесплатный вход в музеи) на КОНКРЕТНЫЙ период времени. Это означает, что это билет, срок действия которого истекает через 1-7 дней (но не более 7 дней).

б) «Поток» пользователя:

1. Пользователь заходит на сайт, заказывает билет на определенный период времени, который дает ему льготы в определенных местах (музеях и т. Д.)
2. После успешного заказа веб-сайт печатает строку из 6 букв (идентификатор). Пример: GFZ-GFY. Есть 26 ^ 6 (~ 308 миллионов) потенциальных комбинаций. Конечно, эти идентификаторы будут храниться в защищенной базе данных.
3. Затем пользователь идет в музей (или другое место) и показывает строку из 6 букв. Сотрудник проверяет его действительность с помощью веб-приложения или отправляя SMS-сообщение на номер, сразу же получая статус действительности (в обоих случаях код будет запрашивать базу данных для проверки действительности билета).

Пока что я выявил 2 потенциальных проблемы:

а) Атаки грубой силой

Там будет 2 "поверхности атаки", под которыми это может происходить:

1. Сотрудник музея будет иметь закрытый доступ к веб-приложению (для проверки действительности билета). Способ, которым я смягчаю это, ограничивает количество просмотров до 1000 в день для каждой учетной записи пользователя.
2. Пользователь сможет проверить статус своего заказа. Я уменьшу это несколькими способами: во-первых, URL-адрес не должен быть «общедоступным» и доступен только пользователям, которые приобрели билет. Во-вторых, я реализую ReCaptcha v3 , запрет IP на более чем 10 неудачных запросов в час.
3. Ожидается, что количество «активных» билетов за раз будет 5000 (на пике), обычно будет около 500-1000, так что, учитывая сотни миллионов комбинаций, потребуется значительное усилие для злоумышленник перебивает путь через это.

Второй (и более простой) подход, который может использовать злоумышленник, - это просто купить билет и переиздать его, либо опубликовать в Интернете для любого использования. Я буду смягчать это путем:

1. После того, как музей проверит действительность пропуска, если они проверят его еще раз, появится уведомление о том, что в данный момент этот пропуск проверен в этом месте: [дата-время].
2. Хотя я планирую повторно использовать тот же код, я позабочусь о том, чтобы между периодами был период не менее 90 дней. Возможно, в этом есть какая-то уязвимость, о которой я не знаю. Код МОЖЕТ или МОЖЕТ не использоваться снова через 90 дней после истечения срока его действия. Все, что я говорю, это то, что он будет выпущен в «пуле» потенциальных (более 300 миллионов) кодов, которые могут быть использованы. Может быть, это не очень хорошая идея?
3. Клиенту будет предоставлен (отправлен по адресу или получен запрос на получение) пустой билетный билет, на котором будет написан код (или ему придется написать код с ручка на билете). Это усложнит атаку, поскольку теперь злоумышленнику потребуется иметь ОБА доступ к коду + принтер, который может печатать такие карты с тем же материалом.

Видите ли вы еще какие-нибудь потенциальные атаки, которые можно было бы сделать? Есть ли что-то, чего мне не хватает в моих нынешних подходах к смягчению?

Answer 1

Вы, кажется, потратили приличное количество времени на обдумывание этого, и вы определили свои самые большие потенциальные поверхности атаки.

Martinstoeckli определяет, что я бы назвал следующими величайшими проблемами, подняв потенциал внедрения SQL-кода и грубой силы. По моему опыту, лучшим средством снижения уровня SQL-инъекций будет просто убедиться, что все входные данные должным образом очищены. Проблема грубой силы никогда не может быть полностью решена, и ключ из 6 символов довольно легко взломать. Включение использования KDF может показаться хорошей идеей, но вы также должны подумать о влиянии производительности на вашу базу данных. С оценкой 500-1000 пользователей / ключей я не думаю, что это будет огромной проблемой.

Я бы рекомендовал не использовать ключи повторно, потому что в зависимости от того, как они хранятся, это может привести к атакам коллизий хэшей через некоторое время, в зависимости от особенностей их хранения.

После этих проблем я бы порекомендовал изучить особенности того, как вы размещаете это приложение. Он размещен на физическом сервере, к которому у вас есть доступ, или это виртуальная машина, находящаяся где-то в облаке? Каждый из них будет иметь свои риски.

Answer 2

Я бы также планировал на случай, если ваша база данных взломана, например, через SQL-инъекцию. Вместо того, чтобы хранить простые текстовые коды, вы можете использовать любую приличную функцию хэширования пароля и хранить только хэш кода. Процедура проверки такая же, как с паролями.

Если нет идентификатора пользователя, код должен быть восстановлен с помощью запроса к базе данных, тогда вы не можете использовать засолку. В этом случае мы можем использовать функцию деривации ключа (KDF), которой требуется некоторое время для вычисления хэша, чтобы сделать грубое форсирование более сложным. Недостающая соль приводит к следующему пункту:

Я бы чувствовал себя комфортнее, используя более длинные коды. Если я правильно прочитал таблицу, вероятность найти действительный код с вашей настройкой (~ 28 бит / 3000 активных кодов) составляет около 0,001 из-за проблемы дня рождения . Коды с 9 символами, вероятно, являются хорошим компромиссом, так как они нечувствительны к регистру, они все же могут быть набраны быстро, но допускают комбинации 5E12. Такие коды можно оставить в базе данных, так что можно сказать, что срок действия билета истек, и нет необходимости использовать его повторно. Брут-форсинг 3 миллиона хэшей не является большим препятствием даже с KDF, а брут-форсинг с комбинациями 5E12 - гораздо большая проблема.