WEB рукоделие

Множественные уязвимости Shop-Script

Сергей — Mon, 14 Jun 2010 10:27:37 +0000

По привычке, время от времени, просматриваю сообщения об уязвимости скрипта Shop-Script. Компания Артикус, автор этого скрипта, уже давно перестала его поддерживать и продает теперь новую версию, более навороченную и красивую. Тем не менее этот скрипт разошелся по сети в миллионах копий, как легальных, так и нелегальных. А также породил великое множество продолжений и улучшений. Поэтому обнаруженный мною отчет, несмотря на то, что ему уже 2 месяца, будет интересен многим.

В отчете рассматривался Shop-Script Free — это как раз бесплатная версия того, что ходит по интернету огромным тиражом. На Free версии основана наиболее цельная и популярная доработка под названием «Shop-Script Free Lego Edition».

Вывод неутешительный. На 14 апреля в скрипте имелось 27 уязвимостей, позволяющих атакующему получить доступ к базе данных, манипулировать данными и скомпрометировать систему.

В частности ошибки, позволяющие выполнять команды SQL, в обработке параметров, передаваемых в скрипт: (1) add2cart, (2) c_id, (3) categoryID, (4) list_price, (5) name, (6) new_offer, (7) price, (8) product_code, (9) productID, (10) rating, and (11) save_product. Пруфлинк.

Тот же контент, только в профиль

Сергей — Sun, 04 Apr 2010 11:18:55 +0000

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

http://www.example.com/products/prices

http://www.example.com/products/prices/index/order:price

http://www.example.com/products/prices/index/order:title

Мне кажется, что поисковому роботу такое может и не понравится, уж больно это смахивает на попытку заспамить поисковик. Я раздумывал о том, что,наверное, такие страницы, в URL которых указаны подобные параметры неплохо бы, наверное, закрывать от индексирования. Обычными директивами meta в заголовке страницы.

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

Совсем небольшая заковыка в разрезе CakePHP состояла в том, что для кейка без разницы URL http://www.example.com/products/prices и http://www.example.com/products/prices/index — надо было бы как-то эту ситуацию обрабатывать.

Совсем недавно наткнулся на решение этой проблемы «похожих страниц» в гугловской документации к платформе Blogger. Не совсем понятно, почему они именно там это разместили, поскольку это было бы полезно всем владельцам сайтов, а не только авторам блогов на платформе Blogger.

Оказывается Google отлично понимает атрибут rel="canonical". Т.е. в заголовке (в разделе ) страниц размещаем элемент:

и больше не паримся. В атрибуте href этого элемента указан адрес «основной» («канонической» в терминах Google) страницы. Поисковик обещает учитывать такие ссылки и стараться выдавать клиентам адрес именно этой страницы.

Ссылка может быть как относительной, так и абсолютной. Но Google рекомендует ставить абсолютную. Можно, кстати, попробовать указать страницу на другом домене — это тоже не возбраняется.

Список всех-всех контроллеров

Сергей — Mon, 30 Nov 2009 10:58:38 +0000

Понадобилось мне получить список всех контроллеров приложения, включая контроллеры плагинов. Configure::listObjects, увы, такого не умеет. Этот метод выдает только все контроллеры приложения, но без контроллеров плагинов. Пришлось немного адаптировать метод, предложенный Rob Weaver в гуглогруппе CakePHP. На выходе у моего метода получается объединенный список контроллеров. Основные — как отдает метод listObjects, а принадлежащие плагинам в виде «Plugin.Controller». Можно их поочередно скармливать сразу в App::import. Разве что выбрость те, названия которых на «App» заканчивается, если они не нужны. Будете загружать, помните, что класс «Controller» уже должен быть загружен.

Update. Метод Folder::findRecursive возвращал слишком много файлов, в том числе и ненужных. Переписал немного, теперь опрашиваем только директорию с плагином и его контроллерами.

/**
 * Lists the names of controllers including plugin controllers
 * 
 * @return array
 */
