Comments 20
Позвольте поинтересоваться, из какого фильма первая картинка?
UFO just landed and posted this here
Разработка продукта на фреимворке — не панацея безопасности (особенно это подтвердил RoR с самого начала года) ...
Мое мнение остается прежним, что лучше весь код писать с нуля, при этом уже имея опыт в безопасности
Ни одна организация никогда не будет настолько крута, как многотысячное open-source-сообщество (прошу только не вспоминать сейчас Windows vs Linux — я не о таких масштабах).
Невозможно набрать достаточно большую команду супер-профессионалов в веб-разработке, чтобы они с нуля писали проекты хотя бы так же быстро, как на фреймворках, и ещё и при этом допускали меньше ошибок в безопасности.
Это фантастика и самоуверенность, которую вы подкрепляете очень спорным аргументом про RoR и WP: если в системе нашли несколько ошибок, это ещё не значит, что система дырявая. Может быть просто очень хорошо искали.
если в системе нашли несколько ошибок, это ещё не значит, что система дыряваяПо-моему, это станет комментарием месяца.
поясните свою демагогию, пожалуйста.
Как мне кажется, если в системе есть ошибки, связанные с безопасностью, то система «дырявая». И это даже хорошо, что находят такие ошибки.
yandex.ru/yandsearch?text=theshock+абсолютная+уязвимость
«Абсолютная уязвимость. Все версии. Все полномочия. Просто шедевр. Браво!»
yandex.ru/yandsearch?text=theshock+абсолютная+уязвимость
«Абсолютная уязвимость. Все версии. Все полномочия. Просто шедевр. Браво!»
в любой программной системе минимум столько вероятных уязвимостей, сколько в ней строк кода. если где-то их не находят, это не значит, что их там нет. и будьте вы хоть двадцать раз супер-крутым infosec-специалистом… вы можете прийти на работу невыспавшимся, вас кто-то может отвлечь, и проявляется человеческий фактор. и тут уже вы допускаете те ошибки, которые фреймворки не дают допускать по определению архитектуре.
Интересно, что вы пытаетесь донести? Что разработка на фреймворке — панацея безопасности? Или что «абсолютная уязвимость» в RoR не делает систему «дырявой» (потому что это RoR)?
я пытаюсь донести то, что писать велосипеды потому, что они безопаснее — сущий бред. фреймворки и cms уровня WP — не панацея безопасности, вы всегда должны иметь свою голову на плечах. но, тем не менее, с ними гораздо безопаснее, чем без них. вероятность найти в них такую «абсолютную уязвимость» гораздо ниже, чем в вашем супер-секьюрном велосипеде.
по части панацеи вы всё-таки соглашаетесь с автором?
и вот про вероятность тоже небольшое дополнение: «в любой программной системе минимум столько вероятных уязвимостей, сколько в ней строк кода.» наверное, в велосипеде будет поменьше строк кода, чем в универсальных фреймворках и cms.
и вот про вероятность тоже небольшое дополнение: «в любой программной системе минимум столько вероятных уязвимостей, сколько в ней строк кода.» наверное, в велосипеде будет поменьше строк кода, чем в универсальных фреймворках и cms.
вы цепляетесь к словам. вы прекрасно понимаете, что повторив это обобщённое выражение автора про панацею, я выражаю почти обратную точку зрения.
Извините. Но вы и в повседневной жизни строите велосипеды? Когда вам хочется кушать, вы конструируете плиту, выращиваете продукты?
Если так фанатеть за написание всего с нуля. То и язык нужно писать свой и среду, и сервер и операционку. А под конец и железо своё делать.
Потому что это всё, тоже может иметь свои уязвимости.
Если так фанатеть за написание всего с нуля. То и язык нужно писать свой и среду, и сервер и операционку. А под конец и железо своё делать.
Потому что это всё, тоже может иметь свои уязвимости.
Согласен, если команда хотя бы > 5 человек, то разрабатывать нужно на фреимворке. Фреимворк в данном случае сократит риски намного больше, чем уменьшится риск от того, что приложение разрабатывается с нуля и его не взломают именно через уязвимости в фреимворке.
Автор, может быть, стоит в конце поста привести какой-нибудь список источников (кроме «набивайте шишки сами», конечно :) ), чтобы почитать и углубить знания по теме для заинтересовавшихся темой?
Не думаю, что писать код с нуля лучше, чем вариант не плодить сущностей и пользоваться проверенными своими или чужими решениями.
А я всегда считал что экранирование символов перед записью в базу данных как раз является менее безопасным.
>>Прямой доступ к файлам в принципе невозможен.
есть ещё такая штука
wiki.nginx.org/HttpCoreModule#internal
в секции с fastcgi запретит запросы к скриптам напрямую
есть ещё такая штука
wiki.nginx.org/HttpCoreModule#internal
в секции с fastcgi запретит запросы к скриптам напрямую
Sign up to leave a comment.
На пути к созданию безопасного веб-ресурса. Часть 2 — разработка