Тут имеется в виду отзыв пользователя, если он считает, что SurfPatrol что-то проверил некорректно (например указал на ошибку в плагине, который обновлен или не установлен), то он может сообщить об этом разработчикам, выбрав вариант из выпадающего списка. Мы еще не пришли к окончательному варианту данной страницы, так что ваш комментарий очень ценен. Спасибо.
Сервис проверяет обновления безопасности. Т.е. если пропущено обновление, в котором не было апдейтов безопасности, то все ок. Если какие-то некорректности замечаете, скиньте плз в службу поддержки.
Безусловно мы проводили тестирование и на «обычных» пользователях. А среди хабраюзеров, как нам представляется, большое количество профессионалов, в т.ч. и тех, кто занимается разработкой интерфейсов для различных аудиторий, и их профессиональное мнение представляет для нас интерес.
Ах, вы об этом.
Детальные данные и выводы см. в оригинале исследования. Этот текст его урезанная интерпретация, сдобренная buzzwords. В оригинале есть информация в том числе и по регулированию, поскольку оно оказывает большое влияние на распределение уязвимостей. Так, благодаря PCI DSS в ДБО практически вычищены XSS и SQLi, но достаточно много логических недочетов связанных со сложными функциями авторизации (одноразовые пароли, sms и проч). Резать по платформам в рамках отрасли на такой выборке не вижу смысла, ибо непонятно к чему это приведет.
Погрешность и достоверность (простите за педантство) несколько разные понятие, чем и был вызван мой вопрос. Резюмируя, наши данные абсолютно достоверны при заданных начальных условиях, изложенных в полном тексте, а именно:
— приложения российских компаний из топ 100
— наиболее бизнес-критичные системы, доступные из Интернет (именно с ними связаны основные риски, именно их и заказывают)
— Ограничения методики «серого ящика» согласно которой анализировались приложения, и которая (как, к слову и любая) не дает гарантии, что все проблемы были обнаружены
К сожалению других чисел у нас нет. То, что делает WASC и Whitehat Security менее адекватно, поскольку содержит либо смесь черного и белого ящика (WASC), либо только черный с ручной верификацией (Whitehat).
Экстраполяции, предсказания и прочая мистика не использовались, только опыт. Что касается практического применения, то многие факты из исследования могут быть использованы в количественных методиках анализа рисков, что, согласитесь, достаточно полезно.
Мы еще на ютуб зальем. Просто было много просьб, поэтому выложили материалы поскорее — пока на ресурсе площадки, где проходил форум. На данный момент это лучшее, что есть.
Презентации наших экспертов постараемся на slideshare выложить, а так, мы в твиттере в ретвитах собираем ссылки на презентации экспертов, которые выступали на форуме. Вот тут и тут
сайты, это конкретные приложения, которые используют наши заказчики. Список их естественно привести не сможем, коммерческая тайна, NDA. Что касается процентов, округляли до целого или двух десятичных знаков.
Разглашение информации — это более чувствительные вещи, например, комментарии разработчиков, трейсы и пути файловой системы в сообщениях об ошибках и прочее.
Еще раз повторю — это реальные цифры и нам (да и владельцам систем) достаточно трудно (да и не особо нужно) угадывать в чем причина дырявости приложения: в особенностях asp.net или в свойствах «прокладки». Да и наша методика анализа не позволяет это понять, для этого надо влезать в SDL и другие процессы компании.
Но в целом да, холиварный отчет. Но вот такой он есть.
Статистика была получена в результате анализа приложений, проводимого на коммерческой основе, поэтому даже если приложение и «коленочное» оно достаточно ценно для заказчика, чтобы инвестировать в его безопасность.
Не понятно что имеется ввиду под погрешностями в данном случае.
Распределение по платформам внутри индустрии можно привести, но непонятен в чем его смысл на такой выборке.
Еще раз напомним, что наше исследование прежде всего практическое, оно показывает как обстоят дела с безопасностью, а не как могли бы быть. Согласитесь телеком компании достаточно все равно, через багу в asp.net модном сайте или унаследованный наколенный php-сайтец были опубликованы смс его клиентов.
Это реальный мир и реальные риски.
Детальные данные и выводы см. в оригинале исследования. Этот текст его урезанная интерпретация, сдобренная buzzwords. В оригинале есть информация в том числе и по регулированию, поскольку оно оказывает большое влияние на распределение уязвимостей. Так, благодаря PCI DSS в ДБО практически вычищены XSS и SQLi, но достаточно много логических недочетов связанных со сложными функциями авторизации (одноразовые пароли, sms и проч). Резать по платформам в рамках отрасли на такой выборке не вижу смысла, ибо непонятно к чему это приведет.
Погрешность и достоверность (простите за педантство) несколько разные понятие, чем и был вызван мой вопрос. Резюмируя, наши данные абсолютно достоверны при заданных начальных условиях, изложенных в полном тексте, а именно:
— приложения российских компаний из топ 100
— наиболее бизнес-критичные системы, доступные из Интернет (именно с ними связаны основные риски, именно их и заказывают)
— Ограничения методики «серого ящика» согласно которой анализировались приложения, и которая (как, к слову и любая) не дает гарантии, что все проблемы были обнаружены
К сожалению других чисел у нас нет. То, что делает WASC и Whitehat Security менее адекватно, поскольку содержит либо смесь черного и белого ящика (WASC), либо только черный с ручной верификацией (Whitehat).
Экстраполяции, предсказания и прочая мистика не использовались, только опыт. Что касается практического применения, то многие факты из исследования могут быть использованы в количественных методиках анализа рисков, что, согласитесь, достаточно полезно.
Разглашение информации — это более чувствительные вещи, например, комментарии разработчиков, трейсы и пути файловой системы в сообщениях об ошибках и прочее.
Еще раз повторю — это реальные цифры и нам (да и владельцам систем) достаточно трудно (да и не особо нужно) угадывать в чем причина дырявости приложения: в особенностях asp.net или в свойствах «прокладки». Да и наша методика анализа не позволяет это понять, для этого надо влезать в SDL и другие процессы компании.
Но в целом да, холиварный отчет. Но вот такой он есть.
Не понятно что имеется ввиду под погрешностями в данном случае.
Распределение по платформам внутри индустрии можно привести, но непонятен в чем его смысл на такой выборке.
Еще раз напомним, что наше исследование прежде всего практическое, оно показывает как обстоят дела с безопасностью, а не как могли бы быть. Согласитесь телеком компании достаточно все равно, через багу в asp.net модном сайте или унаследованный наколенный php-сайтец были опубликованы смс его клиентов.
Это реальный мир и реальные риски.