Как обезопасить проект с полностью раздельным фронтендом и бекендом?

Question

[Crash]

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

Соответственно меня тревожат вопросы по безопасности, т.к. это моя зона ответственности.
В частности - как сделать безопасной аутентификацию?

Пока я сделал так: например, при логине в личный кабинет на сервере генерится и сохраняется в БД токен, отдается фронту, тот сохраняет его в куках или local storage, при каждом GET или POST запросе на бэк передается этот токен, сравнивается с тем что сохранен в БД и если он найден, то разрешаются дальнейшие действия. Токен связан с идентификатором пользователя и имеет ограниченное время жизни.

Насколько это безопасно и как защититься от подделок запросов в целом?
Какие еще вопросы по безопасности нужно закрыть?

Answer 1

[Александр Аксентьев]

Какие еще вопросы по безопасности нужно закрыть?

ровно всё тоже самое что и при монолитном приложении.
пишите нормальный код без дыр в виде sql инъекций и всякого такого.

Насколько это безопасно и как защититься от подделок запросов в целом?

для вас неважно подделка это или нет.
Запросы выглядят одинаково и в случае отправки с сайта, и в случае отправки например каким-нибудь скриптом "злоумышленника".
Если надо защиту, то делайте проверку авторизации и лимит на количество запросов.
Больше вы ничего не сделаете.

В общем разделение не переворачивает весь сайт с ног на голову, это все тот же сайт со стандартными "угрозами" и защитой от них.

Comments

[Alex Wells]

Только не нужно капчу на сайт вешать - лишь усложняет трем сторонам жизнь.

Ну либо внешний, отдельный API без капчи делайте)

[verycooldev]

Alex Wells, это прикол? Говорить о капче на Тостере. Чтобы написать тебе этот ответ я только что заполнил 12 КАПЧ. ДВЕНАДЦАТЬ КАПЧ. Да не простых, а знаешь таких дооооолгих, где Гугл МЕЕЕЕЕДЛЕННО меняет картинку.

ЗЫ если честно после регистрации здесь я офигел что надо капчу заполнять перед каждым ответом. Кроме того, не дают задать больше одного вопроса в сутки. Ребята, до свидания, я ухожу на англ ресурсы, варитесь в этих помоях сами))) Рунет такой рунет

[Alex Wells]

verycooldev, што, какие капчи на тостере? Только когда пишешь вопрос нужно галочку нажать, и все)

Ты с windows xp на старом internet explorer сидишь что ли?)

[batyrmastyr]

Alex Wells, известно какие - дебильные. На линуксе часто выводятся, на мобилке пока ни разу. Отдельно бесит её тупые настройки её работы - нажал кнопку перед тем как писать ответ, "норм, ты человек, а пока пишешь тебе хрясь и "время проверки истекло, теперь я тебе на слово не верю, угадай где тут дорожный знак. И ещё раз или два", сука. Хотя, казалось бы, если я долго набиваю текст, то с фига ли переставить верить в то, что я человек?!

Answer 2

[Алексей Елецкий]

Тут две задачи стоит:

- обезопасить общение между клиентом и фронтендом
- обезопасить общение между фронтендом и бэкендом

Первое делается известными методами, я думаю их перечислять не надо.

Второе можно делать по-разному:

- можно организовать закрытую сеть между всеми серверами (варианты разные: от vpn, до физически отдельной сетки).
- можно делать https соединения, проверяя сертификаты друг друга
- можно подписывать сообщения, например с помощью https://en.wikipedia.org/wiki/HMAC

Можно даже всё вместе сделать - зависит от уровня паранойи.

Передавать креды пользователя в открытом виде, само собой, нельзя. Нужно обезопасить само соединение (например, https использовать) или сами креды (шифровать ключом, известным только фронтенду и бекенду).

Comments

[Станислав Б]

если я правильно понимаю, у автора вопроса на бек идут запросы напрямую из браузера.
и получается вопрос как раз попадает под "Первое делается известными методами, я думаю их перечислять не надо."

[Алексей Елецкий]

Почему тогда речь про разные сервера?

Нужно чтобы автор вопроса уточнил этот момент.

[Crash]

Алексей Елецкий, запросы на бэк действительно идут напрямую из браузера, по абсолютным url. Сервера разные.

[Алексей Елецкий]

Тогда всё правильно сделано. Делается идентификатор сессии и передаётся с запросами.

Дополнительно можете сделать общение по https, тогда перехватить трафик простым способом у злоумышленника не получится, а значит и получить идентификатор сессии он не сможет.

[hckn]

Алексей Елецкий, чушь какая-то.

обезопасить общение между клиентом и фронтендом

клиент === фронтенд. о каком вообще общении может идти речь - загадка

[Алексей Елецкий]

Фронтендом разное называют. Не всегда это то, что на стороне клиента.

Answer 3

[Марат Мхитарян]

1. Хорошо бы OWASP.org прочитать, чтобы знать что такое SQL иньекции и XSS.
2. Перестаньте делать велосипед, когда вы делаете его опять и опять повышаеться вероятность обосраться, поэтому используйте фреймворки. На пример django-rest-framework

Comments

[Crash]

мы и так используем фреймворки, в данном случае Yii2

[SagePtr]

Плюс про CSRF прочитать, про CSRF многие забывают и пренебрегают им, а это способ скормить серверу запрос от имени авторизованного пользователя, заманив самого пользователя на вредоносную страницу.

[Марат Мхитарян]

SagePtr, В OWASP TOP 10 все это есть