static function listControllers()
{
    App::import('Core', array('File', 'Folder'));
 
    $controllers = Configure::listObjects('controller');
 
    $config = Configure::getInstance();
 
    foreach ($config->pluginPaths as $pluginPath)
    {
        $folder = new Folder($pluginPath);
        list($plugin_dirs) = $folder->read();
        foreach($plugin_dirs as $plugin_dir)
        {
            $pluginName = Inflector::camelize($plugin_dir);
            $folder->cd($pluginPath . $plugin_dir);
            $controllerFiles = $folder->find('.*_controller\.php');
            $folder->cd(Folder::addPathElement($folder->path, 'controllers'));
            $controllerFiles = array_merge($controllerFiles,$folder->find('.*_controller\.php'));
            foreach ($controllerFiles as $file)
            {
                $file = basename($file);
                $controllers[] = $pluginName . '.' .
                    Inflector::camelize(substr($file, 0, strlen($file)-
                    strlen('_controller.php')));
            }
        }
    }
    return $controllers;
}

Попробуем почитать между строк

Сергей — Wed, 25 Nov 2009 17:22:03 +0000

Очередное интервью с представителями Яндекса, на этот раз на Roem.Ru. Никаких особенных откровений, конечно, нет. Что же вы хотели, чтоб яндексоиды всем бесплатно раздали рекомендации, как выбраться на первое место в выдаче по любому запросу? Но все-таки что-то надо говорить и из обтекаемых формулировок можно выстраивать разные забавные предположения. Лично я не завсегдатай SEO-форумов, возможно, все это уже где-то обсуждалось — если баян, извините.

Сегалович:

Ровно в этих рамках (борьба с «глупостью») мы относительно недавно реализовали алгоритм определения запросов и ответов, которые можно трактовать двояко: и как поиск эротического и порнографического содержания, и как невинный информационный запрос. Например, запрос [девочки] может быть поиском повести Людмилы Улицкой, а вовсе не «девочек по вызову». Для человека, ищущего Улицкую, ответ с порнографией не просто нерелевантен, он «явная глупость».

Опираясь на классификаторы запросов и сайтов по порнографическому и непорнографическому содержанию, и построив соответствующие метрики, отражающие долю резко нерелевантного поведения нашей системы по «двояким» запросам, мы смогли реализовать механизм понижения в выдаче сайтов порнографического содержания.

Было бы логично, если бы Яндекс подсовывал разным посетителям разные варианты выдачи, основываясь на данных предыдущих запросов, статистики из Метрики и т.д. Не специально для каждого пользователя, а для каких-то условных групп, типа «любитель клубнички», «книжный червь» или каких-то таких. А что? Статистика по запросам есть, статистика посещенных сайтов и проведенного на них времени — то же (Метрика, различные кнопки ТИЦ, блогов и т.д.) — нарисовать схему интересов пользователя можно. И потом соотнести с какой-то своей внутренней классификацией. А вот слова о том, что ответ не подвергается модификации — это, возможно, и временно. На паре «порно/непорно» алгоритм просто обкатывается.

Если Яндекс все-таки реализует модификацию выдачи в зависимости от вычесленных предпочтений пользователя — вот будет головная боль оптимизаторам! Почистил куки, походил по сайтам с пластиковыми окнами – получи выдачи про строительство и остекление балконов, почистил куки, походил по сайтам с программным обеспечением — получи выдачу про Windows. И все в ответ на один и тот же запрос «окошки».

Сегалович:

по ряду запросов мы мониторим выдачу других поисковых машин, всех, кто хоть как-то ищет по-русски, включая все версии самого Яндекса – рабочую версию и внутренние, экспериментальные (у Яндекса много версий). И складываем все результаты в один котел. Если какой-то сайт присутствует в этом «котле», если он там имеет достаточно хорошие оценки, и при этом отсутствует в Яндексе, мы начинаем разбираться – почему

