Проверка чужого скрипта на вшивость

[SCR]

Проверка чужого скрипта на вшивость

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

 

[The employer]

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

Надо смотреть на подписанные с программистом юридически обязывающие документы. В частности, как приложение - листинг того самого кода (да, несколько пачек бумаги). И подписанный NDA, конечно.

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

 

[zerkms]

несколько метров чистого кода

это не шутка??

 

[Krishna]

это не шутка??

а я не программист в общем

HTML небось.
Или лютая цмс, навроде Xaraya

 

[nerezus]

Ну у меня 20мб был сайтик, но с чужими либами.

 

[Mandor]

Автор оригинала: SCR
На что в первую очередь стоит обратить внимание?

Я бы потратил время на следующее:

• Проверка входных данных. Очевидно, что для того чтобы запустить скрытый код нужно передать скриптам какие-то данные (есть еще вариант что скрытый код сработает сам при определенных обстоятельствах), т.е. мы можем: 1. ограничить входные данные, 2. анализировать и логгировать подозрительные.
• Бегло проверить код на наличие функций: eval, create_function, include, require - нужно удостовериться, что внешний пользователь не сможет запустить динамически сгенерированный им же код и не сможет "заинклюдить" файл по имени, генерируемому по входным данным.
• Проверить скрипты аплоада файлов. Нельзя заливать что угодно и куда угодно.
• Имеет смысл проверить критичные для безопасности sql-запросы (например, к таблице пользователей-паролей) и вообще поискать такие запросы по всему проекту (например, по имени таблицы, хотя его не составит труда зашифровать).

На все это не стоит тратить времени более 1-2 часов, т.к. в принципе эта задача по простому не решается, просто есть шанс, что вам повезет.

 

[Mr_Max]

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

 

[TutanXamoN]

Mr_Max
+100)

 

[findnext]

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

 

[pilot911]

интересно, как в ФСБ контролируется качество кода ?

 

[vovanium]

как в ФСБ контролируется качество кода

Да там уже давно больше откаты контролируют, а не качество кода

 

[Mr_Max]

Переезжаем в офтоп.

 

[pilot911]

Автор оригинала: vovanium
Да там уже давно больше откаты контролируют, а не качество кода

не думаю, все-таки, скорее всего, там код каждой функции проходит через несколько человек

 

[vovanium]

pilot911

там код каждой функции проходит через несколько человек

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

 

[DiMA]

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

-~{}~ 20.07.09 17:24:

по теме:

1. можно провести анализ логов и составить жесткие рерайт-правила на переменные (через GET вызвать бекдор или просто незлонамеренную дырку в последствии - не получится). С POST и прочими REQUEST - чуть сложнее, но идея аналогичная.

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

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

4. Мониторим попытки вызвать сетевые функции (скачка, DNS, и т.д.) - блокируем или логируем.

и т.д. можно навыдумывать много ограничений. И чайниковские бекдоры не прокатят.

 

[vovanium]

DiMA

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

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

 

[DiMA]

работал
подписать формальную филькину грамоту и "провести разговор" - это две больших разницы

 

[vovanium]

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