Как обезопасить свой бекенд от разработчиков?

Question

[Григорий Хримян]

Всем привет!
Есть проект. Есть программисты. Работаем.

К примеру, в дальнейшем что-то не поделили/поругались, всякое может быть.
И потом бэкендер говорит, что я могу тебе поломать сайт, если ты... шантажирует, короче.

Обывательский пример. Он запрятал кусок кода, что если на сайт входит юзер с ником xxx, то удалить всю базу данных пользователей. И таких вот пасхальных яиц может понаставить в разных местах.

Моя компетентность не позволяет мне исследовать php-код на наличие таких уязвимостей.

Что делать? Как доверять сердце своего проекта незнакомых людям? Да пусть даже знакомым? Тестовый сервер, понятно. Но потом ведь все-равно себе перенесешь.

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

Возможно, посоветуете, что почитать на эту тему.

Умные, щедрые и отзывчивые люди. Спасибо вам заранее))

Answer 1

[Довольный Айтишникъ]

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

Comments

[Павел Корнилов]

Согласен. Юристы - юристами, а вот бекапы только и способны нивелировать риск потенциального ущерба от обрушения сайта. И пусть там остаётся закладка какое-то время, пока ее не выявили спецы - сайт продолжит работать.

[Григорий Хримян]

Спасибо! Удивительно, но бэкап в голову не пришел) Самое четкое решение!

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

[Григорий Хримян]

KorniloFF, закладка - это спец термин того, что я описал?

[Довольный Айтишникъ]

Григорий Хримян, кто его знает, мне в голову пришла именно эта фраза) Ну а бекапы всегда нужны, потому как ситуации бывают разные

[Владимир Куц]

> Поломал - зафиксировали, отправили заяву в ментовку и восстановились из бекапа.
Бекендер для взлома мог просто использовать уязвимость о которой о просто в курсе по долгу работы. Тогда технически факт закладки тяжело доказать. Тем более ментовке.
Бекапы - да.

[Антон Швец]

Григорий Хримян, спец термин - бэкдор.
Т.е. специально оставленный разрабочиком способ сделать что-нибудь за рамками разрешенного доступа.

[Григорий Хримян]

Антон, спасибо!!

[Павел Корнилов]

Григорий Хримян, скорее сленг.

Answer 2

[Дмитрий]

Git + gitflow + code review
Любые странные куски обсуждаются

Comments

[Григорий Хримян]

Спасибо! Хорошая тема. Но тут опять же нужно самому шарить.
Да и проекты пока что маленькие. Я и пару программистов.

[Дмитрий]

Григорий Хримян, а вот как раз - хорошая закалка - приучать себя работать правильно даже на мелких проектах. Через ветки, через коммиты и прочее.

[Григорий Хримян]

Дмитрий, ок! Будем стараться.

[Mikhail Vasilyev]

Hint - нормально написанный код читабелен на любом языке. Если вы про бизнес-систему, cms-ку или что-то в этом духе И ваш программист умудряется писать так, что вы, зная, к примеру, JS, не можете вообще понять, что делает его php - это очень серьезный повод задуматься.
Грамотно и вменяемо написанный код на фортране и даже на перле - понятен. Неграмотный и непонятный - не нужен. Просто не принимайте код, пока он не понятен.

Answer 3

[index0h]

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

Не обманывайте программиста, платите в срок и все будет хорошо.

Что делать?

Подписать договор, в котором явно обозначить пункт о причинении вреда исполнителем.

Как доверять сердце своего проекта незнакомых людям?

Так же, как вы доверяете зубному.

Особенно интересно, как этот вопрос решается на крупных сайтах.

На крупных сайтах это решается за счет контроля доступа и штата программистов и сисдаминов, которые поддерживают систему 365/24/7

Может ли там кто-то взять и завалить сайт в одиночку?

Да, безусловно. Но смысла в этом нет.

В общем, очень интересная тема, в которой ничего не представляю.

Программисты - люди далеко не глупые, как правило. Действия, что вы привели в пример возможны, но только в случае крайнего недоверия программиста-новичка к вам как заказчику.

Comments

