а я бы поискал. жаль вы все стерли. если есть бекапы и логи вебсервера за несколько предыдущих недель, можно попробовать.
все-таки, если про нее даже не знают на офсайте, это весьма важно.
"вы не в теме". существуют сценарии, при которых вам поставят вредносный код даже учитывая ограничение доступа к админке и отсутствие дыр в openx 2.8.7.
по остальным пунктам все ясно
Skom, ну а как ты собираешься предупреждать пользователей о дырке, если ты точно не знаешь есть ли она или нет?
Вот на античате точно указали где sql injection. Хотя она и не опасна, но она там точно есть. Этим я верю.
Skom, предлагаю подождать пока на серче не взломают в очередной раз openx. Это будет заметно.
Skom, а вы в теме? вместо того, чтобы разобраться и дать программистам информацию для исправления дыры, взяли все и удалили. Там же были логи и внутри openx и на вебсервере.
Пока не известно каким образом у вас оказался вредносный код в базе. Может быть он с предыдущих версий висел и его только сейчас активировали. По крайней мере та дыра, которая описана на античате не имеет практической ценности для взломищка. Возможно, есть и другие дыры.
В любом случае админку лучше запаролить.
Я сейчас посмотрел на эту "дыру" : действительно, есть sql injection в админской части скрипта, но туда можно попасть только залогинившись в сам openx админом.
Логин партнера или менеджера по рекламе не даст выполнять такие задачи.
собственно код который не дает это делать выглядит так
// Security
check
OA_Permission::enforceAccount(OA_ACCOUNT_ADMIN);
так что, как обычно, пук в лужу. Подавляющее число самописа содержит такие "дыры" в админской части, но никто их не ломает.
Skom, а где ж еще находится скрипт http://test.com/www/admin/updates-history.php ?
в админской части
ну если верить товарищу
то там дыра в админской части скрипта.
Skom, кто не закрыл админку паролем - тот лох.
это любого продукта касается. большинство программистов когда пишут админскую часть обычно рассуждают так " а че, этот код все равно только админ может запустить".
Rustamus, а зачем кормить прихлебателей? движок и так продается. цену даже повысили после выхода 4.0 и не прогорели вроде.
Продукт рекламирует себя своим существованием. Вместо рекламы у них вон копирайт висит на тысячах удобнейших форумов. в том числе и на searchengines.
а это еще надо доказать. например, с помощью slow_log.
если там обычные вычисления в зависимости от полей той же записи, с чего бы ему считывать все остальные данные? возможно, эти вычисления сделаны с ошибками и действительно подгребает все остальные записи ради элементарной операции.
netwind добавил 20.10.2011 в 18:05
да и хватит уже пропагандировать этот унылый engine=memory. там можно нарваться на совершенно другие проблемы.
innodb с большим буфером и innodb_flush_log_at_trx_commit=0 почти так же хорошо работает.
есть еще секретные недокументированные опции innodb, так там вообще ничего не пишется на диск до переполнения буфера
