Warning: Cannot use a scalar value as an array in /home/admin/public_html/forum/include/fm.class.php on line 757

Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/include/fm.class.php on line 770
Форумы портала PHP.SU :: Версия для печати :: Обнаружение уязвимостей
Форумы портала PHP.SU » » Вопросы новичков » Обнаружение уязвимостей

Страниц (1): [1]
 

1. snikers987 - 02 Декабря, 2011 - 14:44:17 - перейти к сообщению
Собственно возникла задача разобратся в чужем говнокоде( при чем с большой буквы) и закрыть все уязвимости.

Что сделано:
Все данные от пользователя пропускаются через. след. функцию:
PHP:
скопировать код в буфер обмена
  1. function filter($input){
  2.         if(!empty($input)){
  3.                 if(is_numeric($input)){
  4.                         return abs(intval($input));
  5.                 }else{
  6.                         return mysql_real_escape_string(trim($input));
  7.                 }
  8.         }
  9.         return false;
  10. }
  11.  

2. Закрыт доступ на прямое обращение к критическим файлам и папкам.
3. Жесткая проверка загружаемых файлов.
4. Фильтрация вывода (от XSS)
5. eval и подобные скрипт не использует
На что еще следует обратить внимание?
2. EuGen - 02 Декабря, 2011 - 15:09:35 - перейти к сообщению
snikers987 пишет:
Все данные от пользователя пропускаются через. след. функцию:

А если нужно передать отрицательное число?
snikers987 пишет:
Закрыт доступ на прямое обращение к критическим файлам и папкам.

Каким образом реализовано?
snikers987 пишет:
Жесткая проверка загружаемых файлов.

Какая именно проверка?
snikers987 пишет:
eval и подобные скрипт не использует

Если не используется, можно запретить eval, exec, shell_exec и им подобные просто в конфигурации.

Задача только в безопасности кода, но не всего веб-приложения? (во втором случае можно еще подумать о безопасности окружения)
3. snikers987 - 02 Декабря, 2011 - 15:19:37 - перейти к сообщению
EuGen пишет:

1. А если нужно передать отрицательное число?
2. Каким образом реализовано?
3.Какая именно проверка?
4.Если не используется, можно запретить eval, exec, shell_exec и им подобные просто в конфигурации.
4.Задача только в безопасности кода, но не всего веб-приложения? (во втором случае можно еще подумать о безопасности окружения)


1. Отрицательные числа исключены.
2.Контрольная константа + htaccess
3.Допускаются только изображения, проверка расширения по вайтлисту, getimagesize() (изображение ли получено, размеры), размер загружаемого файла.
4. Так и поступил
5.Нужна безопасность приложения в целом
4. EuGen - 02 Декабря, 2011 - 15:28:49 - перейти к сообщению
snikers987 пишет:
Контрольная константа

Это какая такая?
snikers987 пишет:
Допускаются только изображения

Как это проверяется?
snikers987 пишет:
проверка расширения по вайтлисту

Собственно, расширение - не более, чем приписка к имени. Правда, веб-сервер на него ориентируется, так что сойдет.
snikers987 пишет:
Нужна безопасность приложения в целом

Тогда проверьте, что:
* у каждого сервиса есть свой пользователь, из под которого он работает
* нигде без надобности не стоит лишних прав (в особенности - права на исполнение)
* пользователь БД имеет ровно столько прав, сколько ему необходимо в соответствии с бизнес-логикой приложения
* используется chroot для корневого каталога системы
* логируются самими скриптами все необычные действия пользователей.
* логируется работа системных сервисов
* все php-сообщения об ошибках отключены
5. snikers987 - 02 Декабря, 2011 - 16:02:05 - перейти к сообщению
Цитата:
Это какая такая?


Это такая которая определяется в ядре приложения, а во всех подлючаемых файлах(которые не запускаются на прямую)


Цитата:
Как это проверяется?


PHP:
скопировать код в буфер обмена
  1. if(!getimagesize($img)) die("Фаил не является изображением");
6. snikers987 - 02 Декабря, 2011 - 21:30:18 - перейти к сообщению
Цитата:
логируются самими скриптами все необычные действия пользователей.


Можно подробнее?
7. EuGen - 02 Декабря, 2011 - 22:06:58 - перейти к сообщению
Ну, например, у Вас есть группы пользователей. Есть "модераторы" и "администраторы". Первые не могут удалять пользователей, вторые - могут. Естественно у первых нет кнопки "удалить", у вторых - есть.
Предположим, у Вас есть скрипт, обрабатывающий запросы - users.php и запрос на удаление пользователя выглядит как users.php?action=delete&user_id=X - это есть то действие, которое вызывается администраторской кнопкой. Естественно, модератор не может видеть эту кнопку, а потому такой вызов скрипта ему будет недоступен через интерфейс. Однако же он может (подсмотрев/перехватив вызов к примеру, или попросту "догадаться") послать такой запрос - просто в строке браузера.
Ну а так как Вы все предусмотрели и ни в коем случае не доверяете пользовательскому вводу, то Вы проверяете, достаточно ли прав у пользователя, чтобы выполнить указанное action. Так вот во всей этой длинной истории нестандартное (не предусмотренное логикой приложения) поведение пользователя будет - если Вам придет action, верный по сути (в данном случае delete), но на который у пользователя нет прав. Нужно не просто сообщать пользователю об ошибке (или же перенаправить его куда-либо), но и записать этот факт в лог.
8. snikers987 - 03 Декабря, 2011 - 11:30:51 - перейти к сообщению
Спасибо, сделал!

 

Powered by ExBB FM 1.0 RC1