Комментарии 2
Прочитал статью, очень много и подробно рассказано о том, как народ обмазывается разными сканерами и радуется отчетам. Окей, допустим. Много слов о защите персональных данных, тоже допустим. Открываю случайных сервис от компании, которая упоминается в статье. Окей, не настроили HTTPS, хотя заявляют о ценности и защищенности пользовательских данных. Идем дальше, эти же люди не умеют делать нормальное восстановление паролей. Ладно, восхитительные примеры для статьи про безопасность.
А дальше этот комментарий превращается в достаточно оскорбительное личное мнение об одной из основных проблем. Довольно большое количество программистов — тупые или подлые люди. Тупой программист не думает, зачем и что он делает: зачем думать, что такое пароль, авторизация, восстановление пароля, какое у них предназначение? Нафигачил очередных запросов к базе и пошел отчитываться о готовом модуле, заодно и просить премию. В итоге получаем авторизации без защиты от брутфорса, четырехзначные цифровые коды для восстановления паролей с минимальной защитой, либо шестизначные коды без защиты (ведь 1000000 — это так много, никто никогда не сгенерирует столько запросов к мощному серверу, который легко обрабатывает 50-100 таких запросов в секунду). Тупой программист не задумывается, зачем он что-то вообще делает, а вокруг бегают люди, которые пытаются отловить проблемы сканерами. И я почти уверен, что во все эти системы авторизации сканеры неоднократно засовывали кавычки и разные спецсимволы, чтобы потом сказать «Ммм, качественно, уязвимости не найдены». А подлый программист/тимлид/менеджер отличается от тупого только тем, что он знает (или способен узнать) о таких проблемах, но не делает ничего для исправления, так как ему это не нужно: лучше записаться на митап с коллегами, поесть на полднике или уйти пораньше с премией, чем говорить всем «Народ, у нас идиоты писали половину систем, первые умные хакеры возьмут все, что захотят». Да и зачем что-то делать? Наказаний никаких, зарплату платят не пользователи, они никогда не побьют, даже если слить все данные, а если контора развалилась, то можно пойти в новую.
ИМХО, пока не карают тупых и пофигистичных программистов, нет смысла ожидать серьезных улучшений (ну да, очень круто, сканер нашел пару дыр, одну исправили, другую поставили в бесконечную очередь, а то, что авторизации на самом деле нет — никто не знает и не хочет знать). С другой стороны, наказания имеют свои негативные моменты, но кто знает, что лучше — вечнодырявые сервисы или вечнодрожащие программисты.
А дальше этот комментарий превращается в достаточно оскорбительное личное мнение об одной из основных проблем. Довольно большое количество программистов — тупые или подлые люди. Тупой программист не думает, зачем и что он делает: зачем думать, что такое пароль, авторизация, восстановление пароля, какое у них предназначение? Нафигачил очередных запросов к базе и пошел отчитываться о готовом модуле, заодно и просить премию. В итоге получаем авторизации без защиты от брутфорса, четырехзначные цифровые коды для восстановления паролей с минимальной защитой, либо шестизначные коды без защиты (ведь 1000000 — это так много, никто никогда не сгенерирует столько запросов к мощному серверу, который легко обрабатывает 50-100 таких запросов в секунду). Тупой программист не задумывается, зачем он что-то вообще делает, а вокруг бегают люди, которые пытаются отловить проблемы сканерами. И я почти уверен, что во все эти системы авторизации сканеры неоднократно засовывали кавычки и разные спецсимволы, чтобы потом сказать «Ммм, качественно, уязвимости не найдены». А подлый программист/тимлид/менеджер отличается от тупого только тем, что он знает (или способен узнать) о таких проблемах, но не делает ничего для исправления, так как ему это не нужно: лучше записаться на митап с коллегами, поесть на полднике или уйти пораньше с премией, чем говорить всем «Народ, у нас идиоты писали половину систем, первые умные хакеры возьмут все, что захотят». Да и зачем что-то делать? Наказаний никаких, зарплату платят не пользователи, они никогда не побьют, даже если слить все данные, а если контора развалилась, то можно пойти в новую.
ИМХО, пока не карают тупых и пофигистичных программистов, нет смысла ожидать серьезных улучшений (ну да, очень круто, сканер нашел пару дыр, одну исправили, другую поставили в бесконечную очередь, а то, что авторизации на самом деле нет — никто не знает и не хочет знать). С другой стороны, наказания имеют свои негативные моменты, но кто знает, что лучше — вечнодырявые сервисы или вечнодрожащие программисты.
Спасибо за статью. Мне кажется, в статье очень часто путается понятие «уязвимость» с «потенциальная уязвимость».
Уязвимость — то, что можно как-то использовать. Есть база уязвимостей: CVE. Если мы нашли код, который содержит ошибку, описанную в базе CVE, то это и есть уязвимость. Ложных срабатываний нет: если нашли — значит беда.
Потенциальная уязвимость — программная ошибка, которая при неудачном стечении обстоятельств может быть использована как уязвимость. Пример: выход за границу массива. Подобные потенциальные уязвимости собраны, например, в CWE (list of software weaknesses). Однако не каждый выход за границу массива это уязвимость. Есть ложные срабатывания, так как любой статический анализатор выдаёт ложные срабатывания.
Если я не так понимаю эти термины, то прошу поправить меня.
Теперь обратимся к статье.
Идёт речь про уязвимости… Чем раньше найдена уязвимость,… продукт нужно периодически проверять на уязвимости…
Еще одна проблема — ложные срабатывания....
Стоп. Откуда ложные срабатывания? Так всё-таки говорится про уязвимости или потенциальные уязвимости?
Я был бы благодарен, если бы вы привели пару практических примеров кода, содержащим то, что в статье называется «уязвимость».
Читаем дальше.
В этом случае разработчика рекомендуется: произвести фильтрацию в статических анализаторах по уязвимостям и по файлам. Можно исключать библиотеки, анализировать критичность, добавлять исключения по определенным параметрам.
Т.е. если уязвимость в библиотеке, то и бог с ней? Эксплуатируй не хочу...? :)
Так может быть это не уязвимости, а просто срабатывания анализатора (по делу и ложные), которые не хочется смотреть? Т.е. потенциальные уязвимости?
Уязвимость — то, что можно как-то использовать. Есть база уязвимостей: CVE. Если мы нашли код, который содержит ошибку, описанную в базе CVE, то это и есть уязвимость. Ложных срабатываний нет: если нашли — значит беда.
Потенциальная уязвимость — программная ошибка, которая при неудачном стечении обстоятельств может быть использована как уязвимость. Пример: выход за границу массива. Подобные потенциальные уязвимости собраны, например, в CWE (list of software weaknesses). Однако не каждый выход за границу массива это уязвимость. Есть ложные срабатывания, так как любой статический анализатор выдаёт ложные срабатывания.
Если я не так понимаю эти термины, то прошу поправить меня.
Теперь обратимся к статье.
Идёт речь про уязвимости… Чем раньше найдена уязвимость,… продукт нужно периодически проверять на уязвимости…
Еще одна проблема — ложные срабатывания....
Стоп. Откуда ложные срабатывания? Так всё-таки говорится про уязвимости или потенциальные уязвимости?
Я был бы благодарен, если бы вы привели пару практических примеров кода, содержащим то, что в статье называется «уязвимость».
Читаем дальше.
В этом случае разработчика рекомендуется: произвести фильтрацию в статических анализаторах по уязвимостям и по файлам. Можно исключать библиотеки, анализировать критичность, добавлять исключения по определенным параметрам.
Т.е. если уязвимость в библиотеке, то и бог с ней? Эксплуатируй не хочу...? :)
Так может быть это не уязвимости, а просто срабатывания анализатора (по делу и ложные), которые не хочется смотреть? Т.е. потенциальные уязвимости?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как обеспечить безопасность разработки, сохранив время и нервы