Comments 9
Чтобы безопасно нарезать колбасу нужно взять безопасный стол, безопасный нож и безопасную колбасу. Осуществить безопасное нарезание и обязательно оставить запись в журнале безопасности.
Меня OWASP всегда озадачивал дикой смесью очень полезных и практичных шпаргалок по безопасности против отдельных конкретных атак, и вот таких вот общих бесполезных документов. Нет, в теории здесь всё правильно написано, но на практике это применить либо невозможно (потому что требует дикой бюрократии и на порядок больше ресурсов чем есть у 99% проектов), либо бессмысленно (шифровать хранимые данные есть смысл только при условии что получить доступ к ключу шифрования значительно сложнее, чем к данным — а у большинства проектов такой возможности нет), либо не реалистично (по-настоящему безопасные библиотеки/фреймворки, серьёзно?), либо это настолько очевидные вещи что без них вообще проект не напишешь (идентификация и сессии) или они являются штатными фичами (авторизация). В результате для большинства типичных проектов этот "серьёзный документ" вырождается в несколько банальных рекомендаций: проверяйте все данные на входе, экранируйте все данные на выходе, используйте TLS.
Меня OWASP всегда озадачивал дикой смесью очень полезных и практичных шпаргалок по безопасности против отдельных конкретных атак, и вот таких вот общих бесполезных документов.
Всё просто — это как теоретические основы в какой-нибудь области и практичные справочники.
«Проактивная защита: Топ-10 требований OWASP» как раз хорош кажущейся простотой и даже, возможно, банальностью. При этом в нём сделана хорошая попытка системно подать самые основы разработки безопасных веб-приложений.
В результате для большинства типичных проектов этот «серьёзный документ» вырождается в несколько банальных рекомендаций: проверяйте все данные на входе, экранируйте все данные на выходе, используйте TLS.
Парадокс в том, что за каждым из перечисленных выше пунктов скрывается «большая часть айсбергов». В том смысле, что, например, рекомендовать экранировать все данные без учёта существования контекстов их вывода будет недостаточно. И вообще экранировать или всё-таки кодировать? 0_о В проверках всех данных на входе тоже можно наделать ошибок, а уж сколько всего скрывается за «простым» использованием TLS…
«Проактивная защита: Топ-10 требований OWASP», «Top-10 OWASP», «OWASP SAMM» и те же шпаргалки — всё это попытки с разных сторон (и подходов) помочь разрабатывать в результате безопасные приложения.
На самом деле надо не «избегать интерпретации непроверенных входных данных в составе SQL-команд», а «полностью исключить интеграцию любых входных данных в состав SQL-команд».
Ну например — какой толк вести журналирование, если в эти журналы никто не смотрит…
Используйте TLS, однако обнаруженна уязвимость Apple «goto fail»…
В целом напоминает «не родитесь и тогда вы не умрете»…
OWASP Proactive Controls: cписок обязательных требований для разработчиков ПО