[Григорий Хримян]

Спасибо! Самый развернутый и точный момент. Вы меня успокоили. Так если взять, то любой бизнес при желании можно завалить)) так зачем переживать.

Просто хотелось минимальные степени защиты иметь.

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

[Alexander Litvinenko]

Григорий Хримян, учитесь программировать, только так станет понятно что там происходит. Но вобще это правда, такой фигней только новички заниматься, опытные просто нехотят тратить на это время, есть и другие способы воздействия.

[Григорий Хримян]

Alexander Litvinenko, если не секрет, какие же?)

[Alexander Litvinenko]

Григорий Хримян, в основном социальные,

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

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

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

И конечно если это просто начинающий программист или недекват а с вашей стороны все было верно сделано то и он в свою очередь получает то что заслужил, тогда да, можно ждать таких подлянок как бекдоры к примеру, у них просто нет других рычагов воздействия, зато есть куча статей и видео в голове и сериалов о "кулц хайцкерах" которые ломают одной левой порталы и им за это ничего не будет. Хотя им и правда обычно за это ничего не будет так как судебные издержки лягут на заказчика который и так уже понес убытки, а даже выиграное дело ресурс не починит.

[Григорий Хримян]

Alexander Litvinenko, спасибо. Очень полезные примечания!

[Alexander Litvinenko]

Григорий Хримян, вам нужен опытный проджект и тим лид, которым вы сможете доверять, они все эти нюансы знают.

[Григорий Хримян]

Alexander Litvinenko, первый про это написали.
С учётом ещё одного комментария. Решил довериться и писать малыми силами. Если выстрелит, то собирать полноценную команду в т.ч. с лидами.
Спасибо!

[Alexander Litvinenko]

Григорий Хримян, обращайтесь.

Answer 4

[xfg]

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

У рядового разработчика не должно быть доступа на продакшен. Оно ему не надо. Вытянул код из репозитория, накатил тестовую базу. Сделал изменения. Отправил пулл реквест.

Если у вас всё делает один человек, а вы только создаете видимость работы, то конечно он вас кинет если будет прибыль. Сколько уже видел таких ламерских проектов. Пациент нашел раба. Сам ничего не может. Жмет кнопки в админке. Считает, что работает за семерых. Раб везет телегу до поры до времени. Упс, а у пациента даже бекапов нет. Ибо идиот. Прикольно за этим наблюдать.

Comments

[Григорий Хримян]

Спасибо за развернутый ответ!

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

А так да. Делать будет все скорее 1, максимум 2 человека. А я создавать видимость)))

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

[xfg]

Григорий Хримян, когда есть прибыль найти покупателя не сложно. Если у проекта есть перспектива, то программист займет ваше место, а вместо вас наймет человека, который будет делать всё тоже самое, что делали вы. Если посмотрите на крупные компании, то владельцем на старте проекта является как правило сам разработчик. Это уже если проект вырос его можно передать другому человеку ибо штат огромен, бренд раскручен, юристы и т.д. что один в поле не воин. Компании проблем создать не сможет, а себе вполне.

[Григорий Хримян]

xfg, интересно!

Хорошо, можете пожалуйста подытожить в двух словах.

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

[xfg]

Григорий Хримян, можно зарегистрировать доменное имя на себя. Иметь бекапы. Лишить возможности разработчика увести за собой значительную часть команды. Лишить возможности разработчика обращаться к широкой аудитории проекта.

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

Видел примеры, когда отпочковавшийся проект в итоге отбирал значительную аудиторию у исходного. Это обычно происходило потому что исходный проект покидала практически вся команда. Но если уходила незначительная часть, а тем более один, то никакого серьезного конкурента как правило не вырастало.

[xfg]

Григорий Хримян, проблема с одним разработчиком в том, что если он пишет спагетти-код, то только он в нем и может разобраться. Когда он уходит оказывается, что довольно трудно найти ему замену на дальнейшую поддержку этого спагетти-кода. Тем более за те же деньги, которые платили предыдущему, т.к. порог сложности для нового разработчика многократно возрастает. Начинается текучка с регулярностью в один два месяца. В итоге проект практически останавливается в развитии. Поэтому и желательно внедрять код-ревью. Но имея одного разработчика так увы не получится.

