C, PHP, VB, .NET

В С++ всяка съществуваща унарна или бинарна операция, в която участва поне един обект от даден клас, може да бъде предефинирана от програмиста. Това дава възможност класовете да бъдат интерпретирани, като нови типове данни, които могат да се използват по начин аналогичен на базовите типове. Предефинирането на операции се осъществява чрез операторни функции. Операторната функция е член-функция или приятелска функция на класа, за който тя е дефинирана. Общата форма на една член-функция оператор е следната:

	<тип-резултат> <име-на-клас>::operator<#>(<аргументи>)
	{
		//изпълнявана операция
	}

Типът на връщания резултат най-често е същият като типа на класа, за който е дефиниран операторът. Операторът, който се предефинира, замества # в конструкцията. Когато една операторна член-функция предефинира бинарен оператор, функцията ще приема само един параметър. Този параметър ще получава обекта, който е от дясната страна на оператора. Обектът от лявата страна е този, който генерира обръщението към операторната функция и точно той се предавa неявно на функцията посредством указателя this. Прочети още...

.

Namespace е конструкция за езика C++, която представлява разширение на познатите досега класове, а именно - един namespace може да съдържа в себе си набори от класове. По този начин от една страна се получава естествено обединение на обектите, които имат сходна функционалност, а от друга се решава един основен проблем в дизайна на програмите. Представете си, че имате два header файла, които искате да използвате:

	#include "header1.h"
	#include "header2.h"

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

.

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

.

Има два вида добавяне на 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, които съответно означават, че сесията е стартирана успешно или обратно - засекла е пробив в сигурността. Прочети още...

.