zhekanax30 ноя 2009 в 17:28

Возможность получить информацию о сайте на symfony

1 мин

1.2K

Информационная безопасность *

+15

Комментарии 31

sha1dy 30 ноя 2009 в 18:13

либо в _dev прописываем фильтрацию по ip

alexg 30 ноя 2009 в 18:20

а точнее не убираем её полностью — она там прописана по умолчанию, но все же правильнее вообще не деплоить на продакшен дев окружение

transpond 30 ноя 2009 в 22:45

плюс переименовать файл _dev во что-нибудь непредсказуемое для надёжности

medvoodoo 1 дек 2009 в 07:47

хе, а что мешает для dev сделать стандартную авторизацию? если у вас в проекте sfguard есть, то работы на 5 минут. Набросать роутинг и авторизацию в конфигах. Более того, можно пошаманить и подрубать error_reporting: <?php echo (E_ALL | E_STRICT)."\n" ?> и web_debug: on только для суперадминов, тогда вобще можно стирать dev.

kmike 30 ноя 2009 в 20:31

> Т.к. проект открытый можно посмотреть состояние кода для любой версии и посмотреть уязвимости в багтрекере.

Насчет посмотреть уязвимости в багтрекере — это вовсе не следствие открытости проекта. В той же джанге уязвимости просят сообщать на ящик security@djangoproject.com, к которому есть доступ только у очень ограниченного круга доверенных разработчиков. А если уязвимость подтверждается, вся разработка останавливается до тех пор, пока уязвимость не будет закрыта в транке, текущем релизе и еще 2х предыдущих релизах.

pgrishin 30 ноя 2009 в 22:40

Пятый в Яндексе — «РОМА — доделай до ума» :)

Svarog 30 ноя 2009 в 23:03

Не вижу. Региональная выдача яндекса видать :)

pgrishin 1 дек 2009 в 00:00

уже 8ая :)
www.poiskua.net/frontend_dev.php/

psylosss 30 ноя 2009 в 22:52

В dev на хосте, отличном от 127.0.0.1, можно запустить только тогда, когда чьи-то шаловливые ручки залезли в *_dev.php и убрали заботливо поставленную защиту

VolCh 30 ноя 2009 в 23:04

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

yuretsz 1 дек 2009 в 00:09

Это не уязвимость Symfony. Защита от выстрела себе в ногу присутствует, но особо одаренные личности ее успешно удаляют.

zhekanax 1 дек 2009 в 09:17

Я не писал что это уязвимость. Просто хотелось обратить внимание что _это_ можно увидеть в результатах поисковиков. И еще раз напомнить разработчикам, наглядно показав на примере.

deniamnet 1 дек 2009 в 00:19

www.pallada.ru/frontend_dev.php
50 запросов на страницу — это мощно =) еще немного и получится bitrix

symfony уважаю, ничего личного

alkhankhel 1 дек 2009 в 02:50

В битрексе половина запросов не дублируется :D

proxor 1 дек 2009 в 04:09

И register_globals on, интересно зачем? :)

egorinsk 1 дек 2009 в 07:05

Ха, я 178 видел — www.ontariogreenspec.ca/frontend_dev.php/, не зря я интуитивно не люблю симфони и ORM!

the_buddha 1 дек 2009 в 08:03

Тут уж просто кривизна рук самого программиста, а symfony- то не причем:)

MaEcTPo 1 дек 2009 в 10:27

Это, мне кажется, проблема ORM (пропел там вроде). Если я делал $object->countArtists() то предполагал что оно будет кешировать результат, а не каждый раз делать SELECT COUNT(*) FROM. Когда я увидел что это не так, пришлось самому дописывать такой функционал, что не доставляло ни разу.

alkhankhel 1 дек 2009 в 03:01

Вообще удивляет, как так, вроде использование подобного фреймворка говорит о каком-то профессионализме, и тут такие ляпы =\

proxor 1 дек 2009 в 04:11

Бросьте, использование фреймворка ни о чём не говорит. К тому же ляпы и баги свойственны любому сколь-нибудь сложному программному продукту. Не может программист не делать ошибок.

alkhankhel 1 дек 2009 в 05:32

Я не про ошибки типа как www.pallada.ru/frontend_dev.php, где половина запросов дубли.

А про убирание защиты, которая есть по умолчанию.

proxor 1 дек 2009 в 05:35

Это, имхо, просто безалаберность.

kpower 1 дек 2009 в 03:17

И помимо сноса или блокирования *_dev.php не забываем снимать в настройках / переопределять default модуль. Также накрываем 500 ошибку (создаем свою ошибку для нее) и, если используется check_lock и предполагается блокирование модулей (что скорее всего), — unavaliable. Про 404 я уж совсем молчу — ее хоть в settings не пропустишь.
По-хорошему, вдобавок убираем backend.php из продакшна (мне нравится вариант с поддоменом). А совсем по-хорошему — лезем сюда и побеждаем остальные мелочи, выдающие symfony (будь то имя дефолтной куки или что ещё).