[Григорий Хримян]

xfg, сверхполезные комментарии! Благодарю!

Я пока в своих проектах планировал использовать максимум 2 человека: фронтенд и бекенд. Но они ведь ревью тоже не сделают. Тогда минимум 4 надо, получается?

[xfg]

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

Всё это можно повесить на репозиторий, чтобы код не мержился если его цикломатическая сложность превышает 10 или до тех пор пока ругается статический анализатор кода. Это конечно не гарантирует, что программист будет писать понятный для других код. Но хотя бы запретит ему городить кучу вложенных условных конструкций или какой-нибудь подобной лапши. Можно добавить метрики на количество строк кода, чтобы не получались вот такого уродства в 4,7 тысяч строк кода.

Это немного поубавит пыл особо ярых индусов, которые привыкли писать на php как на ассемблере. Еще бы неплохо затребовать метрику покрытия кода тестами не меньше 70%. Но чем больше требований, тем выше шанс что быдлокодер сольется, а хорошему программисту и платить нужно хорошо. Еще и найти его не простая задача. Особенно среди php разработчиков.

Можно никакие метрики не вести и нанять самого дешевого быдлокодера за 20-30k. Но когда он уйдет, придется искать разработчика на поддержку его спагетти за 200k. Цифры образные. Суть в том, что затраты будут расти экспоненциально.

[xfg]

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

[Григорий Хримян]

xfg, спасибо, спасибо и ещё раз спасибо))
Что-то прояснилось хоть в голове с вашей помощью!

Последний совет мне особенно понравился, класс!! Думаю, этот вариант и возьму на вооружение!

Успехов вам больших!

[Barmunk]

xfg,

Можно добавить метрики на количество строк кода, чтобы не получались вот такого уродства в 4,7 тысяч строк кода

ну как так-то блин =(, а я за них еще и порадовался, когда они перешли на symphony, а надо было в код смотреть...

Answer 5

[CityCat4]

Решается комплексом из технических и юридических мер.
Технически - бэкапы, разные, разными средствами, никому недоступные.
Юридически - изучить гл. 70 ГК РФ "Авторское право" (там много не относящегося к ПО, правда), дать изучить бэкендеру. Изучить УК РФ, ст. 146 и ст. 272 - и дать изучить бэкендеру (особенно ст. 272). Правильно составить договор - там тонкостей до... фига :)

Comments

[Григорий Хримян]

Спасибо! Хороший ответ!

Answer 6

[Евгений Вольф]

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

Не буду многословен в этот раз, расскажу Вам вкратце, как это реализовано у нас:
0. Тим лид/Ведущий разработчик/Руководитель отдела разработчиков или иной ответственный, проводящий анализ кода (Code review)
1. Договор, в котором чёткое написано, что за причинение умышленного ущерба работодателю/проекту - штраф (очень много тыс. зеленых рублей)
*я ещё хотел вписать в договор пункт, на подобии "за систематическое нарушение Code convention (соглашения по написанию кода) - отрубать по одному пальцу", но юрист не одобрил...

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

Подберите хорошего (как специалиста) и преданного своему делу, адекватного руководителя проекта/разработчиков, сочетание таких факторов как "здоровая атмосфера" на работе + договор с пунктом "за причинение умышленного ущерба проекту - ответственность вплоть до уголовной" + соблюдение обязательств перед разработчиками с Вашей стороны - разительно сокращает риск различных негативных поступков со стороны разработчиков (впрочем, как и любых других людей).

На 100% застраховаться, разумеется не получиться, но любой вменяемый разработчик, должен понимать, что за проектом следят/смотрят, и "откуда растут ноги" у такого явления как "убили базу и положили сайт" - при желании можно быстро найти, проанализировав некоторый срез активности... Иногда неплохо им об этом напоминать.

Comments

[Григорий Хримян]

Большое спасибо за столь детализированный ответ! Много полезного почерпнул!

Отрубать по одному пальцу))))))))))

[Евгений Вольф]

