PHP — фреймворки, ORM, инкапсуляция

Помимо языков/сред программирования, много ли разработчиков используют фреймворк в PHP, ORM и все еще соблюдают инкапсуляцию для DAL/BLL? Я управляю командой из нескольких разработчиков и обнаружил, что большинство фреймворков требуют от меня ежедневной проверки кода, потому что мои разработчики используют встроенный ORM.

Прямо сейчас я использую инструмент для создания классов и CRUD самостоятельно, с областью для них, чтобы написать дополнительные запросы/функции. Однако происходит то, что они создают уязвимости, не выполняя надлежащих проверок разрешений на данные или позволяя манипулировать ключевыми полями в форме.

Любые предложения, кроме получения новой команды и нового языка (я видел, что фреймворки Python/Ruby имеют те же проблемы).


frameworks php orm encapsulation
person Community    schedule 24.04.2010    source источник
comment
(связано) stackoverflow .com/questions/2465091/   -  person Gordon    schedule 24.04.2010

Ответы (4)


arrow_upward
3
arrow_downward

Выбрасывать команду нельзя: вместо этого улучшайте ее!

  • Организуйте семинары по безопасности, чтобы они больше знали об этих проблемах.
  • Представьте (или даже лучше: попросите их представить) строки руководства по коду для лучшего решения этих проблем (венгерская нотация с учетом безопасности или использование подготовленные операторы являются двумя примерами)
  • Устраните недостатки в обзорах кода — не обвиняйте их в игнорировании безопасности, просто покажите найденные проблемные фрагменты и объясните, что безопасность очень важна для [выберите одно: этот проект/клиент/репутация вашей компании/вас лично]
  • Позвольте им проводить проверки безопасности самостоятельно или в коде коллег. Пусть они узнают, как легко использовать такие недостатки безопасности.
  • Найдите другие инструменты/фреймворки, которые лучше поддерживают вашу модель безопасности. Но имейте в виду: этот вариант очень дорогой! Вашим программистам нужно будет поддерживать код в старом фреймворке и изучать новый (в худшем случае: им нужно будет изучать новый язык вместе с новым фреймворком).

Но в основном это проблема, которую вы должны решать совместно с вашими разработчиками. Если вы объявите им войну, вы обязательно проиграете (независимо от исхода для разработчиков).

person soulmerge    schedule 24.04.2010
comment
Спасибо. Я представил руководства, обзоры кода, обзоры безопасности и т. д. По иронии судьбы, они понимают XSS/SQL-инъекции и многое другое (главным образом потому, что фреймворк обрабатывает это). Моя проблема в том, что они в значительной степени воспроизводят среду скаффолда, где они не могут проверить надлежащие права доступа к данным. Я заставил их пройти через варианты использования, модульные тесты и т. д., но они изменят модели, чтобы раскрыть все частные методы/члены, чтобы упростить им задачу, и просто использовать операторы типа CRUD, позволяющие любому манипулировать другими пользователями. данные, изменив идентификатор в форме. - person ; 25.04.2010
comment
Если вы не можете заставить их работать над проблемами безопасности, возможно, вам следует попросить внешних разработчиков попытаться взломать ваш собственный сайт. Внесите каждый успешный взлом как ошибку в свою систему отслеживания ошибок. Таким образом, и вы, и ваши разработчики получите метрики, насколько безопасно приложение на самом деле. Люди учатся на ошибках гораздо лучше, чем на чужих словах. - person soulmerge; 25.04.2010

arrow_upward
1
arrow_downward

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

По сути, у меня сложилось впечатление, что сейчас очень мало общения между разработчиками и вами. Может быть, я просто вчитываюсь в это, но мне кажется, что разработчики заперты в подвале, а вы сидите где-то в другом месте и расстраиваетесь из-за они. Измените такое мышление. Вы являетесь частью команды.

Если ваши разработчики не знают об уязвимостях, которые они вносят в код, рассмотрите возможность проведения еженедельных обзоров кода. Пусть разработчики расскажут о коде, который они написали. Пусть они учатся друг у друга. Сделайте код коллективным. Поощряйте обучение и конструктивную критику.

Помните, в Команде нет Я.

person Gordon    schedule 24.04.2010
comment
Спасибо. Помимо корпоративного климата, примерно один день в неделю я просматриваю код. У меня есть документация о том, что они должны делать. Я просматриваю предыдущие шаги, провожу семинары, но они не слушают. Я следил за программированием XP, пробовал Agile и т. д. Команда считает, что они знают лучше, чем все остальные. Я могу закончить тем, что напишу все модели сам, так как они все равно идут и раскрывают частные методы и свойства. - person ; 25.04.2010
comment
@Ian, вы можете использовать некоторые инструменты на phpqatools.org для написания анализаторов кода, которые обнаруживают нарушения кода и предотвращают проверки VCS или в целом подтверждают вашу точку зрения о качестве кода. Но если фронтинг уже есть, возможно, имеет смысл нанять нейтрального внешнего консультанта, например, sektionseins.de или thePHP.cc (не связанного с ними — просто назову самых известных). - person Gordon; 25.04.2010

arrow_upward
0
arrow_downward

Могу ли я порекомендовать Nepthali? Это не ORM, но структура предназначена для обеспечения безопасности. т.е. все переменные кодируются перед выводом на экран; если явно не определено не слишком.

Он также довольно компактен, не имеет ORM и т. д., поэтому вы можете подключить к нему любой ORM, какой захотите. Это довольно мило, на самом деле.

person Zee Spencer    schedule 24.04.2010
comment
Спасибо, но проблемы безопасности, о которых я говорю, это невозможность проверить, есть ли у пользователя доступ к данным. Таким образом, они напишут общую функцию загрузки по первичному ключу и будут использовать ее для всего, поскольку они тестируют только одного пользователя. Все методы CRUD следуют этой проблеме, поэтому, пока у них есть доступ к данным, они предоставляют их пользователю. - person ; 25.04.2010

arrow_upward
0
arrow_downward

Если вы хотите проверить, есть ли у пользователя доступ к свойству, это другой уровень, отличный от уровня доступа к данным. Но все же есть фреймворки, в которых вы можете переопределить функциональность загрузки по умолчанию и вставить свою логику после/перед загрузкой.

Самый легкий фреймворк, с которым я когда-либо работал, — это db.php (http://dbphp.net, https://github.com/hazardland/db.php). Но это рациональный преобразователь кода первого объекта. Вам нужно будет определить классы, после чего базы данных\таблицы будут созданы в соответствии с вашими классами.

Взгляните на метод \db\table::load. У каждого класса есть собственный экземпляр обработчика \db\table, расположенный в массиве database::tables. Вы можете переопределить table::load или создать отдельные обработчики для таблиц, производных от класса \db\table, и поместить их в базу данных::tables.

Единственная проблема заключается в том, что фреймворк не полностью документирован, но имеет очень легкую интуитивно понятную структуру кода и примеры.

Другой вариант - сделать фреймворк dal самостоятельно, это займет до 3-4 месяцев у 1 человека, чтобы сделать его полнофункциональным и мощным.

person BIOHAZARD    schedule 08.09.2014