C, PHP, VB, .NET

Прочети още...

.

Има два вида добавяне на salt към парола. Първия вид е залепването на допълнителен код към паролата и криптирането им заедно (като този код остава известен само и единствено в приложението). Това е популярно също като "глобален salt". Ето какво би се получило след използването на изключително популярната за повечето англоговорящи потребители парола "password":

<?php
	define(SALT, "fd321sfds%#%");

	function saltencrypt($password, $salt){
		return md5($salt.$password);
	}

	echo md5("password");
	echo "<br>";
	echo saltencrypt("password", SALT);
?>

Прочети още...

.

След като обяснихме ползата от криптиране на базата данни остана въпроса как е най-подходящо да го направим. Стандартно и най-често използвани са hash алгоритмите. Това са функции, които трансформират подаден текст само в едната посока (тоест веднъж криптиран не съществува възможност за съставяне на обратен алгоритъм). Най-важната черта за един hash алгоритъм е резултатът от него да изглежда колкото се може повече произволен (тоест да не можем да правим заключение за евентуалният вид на оригиналният текст по вида на криптирания вариант). С други думи двата символни низа "общината отново вдигна данък смет" и "общината отново вдигна данъка смет" би трябвало да дадат визуално напълно различни резултати след криптиране. Прочети още...

.

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

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 (открадване на сесия). Прочети още...

.

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

Прочети още...

.