Web-приложения. Безопасная разработка , развертывание и использование

Привет, Вы узнаете о том , что такое Web-приложения. Безопасная разработка , развертывание и использование, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое Web-приложения. Безопасная разработка , развертывание и использование , настоятельно рекомендую прочитать все из категории Криптоанализ, Виды уязвимости и защита Информации .

ВВЕДЕНИЕ

Современные web-приложения существуют в среде, которая заметно отличается от той, которая

была на заре существования сети Интернет. Они стали важными инструментами работы

компаний, но, при этом, их функционирование зачастую не очень соответствует тому на что

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

и расширение функциональности web-приложений происходили столь быстро, что не всегда

удавалось добиться всего, чего хотелось. Это особенно очевидно в том случае, если речь идет

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

определенные механизмы защиты своих web-приложений, только некоторые из них имеют

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

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

повышает риски и серьезно ухудшает последствия потенциальных атак. А во-вторых, отсутствие

единой системы значительно увеличивает стоимость поддержания приемлемого уровня

безопасности web-приложения, при котором риски и последствия потенциальных атак будут

минимальными.

В данном отчете представлена информация о том, как построить прагматичную систему

безопасности web-приложения за разумную стоимость, но, при этом, обеспечив его эффективную

защиту. Вместо того, чтобы углубляться в конкретные детали какой-либо одной технологии, мы

выделим основные составляющие системы безопасности и то как они должны взаимодействовать

между собой. Начнем с того, что расскажем о том, чем отличаются web-приложения от

коммерческих и других приложений. Затем мы предложим основные обоснования, которые

можно использовать для получения бюджета для данной задачи. А также сосредоточим

внимание на специфических потребностях в области безопасности web-приложений, углубимся

в детали основных компонентов безопасности и, в результате, объединим их в общую систему

безопасности web-приложений, основанную на типичных примерах использования.

Проблема безопасности web-приложений

Коммерческие web-приложения развивались таким образом, что стали головоломкой с точки

зрения безопасности. Несмотря на то, что все в ИБ наблюдали за их появлением развитием, на

первых этапах их относили к приложениям с не очень высоким уровнем риска. Но в короткое

время web-приложения выросли из экспериментальных систем в критически важные бизнесприложения. Спросите у любого разработчика web-приложений и он расскажет вам историю

о том, как их маленький внутренний проект вдруг стал важнейшей частью бизнеса, как только

они сделали ошибку, расхвалив его бизнес-подразделению своей компании. В результате, сейчас

нет возможности прервать развитие web-приложений и вернуться к основам, чтобы учесть все

важные моменты, которые были упущены на заре становления, что в итоге привело к текущей

ситуации в плане безопасности:

• До начала активного использования web-приложений, лишь малое число компаний

организовали взаимодействие своих внутренних систем с внешним миром. И даже те,

кто сделали это, предоставляли доступ лишь бизнес-партнерам, а с широким кругом

пользователей работали и вовсе – единицы.

• Web-приложения выросли самостоятельно – ониначинали с информационных сайтов,

которые были лишь чуть больше, чем каталоги. А затем через базовые сервисы они были

связаны с критически важными бэк-енд системами.

• Те приложения, что разрабатывались достаточно долго и не менее долго насыщались

функционалом, зачастую вызывают к себе излишнее доверие, хотя по факту могут быть

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

принцип “лягушка в кастрюле” – если лягушку закинуть в горячую воду, то она сразу

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

• Протоколы web-приложений разработаны с целью обеспечить простоту и гибкость

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

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

• Угрозы для web-приложений развиваются также быстро, как и сами web-приложения, а

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

Web изначально не предназначался для безопасного запуска критических приложений, а это

значит, что все разработанные приложения фактически используют неподходящую для этого

платформу.

• Только некоторые приложения разработаны с нуля с учетом всех требований безопасности,

а также поддерживаются в актуальном состоянии достаточно долго.

• Когда случаются инциденты безопасности, имеются проблемы с их обнаружением и

анализом.

В свете всех этих факторов, стоит отметить, что финансирование разработки web-приложений,

как правило, является недостаточным. Кроме того, как и все разработчики, создатели webприложений находятся под постоянным прессингом, жестко ограничены в сроках и, зачастую,

вынуждены закрывать глаза на некоторые не совсем правильные с точки зрения безопасности

моменты в угоду бизнес-задачам. Мы категорируем проблемы безопасности web-приложений

следующим образом:

• Лишь некоторые приложения разработаны с учетом требований безопасности.

• Приложение зависит от используемого web-браузера, который не является ни безопасной,

ни доверенной средой.

• Web-приложения развивались с целью обеспечения доступа к самым чувствительным

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

• Web не был разработан как безопасная платформа и, соответственно не соответствует

тривиальным правилам безопасности – конфиденциальность, целостность, доступность.

• Лишь небольшое количество нарушений безопасности обнаруживаются и позволяют

проанализировать потери компании и, соответственно, привести к усилению внимания к

проблеме со стороны руководства.

• У нас есть огромный объем старого кода, который постоянно исправляется, но, в тоже время,

постоянно дописывается все новый и новый код.

• Web-приложение – это комплекс платформ, инструментов и сервисов от множества

провайдеров, каждый со своими вызовами безопасности.

• Многие web-приложения имеют критическое значение, но разработаны без учета этого

факта.

• Если Web-приложение разработано внутри компании, то именно внутри компании должны

отслеживаться уязвимости и выпускаться исправления – никто другой эту работу не сделает.

• Требования безопасности зачастую вступают в конфликт с требованиями, выдвигаемыми

бизнесом, в частности, если это касается простоты использования и скорости работы.

• Ни один инструмент безопасности web-приложений не обеспечит эффективную защиту в

одиночку.

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

боя с постоянно меняющимися функциональными требованиями, деталями, топливом и

законами физики. И это притом что в этом процессе истребитель постоянно атакуют миллионы

разнообразных вражеских объектов, о которых мы практически ничего не знаем.

Обоснования для бизнеса

Обеспечение безопасности приложений традиционно страдает от недофинансирования и

убедить руководство в необходимости новых затрат на улучшение их защиты достаточно сложно,

ведь оно и так отлично работает. Конечно, это касается не только приложений, а фактически

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

защищенности не вызывают позитива у бизнеса, так как угрозы и последствия инцидентов плохо

поддаются количественной оценке. Построение полной модели обоснования инвестиций в

безопасность web-приложений выходит далеко за рамки данного материала, но мы не можем

говорить о создании системы безопасности без, по крайней мере, некоторых основных

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

руководство поддержать вас. Следующий список не является исчерпывающим обоснованием

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

обоснования необходимости инвестиций в безопасность web-приложений:

Соблюдение требований. Нравится нам это или нет, информационная безопасность является

объектом контроля со стороны государства, а также регулируется индустриальными стандартами

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

отдельные части: собственно сами требования; дополнительные требования, которые могут

возникнуть (защита персональных данных и т.д.); снижение затрат на соответствие требованиям и

аудит. В среднем организация использует все три фактора для оценки инвестиций в безопасность

web-приложения.

Борьба с мошенничеством. Если вы можете достаточно точно оценить потенциальный ущерб

от мошенничества, это может быть одним из важных драйверов при обосновании инвестиций

в безопасность. А в некоторых случаях вы можете получить конкретные данные о случаях

мошенничества и показать каким способом их можно избежать с помощью тех или иных

необходимых решений. Также имейте в виду, что вы можете не иметь правильной инфраструктуры

для обнаружения и оценки случаев мошенничества, что само по себе может стать достаточным

обоснованием. Тесты на проникновение также могут быть хорошим шансом на получение

инвестиций для снижения количества случаев мошенничества – тест может показать неизвестные

пути для использования эксплойтов, активную атаку или возможности для будущих атак. Вы можете

использовать результаты теста на проникновение для оценки потенциальных возможностей для

мошенничества и составить план, который позволит снизить риски до приемлемого уровня.

Экономия. Как мы уже упоминали в секции о соблюдении требований, контроль безопасности

может снизить расходы на аудит, но это лишь дополнительная возможность для экономии.

Использование средств безопасности web-приложений при разработке и в процессе

использования позволит снизить затраты на ручной контроль безопасности и устранение

выявленных уязвимостей, а также в общем повысить эффективность работы web-приложения.