Садовский:

Чтобы было понятно, «котел» какого объема оценивается, подчеркну, что это речь идет о десятках тысяч запросов, которые мы проверяем таким образом. Мы проверяем первые 30 позиций по каждому запросу. Считайте: десятки тысяч запросов, умножить на 30 первых позиций, умножить на количество версий, – это десятки миллионов URL.

Мониторят конкурентов. Очевидно, Google, Bing и Рамблер. Наверное и Yahoo. Об остальных можно только догадываться. Составляют множество сайтов, попадающих в выдачу всех или бОльшей части конкурентов. Потом сравнивают со своими результатами. Конкретная позиция, наверное, не очень важна — главное присутствие в первых 30-ти результатах. Смотрят, какие сайты попали к ним — если различие сильное, это повод задуматься. Т.е. если после получения результатов от конкурентов оказывается, например, что 22 сайта присутствуют у всех, а у Яндекса только 5 из этих сайтов — это повод побеспокоиться.

Сразу возникает интересная идея — путь к первой странице выдачи Яндекса может лежать и через результаты выдачи его конкурентов.

Сегалович:

Так вот, практически все обращения в службу техподдержки – я думаю, в цифрах это будет более 90% – касаются именно таких сайтов из «серой зоны». Пишут грамотные аргументированные письма: «А вот смотрите, почему вы этот сайт выбросили, он качественный, контент уникальный, ссылки по теме. Объясните почему.» Цель таких писем – методом перебора уточнить безопасные границы в этой «серой зоне». Предприняли какое-то действие – смотрят результат. Если результат отрицательный, сайт попал под санкции, они пытаются получить от нас обратную связь, проанализировать причины.

Певцов:

…как показывает практика, большинство сайтов, по поводу отсутствия которых в выдаче к нам обращаюся вебмастера, создавались специально с целью обмана поисковой системы и манипуляции результатами поиска…

Садовский:

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

Ну все уже догадались? Жаловаться на то, что сайт выпал из индекса, хотя соответствует «техническим параметрам» – ссылки, качество контента и т.д. – не надо. Ищите другую аргументацию. Вам же не робот отвечает, человек. И он понимает, что вебмастер беспокоящийся о технической стороне вопроса — не их союзник. И еще. Удалось убедить, что «сателлит» белый и пушистый? Будьте готовы к тому, что из под санкций могут выползти и «сателлиты» конкурентов. Любите жаловаться на «сателлиты» конкурентов, присутствующие в выдаче? Будьте готовы к тому, что вместе с ними пойдут ко дну и ваши такие-же.

Певцов:

уникальность контента совсем не определяющая вещь. О ней много говорят, но более важная характеристика – не уникальность, а полезность контента [и далее по тексту]

«У вас на сайте неуникальный текст! Ужас-ужас-ужас!» – страшилка. То есть, если скопировать все подряд, санкции будут. Но умеренное разбавление своих статей статьями, взятыми из других источников, может не повлечь никаких санкций. Таким образом, если где-то в интернетах нашлась удачная статья, подходящая сайту и автор не против ее распространения, можно спокойно скопировать ее к себе или процитировать. Ссылка на оригинал, как мне кажется, в данном случае будет лишним подтверждением «добрых намерений».

Четвертая часть о воровстве контента. Авторам стОит отдавать свои статьи в RSS. Не жмотитесь, отдавайте всю статью. Роботы, сканирующие блогосферу быстрее и чаще забирают контент. Если статья у кого-то скопирована, не надо расстраиваться, страница с этим текстом не первая в выдаче. Еще не факт, что посетителя заинтересует первый сайт. 2-5 место тоже хороши. И до конца первой страницы – нормально. Кроме того, скопированная страница может придать общий тематический вес сайту, подняв его по другим, похожим, низкочастотным запросам.

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

Ну вот как-то вот так. Спасибо, что дочитали до конца. :)

Контроллеры: загрузка

