Найбільш безпечний движок для сайта

20:43 03.01.2007

На секлабі пройшло цікаве опитування: “Який движок для веб сайта найбільш безпечний?”. В якому я також прийняв участь. На мою думку, найбільш безпечний, є той движок, при розробці якого приділялася достатьня (бажено посилена) увага питанням безпеки. А враховуючи те, що на інших розробників не варто розраховувати, можна лише на себе розраховувати - тому найбільш безпечним є саме власний движок.

А те, що я регулярно знахожу уразливості в різних движках (як комерційних, так і відкритих, причому в комерційних більше), а також про уразливості в движках пишуть на секюріті сайтах - лише відтверджує дану тезу. Сам я в більшості випадків використовую лише власні движки (виключенням є лише даний мій проект).

Результати опитування наступні:

  • Власноруч написаний движок - 44,84%
  • CMS під вільними ліцензіями (Drupal, XOOPS, PHP-Nuke та інші) - 18,89%
  • Не знаю - 17,63%
  • CMS під пропрієтарними ліцензіями з відкритим віхідним кодом (наприклад, Бітрікс) - 10,08%
  • CMS під пропрієтарними ліцензіями с закритим віхідним кодом (більшість платних CMS) - 7,81%

Більшість опитаних (майже половина) мають подібну думку. Що власний движок є найбільш безпечною основою сайта.

  • Какой движок для Web сайта наиболее безопасен? (деталі)

