На пути к созданию безопасного веб-ресурса. Часть 2 — разработка

[@rosko]

Позвольте поинтересоваться, из какого фильма первая картинка?

[@KingOfNothing]

Если не ошибаюсь, то из сериала IT Crowd.

[@GearHead]

Разработка продукта на фреимворке — не панацея безопасности (особенно это подтвердил RoR с самого начала года) ...

Мое мнение остается прежним, что лучше весь код писать с нуля, при этом уже имея опыт в безопасности

Ни одна организация никогда не будет настолько крута, как многотысячное open-source-сообщество (прошу только не вспоминать сейчас Windows vs Linux — я не о таких масштабах).

Невозможно набрать достаточно большую команду супер-профессионалов в веб-разработке, чтобы они с нуля писали проекты хотя бы так же быстро, как на фреймворках, и ещё и при этом допускали меньше ошибок в безопасности.

Это фантастика и самоуверенность, которую вы подкрепляете очень спорным аргументом про RoR и WP: если в системе нашли несколько ошибок, это ещё не значит, что система дырявая. Может быть просто очень хорошо искали.

[@anitspam]

если в системе нашли несколько ошибок, это ещё не значит, что система дырявая

По-моему, это станет комментарием месяца.

[@GearHead]

поясните свою демагогию, пожалуйста.

[@anitspam]

Как мне кажется, если в системе есть ошибки, связанные с безопасностью, то система «дырявая». И это даже хорошо, что находят такие ошибки.
yandex.ru/yandsearch?text=theshock+абсолютная+уязвимость
«Абсолютная уязвимость. Все версии. Все полномочия. Просто шедевр. Браво!»

[@GearHead]

в любой программной системе минимум столько вероятных уязвимостей, сколько в ней строк кода. если где-то их не находят, это не значит, что их там нет. и будьте вы хоть двадцать раз супер-крутым infosec-специалистом… вы можете прийти на работу невыспавшимся, вас кто-то может отвлечь, и проявляется человеческий фактор. и тут уже вы допускаете те ошибки, которые фреймворки не дают допускать по определению архитектуре.

[@anitspam]

Интересно, что вы пытаетесь донести? Что разработка на фреймворке — панацея безопасности? Или что «абсолютная уязвимость» в RoR не делает систему «дырявой» (потому что это RoR)?

[@GearHead]

я пытаюсь донести то, что писать велосипеды потому, что они безопаснее — сущий бред. фреймворки и cms уровня WP — не панацея безопасности, вы всегда должны иметь свою голову на плечах. но, тем не менее, с ними гораздо безопаснее, чем без них. вероятность найти в них такую «абсолютную уязвимость» гораздо ниже, чем в вашем супер-секьюрном велосипеде.

[@anitspam]

по части панацеи вы всё-таки соглашаетесь с автором?
и вот про вероятность тоже небольшое дополнение: «в любой программной системе минимум столько вероятных уязвимостей, сколько в ней строк кода.» наверное, в велосипеде будет поменьше строк кода, чем в универсальных фреймворках и cms.

[@GearHead]

вы цепляетесь к словам. вы прекрасно понимаете, что повторив это обобщённое выражение автора про панацею, я выражаю почти обратную точку зрения.

[@syschel]

Извините. Но вы и в повседневной жизни строите велосипеды? Когда вам хочется кушать, вы конструируете плиту, выращиваете продукты?

Если так фанатеть за написание всего с нуля. То и язык нужно писать свой и среду, и сервер и операционку. А под конец и железо своё делать.
Потому что это всё, тоже может иметь свои уязвимости.

[@BeLove]

Согласен, если команда хотя бы > 5 человек, то разрабатывать нужно на фреимворке. Фреимворк в данном случае сократит риски намного больше, чем уменьшится риск от того, что приложение разрабатывается с нуля и его не взломают именно через уязвимости в фреимворке.

[@Die_Gelassenheit]

Автор, может быть, стоит в конце поста привести какой-нибудь список источников (кроме «набивайте шишки сами», конечно :) ), чтобы почитать и углубить знания по теме для заинтересовавшихся темой?

[@truezemez]

OWASP

[@dkiyatkin]

Не думаю, что писать код с нуля лучше, чем вариант не плодить сущностей и пользоваться проверенными своими или чужими решениями.

[@ngreduce]

Я думаю имелось ввиду как раз свое, проверенное решение.

[@ngreduce]

А я всегда считал что экранирование символов перед записью в базу данных как раз является менее безопасным.

[@abrwalk]

>>Прямой доступ к файлам в принципе невозможен.

есть ещё такая штука
wiki.nginx.org/HttpCoreModule#internal
в секции с fastcgi запретит запросы к скриптам напрямую