Инфосистемы Джет corporate blog
Information Security
Website development
Web services testing
Comments 9
+2
Выглядит конечно странновато.
Чтобы безопасно нарезать колбасу нужно взять безопасный стол, безопасный нож и безопасную колбасу. Осуществить безопасное нарезание и обязательно оставить запись в журнале безопасности.
+2
Если бы все соблюдали эти правила — мы бы каждый день не читали про взлом того или иного ресурса или крупную утечку.
+3
Ну это некая попытка формализовать знания известные опытным разработчикам. Дело нужное, если не будет заброшено и будет дополняться и развиваться.
0

Меня OWASP всегда озадачивал дикой смесью очень полезных и практичных шпаргалок по безопасности против отдельных конкретных атак, и вот таких вот общих бесполезных документов. Нет, в теории здесь всё правильно написано, но на практике это применить либо невозможно (потому что требует дикой бюрократии и на порядок больше ресурсов чем есть у 99% проектов), либо бессмысленно (шифровать хранимые данные есть смысл только при условии что получить доступ к ключу шифрования значительно сложнее, чем к данным — а у большинства проектов такой возможности нет), либо не реалистично (по-настоящему безопасные библиотеки/фреймворки, серьёзно?), либо это настолько очевидные вещи что без них вообще проект не напишешь (идентификация и сессии) или они являются штатными фичами (авторизация). В результате для большинства типичных проектов этот "серьёзный документ" вырождается в несколько банальных рекомендаций: проверяйте все данные на входе, экранируйте все данные на выходе, используйте TLS.

+1
Меня OWASP всегда озадачивал дикой смесью очень полезных и практичных шпаргалок по безопасности против отдельных конкретных атак, и вот таких вот общих бесполезных документов.

Всё просто — это как теоретические основы в какой-нибудь области и практичные справочники.
«Проактивная защита: Топ-10 требований OWASP» как раз хорош кажущейся простотой и даже, возможно, банальностью. При этом в нём сделана хорошая попытка системно подать самые основы разработки безопасных веб-приложений.
В результате для большинства типичных проектов этот «серьёзный документ» вырождается в несколько банальных рекомендаций: проверяйте все данные на входе, экранируйте все данные на выходе, используйте TLS.

Парадокс в том, что за каждым из перечисленных выше пунктов скрывается «большая часть айсбергов». В том смысле, что, например, рекомендовать экранировать все данные без учёта существования контекстов их вывода будет недостаточно. И вообще экранировать или всё-таки кодировать? 0_о В проверках всех данных на входе тоже можно наделать ошибок, а уж сколько всего скрывается за «простым» использованием TLS…

«Проактивная защита: Топ-10 требований OWASP», «Top-10 OWASP», «OWASP SAMM» и те же шпаргалки — всё это попытки с разных сторон (и подходов) помочь разрабатывать в результате безопасные приложения.
0
> C3: Обеспечение безопасного доступа к базам данных

На самом деле надо не «избегать интерпретации непроверенных входных данных в составе SQL-команд», а «полностью исключить интеграцию любых входных данных в состав SQL-команд».
-2
Странное ощущение, вроде все правильно, а на деле как то не але…

Ну например — какой толк вести журналирование, если в эти журналы никто не смотрит…
Используйте TLS, однако обнаруженна уязвимость Apple «goto fail»…

В целом напоминает «не родитесь и тогда вы не умрете»…
0
К статье напрашивается краткая схема с отображением этих принципов.
Only those users with full accounts are able to leave comments. , please.