Іноді в новинних стрічках то там, то тут миготять статті про злом сайтів тих чи інших організацій. Мільйони захоплюються сміливцями, які кинули виклик системі. Вони звеличують людей, які ламають портали великих корпорацій, паралізуючи їх роботу. Але це в ідеалі. На практиці ж будь-яка людина, мало-мальськи знайомий з PHP , Perl, SQL може зламати сайт середнього рівня. І справа тут не в винятковому менталітеті. Хоча, зізнатися, часом злам сайту нагадує шахову партію з безліччю варіантів ходів.

Просто з нескінченним безліччю CMS систем, платних, безкоштовних або ж самописних, по мережі поширилося і безліч всіляких дір і вразливостей. Якщо ще десятиліття тому, в еру HTML, доводилося шукати уразливість безпосередньо в HTTP-сервері , То тепер завдяки невдахою програмістам або "слабким" системним адміністраторам процес спростився донезмоги.

Я не буду описувати методику злому абстрактних інтернет-ресурсів , Так як сенсу в цьому не бачу. На прикладі декількох сайтів я розповім, як виглядають типові помилки програмістів і чим вони можуть обернутися.

Самопісний інтернет-магазин

В Україні існує маса інтернет-магазинів , Які торгують комп'ютерами і різного роду побутовою електронікою. В одну з таких організацій влаштувався мій хороший знайомий.

Щоб ознайомитися з тим, чим торгує фірма, я вирішив дізнатися адресу сайту. Отримавши заповітну посилання, гуляючи по сторінках з товарами, я помітив одну помилку, закралася в скрипт відображення мініатюр картинок. Вона сильно збентежила мене. Справа в тому, що помилка досить поширена, і виглядає вона як script.php? File = file, де script.php - файл скрипта в рядку адреси, а file - власне файл для перегляду на сервері.

Заради інтересу в адресному рядку, я набрав наступне script.php? File = index.php (це означає, що я попросив скрипт переглянути файл index.php - заголовну сторінку сайту). У звичайній ситуації такий скрипт повинен перевіряти розширення запитуваного файлу і не давати можливості користувачеві ресурсу створювати подібні запити для php. Але штатний програміст в тій компанії не знав про цю особливість, і залишив цю уразливість доступною.

Далі все проходило швидко. Дізнавшись, що компанія використовує Vbulletin як движка форуму, я скачав подібну версію, щоб дізнатися шляху до файлів конфігурації. Потім написав запит в адресному рядку браузера script.php? file = / forum / includes / config.php і, побачивши повідомлення з помилками, відкрив вихідний код сторінки в Opera , Отримавши файл конфігурації форуму.

Що це означало? У мене були розв'язані руки. Можна було закачати, наприклад, phpshell - файловий менеджер, написаний на PHP, і повністю отримати доступ до всього сервера. Але завдання людини полягає не в руйнуванні, а в творенні. Тому я опублікував в форумі новина від імені адміністрації з проханням зв'язатися зі мною для усунення помилки.

Я написав довгого листа про те, що необхідно виправити. Справа в тому, що на тому CMS-движку базувався не один сайт, а не менше десяти в різних регіонах України. І якби цю помилку виявив якийсь "ошпарений" товариш, то наслідки для іміджу фірми і її клієнтів могли бути незабутнє сумними.

Безкоштовна галерея

Існує дуже хороший сайт, присвячений старими фотографіями міст. Але біда цього ресурсу була в тому, що його адміністратор не зміг налаштувати безкоштовний скрипт галереї 4gallery правильно. А це означало, що бекапи SQL зберігалися в стандартному каталозі backup, доступному до перегляду через банальний лістинг директорій. Що це означало? А це означало те, що маючи дамп бази даних, я міг спокійно увійти під обліковим записом адміністратора.

Фахівці заперечать, мовляв, в цьому випадку паролі зашифровані MD5 . Так, і це правда. Але правда полягає і в тому, що хоча MD5 неможливо на сьогоднішній день зламати, його можна обійти. У мережі існує маса словників, куди вводиться зашифрований хешкод для декодування. єдина гарантія захистити себе від подібного злому - це використовувати складний і довгий буквено-символьний пароль.

На жаль, автор сайту не використовував пароль належної складності, і тому підібрати пароль за словником MD5 виявилося просто. Увійшовши на сайт від імені адміністратора, я написав на титульній сторінці про уразливість і про те, як зі мною зв'язатися, щоб її усунути.

Підбиваючи підсумки

Не хочеться вдаватися в довгі дискусії про те, що робити або хто винен в тій чи іншій ситуації, але зазначу, що чим складніше CMS і чим більше вона використовує додаткових модулів, тим більше шансів, що її зламають. Єдина реальна захист від цього - оперативне оновлення всього програмного забезпечення від сервера до скриптів і копіювання баз даних з усім їхнім вмістом хоча б раз на тиждень. Але це утопія. З великим сумом мушу визнати і той факт, що мій сайт вразливий настільки ж, наскільки і інші ресурси. Але, знаючи це, я нічого з цим не можу вдіяти. Просто тому що я не розробник .

На жаль, формат статті "Комп'ютерних Вістей", не дозволяє мені розглянути найбільш типові помилки, що виникають в ході налаштування http-серверів і CMS. Але, для роздумів підкину читачам ось таку ось посилання: www.exploit-db.com . Задумайтесь, можливо, експлойт на вашу CMS вже опублікований там.

Роман КАРПАЧ,
консультант з проблем ІТ,
www.fdd5-25.net