g_hagmt
@g_hagmt
Начинающий веб-разработчик

Насколько сложно защитить веб-приложение от основных видов атак?

Насколько я знаю и понимаю, самые популярные виды атак это:
Различного вида инъекции (особенно выделяют SQL), XSS, CSRF, Брутфорс, DDoS.
Изучая тему ИБ в контексте веб-разработки, я сделал для себя некоторые выводы, и хотел уточнить, не ошибаюсь ли я в чем-то, и не упускаю ли чего:

  1. Все данные, которые поступают от клиента, нужно проверять на валидность, и во многих случаях экранировать;
  2. URL, вводимый пользователем должен сверяться с белым списком;
  3. Не должно быть url-адресов, которые без подтверждения пользователя выполняют какие-то действия на сайте;
  4. POST предпочтительней GET;
  5. При возможности, стоит включить CSP;
  6. Все важные данные нужно хешировать (последним поколением хеш функций);
  7. Необходимо использовать https протокол (тем более, СЕО...);
  8. В куки не следует хранить конфиденциальную информацию, кража которой могла бы навредить;
  9. При регистрации пользователя требовать некоторого уровня надежности пароля;
  10. При нескольких неудачных попытках входа с одним и тем же логином, или на одном ip, нужно добавить паузу и/или капчу, в определенных случаях блокировать ip;
  11. Чтобы в некоторой степени защититься от DDoS атак, неплохо бы написать скрипт, который в случае превышения определенного лимита connect/time с одного ip, блокировал бы этот ip.


Вероятно, многое из этого вполне очевидно, но все же... Разумеется, все написанное выше должно применяться в большей степени к сайтам, которые требуют некоего уровня защищенности, а не абсолютно ко всем. Я с большой вероятностью мог что-то не учесть, или где-то ошибиться поэтому спрашиваю вашего мнения. Заранее спасибо.
  • Вопрос задан
  • 225 просмотров
Решения вопроса 2
DevMan
@DevMan
1.да
2.нет
3.да
4.нет
5.да
6.нет
7.да
8.да
9.otp лучше
10.да
11.да/нет
Ответ написан
Jump
@Jump
Системный администратор со стажем.
1.Да
2.Не вижу особого смысла, хотя иногда может быть и полезно.
3.Адрес это адрес, он не может выполнять какие-то действия. Так что высказывание не имеет смысла.
4.С чего бы это?
5.Если это необходимо.
6.Зачем??? Ну что изменится что вы рассчитаете хэш у каких то данных??? Дичь какая-то.
7.Да
8.Да
9.Возможно. Зависит от ситуации, смотря как сделаете, ибо может и навредить.
10.Разумно
11.В некоторых случаях может и поможет.

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

А вы похоже просто пытаетесь защититься какими-то действиями сами не понимая для чего оно и зачем. По такому принципу можно еще вязанку чеснока над сервером подвесить - старые люди, говорят очень хорошо в плане защиты от всякой фигни.
Ответ написан
Пригласить эксперта
Ответы на вопрос 2
dollar
@dollar
Делай добро и бросай его в воду.
Зависит от того, что за конкретное приложение и кому может понадобиться его ломать, сколько он готов будет вложить времени и денег. Ответ на это определит возможный вектор атак и соответствующие меры и стоимость защиты.

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

В общем, вы сейчас пытаетесь изобрести универсальный рецепт приготовления обеда из абстрактных ингредиентов в вакууме. Выбирайте, либо вы тратите кучу времени на чтение кучи книг и изучение темы ИБ в целом, либо вы решаете конкретную задачу и изобретаете что-то своё или берёте от ИБ то немногое, что понадобится в рамках этой задачи. А просто перечислить в 300 символов, что хорошо и что плохо, - не получится.
Ответ написан
inoise
@inoise
Solution Architect, AWS Certified, Serverless
Все данные, которые поступают от клиента, нужно проверять на валидность, и во многих случаях экранировать;

Ваш КЭП. Только что касается экранирования тут все куда сложнее чем тебе кажется

URL, вводимый пользователем должен сверяться с белым списком;

Ну, неплохая идея, если бы белый список не был бы такой что вы его никогда не составите. Как и черный список. Скорее тут надо вводить дополнительные системы мониторинга и модерации

Не должно быть url-адресов, которые без подтверждения пользователя выполняют какие-то действия на сайте;

Ну не делай их

POST предпочтительней GET;

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

При возможности, стоит включить CSP;

Можно, но это уже так, с боку бантик

Все важные данные нужно хешировать (последним поколением хеш функций);

Особенно нравится все и последним поколением. Идея в примерно отдаленно верном направлении, а формулировка все портит и говорит "пойди почитай матчасть про хэширование"

Необходимо использовать https протокол (тем более, СЕО...);

Хорошая идея, но, только не так. Читай про SSL/TLS

В куки не следует хранить конфиденциальную информацию, кража которой могла бы навредить;

Есть целый блок ИБ про Sensitive Information. Нужно понимать что это и понять что куки это всего одно из миллиона мест

При регистрации пользователя требовать некоторого уровня надежности пароля;

Лесом. Эта практика умирает как и ротация паролей - даже Microsoft отказывается от таких практик в Active Directory. В области Web так вообще пароли редкость уже для сервисов ибо есть социальные логины, SSO, мультифактор и много еще чего

При нескольких неудачных попытках входа с одним и тем же логином, или на одном ip, нужно добавить паузу и/или капчу, в определенных случаях блокировать ip;

Можно, но это опять - с боку бантик

Чтобы в некоторой степени защититься от DDoS атак, неплохо бы написать скрипт, который в случае превышения определенного лимита connect/time с одного ip, блокировал бы этот ip.

Мимо. Просто мимо. Читать матчасть

По сути про ИБ тут ничего от слова совсем. По крайней мере кроме валидации данных и SSL ничего действительно серьезного не затронуто. Я бы сказал что тут от ИБ и сотой доли процента нет
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы