Проблемы автоматизации тестирования web сервисов на уязвимости

Каждый день тысячи сервисов подвергаются атакам со стороны киберпреступников. В связи с этим, проведение мероприятий по тестированию уязвимостей сервисов и программ становится необходимым. Более того, этот процесс должен быть качественным, чтобы обезопасить конфиденциальные данные пользователей и компаний. Автоматизирование тестирование – это очень трудоемкий процесс, однако этот процесс может сэкономить очень много времени в дальнейшем. Каждый программист или разработчик всегда старается автоматизировать большую часть своих рутин, но всегда ли это эффективно? В этой статье я говорю не об автоматизации тестирования, как о наборе готовых сценариев автотестов для проверки сервиса, а как об общих практиках системного тестирования. То есть автоматическое систематизированное тестирование с минимальным участием пользователя (тестировщика). Конечно, при решении этой задачи всплывает ряд как очевидных, так и не очень проблем. Автоматизация может быть частичной и полной. При частичной автоматизации автоматизируются только отдельные части процесса, когда при полной автоматизации конечной целью является инструмент или система, позволяющая провести все тестирование с минимальным участием человека. На данный момент существует ряд инструментов позволяющих частично автоматизировать процесс тестирования на уязвимости, среди них есть такие как SQLmap (для нахождения SQL инъекций), XSSer (для нахождения XSS инъекций), nikto scanner (для определения устаревшего и уязвимого ПО на сервере, неправильных конфигураций, а так же много другого), wpscan (для нахождения уязвимых плагинов к Wordpress), и некоторые другие.

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

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

Кроме того, существует еще одна проблема частичной автоматизации сканирования, да и самого тестирования на уязвимости в общем. Здесь я хочу подчеркнуть слова сканирование и нахождение, а не их эксплуатацию. Есть два вида сканирования на какую-либо уязвимость - активное и пассивное. И если пассивное сканирование позволяет нам найти необходимые дыры, которые могут стать причиной утечки каких-либо данных или уязвимость, которая может быть эксплуатирована для получения несанкционированного доступа к ресурсу, не используя самую уязвимость, то активное тестирование подразумевает конкретно эксплуатирование самой потенциальной уязвимости, для того, чтобы её обнаружить. Проблема же заключается в том, что для некоторых типов уязвимостей на данный момент не существует способов и инструментов, которые позволили бы провести пассивное сканирование. В большей это конечно касается уязвимосте в веб-приложениях, когда нет возможности сделать полный бэкап системы или сервиса для того, чтобы восстановить все после активного сканирования. В этом случае, активное тестирование может привести к нежелательным и неожиданным последствиям. Чтобы было более понятно, я могу привести пример. На данный момент не существует распостраненного способа пассивного обнаружения CSRF уязвимостей. Чтобы их обнаружить, их нужно попробовать эксплуатировать. Для того чтобы проверить их наличие, нужно попробовать обратиться к конечной функции (сделать запрос к конечному url) какой-либо формы (поле action) из другого места, из которого не должно быть доступа к этой функции. И, например, если эта форма позволяет либо изменять данные или базу данных или поменять конфигурацию, то тестирование этого поля на csrf уязвимость может привести к непоправимым результатам. Для решения этой проблемы сообществу нужно направить свои силы на поиски и разработку решений пассивного сканирования систем на наличие некоторых типов уязвимостей.

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

На данный момент существует некоторое количество систем автоматического тестирования безопасности веб-сервисов. Во время изучения этого вопроса мной были найдены и изучены следующие существующие решения. Среди них Acunetix Online, Cloud Penetrator, Qualys, и некоторые другие. Здесь я бы хотел выявить ещё одну проблему, которую лично я считаю очень важной. В таких щепетильных вопросах, как безопасность сервисов, особенно хранящих конфеденциальные данные, очень остро стоит вопрос доверия к технологиям, которые используются для аудита безопасности этих приложений. Большинство из этих сервисов аявляется закрытыми программными продуктами с закрытым, проприетарным исходным кодом. Это не дает возможности сторонним исследователям изучить благонадёжность самого этого сервиса и убедиться в том, что его использование оправдано и безопасно. Более того, компании, разрабатывающие эти продукты, в большинстве своём не публикуют информации о том. какие именно технологии лежат в основе их сервисов, в связи с чем вопрос доверия к ним остается открытым. Кроме этого, большинство этих сервисов стоят достаточно дорого и их могут позволить себе только компании у которых есть деньги, но нет средств либо необходимости содержать свой собственный отдел информационной безопасности, который занимался бы поиском уязвимостей и тестированием на проникновение. То есть, рядовой разработчик, или начинающий стартап не могут себе позволить эти инструменты. Возможно, частично, эти сервисы и пытаются решить проблемы автоматизации аудита безопасности систем, но вопрос об их использовании всё ещё неоднозначен.

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

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

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