Как обезопасить сайт?

175

19 июня 2017, 21:45

Вечер добрый!

Имеется следующая схема работы: 1. api, разработанное на laravel 2. веб-морда на html+js

Все действия выполняются запросами к api. Пользователь вводит логин-пароль, получает api_token, который записывается в cookie и все запросы уже выполняются уже с использованием api_token.

api_token постоянный. Вопрос: насколько небезопасна эта система и что можно сделать, чтобы обезопасить её от вредоносных действий? Например, от кражи токена. Если иметь принять, что api_token будет постоянный - какие подводные камни? Как лучше проверять по кукам, "правильный" ли пользователь выполняет действия?

Нужно ли делать временный токен?

Не обязательно все ответы, достаточно наводящих слов, чего почитать. Спасибо!

Answer 1

Любая безопасность начинается с представления о том, от чего мы защищаемся.

К примеру, на компьютере пользователя установлен троян, который может эти куки украсть. Но при таком подходе украсть можно и логин с паролем. Зато можно дать пользователю бумажку и научить его генерить одноразовые пароли. Альтернативно, отсылаем пароли с голубями. Но надо помнить, что голубя можно перехватить, равно как и смс-сообщение, бумажка будет безопаснее. Но бумажку можно выкрасть.

Если на сайте нету https, то куки видит каждый, кому не лень. Если при этом нет HSTS, то рано или поздно будет палево. Это подсказывает, что безопасность - комплексная штука и пренебрегать ей не следует. Зато можно и теперь модно хранить какой-то ключ в LocalStorage, которым подписывать каждый запрос. Осталось понять, как эти ключи генерить и валидировать.

Answer 2

Куку проще украсть, чем логин/пароль. Поэтому токены желательно делать временными. Но чтобы не раздражать пользователя вводом логина и пароля: нужно продумать, как её актуализировать.

Безопасность тут больше упирается не в то, делать ли временной куку, внимание следует уделить следующим вещам:

Способ генерации токена.
Шифрование паролей в БД с солью.
CSRF защита, хотя-бы базовая.
XSS уязвимости, БД-уязвимости сайта.
Отображение пользователю в интерфейсе - с каких IP он заходил, на каких адресах/браузерах он в данный момент авторизован.
Проверка по смс в случае подозрения на взлом. Подозрение - это естественно тоже алгоритм.
Обязательное хождение админов, или важных пользователей под https. Иначе токен украсть просто при желании.
Безопасность самих серверов: открытыми должны быть только необходимые порты, остальные видны только в сети серверов, запрещение входа под root из ssh напрямую, и.т.п.

Можно ещё много чего привести в пример - почти любая дыра открывает возможность получения доступа к пользователю.

Но главное надо помнить - если вы разрабатываете проект не для хранения секретных документов ФСБ, и не огромную высоконагруженную соц-сеть: то возможно врядли кому-то будет интересно взламывать ваших пользователей. Если же боитесь за взлом админа - просто ограничьте админство по IP, например, или введите двойную авторизацию только админу. Всякая безопасность - в меру.