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

 Насколько я знаю и понимаю, самые популярные виды атак это:  

Различного вида инъекции (особенно выделяют 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.

  
  

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

 1.да  

2.нет  

3.да  

4.нет  

5.да  

6.нет  

7.да  

8.да  

9.otp лучше  

10.да  

11.да/нет 

 1.Да  

2.Не вижу особого смысла, хотя иногда может быть и полезно.  

3.Адрес это адрес, он не может выполнять какие-то действия. Так что высказывание не имеет смысла.  

4.С чего бы это?  

5.Если это необходимо.  

6.Зачем??? Ну что изменится что вы рассчитаете хэш у каких то данных??? Дичь какая-то.  

7.Да  

8.Да  

9.Возможно. Зависит от ситуации, смотря как сделаете, ибо может и навредить.  

10.Разумно  

11.В некоторых случаях может и поможет.  
  

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

После этого нужно составить план защиты, и уже по этому плану работать.  
  

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

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

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

В общем, вы сейчас пытаетесь изобрести универсальный рецепт приготовления обеда из абстрактных ингредиентов в вакууме. Выбирайте, либо вы тратите кучу времени на чтение кучи книг и изучение темы ИБ в целом, либо вы решаете конкретную задачу и изобретаете что-то своё или берёте от ИБ то немногое, что понадобится в рамках этой задачи. А просто перечислить в 300 символов, что хорошо и что плохо, - не получится. 

> Все данные, которые поступают от клиента, нужно проверять на валидность, и во многих случаях экранировать;

  

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

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

  

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

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

  

Ну не делай их  
  

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

  

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

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

  

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

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

  

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

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

  

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

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

  

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

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

  

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

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

  

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

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

  

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

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