Информационната сигурност при споделения хостинг е от основно значение за вашия бизнес. Неправомерен достъп до хостинг акаунт, би могъл да доведе до изтеглянето на огромни бази данни с конфиденциална информация, дефейс на вашия сайт, снифинг на трафика, разваляне на вашата репутация и какво ли още не. За това всеки един собственик на уеб хостинг акаунт би трябвало да се замисли, до колко информацията, която той съхранява е защитена.
Сигурността на самите уеб приложения е от основно значение за сигурността и на вашия хостинг акаунт. Уязвимите уеб приложения позволяват неправомерното проникване във хостинг акаунта, който управлява приложението. Фактически, хакерите могат да получат достъп до базата данни, файловата система, а в някои случаи дори до контролния панел на акаунта. Сами ще се убедите, че за защитата на хостинг акаунта е достатъчно вашето приложение да бъде защитено и да спазвате елементарни правила за безопасност в интернет пространството.
Ще се опитаме да обобщим кои са най-често срещаните грешки, свързани със сигурността на уеб хостинг решенията и какви са вариантите за избягването им.

1. 
   Използване на лесни за налучкване пароли или използване на една и съща парола за login на различни места.

   Доста често лесните пароли са основната причина за това, акаунтите да бъдат разбивани. Хакерите могат да използват специални речници или така наречените brute force (брутална сила) атаки за успешното пробиване на вашата парола. Какво е най-лесното и правилно решение? Да използвате по-силни пароли разбира се… Основно място, на което трябва да акцентирате са вашите имейли, защото обикновенно след това хакерите могат да полуат достъп до почти всички ваши услуги.
   Най-добре е да използвате различни пароли за различните си профили. На някои потребители това може да се стори достатъчно сложно и неудобно, но може да спести много главоболия впоследствие. За съхраняването на паролите си използвайте Password Manager – вече има доста подобни услуги, включително и онлайн базирани.
   Повече информация за силните пароли можете да прочетете на сайта на Zapprotect.

2. 
   Прихванати пароли, посредством неоторизиран достъп до e-mail кутия, в която се съдържат данни за достъп до акаунта/сървъра.

   Данните за достъп до e-mail кутиите трябва да се съхраняват прилежно и отговорно, тъй като чрез неоторизиран достъп до e-mail кутия може да се направят редица злонамерени действия, включително и да се компрометира по всякакви начини собственика на съответната mail кутия. Силно препоръчително е паролата за вашия имейл да бъде максимално силна – поне 8 символа дължина, да съдържа букви (малки и големи), цифри и специални символи. Друга добра практика е да заменяте паролата периодично. Силно препоръчително е да използвате криптирана HTTPS връзка.
   Разполагайки с имейл акаунт, използван за създаването на хостинг акаунт, хакера може да използва изпратената парола, да създаде нова такава и включително да комуникира с хостинг компанията от ваше име.

3. Наличие на злонамерен и шпионски софтуер на локалните компютри, от които се достъпва хостинг акаунта.

   Ако на даден компютър има инсталиран злонамерен и шпионски софтуер може всякаква чувствителна информация да бъде записана (прихваната) и след това изпратена към недоброжелатели (хакери) без знанието на администратора на компютъра.

   За да не се стигне до подобна ситуация, трябва компютрите да се поддържат, чисти от подобен вид шпионски приложения и вируси, да се сканират периодично с антивирусна програма, особено компютрите, от които се осъществява достъп до акаунта. По този начин ще се елиминира възможността за запис и злоупотреба с лични и конфиденциални данни, като потребителски имена, пароли и други, които в последствие могат да бъдат използвани за достъп до акаунта.

   Да предположим, че шпионски софтуер успешно е прихванал вашата FTP парола (или още по-лошо – вашия логин за контролния панел на хостинг акаунта). Разполагайки с тази информация хакерите биха могли да изтеглят цялата база данни на сайта, който хоствате, получавайки достъп включително и до мейл адресите на потребителите, техните имена, пароли и друга конфиденциална информация.

   Има вируси, които включително модифицират изходния код на сайта по такъв начин, че се прави опит да бъде инсталиран вирус на компютрите на крайните потребители. Виждате какво широко приложение имат компютърните вируси. За това от основно значение е до колко е защитен от зловреден софтуер компютъра, който използвате за управление на хостинг акаунтите си.

