Узнать не оставил ли фрилансер бэкдоров в коде

Вредят обычно не из "надобности", вредят обычно из выгоды или по дурости... иногда из выгоды и по дурости сразу одновременно 😂

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

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

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

Не вариант.

У тестировщика не должно быть полномочий изменять исходный код.

так заказчик не шарит что было что стало :) может не все дырки обозначить :)

зы вопщем тема не о чем, хотя нет - о параноиках..)

CMS всегда передаёт какие-то данные куда-то. Например, она передаёт данные посетителю сайта. И принимает от него данные. И записывает их в базу данных.

Доступ к базе данных явно есть у CMS. Иначе зачем вообще база данных? Значит, CMS может забрать данные из базы и показать посетителю. То есть тот факт, что напрямую до БД не достучаться, очень слабо защищает от тех же бэкдоров.

Был у меня один небольшой скрипт, который по url с определёнными хитрыми параметрами показывал определённые данные из базы. Использовался не в качестве бэкдора, но вполне мог бы, если бы в БД в незашифрованном виде хранилось бы что-то полезное.

угу, вот только у CMS доступ через localhost 😂 и ваш стронний скрипт идёт лесом при параметрах любой уровня хитрожопости (если перед этим не был вскрыт сервер, но это уже другая песня). а если проскакивают XSS то это не "оставленный бэкдор", а обычная дырка в безопасности CMS и тоже не в тему..

DiAksID, принцип работы был примерно такой: CMS обращается к базе, смотрит на определённую ячейку, показывает это в браузер. То есть делает всё то, что делает при, например, отображении текста статьи. Статья хранится в БД, CMS обращается к БД (по локалхосту, окей), берёт текст, показывает текст в браузер. Ну, если упрощённо говорить. По сути текст статьи - это всего лишь ячейка БД. Ничто не мешает показывать другую ячейку.

Параметры нужны были просто для отображения именно нужной информации, да и вообще всё это использовалось для тестирования. С тем же успехом параметры можно было упразднить и показывать всё по чистому url без параметров.

это не "упрощённо говоря" - это бред нуба 🙅 , пардон, но факт.

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

DiAksID, возможно, мы просто говорим о разных вещах. CMS заглядывает в БД, а потом показывает в браузере то, что она там увидела. Промежуточные звенья я опускаю сейчас. Она делает это для определённых таблиц/ячеек. Если CMS может делать это для одних таблиц, то может делать и для других. У нас же самописная система, что хочет, то и делает. Так что мешает ей иметь функцию отображения таблиц, нежелательных для этого самого отображения?

Для таких задач надо нанимать человека

на постоянную работу с хорошим окладом.

На самом деле есть простой и действенный способ:

пишите простенький php скрипт (ну или находите его в интернете), который рекурсивно обходит всю вашу файловую систему, где лежит сайт, запоминает её в БД + запоминает к каждому файлу md5

При втором запуске скриптик сверяет md5, который был с md5, который стал + ищет новые файлы, которых не было ранее.

Ну а потом остаётся только визуально проверить то, что изменилось, если квалификация позволяет.