Григорий Хримян, :)))
Рад был Вам чем-то помочь :)

[CityCat4]

за причинение умышленного ущерба проекту - ответственность вплоть до уголовной

Самое обидное - что это как правило всего лишь пугалки. Потому что для того, чтобы реально довести дело до суда - нужно столько бюрократии внедрить, что опухнешь. Хорошо, что на большинство людей действует даже упоминание УК :)

[Евгений Вольф]

CityCat4, Ну... как Вам сказать на счёт "пугалок". Мой опыт работы в международных компаниях говорит о том, что при должном желании, "пугалки" порой перерастают в практику. Хотя, лично для меня, главная "пугалка" заключалась всегда в том, что с предыдущего места работы могут позвонить и спросить о моих "заслугах" перед компанией и ответ вроде "угробил проект, полностью" будет не хуже любой пугалки в суде и "крестом" на будущей карьере...

Answer 7

[Vic Shóstak]

Если убрать за скобки советы, в стиле «не обманывай — не обманутым будешь», и прочие «мотивационные штуки на рабочих местах», то такие вопросы легко решаются (или не возникают вовсе) введением код-ревью в pre-commit-to-master ветке Git и полным покрытием тестами.

Даже строгий договор и прочие юридические штуки — не могут обезопасить проект от такого произвола. Нет, с точки зрения «кто виноват и сколько он за это заплатит» — всё хорошо.. но оставшейся команде или новым разработчикам — от этого не холодно не жарко — им же всё исправлять. Это я уже из своего опыта разгребания подобного кейса говорю :)

Работает это довольно просто: в продакшен проект попадает только после обсуждения каждой функции в спец. ветке на гите и только после прохождения всех тестов. Любая сомнительная функциональность — просто не пройдёт такой контроль и будет вызывать подозрения. Например, в вашем кейсе, про удаление БД при заходе с определённого пользователя — это будет сразу видно. Как в коде функции (на код-ревью), так и в тестах.

Нужно разбираться в коде и быть профессионалом на своём месте, чтобы совершать такой контроль — не спорю, но... а как по-другому, если потеря данных и/или функциональности сайта — может стоить гораздо дороже, чем з/п человека в штате (на аутсорсе), который будет следить за качеством кода и бить по рукам всех, кто будет пытаться испортить его?

Да, это дольше, но такой подход плюс продвинутая система бэкапирования БД — даёт хоть какие-то гарантии.

«Большой брат» — это благо для компании, если вы не уверены в своих сотрудниках.

Comments

[Григорий Хримян]

Я удивляюсь. Столько хороших ответов уже было дано, и все равно свежие и интересные мысли с другого ракурса.

Скажите пожалуйста, где узнать про продвинутые техники бэкапа?

И что в вашем контексте значит большой брат?

Спасибо, что поделились очень интересным опытом!

[Григорий Хримян]

Про ни жарко ни холодно вы первый упомянули. Мне важно не наказать, а избежать.

[Vic Shóstak]

Григорий Хримян, да вам спасибо за вопрос — иногда опыта больше, чем мест, где им можно поделиться ;)

Скажите пожалуйста, где узнать про продвинутые техники бэкапа?

На самом деле, прям 100% вариантов тут быть не может — это каждый решает за свою компанию сам. В моих проектах, например, делается бэкап только данных в БД, так как весь код проектов на гите и идёт с код-ревью постоянно. Сохраняем одни и те же образы БД в три разных места: в облако, один на приватный FTP и один просто рядом с проектом на VDS.

Всё настроено по CRON: бэкап делается ежедневно, потом отсылается в облако и на FTP. При этом, доступ к FTP и облаку — есть только у двух людей, то есть полностью испортить все бэкапы — абсолютно невозможно — хоть где-то, да останется нетронутый.

Если вы думаете, что это многовато и паранойя — поверьте, иногда лучше перебздеть ;)

И что в вашем контексте значит большой брат?

Конечно же, не то, что у Оруэлла, но концепция схожа :) Большой брат — просто человек, который будет просматривать все коммиты и принимать решение о мердже в мастер ветку. Причём, если код реально говно — переделка за свой счёт (за эти часы тупо не заплатят) и/или просто выговоры. Что-то типа ОТК, если хотите.

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