4. Пропуски в CMS системите
   

   Едни от най-масово използваните CMS системи са Joomla, OS Commerce, e107, WordPress, Drupal и др. Посредством пролуки в такива приложения се разполагат PHP скриптове, shell файлове и др., които дават пълен достъп до съдържанието на акаунта на всеки, без необходимост от потребителско име и парола. В последствие, посредством тези скриптове, се модифицира съдържанието в акаунта, добавят се чужди файлове, злонамерен код, вируси, троянски коне и т.н..

   За да се избегнат подобни последствия трябва всички инсталирани системи на акаунта, както и използваните от тях модули и компоненти, винаги да се обновяват до последна версия. При последните актуални версии на системите откритите пропуски са отстранени и системите са подсигурени срещу неоторизиран достъп.

   Именно поради тази причина от основно значение при информационната сигурност е одита на сигурността. Навременната намеса на необходимите специалисти може да спести много работа и главоболия впоследствие. Всеки един собственик на хостинг акаунт сам за себе си е отговорен за съдържанието което хоства. Да предположим, че хакер успешно експлоитира уязвимост в WordPress 2.9.1 (при наличие на текуща версия 3.0.1) и успешно получи достъп до административния панел на системата. Дефакто, той може да направи всичко със съдържанието – включително и да го изтрие. Отговорността за загубата на информацията носи администратора на сайта, който не е обновил системата. Да, действително има вероятност хостинг компанията да прави периодично резервни копия на информацията. Но какво става, ако тези копия се правят на по-голям интервал от време? Със сигурност ще има някакви загуби. Ще загубите и доверието на потребителите.

5. 
   Наличие на незащитени Upload форми и галерии, които позволяват разполагането на скриптове със зловреден код – shell файлове.

   Ако на акаунта има страници, през които могат да се качват файлове от всякакъв тип, без ограничения и без да е необходима ауторизация (потребителско име и парола за достъп), е задължително те да бъдат премахнати или защитени. Трябва да се прегледат всички файлове, които са разположени в директориите на тези форми и галерии, като там не би трябвало да присъстват файлове от типа на .php, .txt или други формати, които не са в снимков формат. Проверката на качваните файлове не трябва обаче да бъде само по разширение, например да могат да се качват файлове само .jpg, .png, .bmp и др, а трябва да се прави проверка дали съответния файл отговаря на посоченото разширение. Двойната проверка е задължителна, тъй като може даден .php файл да бъде преименуван на .jpg, но след като бъде качен на сървъра да бъде стартиран като .php файл, независимо от неговото разширение.
   Включително и формите в административния панел на уеб сайта трябва да бъдат защитени. Доста често тези форми биват игнорирани от програмистите с презумцията, че хакерите не трябва да стигнат до там. Но какво става ако получат достъп до администрацията на сайта (чрез SQL инжекция, например)?
   При разработването на уеб форми задължително трябва да се определи какви точно файлове трябва да приемат те. Проверката, която трябва да се прави е по разширението на файла и по неговия MIME тип. Единствено тогава една уеб форма може да се смята за сигурна.

6. 
   Вмъкване (include) на файлове, които се подават като параметър през URL адрес, без да се прави коректна проверка дали файлът, който се вмъква, е от същото приложение.
   При тези случаи злонамерено лице може да вмъкне (include) произволен файл или адрес, след което и да получи пълен достъп до акаунта.

   По принцип не е добра практика, директно да се вмъкват (include) файлове, чието име се подава като параметър в адреса. Едно от решенията е, вместо това да се създаде таблица, в която с ID-та са описани файловете, които ще се вмъкват, като в адреса се подава ID-то на файла, а вътрешно в скрипта е определено кой файл трябва да се включи.

   По този начин няма как да се подаде друг файл, освен този, които е дефиниран.

   Ако по някаква причина трябва да остане подаването на файл в URL адреса трябва да се добави и проверка, дали файлът се намира в хостинг акаунта и да се вмъква само ако е изпълнено това условие.

Още за споделения хостинг

За съжаление начините за пробив в сигурността на приложенията не се изчерпват само с описаните по-горе. Съществуват и други възможности за злоупотреби, като Cross-site scripting (XSS), SQL Injection, използване на Social engineering, sniffing на мрежата и др. Те обаче се срещат значително по-рядко, така че при спазване на посочените по-горе препоръки, съдържанието на акаунта е значително по-подсигурено и възможността за неоторизиран достъп е сведена до минимум.

Едно е сигурно – пробив на приложението означава и неправомерен достъп до хостваната информация, следователно и до самия хостинг акаунт. В този случай собственика на хостинг акаунта сам носи отговорността за загубата на информацията си.