Сегодня вновь очень активно развивается тема автоматизации тестирования безопасности веб-приложений с использованием PhantomJS в связке с BurpSuite, ModSecurity, Garmr и т.д. Я не стал исключением, о своём опыте разработки относительно рабочего прототипа сканера с поддержкой Javascript, Ajax и DomMutation я бы и хотел с вами поделится. Может это поможет кому-то разработать собственное решение, которое будет гораздо лучше. Всех заинтересованных прошу под кат:-)
Как npm обеспечивает безопасность
7 min
8.8KВсем привет! В предыдущих постах мы подробно поговорили про выбор зависимостей и использование lock-файлов в npm, однако я только вскользь касался вопросов безопасности. Пришло время исправить этот недочет: этот и следующий посты будут полностью посвящены безопасности в npm! И для начала мы рассмотрим, как безопасность обеспечивается на уровне инфраструктуры npm и экосистемы в целом.
+21
OVAL® или «миф об идеальном сканере»
3 min
9.9KПриветствую, коллеги.
Вопрос автоматических сканеров безопасности стоит весьма остро на «корпоративном» рынке услуг.
Конечно, кому же хочется проверять тысячи хостов вручную?
Поскольку спрос рождает предложение, вы можете найти их на любой вкус, цвет и бюджет.
Они призваны решать одни и те же цели: комплайнс-менеджмент.
Тем самым сэкономить корпорации огромное количество денег при массовой стандартизации PCI DSS и подобным стандартам.
Они все такие разные, но все же у них есть одна общая черта: полнейшая анархия и разброд в формате отчетов, результатов инвентаризации и контента для обновления. Как каждая группа программистов придумала, так и было сделано. Такая ситуация привод к тому, что сравнить сканеры безопасности становится чрезвычайно трудоемко. А разговора о том, что бы использовать накопившиеся за время использования продукта «А» данные при переходе на продукт «Б» не может быть и речи. Как же: куда не сунься, везде «коммерческая тайна» да «интеллектуальная собственность». Решение, уважаемый мой читатель, очевидно: стандартизация входных и выходных форматов на всех этапах деятельности сканера. Именно это и описано в стандарте Open Vulnerability and Assessment Language (OVAL)
Вопрос автоматических сканеров безопасности стоит весьма остро на «корпоративном» рынке услуг.
Конечно, кому же хочется проверять тысячи хостов вручную?
Поскольку спрос рождает предложение, вы можете найти их на любой вкус, цвет и бюджет.
Они призваны решать одни и те же цели: комплайнс-менеджмент.
Тем самым сэкономить корпорации огромное количество денег при массовой стандартизации PCI DSS и подобным стандартам.
Они все такие разные, но все же у них есть одна общая черта: полнейшая анархия и разброд в формате отчетов, результатов инвентаризации и контента для обновления. Как каждая группа программистов придумала, так и было сделано. Такая ситуация привод к тому, что сравнить сканеры безопасности становится чрезвычайно трудоемко. А разговора о том, что бы использовать накопившиеся за время использования продукта «А» данные при переходе на продукт «Б» не может быть и речи. Как же: куда не сунься, везде «коммерческая тайна» да «интеллектуальная собственность». Решение, уважаемый мой читатель, очевидно: стандартизация входных и выходных форматов на всех этапах деятельности сканера. Именно это и описано в стандарте Open Vulnerability and Assessment Language (OVAL)
+20