Мы также можем рассчитывать на экономию от сокращения количества инцидентов, а также при

восстановлении работоспособности web-приложения после них.

Доступность. При работе с web-приложениями мы оцениваем как время общей доступности

сервиса, так и доступность услуг (есть вероятность потери части функционала приложения

из-за атаки или устранения ее последствий). Например, крайне редко можно увидеть полное

отключение сайта вследствие проблем с безопасностью web-приложений, в то время как

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

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

функции для обеспечения защиты пользователей и их данных, даже в том случае, если атака не

задевает возможности данной услуги напрямую.

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

выражен какой-либо суммой денег, главным стимулом для инвестиций в безопасность webприложения является необходимость защиты пользователей и их конфиденциальных данных,

так как невнимание к этому моменту может негативно сказаться на их доверии к компании и,

соответственно, на ее имидже. Злоумышленники вообще достаточно часто не наносят никакого

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

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

как ваше web-приложение может стать площадкой для атак на ваших пользователей. Большая

часть компаний получает прямой или косвенный доход от данных пользователей и это уже

создает обязательство о необходимости защиты этих данных.

Защита репутации. В то время как множество моделей пытаются дать количественную оценку

репутации и оценить потенциальные потери от ее ухудшения, реальность такова, что все эти

модели фикция – точного метода измерения потенциального ущерба для репутации из-за

атак злоумышленников не существует. Несмотря на многочисленные прогнозы, относительно

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

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

допустила одну из крупнейших утечек данных в истории и этот факт был обнародован, продажи

пошли вверх. Но только тот факт, что невозможно точно просчитать репутационные риски, не

означает, что это не является важным фактором при обосновании необходимости инвестиций

в безопасность web-приложений. Просто спросите себя (или менеджмент компании) о том

насколько важно приложение для имиджа компании и насколько готовы к рискам связанным

с потерей информации клиентов. Доверие пользователей, инвесторов и партнеров вашей

компании и сервисам хоть и не зависит напрямую от защищенности web-приложения, но все же

этот момент очень важен и может сказаться на общей ценности бизнеса.

Прямые потери от инцидентов. Кроме потерь от мошенничества, так же имеют место быть

и прямые финансовые потери. Даже если мы не будем обращать внимания на репутационные

потери бизнеса, а также стоимости компании, а сосредоточимся только на потерях, которые

выражаются конкретными цифрами, то выясниться, что и они есть. К примеру, на рассылку

уведомлений пользователям, восстановление работоспособности и оплату персонала call-центра.

Вы поймете какая комбинация из этих работ лучше, основываясь на потребностях вашей компании

и приоритетах менеджмента, но вы должны объединить качественные и количественные

оценки для того чтобы верно расставить приоритеты при инвестициях. Если вы работаете с

персональными данными (финансы/розница/медицина) то контроль безопасности и снижение

расходов будут лучшими доводами. Для web-приложений общего назначения важными будут

защита пользователя и репутации, снижение рисков мошенничества и обеспечение доступности.

И давайте не будем забывать о том, что все эти доводы также применимы и для внутренних

приложений. Независимо от сферы применения, недостатка в обоснования для бизнеса (в отличие

от технической стороны) в пользу инвестиций в безопасность web-приложений нет.

Web-приложения другие

Мы много лет потратили на изучение вопросов безопасности сетей и хостов и построили

системы безопасности в области информационных технологий сосредоточившись на базовой

инфраструктуре. Но, как мы уже отмечали, безопасность web-приложений заметно отличается

от всего этого и требует совершенно иного подхода. Безопасность web-приложений отличается

и от защиты традиционного ПО, хотя и имеет с ним гораздо больше общего. В предыдущей

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

специфических технических и нетехнических отличиях в безопасности web-приложений, перед

тем как дадим наши рекомендации по жизненному циклу защиты web-приложений.

Почему защиты web-приложений отличается от защиты сетей

и хостов

При обеспечении безопасности сети или хоста мы сосредоточены на блокировании

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

Также при обеспечении безопасности корпоративных приложений мы в основном занимаемся

блокированием платформ, защитой коммуникаций, аутентификацией пользователей и

осуществляем контроль безопасности посредством средств, предоставляемых платформой

