C, PHP, VB, .NET

При всяка система, свързана с автентикация, има едно особено критично звено, което трябва да бъде пазено на всяка цена – базата от данни с имена и пароли на потребителите. На първо място трябва да отбележим няколко практични съвета за администриране на такава база от данни:

1. Заключете сървъра за бази от данни за външния свят. Стандартно сървъра би трябвало да приема връзки само от localhost и да не „слуша“ за автентикация на никакви портове (пример стандартно 3306 за MySQL). Ако все пак вашето приложение е качено на един сървър, а базата от данни е сложена на друг – настройте защитната стена на сървъра с базата от данни така, че да приема заявки само от IP адреса на уеб приложението. Сменете стандартния порт, така че евентуално да заблудите автоматични brute force кракери от вашата мрежа.

2. Давайте само тези права на DB user, които са му нужни. Прочети още…

.

Нека вземем кода от предишната статия и се опитаме да го направим по-сигурен. На първата стъпка ще се възползваме от няколко допълнителни променливи, които можем да дадем като входни параметри при създаване на cookie, а именно:
– директория на сървъра, за която cookie е валидно
– домейн за който cookie е валидно
– задължително използване на SSL
– httponly (предотвратява изпращането му с javascript)

Промяната в кода на съществуващата програма е в два реда: Прочети още…

.

Нека разгледаме прост скрипт, в който автентикираме потребител. В началото на файла ще стартираме потребителска сесия (като абстрактно ще използваме създадената в предишните статии функция security_start_session), за да сме сигурни, че няма фиксиране на сесия. При първоначално зареждане ще се извежда форма, питаща потребителя за име и парола. Тя ще изпраща информацията чрез POST към същия скрипт. При положение, че сме въвели вярна комбинация (проверявано от функцията checklogin), то ще запишем в сесията поле „authenticated“ със стойност „1“. Чрез това поле ще накараме скрипта да следи, дали случайно не сме въвели вече вярно име и парола и ако да – няма да извежда формата на екрана. Ето и примерен код:

Прочети още…

.

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

Често в редица приложения като форуми, блогове, електронни пощи и т.н. сте виждали реализирана функционалност от вида „запомни моята парола“, т.е. сървъра „запомня“ вашият компютър и не ви кара да въвеждате парола когато влизате в сайта, а автоматично ви разпознава. Широко употребявана техника за постигане на това е т.нар. cookie – парче информация, което сървъра съхранява в кеша на вашия браузър. Прочети още…

.

Нека обобщим всичко написано дотук за фиксиране на потребителски сесии, като запишем описаните техники за контрол в една функция. Нека функцията се казва „security_start_session“ и да приема три параметъра:
1. Първи параметър: число със стойност 0 или 1, което указва дали приложението задължително насочва връзката през HTTPS.
2. Втори параметър: времето за активност на сесия (в секунди). Ако се подаде отрицателна стойност или 0, то функцията няма да проверява за дължината на активността на сесията.
3. Трети параметър: максимална активност на сесия. Отново ако подаденото число е по-малко от нула, то функцията няма да прави тази проверка.
4. Четвърти параметър: число със стойност 0 или 1, което указва дали сесията да бъде фиксирана по IP адрес или не.

Като изходни данни функцията трябва да връща числата 1 или 0, които съответно означават, че сесията е стартирана успешно или обратно – засекла е пробив в сигурността. Прочети още…

.

Проблемът „човек в средата“ се появява, когато някой подслушва трафика между вас и сървъра. На практика досега не съществува техника, чрез която да откривате по безупречен начин, че някой подслушва вашата връзка. Затова когато разработваме сигурен софтуер трябва по условие да приемем, че нашия трафик е подслушван. Тук не става дума за фиксиране, а по-скоро за открадване на сесии (session hijacking).

Засега най-ефективният начин за защита е използването на криптография. В света на Интернет приложенията вече най-широко се употребява протокола за комуникация HTTPS, чрез който се пренася HTTP трафик през SSL (Secure Socket Layer).

Всички разгледани дотук техники за защита на потребителска сесия са напълно безполезни, ако използваме некриптиран канал за комуникация. В най-лошият случай, когато не криптираме нищо, то атакуващият дори няма да има нужда да прониква в сесията – той ще може да подслуша канала и да добие нужната информация от самите вас. Може да се приеме, че във всички случаи, когато session id се предава некриптирано, е възможен session hijacking (открадване на сесия). Прочети още…

.

В тази тема ще си поставим въпроса дали може да се направи нещо в помощ на потребителите дори в случая, когато сесията е открадната. Дали можем да „заключим“ сесията така, че да не може да бъде използвана в браузър, който е различен от неговия?

Прочети още…

.

Както вече споменахме в статията за фиксиране на потребителски сесии, е добре приложенията, които пишем, да имат собствен таймер за активност, който е независим от настройките на сървъра. За щастие това се оказва доста лесна задача, тъй като всички езици за програмиране ни дават възможност за достъп до системния часовник на сървъра. В PHP ще реализираме тази функционалност чрез функцията time(). Тя връща броя секунди изминали от началото на „UNIX епохата“, т.е. от 1 януари 1970. Нека преправим вече разгредания пример така, че да прекратява сесията ако тя е била неактивна повече от пет минути: Прочети още…

.

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

PHP предава идентификатора на сесията чрез специална променлива PHPSESSID. При него е предоставена възможност за предаване на тази променлива през URL, например: http://worldbank.dom/login.php?PHPSESSID=1234

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

Нека разгледаме следния примерен код. В него просто създаваме потребителска сесия, в която вкарваме като променлива брояч. Кода на fixation.php ще бъде следния: Прочети още…

.

Виртуалната функция e член-функция, която се дефинира в базовия клас и се предефинира в производния клас. Както и при виртуалните класове ключовата дума е virtual. Когато виртуална функция се предефинира в производен клас, ключовата дума virtual не е необходима. Чрез виртуалните функции се постига също „полиморфизъм по време на изпълнение“. За целта виртуалната функция трябва да бъде извикана посредством указател. Когато указател към базов клас сочи към обект от производен клас, съдържащ виртуална функция, и тази функция се извика посредством указател, С++ решава коя версия на функцията ще бъде извикана въз основа на типа на обекта, сочен от указателя. Именно това решение се взема по време на изпълнение. Прочети още…

.