Значится так. Вот что у тебя происходит:
Первое.
PHP:
89.251.104.186 - - [17/Jan/2011:08:51:43 +0200] "GET /index.php?links_exchange=yes&page=2 HTTP/1.0" 200 24653 "-" "Mozilla/4.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.1.20) Gecko/20081217 Firefox/2.0.0.20"
кулхацкер зашел на страничку добавления ссылок из своих закладок.
Второе.
PHP:
89.251.104.186 - - [17/Jan/2011:08:52:02 +0200] "POST /index.php?links_exchange=yes&page=2 HTTP/1.0" 302 3 "http://site.com.ua/index.php?links_exchange=yes&page=2" "Mozilla/4.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.1.20) Gecko/20081217 Firefox/2.0.0.20"
через форму добавления линков, запихнул свои ссылки посредством SQL-иньекции. При этом интересно ,что сервер выдал код 302 - "302 Moved Temporarily". а затем страница благополучно перезагрузилась, на правильную, что отображает третья строчка:
PHP:
89.251.104.186 - - [17/Jan/2011:08:52:06 +0200] "GET /index.php?links_exchange=yes&page=2&added=ok HTTP/1.0" 200 24767 "http://site.com.ua/index.php?links_exchange=yes&page=2" "Mozilla/4.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.1.20) Gecko/20081217 Firefox/2.0.0.20"
Для того, чтобы добавленная ссылка отображалась, в соответствующей таблице БД, поле "le_lVerified" должно содержать дату, а не NULL.
Т.е. SQL-иньекция добавляет ссылки в БД с датой валидации ссылки.
Как бороться.
1. Сложный вариант - найти дыру (уязвимость) в обработчике переменной $_POST, данной формы.
2. Простой, но как средство спрятать дыру, а не удалить:
- изменить имя переменной
links_exchange на другую, например
exchange77_links88.
- изменения затронут только два файла - links_exchange.php и links_exchange.tpl.html
Простого варианта в принципе должно хватить, т.к. злоумышленник использует скрипт автоматизирующий процесс добавления (это видно по дате валидации линка - она одна и таже) и скорее всего не будет из 200 или 1000 сайтов, на котором "фокус не удался", выяснять причину - почему не удалось! И даже скажу больше. Этот кадр скорее всего не является дыркооткрывателем и мозгом написавшим хак-скрипт. Поэтому простой вариант условно решит проблему.
Заморачиваться на сложный вариант можно только из принципиальных соображений и при наличии бабла на толкового программера, который устранит саму уязвимость кода.