приложения. Но в случае с web-приложениями мы сталкиваемся не только со всеми этими

вопросами, но и имеет дело со сторонним или собственным кодом. В зависимости от того, является

приложение доступным извне или предназначенным только для внутреннего использования, они

имеют существенные отличия:

UI браузера: В большинстве приложений мы создаем пользовательский интерфейс. Но в случае

с web-приложениями, мы полагаемся на сторонний просмотрщик (браузер), который не можем

полностью контролировать и который может контактировать и с другими приложениями в один

момент времени.

Собственный код порождает собственные уязвимости: В случае в web-приложениями вы обычно

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

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

свое приложение, то никто не сообщит вам о каких-либо имеющихся уязвимостях и никто не

предложит патч, позволяющий их закрыть.

Вы разработчик: Когда появится уязвимость, у вас не будет разработчика, который подготовит патч

(вы должны, конечно, установить патчи для всех инфраструктурных компонентов, фреймворков

и скриптов, которые вы используете). Если вы обслуживаете клиентов, то вам необходимо

придерживаться пункта договора об уровне сервиса и обеспечивать необходимую доступность

сервиса.

Межсетевые экраны в одиночку не могут защитить web-приложение: Когда мы обнаруживаем

уязвимостивнашем корпоративномПО,операционных системах,приложениях,базах данныхит.д.,

мы используем инструменты вроде межсетевых экранов или IPS для блокирования возможностей

для потенциальной атаки на время ожидания выпуска патча для уязвимого программного

обеспечения. Такая “блокировка до патча” имеет лишь ограниченную эффективность. А Web Application Firewall (WAF) не сможет защитить вас от логических ошибок. Хотя WAF может помочь с

некоторыми классами атак, но “из коробки” они не знают или не понимают выше приложение,

а потому не сможет “прикрыть” пользовательские уязвимости. WAF безусловно является важной

частью защиты web-приложений, но лишь в том случае, если он является частью комплексной

системе, о которой мы поговорим позже.

Вечная бета-версия: При разработке традиционного приложения проводится полный цикл

проверки: контроль на стадии разработки, внутреннее тестирование, а также, зачастую,

дополнительное тестирование с привлечением сторонних пользователей – бета-тестеров. И

все это до того, как приложение перейдет в эксплуатацию. Было бы здорово, если бы и webприложения проходили этот последовательный цикл, но, как уже было сказано, так бывает

крайне редко. Большая часть web-приложений, даже рассматриваемых разработчиками как

неокончательная, в действительности уже запущена в эксплуатацию и даже стали ключевыми

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

постоянного изменения и их разработчики даже не придерживаются формального цикла

разработки. Постоянно меняющиеся приложения – это непростая задача для существующих

средств контроля безопасности, таких как WAF.

Опора на фреймворки/платформы: Web-приложения редко строятся с нуля, радуя “вылизанным”

кодом на C. Чаще всего это смесь разнообразных фреймворков и средств разработки и платформ,

которые не всегда разработаны для совместной работы. Задача разработчиков обеспечить

взаимодействие всех этих частей, а также собственного кода. Такой подход, зачастую, создает

серьезные проблемы безопасности из-за неправильного использования компонентов, их

взаимодействия между собой, а также с собственным кодом.

Унаследованный код: Даже если новый код пишется с чистого листа и действительно безопасен, то

не стоит забывать, что в большинстве случаев есть еще огромный массив старого кода, который

также имеет огромное число уязвимостей, а потому подлежит анализу и исправлению. Если

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

новый. Зачастую, именно устаревший код становится виновником атак на web-приложение.

Динамический контент: Большая часть web-приложений имеет чрезвычайно динамичный