Сергей — Mon, 23 Nov 2009 17:50:02 +0000

Удивительно но факт. Если из консольного, например, приложения нужно попользоваться моделью, то, само собой, надо загрузить класс модели.

App::import('Model', 'MyModel');

Но загрузить контроллер так не получится. Получим сообщение об ошибке из-за невозможности найти базовый класс Controller. Вот найти класс Model кейк может, а Controller – нет. Во всяком случае 1.2.5. В версии 1.3 не пробовал.

Поэтому приходится загружать его явно и напрямую:

App::import('Core', 'Controller');
App::import('Controller', 'MyController');

Компоненты: перезагрузка

Сергей — Tue, 13 Oct 2009 22:02:40 +0000

Не знаю, такую-ли ситуацию имел в виду BorisPlus в своем комментарии. Ну, чем богаты. Вообще не хотел это все описывать, потому как код довольно халтурно написан.

Этот код приложения, изначально крутившийся по Cake 1.1, был переписан для какой-то беты Cake 1.2. С текущей версией, 1.2.5, он работает без проблем, но, возможно, нуждается в чистке.

Эта часть программы выполняющий импорт данных от поставщиков. Поставщики предоставляют данные в CSV формате, но порядок колонок, некоторые значения и т.д., конечно разные. Для осмысленной обработки эти полученные данные надо привести к единообразному виду.

Данные поступают из написанного куцего Datasource, скармливанются компоненту, который и выполняет разбор и приведение к общему виду, потом записываются в нашу таблицу.

Компонент подгружается динамически, в зависимости от поставщика. Все компоненты являются наследниками базового и реализуют метод parse. Этот метод базового компонента, если не перегружен, возвращает NULL — в этом случае в нашу таблицу ничего не записываем, переходим к следующей порции данных. Соответственно методы наследников тоже могут возвращать NULL при ошибке разбора, например, при отсутствии какого-либо ключевого поля.

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

Увы, все файлы с компонентами находятся в каталоге components. Зато после перегрузки можно к загруженному компоненту обращаться по имени базового:

$this->SupplierCsv->parse($data);

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

if (!App::import('Component', 'SupplierCsv'))
    die('Cannot load SupplierCsv component');

Еще у базового компонента есть метод factory. Я не помню, почему я его статическим объявил, честно. :-) Он получает в качестве параметра ссылку на контроллер и название компонента для обработки данных от конкретного поставщика:

SupplierCsvComponent::factory($this, array('CsvComponentName'=>$component_name));

Теперь методы базового компонента, SupplierCsvComponent:

function startup(&$controller)
{
    $this->controller = $controller;
    $controller->SupplierCsv = $this;
}
 
static function factory(&$controller, $supplier)
{
    App::import('Component', $supplier['CsvComponentName']);
    $componentclass = $supplier['CsvComponentName'] . 'Component';
    $controller->SupplierCsv = new $componentclass;
    $controller->SupplierCsv->startup($controller);
}

ну и код метода startup дочерних классов:

function startup(&$controller)
{
    parent::startup($controller);
    $this->init = $this->name;
}

Решение неидельное, наверняка можно соптимизировать. Мне, честно говоря, заниматься этим не хочется. Просто потому, что я в итоге начну вообще все с нуля переделывать и менять логику. :)

Откровенно говоря, огород можно было бы и не городить. Можно через App::import() загрузить класс компонента, а потом какой-нибудь переменной контроллера присвоить экземпляр этого класса.

Наверное, я раньше грузил компонент, указывая его в массиве $components, потому и сделал такую навернутую схему.

А может мне не хотелось require_once использовать… Ну не помню. :)

Update: Если соберусь переписывать, надо будет рефлексию попробовать использовать. :)

Кэш и консоль

Сергей — Mon, 21 Sep 2009 16:41:48 +0000

За полноценный пост не считается. Так, узелок на память.

