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

Question

[Gene 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.
    

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

Answer 1

[DevMan]

1.да
2.нет
3.да
4.нет
5.да
6.нет
7.да
8.да
9.otp лучше
10.да
11.да/нет

Comments

[Gene Hagmt]

Насчет OTP, тема интересная, спасибо. По поводу Get/Post, я просто не уточнил. Речь идет, о том, что не стоит отправлять данные из форм Get'ом в url. Насчет хеша, это точнее не относительно важных данных, а относительно конфиденциальных - пароль, кредитка... (опять таки, немного неточно написал). Чем 2 пункт плох, даже не знаю. Ну то есть пользователь вводит запрос, он направляется в роутер, роутер сверяет запрос с массивом в формате '/userpage/[0-9]+' => 'dynamic/user.php' и инклудит нужный файл (user.php). Очень много проблем безопасности читал из-за url, так что это вроде как решение?

[DevMan]

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

[АртемЪ]

Gene Hagmt,

Насчет хеша, это точнее не относительно важных данных, а относительно конфиденциальных - пароль, кредитка..

Похоже вы просто не понимаете что такое хэш.

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

Конфиденциальные данные хэшировать смысла нет.
Есть смысл хэшировать любые данные, чтобы потом определить были ли они изменены - еще раз хэшировать и сравнить хэш.

[Gene Hagmt]

АртемЪ,

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

С пониманием этого у меня проблем нет. Но много где советуют не сохранять в БД пароль в исходном виде, а хешировать, также часто упоминается важность соли. Думаю это убеждение не из воздуха появилось, да и звучит вполне разумно.

[DevMan]

Gene Hagmt, совершенно верно. только:
1. хранят не пароли, а их хэши. и это в данном случае справедливо.
2. а вот что вам даст хэш кредитки?

Answer 2

[АртемЪ]

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

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

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

Comments

[Karpion]

3. Адрес - это запрос на сервер по этому адресу. Адрес типа www.site.ru/delete/имя_юзера - по смыслу удаляет юзера. Так вот, тут надо требовать подтверждение.

Answer 3

[dollar]

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

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

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

Comments

[Gene Hagmt]

Ну ладно, вы уточнили насчет DDoS, понял. Но что по поводу остального?

[dollar]

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

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

[Gene Hagmt]

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

[dollar]

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

Вот, скажем, ваш пункт про пароль - уверен, многие будут ругаться, когда ваше приложение откажет пользователю ввести 12345. Это может даже снизить конверсию, т.е. напрямую повлиять на доходы владельца приложения, в случае если оно никому особо не нужно. Вот лично я, когда есть ненужные мне требования, ввожу что-то типа 123456aA - прокатывает, при этом безопасности ноль, хотя 8 символов, есть цифры и буквы в разном регистре. Как пользователю, мне иногда нужно быстро и без гемора.

Ну и также всё остальное. Нельзя, к примеру, однозначно сказать, что лучше GET или POST. Вот я недавно делал необычное приложение с одноразовой авторизацией по ссылке. Как вы понимаете, при такой архитектуре ключ хранится прямо в get-параметрах. И безопасность пришлось продумывать отдельно, без учета всяких модных тенденций и всего такого.

Answer 4

[Иван Шумов]

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

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

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

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

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

Ну не делай их

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Comments

[Gene Hagmt]

Серьезно?? И сотой доли?? Это перегиб, бро. Может это и не супер-волшебные-решения, но если бы я и этого не использовал, то любой школьник сломал бы мой сайт. Я, честно признаться, в основном, по хабру копался. И я понимаю что лучше бы я пару книжек прочитал по ИБ, но в данный момент при разработке текущего проекта, я хотел бы применить хотя бы базовые возможности для защиты. Но я смотрел статистику по теме уязвимостей и самые распространенные это те, что я описал. И при этом, где бы я не искал инфу о защите от этих атак, везде +- одно и тоже: валидация, экранирование... Так почему же это не относится к ИБ? П.С. По поводу Get/Post, я просто не уточнил. Речь идет, о том, что не стоит отправлять данные из форм Get'ом в url.

[Иван Шумов]

Gene Hagmt, сколько экспрессии) ИБ начинается с вопросов о том:
- что мы защищаем
- от чего мы защищаем
- где мы защищаем

и из этого уже получается
- как мы защищаем

У AWS есть несколько очень интересных whitepapers, которые можно порекомендовать даже новичкам вроде тебя и безопасность начинается с этих вопросов, продолжается мониторингом (visibility, да-да. а по-хорошему с этого вообще начинается).

Что же сделал ты:
- начитался всякого
- выдернул в отрыве от контекста разные решения от каких-то отдельных случаев
- подумал что собрал какой-то универсальный список решений.

Так не работает, парень. Совсем не работает. Безопасность приложения это огромный комплекс, включающий сбор информации, анализ, множество взвешенных решений и эксперименты. На этот счет написаны сотни книг и существуют огромные талмуды на сотни страниц просто о том "как проверить мой маленький сервер на дыры".

[Gene Hagmt]

Иван Шумов, понимаю, тут согласен. Но этот список и не претендует ни на что великое. Это всего лишь список базовых рекомендаций самому себе при разработке сайта(веб-приложения), список, который нацелен отсеять самые распространенные и простые варианты взлома или порчи сайта. И я не думаю, что можно сказать, мол, это не имеет отношения к ИБ. Есть такие новички, которые даже такие простые вещи не обдумывают, а я просто не хочу быть одним из них.

[Иван Шумов]

Gene Hagmt, тогда, пожалуйста, не называй это безопасностью) пусть это будут просто базовые рекомендации для создания хорошего приложения. именно что базовые (anti-ddos к этому точно не относится).

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