10 відповідей на “Найбільш безпечний движок для сайта”

  1. guman каже:

    Так, власноруч написаний це добре, але не у всіх руки виросли звідки треба. І якби опитування провели у Host-ерів, що дорожать своєю репутацією, то для движків Drupal, XOOPS, PHP-Nuke тощо результати були б невтішні, вони їх просто ненавидять :x
    Мабудь самий непробивний сайт, написаний у блокноті на чистому HTML-і без форумів, дошок і чатів 8O
    Тому платні движки (на рівні 50-150 уо) по-моєму залишаються альтернативою різного роду халявних CMS

  2. MustLive каже:

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

    І власний движок движку рознь - кривих і дирявих движків вистачає (що я знаю зі власного досвіду пошуку уразливостей). В не залежності від того, власний чи сторонній (платний чи безплатний) движок, головне щоб безпека сайта була перевірена - тобто проведений секюріті аудит (з цього приводу можна і до мене звернутися). Інакше безпека сайта буде під питанням.

    Мабудь самий непробивний сайт, написаний у блокноті на чистому HTML-і

    З цього приводу я писал в записі Хакінг сайту через уразливості в коді зовнішніх систем, що навіть сайт на голому html може мати уразливості, які можуть бути використані проти адміна і відвідувачів сайту.

    Ну а стосовно платних движків, то зверни увагу на те, що я сам в основному знахожу уразливості саме в платних CMS (а також різних саморобних движках, які зроблені на заказ в студіях). Тобто проблем вистачає в будь-яких движках, і передусім тих, де не приділяли достатньо уваги безпеці.

  3. guman каже:

    ну не знаю, якщо є дірка у платному движку, то, або адмінам пофігу що там буде з їх сайтом, або закінчилась ліцензія, і їх студія-розробник не підтримує. Постійна економія або лінощі приводить до того, що сайт перетворюється у дуршлаг. Тому є тільки два варіанта: або вчити самому програмування, щоб аж вночі снилося “include”, “else” і т.д. або вкладати постійно гроші у апдейти і нагинати по повній програмі розробника движку.
    А в загалі-то, самий кращий движок той, про який не кричать на кожному кроці, а який собі тихесенько живе і своєчасно підтримується командою розробників не “за спасибі”, а за бабло, щоб було натхнення рухатись уперед. А халявний движок рано чи пізно, або відімре або перетвориться у комерційний проект.

  4. MustLive каже:

    guman, на жаль в комерційних движках дірки трапляються (як і в будь-яких), і доволі часто. Хоча здавалося би в них повино бути більше ресурсів для проведення нормальних аудитів безпеки.

    В своїй практиці соціального секюріті-аудита, я не дивлюся на те, на якому движку сайт - я про знахожу діри. І вже потім може вияснитися, що сайт на такому-то движку, і доволі часто на комерційному. В такому випадку, я також повідомляю виробника уразливого движка чи веб додатка (які потім іноді до мене звертаються за аудитом). Причому нерідко знахожу ці самі діри на сайті самого виробника :-) , бо нерідко той же софт використовується на його сайті.

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

    Тому в будь-якому випадку, не в залежносності від движка, варто слідкувати за безпекою свого сайта. Робити це можна або самотужки, або до фахівців звертатися. Але в будь-якому випадку безпека чогось варта, на ній не потрібно економити (одного “спасибі” не вистачить). На чому нерідко економять розробники як відкритих, так і закритих веб програм. Тому при виборі софта чи системи для сайту, потрібно серьёзно подумати і вибрати тих хто більше займався безпекою свого продукту (або займатися цим самому, за свої кошти).

    Халявний движок не довговічний, тут ти правий, без доброї і постійної мотивації довго не протягнеш. Тому або з часом проекти відходять, або частково чи повністю комерціалізуються (можна зробити окрім основної і free версію, як варінт).

  5. Volodimir каже:

    MustLive
    А можна Вас, або когось iншого попрохати перевiрити мiй движок на вразливостi.

  6. MustLive каже:

    Volodimir

    Вам не потрібно нікого прохати, ви можете замовити аудит безпеки. В мене чи будь-кого іншого, хто пропонує дані послуги. Безпека коштує грошей і вона того варта. І про це завжди слід пам’ятати всім адмінам сайтів та веб розробникам ;-) .

    Можна розраховувати на мій соціальний секюріті аудит. Що я колись знайду час і зайду на сайт на вашій CMS і найду одну або декілька дірок (стільки я знахожу під час соціального аудиту). Але для повноцінної перевірки движка потрібно проводити його повну перевірку, а не біглий перегляд (і знаходити всі дірки, а не тіільки декілька). Також можете на хакерських форумах попросити “подивитися на безпеку вашої CMS”, але ефект від цього буде невеликий (від халявної перевірки й результат буде відповідний).

    Тому вам варто або замовляти повний секюріті аудит, або проводити його самотужки (при наявності відповідних знань). Дірки у вас на сайті є, як й швиденько його оглянув. Зокрема, якщо робити аудит самому, то вам можуть стати в нагоді секюріті сканери (якщо без них важко провести перевірку). Сам я сканерами не користуюся і не поважаю їх (на протязі багатьох років), але веб девелоперам, що хочуть зекономити на аудиті, вони можуть прислужитися.

    Зазначу, що безкоштовні секюріті сканери за звичай майже зовсім неефективні, тому треба використовувати комерційні сканери, що коштують грошей (і в результаті їх купівля вийде дорожчою і менш ефективною, ніж замовлення аудиту). Але можете скористатися trial версіями сканерів, щоб швиденько провести перевірку, поки вони будуть працювати (для надійності можете одразу декілька сканерів використати).

  7. Volodimir каже:

    Дякую за поради, якщо я буду колись робити комерцiйну CMS, звернусь саме до Вас. А доки самотужки). Зроблю бекапи - та до хакерiв. Хоча вже одну атаку движок вiдбив.

  8. MustLive каже:

    Володимир, завжди будь ласка.

    Раз самотужки перевіряєте безпеку CMS, то чи секюріті сканери, чи “хакери у яких забагато вільного часу” вам можуть допомогти. Головне, щоб користь від їхніх дій була ;-) . Можете на форумі hackua.com відкрити відповідну тему (подібні прохання там вже раніше піднімалися).

    Хоча вже одну атаку движок вiдбив.

    Це добре. Тільки зазначу, що писати в “Історії” про те, що покращена безпека системи, але не вказуючи які саме уразливості виправлені - це не кращий варіант. Не соромтесь вказувати повний перелік дірок які були виправлені - без деталей, лише кількість виправлених дірок різних класів (такі-то класи дірок, така-то кількість).

    Це дозволить вам краще вивчити класифікацію уразливостей в веб додатках. Та покаже, що ви слідкуєте за безпекою своєї CMS (не просто “покращили безпеку”, а виправили відповідну кількість відповідних дірок).

  9. Volodimir каже:

    Iсторiю виправлю, взагалi не соромлюсь, але було таке, що й соромився, наприклад спочатку не було перевiрки типу get переменних. Був тiлькi фiльтр $id += 0. Хоча це i не могло, на мiй погляд, сприяти взлому.

  10. MustLive каже:

    Соромитися не потрібно.

    Робіть в історії опис усіх виправлень уразливостей - наприклад, як я це роблю. Причому детальний - не просто покращена безпека, а перелік класів уразливостей (і бажано їх кількість, як я вже казав). Це продемонструє ваш публічний підхід до питань безпеки власних програмних продуктів.

    спочатку не було перевiрки типу get переменних.

    Перевіряти тип не обов’язково, це лише в деяких випадках може допомогти. Але існують різні методи валідації вхідних даних, в тому числі й перевірки на тип даних (а можна й використовувати приведення до необхідного типу як захисний метод).

Leave a Reply

You must be logged in to post a comment.