В качестве кэша байткода и переменных я использую XCache. Но при запуске консольных приложений, он у меня не работает. Должен или нет, не знаю, не разбирался. Наверное, не должен, если подумать. :-) Просто отметил, что консольные приложения Cake, включая ‘cake bake‘ высыпают кучу ошибок, если XCache используется, как кэш по умолчанию. Поэтому в конфигурации кэша приложения (APP/config/core.php) на CakePHP добавляю маленькую проверку на тип API.

Вот как-то так:

if (PHP_SAPI == 'cli') {
  Cache::config('default', array('engine' => 'File'));
} else {
  Cache::config('default',
    array(
      'engine' => 'Xcache',
          'prefix' => 'mypfx_',
          'user'=>'IamAdmin',
          'password'=>'c00leztPass'));
}

Можно пользоваться константой PHP_SAPI или функцией php_sapi_name(), не важно.

CakePHP 1.2, Content-type, debug, RequestHandler и все-все-все

Сергей — Sat, 12 Sep 2009 12:46:16 +0000

Как правильно, с точки зрения CakePHP, отвечать на запросы, если ответ требуется не html, а, например, json? Я считаю, что для получения ответа в нужном формате надо воспользоваться компонентом RequestHandler и указать в запросе расширение, в нашем случае ‘.json’. URL для запроса получится какой-то такой:

http://www.oursite.com/controller/action.json

Чтобы Cake не пугался этого расширения и вызывал правильное действие (action), в файл APP/config/routes.php добавим строку:

Router::parseExtensions('json');

Теперь надо разобраться с разными представлениями наших данных, чтобы по запросам к /action и /action.json возвращались разные виды. Для этого нужен компонент RequestHandler. Подключим его либо в самом контроллере, либо в родительском AppController:

var $components = array('RequestHandler');

Теперь шаблоны для view и layout Cake будет искать в поддиректориях /json. Т.е для layout надо будет создать файл /views/layout/json/default.ctp:

 echo $content_for_layout; ?>

и файл для действия /views/controller/json/action.ctp. Какой-то такой:

 echo $javascript->object($data); ?>

Это все и без меня все знают, ничего нового тут нет. Разве что cakebaker советует воспользоваться Zend::Json вместо стандартного помощника Javascript, дескать Zend’овская библиотека автоматом кодирует некоторые спецсимволы.

Но есть одна тонкость, недостаточно отраженная в документации — заголовок ответа Content-type. По всем ожиданиям он должен быть ‘application/json’, как это определено в коде компонента RequestHandler.

Однако, если включен режим отладки, т.е. Configure.debug > 0, то RequestHandler устанавливает Сontent-Type в text/html без вариантов. Это, в общем-то описано в документации и докопаться до этого можно.

Но совершенно неочевидно, что если режим отладки выключить в коде самого action, написав

Configure::write('debug', 0);

то это ничего уже не изменит! RequestHandler устанавливает заголовок во время загрузки компонента. Его метод startup() вызывает метод renderAs(), который вызывает метод respondAs(). Таким образом шаблоны подключаются нужные, те, которые из директорий /json, а Content-Type неправильный.

Лично я, пока, в acton, который должен отдавать данные в json, явно вызывываю RequestHandler->respondAs() повторно:

if (Configure::read()) {
    Configure::write('debug', 0);
    $this->RequestHandler->__responseTypeSet = null;
    $this->RequestHandler->renderAs('json');
}

Это заставляет RequestHandler изменить заголовок Content-type еще раз. Можно похожий код, с проверкой типа запроса и установкой режима отладки и заголовков попробовать запихнуть, скажем, в beforeRender. Обратите внимание на грязный хак с установкой свойства __responseTypeSet в NULL. Метод respondAs сохраняет в эту переменную тип ответа и повторно не будет срабатывать, если он уже был вызван.

Метрическая аналитика

Сергей — Fri, 01 May 2009 21:01:29 +0000

У Яндекса есть полезная система статистики, похожая частью на Google Analytics, частью — на счетчик Liveinternet. Называется Яндекс.Метрика.

