C, PHP, VB, .NET

Препълването на буфера или „buffer overflow“ е проблем, който отново се основава на лошо филтриране на входните данни. Особено силно видими са проблемите при езици за програмиране, които позволяват директен достъп до паметта на ниско ниво (например С и С++). Този проблем е може би най-разпространения при много видове сървърни приложения.

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

.

Дотук разгледахме най-често срещаният проблем, позволяващ вмъкване на нежелан SQL код – лошо филтриране на входните данни. Отбелязахме, че е по-добре да даваме множество от позволени стойности на входните данни, а не просто да забраняваме непозволените символи. За да обясним защо ще демонстрираме чрез пример, в който няма да използваме кавички при изпълнение на заявката. Нека например изпращаме следната заявка:

	$sql = "SELECT * FROM stats WHERE id=$id"

В случая полето в базата данни „id“ е от тип int и поради тази причина не е нужно ограждането на стойността в кавички. Ако подадем например числото „5″ ще се генерира следната заявка към базата данни: Прочети още…

.

Вмъкването на нежелан SQL код е уязвимост на приложението, при което атакуващият взима пълен или поне частичен контрол над базата данни на клиента. Почти при всички случаи това се дължи на не добре филтрирани входни данни или лош контрол върху множеството от стойности. Всъщност този пробив в сигурността е подмножество на една по-обширна тема, а именно филтриране на входните данни. Преди да започнем ще отбележим основното „лекарство“ за борба с тези атаки, а именно: никога не вярвайте на данни подадени от потребителя и винаги правете обстоятелствена проверка върху тях. Прочети още…

.

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

.

Има два вида добавяне на 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

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

.

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

.

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

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

.