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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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