Яндекс.Метрика

Все как обычно — устанавливаете код на страницы своего сайта и наблюдаете статистику по посетителям. В отличие от GA, которая обновляется раз в сутки, Метрика показывает результаты практически в реальном времени, как Liveinternet — это гораздо удобнее.

Если сайт рекламируется с помощью Яндекс.Директ и на рекламируемом сайте установлен код для сбора статистики для Директа — это и есть код Метрики! В этом случае можно уже не напрягаться, а смотреть отчеты.

UPDATE нельзя INSERT

Сергей — Sat, 11 Apr 2009 22:13:55 +0000

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

Эта тема пару месяцев назад обсуждалась в ЖЖ сообществе ru_php, но как-то вяло. Попробую этим небольшим постом обобщить разные методики.

Самый простой метод: сначала SELECT COUNT(*), а потом, по результатам, либо INSERT, либо UPDATE. Если речь идет об обновлении одной записи на этом методе можно остановиться.

Увы, если надо вставить много записей, этот метод начинает изрядно тормозить. Для такого случая у MySQL есть несколько разных методов.

REPLACE — наиболее очевидный и самый неудобный. Сервер пытается вставить новую строку, если возникает ошибка с повторяющимся уникальным ключом, запись удаляется и потом снова добавляется новая. Увы, при этом значения тех полей, которые обновлять не надо сбрасываются в дефолтные. Использовать эту команду можно, если обновляется полностью вся запись, что случается редко. Например, если в таблице есть колонка `created`, содержащая дату создания записи, то REPLACE уже не подходит. Кроме того, в случае, если большинство записей заменяется, а не добавляется, получается конструкция INSERT-(ошибка)-DELETE-INSERT — три запроса!

INSERT … ON DUPLICATE KEY UPDATE … — этот вариант сильно интереснее. Сервер пытается вставить запись, если получает ошибку c дублирующимся ключом, обновляет поля, указанные в после UPDATE. Работает отлично, в документации сказано, что эта конструкция специально задумана для вставки множества записей. Но пара неприятных моментов есть.

Первый, как мне казалось, довольно экзотичный, но я с ним все-таки столкнулся. В конструкции INSERT можно в качестве источника данных использовать подзапрос SELECT. Но, в случае с INSERT … ON DUPLICATE KEY UPDATE, в подзапросе не должно быть группировки GROUP BY.
Второй момент для многих неважен. Если записей для обновления сильно больше чем новых, то получается все равно много лишних обращений к БД — ведь вся конструкция это сочетание INSERT-(ошибка)-UPDATE. Лучше, чем с REPLACE, но все же…

Долгое время я пользовался UPDATE, а потом проверял mysql_affected_rows() (в CakePHP это $DataSource->lastAffected(). То есть проверял количество обновленных записей и, если получал 0, добавлял запись. У этого метода есть очень существенный недостаток: если среди данных для обновления встречаются две одинаковых строки, то при повторном UPDATE сервер, как самый умный, не обновляет запись. Соответственно число обновленных записей, affected rows, при построчном переборе, будет равно 0 несмотря на то, что такая строка в таблице есть. Соответственно решение о вставки новой строки будет ошибочным.

Устав мириться с ожидаемым, но неприятным поведением mysql_affected_rows() я порылся в документации на MySQL и нашел еще одну функцию: mysql_info(). Она выдает обычную строчку со статистикой последнего запроса к БД, причем для разных типов запросов строчки разные. Для UPDATE выглядит так:

Rows matched: 40 Changed: 40 Warnings: 0

Зато содержит чрезвычайно ценную информацию: количество записей, которые попадают под условие для обновления. Это те цифры, что после слова ‘matched:‘. Ну, регулярное выражение для получения циферок из строки сами напишите? ;-)

P.S. У меня ощущение deja vu — мне кажется, что я уже писал похожий пост. Перерыл дневники — нет такого. Или это черновик был…