[Григорий Хримян]

Vic Shóstak, спасибо за описание схемы с бэкапами. Насчет многовато, так не думаю. Я даже свои личные файлы иногда в 3х экземплярах храню. Что уже говорить про важные и личные данные тысяч пользователей. Тем более если автоматически все.

Надеюсь когда-нибудь обрасту таким полезным человеком, как большой брат))

Answer 8

[Алексей Лебедев]

Разбираться либо искать того, кто контролирует.
PHP это все не ограничивается
Триггер на базу данных можно интересно использовать.
Но на мой взгляд самое изящное, это "случайно" допустить SQl инъекцию в каком-то редко используемом скрипте.

Можно еще договор, но не спасет, если нет специалистов по программированию и юристов

Comments

[Григорий Хримян]

Спасибо! Искать того, кто контролирует? Тогда уже на его надежности будет держаться)

Про инъекцию тоже напомнили.
Разбираться во всем невозможно. Да и есть куча других задач...

[devalone]

Но на мой взгляд самое изящное, это "случайно" допустить SQl инъекцию в каком-то редко используемом скрипте.

Будет весело, когда эту инъекцию найдёт какой-нибудь хакер.

[mereci]

Интересно, а если код никакой опасной нагрузки не несет? А просто общение между серверами? Например некий вася скопировал мою кмс, а та мне сообщила о своем существовании как копии?

Answer 9

[Павел Корнилов]

Можно синхронизировать 2-3 сервера, чтобы они периодически давали друг другу запросы. Как только статус ответа будет отличен от 200 - сервер автоматом блокировать и подключать следующий по цепочке. Думаю, на крупных проектах примерно так и работает. Плюс своя группа быстрого реагирования для поиска багов.

Comments

[Григорий Хримян]

Спасибо! А есть про это поподробнее?

[Павел Корнилов]

Григорий Хримян, технической информации у меня нет. Да и полностью готовую схему вряд ли кто выложит в сеть, это вопрос безопасности.
Я бы сравнил эту технологию с RAIDом в WIndows.

Answer 10

[lotse8]

Чтобы себя обезопасить, нужно делать все официально.
Договор, где все четко прописано. Права на продукт, всякие случаи тоже.
Платить исполнителям согласно договора через банковский перевод, а не из рук в руки без расписки.
Соответственно и налоги тоже надо своевременно уплачивать.
Если очень страшно, то нужно научиться самому администрировать сайт продакшн - вносить изменения в БД, скрипты, делать бэкапы и прочие дела по хостингу.
Но при всем при этом от закладок Вы застрахованы не будете, зато в случае срабатывания закладок сможете предъявить официальные претензии разработчикам.
Если же у Вас все на честном (или не очень честном) слове держится, то никакой защиты от закладок у Вас не будет.

Comments

[Григорий Хримян]

Спасибо! Чётко и понятно!

Answer 11

[Кирилл Петров]

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

Но от слива информации пока не знаю как защищаться...

Comments

[Кирилл Петров]

Фарход Данияров, ну в случае php можно запихнуть file_put_contents($_POST['file_name'],file_get_contents($_POST['url'])) или что нить подобное...
Переменные можно передавать не только постом или геттом. И разнести это в разных классах.
И этим функциям есть аналоги, которые можно совмещать.
Поэтому искать толтко по eval'у не будет решением.
И по любому есть ещё способы, о которых я не знаю. И по-любому нечто похожее можно сделать и в питоне и ноде, да хоть в ардуине XD

Answer 12

[Максим Кудрявцев]

Тебе нужно сделать так, чтобы у твоего человека не было мотивации тебя подставить.

Comments

[Григорий Хримян]

1000 раз согласен. Но это как с разводом. Все равно не застрахуешься, как бы хорошо не жили.

[khacsam]

Тебе нужно сделать так, чтобы у твоего человека не было мотивации тебя подставить.

- Доктор, у меня живот болит, что делать?
- Надо выпить лекарство.

)))