Выглядит всё красиво, логично и... безопасно?
А что если...
А что если у вас некий Вася Пупкин плохо написал серверную часть (бэкенд)?
Он принимает на веру все данные, которые ему отправил пользователь за чистую монету и с этими данными дальше работает.
Допустим, Вася написал у себя на сервере такой код:
- получить с формы данных сайта сумму для списания денег со счёта пользователя и записать это значение в переменную amount;
- найти в базе данных пользователя с указанным userID;
- вычесть эту сумму у пользователя. Например, так:
SET user_amount = user_amount - @amount FROM users WHERE user_id = @userID
Выглядит логично.
Но.
Наш Вася не делает никаких проверок на вводимые данные.
Про SQL-Injection мы поговорим позже, сейчас мы о другом.
А что, если пользователь (который теперь уже в наших глазах становится злоумышленником), вместо отправки вам 10 долларов введёт -10 (минус десять) делларов?
Что тогда произойдёт?
Давайте снова посмотрим на код Васи Пупкина:
SET user_amount = user_amount - (-10) From users ...
Понимаете теперь?
Минус на минус даёт плюс! Злоумышленнику вместо списания 10 долларов они наоборот начислятся! И он станет на 10 долларов богаче. Ну почему на 10? Что мешает вместо 10 долларов ввести 100 или... Ну дальше вы сами мечтайте...
Как от этого защититься?
Ну, первое правило - это фильтрация всех входных данных. Нельзя вводить ничего кроме цифр, нельзя вводить отрицательные числа, спецсимволы, ввести ограничение на большие числа, и на маленькие тоже. Проверяйте всё.
Это нужно делать как на стороне фронтенда (сайта), так и на стороне бэкенда, когда вы получаете данные от клиента. Не забывайте, что клиент-злоумышленник может обойти первичную защиту на фронтенде и вы априори не должны доверять тем данным, которые к вам приходят.
Подпись и MITM.
Ну хорошо. У нас все защиты и проверки стоят, всё замечательно.
Тётя Клава приходит на ваш сайт, вводит сумму для оплаты товара на 1 доллар, но у неё со счёта списывается 100 долларов. И при этом эти деньги уходят какому-то другому пользователю этого сервиса! Как такое возможно?
Поверьте, что такое часто было в конце 1990-ч - начале 2000-х годов, когда на сайтах не было HTTPS и была возможность MITM-атак (Man-In-The-Middle).
Пока не изобрели HTTPS платёжные системы защищались с помощью цифровой подписи.
Давайте разберёмся, как же украли деньги у тёти Клавы.
Представим ситуацию, что тётя Клава пришла в свою любимую кафешку с бесплатным вайфаем, подключилась к нему и сёрфит в интернетике. Но в этой кафешке есть злой хакер-админ, который видит всё, что пишет и отправляет наша Клава в интернет (не забывайте, у нас нет безопасного HTTPS, есть только HTTP). Но мало того - он может подменять все данные, которые она отправляет в сеть, и подменять то, что она получает. Допустим, тётя Клава делает покупку на 1 доллар, а злой-хакер заменяет 1 на 100 долларов и в итоге с её счёта списывается 100 долларов вместо 1.
Умные программисты придумали способ как от этой проблемы защититься.
И придумали цифровую подпись.
... дальше про хэши
... дальше про хэши
про коллизии
про брутфорс
ограничение на вводимые данные, защита от радужных таблиц