характер, создавая большую часть контента “на лету”, нередко с использованием данных (в том

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

тем самым, новые классы проблем безопасности.

Новые классы уязвимостей: Как и в случае с классическими приложениями, исследователи

и злоумышленники постоянно открывают новые классы уязвимости web-приложений. Таких

примеров множество. А потому нужно помнить, что даже идеальный с точки зрения сегодняшнего

дня код вовсе не гарантирует то, что он всегда будет безопасен.

Мы перечислили ряд причин по которым следует смотреть на web-приложения иначе, чем

на классические. Внедрение системы безопасности web-приложений требует достижения

консенсуса в компании. Вносить изменения будет трудно и рискованно. В перспективе это

приведет к снижению расходов, но оплатить все изменения придется сразу, не зная в какой мере

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

инвестиций,вампонадобятсявескиепричины. И есливысопоставитестоимостьспреимуществами,

описанными в этом разделе, вы получите вполне объективный ответ на то как данные расходы на

безопасность повлияют на вашу компанию.

Жизненный цикл защиты web-приложения

В оставшейся части материала вы найдете рекомендации по действенным шагам, которые

способствуют повышению уровня безопасности web-приложений. Учитывая масштабы задачи,

мы не сможем дать подробную информацию по каждой составляющей системы безопасности,

а рассмотрим их в общих чертах. В то время как web-приложения ставят отличные от привычных

задачи, дополнительные шаги для защиты неотличаютсяот тех, чтовы делаете сейчас. Упрощенную

схему цикла разработки и использования мы разложили на 3 шага и 7 зон:

Безопасная разработка

Процесс и обучение: В этом разделе мы сфокусируемся на построении безопасности в цикле

разработки программного обеспечения. Это включает, в том числе, подготовку людей,

занимающихся разработкой и улучшение процесса разработки. Обучение разработчиков должно

быть ориентировано на обеспечение безопасности функциональных возможностей приложения.

Мы также рассмотрим инструменты, которые помогут автоматизировать часть работы:

статистический анализ на поиск уязвимостей в коде и динамический анализ для выявления

аномального поведения приложения.

• Безопасная разработка: Внедрение практик безопасной разработки в процессе создание

web-приложения.

• Статический анализ: Инструмент для сканирования исходного кода приложения на ошибки

безопасности. Также эти инструменты называют “white box”.

• Динамический анализ: Инструменты исследующие не исходный код, а само запущенное

приложение при попытках атаки. Эти инструменты часто называют “black box”.

Безопасное развертывание

На этапе, когда разработка приложения уже закончена или, как минимум, оно доведено до такой

стадии, когда возможно использовать его для тестирования, приходит время проверить, что

приложение свободно от известных проблем безопасности и настроено нужным образом. В это же

время можно начинать оценивать уязвимость приложения и проводить тесты на проникновение,

наряду с традиционным анализом конфигурации и проверок согласованности взаимодействия с

системами.

• Оценка уязвимости: удаленное сканирование web-приложения, как с учетной записью,

так и без. Оценка уязвимости web-приложения концентрируется на самом приложении,

в то время как стандартная оценка уязвимости сосредотачивается на исследовании хостплатформы.

• Тестирование на проникновение: Тестирование на проникновение является фактически

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

риски, которые они несут. Тестирование на проникновение позволяет оценить недостатки

приложения, классифицировать их и правильно расставить приоритеты.

Большая часть людей не уделяет должного внимания тестированию собственного кода, а

сосредоточены исключительно на расширении функционала, добавлении новых функции

и достижению стабильной работы web-приложения. Это все, безусловно, важно и для этого

собирается серьезная команда разработчиков. Таким же серьезным должен быть и подход

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

приложение, подвергается тотальному анализу с точки зрения безопасности.

Безопасное использование

Вэтомразделемыперейдемотинструментовипроцессов, которыепозволяют сделатьприложение

защищенным на этапе разработке, к тем, которые обеспечивают возможности обнаружения атак

и реагирование на них. Основной акцент здесь делается на возможностях WAF, который должен

защищать web-приложение от несанкционированных действий пользователей, а также других

инструментах, которые сканируют запросы и выявляют неприемлемую активность в отношении

web-приложения и других связанных с ним компонентов. Последние разработки в области

средств обнаружения способствуют соблюдению политик, адекватно реагируют на события, а

также объединяют несколько сервисов в кооперативную гибридную модель.

• Web Application Firewall: Сетевой инструмент, который занимается контролем трафика к

web-приложению и сообщаете об известных атаках и/или блокирует их.

• Мониторинг активности приложения и базы данных: Инструмент, который контролирует

активность приложения и базы данных (с помощью различных методов) для аудита и

генерации предупреждений безопасности, основанных на нарушении заданных правил.

Поскольку многие организации только начинают создавать правила безопасности приложений,

мы попытаемся наметить рамки и проиллюстрировать возможности, что позволит рассмотреть

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

обзор имеющихся возможностей, а также базовую информацию о том как это работает и как это

интегрировать. Более подробно, особенно о том “как”, написать в рамках материала невозможно

– эта тема заслуживает нескольких полноценных книг. Специфика модификации процессов,

применения различных методик и связанных с ними нюансов тоже выходят за рамки этого

документа.

Безопасность web-приложений претерпевает очень быстрые изменения – меняясь также быстро,

как злоумышленники находят новые способы атак. Мы обсудим передовые инструменты и

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

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

в одиночку. Вам нужны правильные инструменты в правильных руках как часть правильного

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

следующим причинам:

• Многие инструменты автоматизируют большую часть передовых подходов к оценке

безопасности

• Ваши разработчики и сотрудники службы контроля могут быть не в состоянии идти в ногу

с постоянно меняющимися тенденциями информационной безопасности, а также иметь

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

степени нивелировать эти недостатки.

• Объем работ по тестированию на безопасность для обеспечения должного качества

требует автоматизации. Об этом говорит сайт https://intellect.icu . Соотношение требования/ресурсы для любой рабочей группы без

автоматизации будет очень и очень плохим.

• Инструменты обеспечивают платформу для настройки и тестирования политик и являются

результатом исследований и огромного опыта, что делает их незаменимыми на всех этапах

разработки и использования web-приложения.

В дальнейшем мы разберем каждую из описанных частей и покажем, как они вписываются в

общую систему безопасности web-приложения, а также укажем их достоинства и недостатки.

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

книги, а потому сосредоточимся на основных моментах.

Безопасная разработка

В безопасности web-приложений зачастую уделяется недостаточно внимания процессам

модификации, обучения и выбору средств разработки. Безопасностью очень часто начинают

заниматься уже после окончания основной разработки, а не во время ее. А ведь внимательность

к этим вопросам при разработке позволяет сделать приложение более безопасным при меньших

расходах. В этом разделе мы обсудим лучшие варианты для интеграции безопасности в webприложение на этапе разработки.

Безопасность web-приложений: подготовка и жизненный цикл

разработки приложений

Большая часть сегодняшних web-приложений были спроектированы, разработаны и развернуты

до того как появились нормы и принципы безопасности web-приложений. Безопасные методы

разработки в командах web-разработки зачастую входят в сознание только после того, как

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

в рамках имеющихся требований, исполнение которых обязательно. Новости часто привлекают

внимание к атакам с помощью SQL-инъекций, но большинство разработчиков не представляет

как отражаются атаки с использованием межсайтового скриптинга, и еще меньше знает о том,

как защититься от них. Практика безопасной разработки приложений находится в зачаточном

состоянии и далека до зрелости. Конечно, значительные знания уже накоплены, но они пока еще

не всеобъемлющи и доведены далеко не до каждого разработчика.

Независимо от того, что вами движет, образование и модификация процессов являются самыми

важными первыми шагами для создания безопасного web-приложения. Если вы разрабатываете

новое или модернизируете старое приложение, то менеджеры проекта, разработчики и другие

специалисты должны быть осведомлены о потенциальных проблемах безопасности решения, а

также о методах безопасного проектирования и написания кода. Учебная программа должна

охватывать как общие угрозы, так и известные методы, которые злоумышленники используют для

атак на системы. Специализированная подготовка нужна для сотрудников каждой субдисциплины,

включая возможности модификации процессов, безопасную модель развертывания платформы,

инструменты безопасности и методологию тестирования. Если ваша команда не знает, как

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

(поставщики услуг или хакеры), а это обходится гораздо дороже.

Менеджеры проектов должны знать, какие типы угроз могут быть применимы к

разрабатываемому web-приложению, и как минимизировать имеющиеся риски, обеспечив при

этом требуемый функционал.

продолжение следует...

Продолжение:

Часть 1 Web-приложения. Безопасная разработка , развертывание и использование
Часть 2 Инструменты статического анализа - Web-приложения. Безопасная разработка , развертывание и
Часть 3 Подводим итоги - Web-приложения. Безопасная разработка , развертывание и использование