Ето и първите три доклада от 2011г.:

• Боян Лазаров – Flash Security;
• Гаро Гарабедян – CSRF с JSON данни + презентация. Може да бъде намерен и на личния сайт на студента тук;
• Илиян Недялков – Ентропия на PHPSESSID.

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

$var1 = 'blablabla';
$var2 = 0;
if ($var1==true && $var2==false && $var1==$var2){
    echo ('WTF');
}

Логически погледнато условието „$var1==true && $var2==false && $var1==$var2″ би трябвало винаги да върне false. Да, но не – пробвайте и на екрана ще видите едно WTF! Ето какво се получава:

1. „$var1==true“ връща true, защото променливата $var1 не е празна;
2. „$var2==false“ връща true, защото стойността на $var2 е 0, което отговаря на стойността на константата false;
3. „$var1==$var2″ магически също връща true, защото низът ‘blablabla’ автоматично се превръща в цяло число, което очевидно е 0, а 0 си е равно на 0.

Уплашихте ли се? За щастие конкретно за този проблем има лек и той е операторът „===“, който означава „идентично равно по стойност на“. За разлика от „==“ (равно по стойност на), операторът ще търси освен равни стойности и еднакви типове данни.

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

Други типични PHP проблеми могат да възникнат при неинициализирани променливи. Какво мислите ще се случи, ако използвате променлива, която никога преди това не сте я инициализирали? Отговор – няма проблем, просто ще бъде хвърлен един „Undefined variable“ notice ако пазите разширен лог файл (в повечето случаи дори няма да забележите). Променливата ще бъде инициализирана със стойността по подразбиране (в зависимост от контекста ще бъде „“, 0, false или null). Затова винаги инициализирайте променливите си – дори те да трябва да са със стойности по подразбиране! Всъщност напук на първосигналната логика – този „спестен“ ред код (от пропускането на дефиниране на променлива) всъщност забавя бързодействието на програмата, вместо да помага.

Накрая ще спомена за още един типичен PHP проблем, който заблуждава програмистите – проверката за това дали променлива има някаква стойност (функция isset()) и дали променливата е празна (функция empty()). Когато използвате isset вие проверявате просто дали променливата е инициализирана. Например една променлива $string=“" е празна, но все пак е дефинирана. Функцията empty() връща булева стойност и проверява за:

1. „“ или “- празен низ;
2. 0 – цяло число 0;
3. „0″ или ’0′ – нула като низ;
4. null – празна стойност;
5. false – булева стойност „неистина“;
6. array() – празен масив;
7. var $var – променлива в class без стойност.

Особени проблеми с empty() поражда точка 3. Например отговор „0″ на въпроса „колко пари получавате като заплата на месец“ би бил логически валиден ако сте безработен, но ако използвате функцията „empty()“ ще получите true, т.е. функцията приема, че получения низ/число е празен. Ето един практичен пример – търсим дали дадена дума се среща в текст и използваме позицията й:

$string  = "Philip Petrov";
$var = strpos($string, "Philip");
if(empty($var)){ // грешна проверка - ще върне true
    echo 'The word "Philip" is not found in the text!';
}

Функцията strpos() връща число (на коя позиция се среща търсения низ в дадения) или false в случай, че търсения низ не е намерен. Тъй като както казахме empty() ще върне true при стойност на променливата“false“ и ще върне true при подадено цяло число. Да, но забравихме за цялото число 0, нали? Затова и сравнението е неправилно, защото се получава частен случай. Това поведение на функцията empty() всъщност е напълно логично ако се върнете в първата част на статията – всъщност empty($var) е отрицанието на (boolean)$var (превръщането на променливата $var в булев тип),т.е. същия проблем се получава често при хората, които не използват функции, а разчитат директно на превръщане на типовете, като например условия като „if($var)…“. Затова много внимавайте коя функция къде се използва и следвайте добре програмната логика. Най-общо казано – просто не ползвайте empty(), а си пишете условията сами. Иначе примерът от по-горе трябва да се пренапише така:

$string  = "Philip Petrov";
$var = strpos($string, "Philip");
if($var===false){ // правилна проверка
    echo 'The word "Philip" is not found in the text!';
}

Описаният по-горе проблем може да се формулира по-простичко – PHP третира числото 0 като false, що се отнася до булеви сравнения. Затова много се пазете от него. Много функции като strpos могат да върнат 0, което да се интерпретира като false и това да обърка програмната ви логика.

Колкото до isset() – добре е да го използваме когато не сме сигурни какво става с данните „над нас“. Например една проверка „if($var<6)…“ ще върне true, ако променливата $var не е инициализирана (тя ще се инициализира със стойност по подразбиране 0, а условието 0<6 е истина). Когато работим в екип не е изключено да получим подобен „подарък“ от колега. Затова когато програмиране в „несигурна среда“ използвайте винаги условието в комбинация с isset(), т.е. от примера „if(isset($var) && $var<6)…“. Но за да ви уплашим още повече от езика за програмиране PHP ще трябва да споменем, че променливи инициализирани със стойност „null“ се третират от isset() като „неинициализирани“. Например следният код ще изпише на екрана „not initialized“:

$var = null;
if (isset($var)) echo "initialized";
else echo "not initialized";

С други думи точното определение на isset() е „проверява дали променливата е инициализирана и има стойност (т.е. не е null)“. Помнете и тази подробност и се пазете от грешки. Съществува функция is_null(), която за нещастие връща „true“ при подадена неинициализирана променлива. Изобщо PHP и в момента страда от липсата на истинска is_defined() функция. Затова спазвайте един съвет от мен – нека докато разработвате вашите скриптове винаги имате една команда „error_reporting( E_ALL );“ в началото на всеки PHP файл. Когато свършите работа и изчистите всички възможни грешки я махнете.

В заключение: PHP ни дава лесна възможност за промяна на типовете данни. По ирония на съдбата именно това „удобство“ ни задължава много по-стриктно да следим сами типовете данни в PHP отколкото го правим в другите езици. С други думи вместо да ни спести, това „удобство“ всъщност ни донася допълнитeлна работа. Тук засегнахме само малка част от проблемите, които може да очаквате „под път и над път“.

1. Инкрементиране на променлива: „++$i“ е по-бързо от „$i++“ – специално в PHP това се получава, защото второто изисква създаването на временна променлива. Ако не желаете да помните този факт – използвайте $i = $i+1. Същото естествено важи и за оператора за декрементиране (–);
2. Проверка за дължина на низ: стандартно когато проверяваме дали един низ $string е с по-малко символи от дадена дължина $len ние правим „if (strlen($string)<$len) …“. Доста по-бързо е ако направим тази операция като „if (!isset($string[$len])) …“. На първо място не броим символите на $string – от там нататък всички допълнителни разяснения са бонус към бързината;
3. Отпечатване на екрана: аз лично не съм виждал хора, които печатат на екрана с print или printf, но все пак ако има – echo е доста по-бързо. Това е защото то не връща стойност. За самото echo – параметризираното echo e по-бързо отколкото конкатенацията на низове в echo (за справка как се прави – прочетете документацията на echo). Друга тънкост е, че когато текстът е статичен, то е по-добре да затворите тага <?php с ?>, да напишете текста в чист HTML код и да си отворите отново <?php таг, за да продължите. С други думи – ако текста не е прекалено къс и си заслужава, то можете да минете въобще без echo;
4. Граници за цикъл: много често хората пишат код като „for($i=0;$ i<count($arr); $i++)…“. Вече знаем тънкостта за оператора за инкрементиране. Има обаче и още един проблем – функцията count се извиква на всяко завъртане на цикъла. Затова този код може да бъде пренаписан като: „for($i=0,$k=count($arr);$i<$k;$i=$i+1)…“. За този конкретен пример също толкова добре се представя foreach, който по някакъв начин си е оптимизиран по описания начин вътрешно: „for($i in $arr)…“;
5. Кавички за низове: някои хора казват, че „низ“ (с двойни кавички) се компилира по-бавно от ‘низ’. Склонен съм да вярвам. Причината е, че двойните кавички позволяват вмъкване на стойност от променлива, например „стойността е $i“ (тук ще се отпечата стойността на $i), докато единичните кавички интерпретират всичко вътре като символи, например ‘стойността е $i’ (тук ще се отпечатат просто символите ‘$’ и ‘i’, но не и стойността на променливата). Ако все пак ви се наложи да отпечатвате стойността на променливата в текста – вместо двойни кавички използвайте функцията sprintf(). Резултатът от „парсването“ е в пъти по-бърз!;
6. Вмъкване на файлове: ако пишете кода си добре и не се нуждаете от проверка – използвайте require() вместо require_once(). Грубо казано ще си спестите един if :);
7. Текущо време: малко хора знаят, но текущото време (функцията time()) се извиква при всяко зареждане на скрипт и се записва в $_SERVER[’REQUEST_TIME’]. Затова защо да извикваме time() отново, като можем да използваме директно вече записаната променлива?;
8. Вложени логически оператори: колкото и да е дразнещо за пригледността на кода „if-else-if-else…“ е по-бързо от „switch()“;
9. Извикване на елемент на масив: просто $arr['name'] е по-бързо от $arr[name]. Доколкото знам във втория случай компилаторът прави проверка дали имате в предвид променлива или константа. Когато види, че не е променлива (не започва с ‘$’) – ще го приеме за константа. В първия случай ние директно указваме константа;
10. Локални дрещу глобални променливи: при всички случаи работата с локални променливи е по-бърза от работа с глобални.

Засега това са нещата, за които се сетих. Ако се сетя за още – ще допълвам.

1. short_open_tag – Един PHP файл може да съдържа „микс“ между HTML и PHP код. Стандартно кода се огражда с <?php … ?>. Кратките тагове позволяват това да става с <? … ?>. По принцип се счита за лоша практика и е добре да го избягвате – стандартно дръжте стойността на off;
2. output_buffering – стандартно трябва да инициализираме сесиите в PHP преди да са изпратени каквито и да е headers в HTTP протокола. Затова и стандартно output_buffering е off. Възможно е да дадем стойност, например 2048 байта, с която да направим буфер, в който да може да се записва информацията от HTTP headers и да бъде изпращана след инициализиране на сесията. Така сесията може да се инициализира навсякъде. Това е изключително лоща практика, която освен всичко има лош ефект върху производителността. Затова винаги дръжте стойността на off и винаги стартирайте сесиите преди всичко останало;
3. expose_php – стойността по подразбиране е „on“, което изначава, че в http headers се изпраща версията на PHP. Принципно това е безсмислена информация – добре е да я скриете. Затова „добрата стойност“ е „off“;
4. include_path – посочват се директориите с библиотеки, т.е. файловете в тях могат да се викат с „include“ без да се указва път. Стандартно в include_path се съдържа текущата директория „.“. Ако искате да добавите втора, то се използва разделител от двуеточие, например: „.:/usr/local/lib/php/pear:“;
5. error_reporting – първоначално начинаещите администратори си мислят, че не е добре да дават информация на потребителите за това какви грешки се случват в системата. Променливата error_reporting е нещо като „глобална“ за „рапорт на грешки“. Наистина не бихме искали заради грешка в приложението ни да се показват грешки в браузъра на клиентите. Но не е и добре никога да не разбираме за тези грешки. Затова дръжте тази променлива със стойността по подразбиране E_ALL и използвайте следващите изброени променливи за настройка;
6. display_errors – указва дали да се показват грешките в стандартната конзола. По подразбиране е „on“, което е добро само за машини за разработчици. На „production server“ го дръжте винаги на „off“ – вашите клиенти не трябва да виждат warnings и errors;
7. display_startup_errors – също както display_errors, ние не бихме искали да показваме, че имаме проблеми по време на стартирането на PHP. Затова и тази стойност е добре да бъде „off“;
8. log_errors – по време на разработката на приложение обикновено има много грешки и държим стойността на „off“. Когато става дума за приложение в реална среда обаче нещата се променят – там сме скрили грешките от потребителите, но ние лично се интересуваме сериозно когато те се появяват. Затова е добре да сложим стойността на „on“ и редовно да преглеждаме този log файл;
9. error_log – като стойност указва името на log файла;
10. log_errors_max_len – максимална дължина на лог файла в байтове;
11. ignore_repeated_errors – по подразбиране е изключено (стойност 0). Ако се включи, то в лог файла ще бъдат записвани само уникални грешки;
12. report_memleaks – по позразбиране стойността е true (т.е. 1). Указва дали да се записват в лог файла грешки свързани с утечки на памет;
13. extension_dir - указва пътя (директорията) в която се намират разширенията на PHP. До PHP5 включително не е възможно да имаме разширения от различни директории, т.е. стойността на тази променлива е само една директория. Обикновено не я променяме, а пазим стандартните пътища;
14. safe_mode – по подразбиране е изключено. От PHP6 тази опция ще бъде премахната (т.е. перманентно изключена). Ако се включи, то се презаписват include_path с директория зададена в 15. Също така се задава специална директория, в която да могат да се изпълняват външни програми с exec();
15. safe_mode_include_dir – директорията за include_path при включен safe mode;
16. safe_mode_exec_dir – директорията от която могат да се стартират външни програми с exec();
17. open_basedir – указва „главната“ директория за PHP. Добра идея е да организирате сайтовете на потребителите си в специфична директория, например в /home, и да забраните на PHP скриптове да излизат извън нея. Затова се грижи open_basedir;
18. max_execution_time – не е добре вашите скриптове да изпадат в безкрайни цикли и да натоварват сървъра ни. Всъщност това е и потенциална атака към стабилността. Затова е добре да изберем разумно максимално време за изпълнение на скрипт в секунди. Естествено понякога това има и своята вреда – скриптове, които отварят мрежови връзки, или такива изпълняващи множество тежки операции, може да не успеят да завършат своята работа;
19. register_globals – това е „голямата болка“ на сигурността на PHP. В по-старите версии това „удобство“ водеше до огромни дупки в сигурността. След PHP4 по подразбиране е „off“. Очаква се в PHP6 да бъде премахнато като възможност въобще. Ако бъде включена, то имате възможност да приемате променливи от форми, например <input type=“text“ name=“email“ /> директно чрез име на променлива (от примера $email), вместо стандартния начин $_POST['email'] или $_REQUEST['email']. Същото важи и за GET заявки. Силно препоръчваме да НЕ пускате register_globals никога. Ако даден стар софтуер не работи – поправете го, но не правете компромис със сигурността!;
20. post_max_size – стандартно 8M, това указва максималното количество данни, което получаваме с POST заявки. Ако нямаме форми получаващи файлове, то можем спокойно да намалим стойността драстично. Това ще намали ефекта от потенциални атаки с невалидни заявки;
21. max_input_time – нова променлива от PHP5, която указва какво е максималното време в секунди, за което PHP ще обработва POST заявки. Ако не очакваме голями POST заявки, то е добре да го намалим. Стойността винаги е разумно да е по-малка или равна на max_execution_time – в противен случай е безсмислена стойност;
22. memory_limit – стандартно 8M – указва максималната RAM памет, която може да използва един PHP скрипт. Хубаво е да изчислявате теоретичния максимум памет за вашият „най-тежък“ скрипт и да слагате лимит на паметта спрямо него. Имайте в предвид, че със сигурност стойността трябва да е по-голяма от post_max_size, защото информацията от POST заявките също се включват в общата използвана памет;
23. register_argc_argv – важи само при извикване на скрипт през командния ред. Това са допълнителните параметри, които се подават към приложението. Рядко извикваме скриптове от командния ред, а още по-рядко им предаваме параметри. Затова го дръжте „false“;
24. register_long_arrays – всяко модерно приложение ще го държи на стойност false. Тази стойност ще забрани остарелите $HTTP_GET_VARS и $HTTP_POST_VARS, които вече са заменени от по-модерните $_POST и $_GET масиви. Освен всичко друго подобрява и бързодействието. Важи само за PHP5 и по-нови версии;
25. disable_functions – ако искате да забраните „опасни“ функции, то можете да ги изброите при тази променлива. Използва се често при „несигурна среда“ каквато например е споделен хостинг. Примерна стойност е „exec, passthru, shell_exec, system, proc_open, popen, curl_exec, curl_multi_exec, parse_ini_file, show_source“.

Както споменахме стойностите са много повече, но в общи линии изброените по-горе са най-съществените. Допълнително с повтарящите се променливи „extension“ можете да добавяте или премахвате разширения. Препоръчваме да добавяте само и единствено разширенията, които използвате.

Едва ли има потребител в интернет, който да не използва електронна поща, та дори и бутафорно само с цел да се регистрира за дадени услуги. От това множество потребители пък едва ли има такива, които не са получавали „нежелани съобщения“, които ние вече дори приехме в българския език като чуждицата „спам“ (spam).

Когато говорим за „спам“ обикновено го свързваме наистина само и единствено с електронната поща. Естествено съществуват и много други видове спам:

1. В коментари под блогове, книги за гости на сайтове;
2. В социални мрежи;
3. Във форуми;
4. По т.нар. Instant Messengers (ICQ, Skype, AIM, и др.);
5. В масови интернет игри;
6. SMS по мобилните телефони;
7. Обаждания по домашния или мобилния телефон;
8. SEO спам (да, т.нар. spamdexing го приемам за спам и наистина е нежелан).

Естествено, че множеството може да се разширява и с всякакви подобни услуги, но главният фокус на обема на понятието пада върху електронните услуги. Що се отнася до уеб-приложенията, които позволяват приемане и визуализация на информация от потребителите (1, 2, 3) – там сме свидетели на една непрекъсната борба на технологии. Обикновено не говорим за „лош човек“, който пуска нежелани съобщения (естествено и такива има, но с тях се „справяме“ сравнително лесно само с човешка сила – т.нар. модератори), а за компютърни програми, които злонамелено пускат масово нежелани съобщения (т.нар. „ботове“).  Засега най-разпространената защита е captcha, но добиването на все повече компютърна изчислителна мощ все повече и повече затруднява процеса на тази защита, защото изображенията трябва да стават все по-трудни за разпознаване, а от там и все по-непрактични за обикновените потребители. Затова аз лично смятам, че captcha е тактика за защита със затихващи функции – колкото повече се развива компютърната техника, толкова повече captcha ще става непрактична. Затова в употреба влизат все повече и повече алтернативни услуги като askimet, които се базират на статистически методи, базирани на данни подадени от потребителите. Положението с IM и игрите (4 и 5) не е по-различно от това на другите уеб-услуги.

Колкото до споменатите SMS спам и нежелани обаждания по телефона (6 и 7) – там положението е по-скоро законодателно, отколкото технологично. Този вид спам е скъп  – обикновено той се прилага единствено от много големи корпорации, които обикновено клонят или са монополисти в бранша си. В такъв случай наистина проблема става политически и правата на гражданите трябва да се бранят от държавите. Например в САЩ съществуват т.нар. „do not call list (DNCL)“ списъци, които дават законово право дори да съдите компании, които се опитват да рекламират продукти по телефона. Рекламните обаждания обаче са трудно доказуеми и все още в тази сфера има много законодателна работа.

Съвсем леко ще засегна т.нар. SEO (search engine optimization) спам (spamdexing). Истината е, че това не само е доходоносен бизнес, но вече се превърна и в професия. Наистина има много хора, които вече гордо се наричат „SEO експерти“, които вкарват скрити фрази в страниците на сайтове, пускат връзки към страници извън контекста на темите по чужди сайтове, правят т.нар. „google bombing“, само и единствено, за да успеят да „индексират“ страниците си/за които работят по-напред в търсачките. Тук въпросът за разграничаване между стандартно оптимизиране на страница за по-добра позиция и spamdexing на страница е доста трудно. На практика „SEO“ и „SEO спам“ са едни и същи подходи – разликата се състои само в това дали страницата, която се „промотира“ е свързана с ключовите думи или не.

В настоящата статия обаче ще се фокусираме основно върху най-популярния спам – този предаван по електронната поща. Есествено трябва да започнем от фундаментите на проблема – защо въобще ни пускат тези съобщения? Та нали те дразнят, та нали винаги ги изтриваме – какво се печели от това? Истината е, че от спам се печели!

II. Защо има спам?

Можете ли да си представите множеството от хора, които използват електронна поща? В днешния свят те са всякакви, от всички социални класи. Каквито хора има в обществото – такива има и в интернет. В развитите държави вече почти всеки използва интернет, затова можем да приемем, че дори множеството на всички хора скоро ще съвпада с множеството на интернет потребителите, а от там и множеството на хората имащи досег с електронна поща. Сега се замислете за хората, които виждате в обществото около вас. Има умни, глупави, богати, бедни, хитри, наивни, предприемчиви, загубени – в общи линии „за всеки влак си има пътници“. Е, точно така е и със спам! И за него „си има пътници“. Ако един от всеки хиляда потребителя повярва на съобщението, то това би било доста добра печалба. А ако смятате, че един на хиляда е прекалено малко, то нека да разгледаме статистиката на Cisco Systems за топ 10 държави за 2009, от които идва смам (мерната единица е „трилиони съобщения за година“):

1. Бразилия: 7.7;
2. САЩ: 6.6;
3. Индия: 3.6;
4. Южна Корея: 3.1;
5. Турция: 2.6;
6. Виетнам: 2.5;
7. Китай: 2.4;
8. Полша: 2.4;
9. Русия: 2.3;
10. Аржентина: 1.5.

Надявам се, че успях да ви убедя, че „спам“ е проблем, който изисква специално внимание. Всъщност този бизнес е достатъчно печеливш, за да съществува и вътрешен „черен пазар“ между „спамерите“. Има търговия на e-mail адреси. Още повече – има търговия с профилирани e-mail адреси, като се продават списъци с потенциални клиенти в дадена сфера. Не рядко това се прави и от реномирани и известни компании, но естествено се осъществява „под масата“ в нарушение на тяхната „privacy policy“. Никога ли не сте си задавали въпроса защо при регистрация за дадена услуга ви анкетират за рождена дата, адрес на местоживеене, професия, хоби и други подобни неща, които по принцип нямат никаква връзка с услугата, която ще ползвате? Естествено другите банални начини да се сдобият с вашия e-mail адрес са намирането му от уеб сайт, социална мрежа, налучкване и др.

III. Кой изпраща спам?

Сега да разгледаме въпроса „как се изпраща спам“. Обикновено „спамерите“ не желаят да оставят следи кои са и не желаят да бъдат проследени. Това им помага при евентуално съдебно преследване, защото въпреки, че рекламират конкретна (неанонимна) услуга фактът, че изпращачът на съобщенията в нарушение е анонимен ги защитава доста умело (може конкурентна фирма да изпраща от ваше име и така да ви „злепоставя“, нали?). Затова обикновено „спамерите“ целят да са анонимни. Затова спам се изпраща най-често по следния начин:

1. През т.нар. „open mail relays“ – обикновено начинаещи администратори на малки сървъри не знаят как да ги конфигурират и оставят своите SMTP сървъри да приемат заявки от всекиго, дори неавтентикирани потребители. Този проблем е наследство от първоначалния дизайн на електронната поща от зората на интернет. Въпреки, че проблемът с изпращането на спам от open mail relays е известен още от средата на 1990г., все още не е разрешен напълно. Обикновено сървър с open mail relay бива засечен и блокиран от своя доставчик (provider) бързо, но все пак през времето си на активност той изпраща огромно количество съобщения;
2. Чрез инфектирани с вирус потребителски машини – всеки компютър с достъп до интернет е потенциален SMTP сървър, който може да изпраща поща. Не са малко вирусите, които правят именно това – превръщат нищо неподозиращ потребител в „спамър“;
3. Лошо написани интернет приложения – често можете да видите форми за контакти на уеб сайтове, които биват използвани за спам. Наистина при тях човекът, който получава спам е един (получателя от формата за контакт). Тук обаче не трябва да ограничаваме множеството само до такива форми. Има форуми и социални мрежи, които позволяват на потребителите си да изпращат съобщения един на друг – те също могат да бъдат експлоатирани за спам. Тук не става въпрос само за електронна поща – дори т.нар. „лични съобщения“ във форумите са уязвими от „спам ботове“. Спам в коментари или постинги също;
4. Доставчици на интернет – на пръв поглед звучи странно, но всъщност е разпространена практика. Често т.нар. „провайдъри“ получават пари и допускат огромно количество спам, като когато получат оплакване, то се извиняват, че е уж от „техен потребител“. Така де, толкова ли е трудно на провайдъра да инсталира софтуер за мониторинг на трафика и като забележи, че негов потребител е изпратил над 100 e-mail съобщения за една минута, то да го блокира моментално? Изглежда, че е трудно, защото „техни клиенти“ успяват да изпратят милиони съобщения… Обикновено в почивните дни (като оправдание за доставчика).

IV. Законова рамка за борба със спам

Тъй като „спам“ е вид бизнес, то независимо, че почти навсякъде се счита за нелегален, той няма да може да бъде спрян напълно. Това обаче не означава, че трябва да се примирим с него! Има два вида борба със спам – законова и технологична. По света, но най-вече в САЩ, има примери за съдебни дела срещу „спамери“, но опитите в тази посока все още са плахи. Колкото до България – ние можем да се „похвалим“, че сме първата и засега единствена държава, която легализира и узакони изпращането на спам. Вече често ще можете да видите писма, които съдържат текста „съгласно Закона за Електронна Търговия Ви съобщаваме, че съдържанието на този e-mail е непоискано търговско съобщение“. Ако получите „нежелано съобщение“ и то не включва този текст, то бихте могли да предявите съдебен иск. Истината е, че тази „битка“ засега е обречена на провал. Понякога е трудно да се докаже кой е изпратил съобщението и трудно се доказва, че съобщението е било „нежелано“. Е, не можем да не отречем, че тази законова мярка на българското правителство имаше и един много положителен ефект – в черният списък на спам филтрите на хората вече масово присъства фразата „непоискано търговско съобщение“. Честно казано засега тази мярка помага доста – възможно е това да се окаже правилен подход в крайна сметка.

V. Технология за борба със спам при получателя

Технологичната борба със спам засега е на три софтуерни нива – на интернет доставчиците, през които се изпраща поща, на сървърите получаващи пощата и накрая при крайния потребител. В началото се слагаха т.нар. „филтри“ само на машините на крайния потребител, т.е. доставчиците на електронна поща дават целия трафик на потребителя и го оставят да се справи сам с нежеланата част от него. Това е логично с оглед на това, че всеки потребител трябва да отговаря сам за действията си в случай, че изтрие някое валидно съобщение. С огромното нарастване на трафика на нежелана електронна поща, както и поради незнанието как да се справят с проблема от страна на потребителите, с времето се наложи да се слагат филтри директно върху сървърите получаващи електронна поща. С бързото навлизане на уеб-базирани приложения за електронна поща (gmail, yahoo, abv и т.н.) този вид филтриране (от сървъра) стана основен и почти извзе всички функции по защитата от спам.

Досега има няколко основни подхода за „филтриране“ на електронна поща що се отнася до сървърите получаващи поща и крайните потребители:

1. Черни списъци – след получаване на нежелано съобщение потребителят добавя e-mail адреса, IP адреса или други характеристики на това съобщение в „черен списък“. Когато се получи втори път подобно съобщение, което отговаря на такъв критерий, то не се доставя до потребителя. Обикновено тези черни списъци са изцяло под контрола на крайния потребител. Изключение се получава когато спамър прави целенасочена атака към конкретен сървър и неговите потребители – тогава администраторът може да защити всичките си потребители с „глобален черен списък“;
2. Бели списъци – това е рядко използван подход, при който се разрешава получаване на поща от конкретен списък с адреси и блокиране на всички останали. Този разрешителен режим е много ефикасен, но приложим само в малко случаи при фиксирана служебна кореспонденция. Отново отговорността за тези филтри е изцяло върху крайния потребител;
3. Ключови думи – въвежда се списък със забранени думи и фрази в клиентското приложение. Така например беше споменато за блокирането на фразата „непоискано търговско съобщение“ с цел защита срещу „легитимния български спам“;
4. DNS Block Lists – това е защита, която се конфигурира предимно на ниво „сървър“. Тактиката е да се блокира трафик от „известни източници на спам“. Както подсказва името, обикновено се блокират конкретни IP адреси и мрежи. Проблем с този вид филтриране е, че често се блокират цели доставчици и по този начин и техните легитимни потребители. Все пак в днешно време това се счита за най-добрия подход за справяне на масовия спам, т.е. този изпращан в огромни размери;
5. Bayesian филтри – това е статистически метод за категоризиране на съобщенията. Обикновено се използват две категории – „спам“ и „валиден“, но понякога и категория „съмнителен“. Идеята на този метод е в събирането на информация от потребителите – обикновено в e-mail приложенията има бутон за отбелязване на дадено съобщение като „спам“ и така се събира характеристична информация за разпознаване на бъдещи съобщения като спам. Освен информация подадена от потребителите се взимат в предвид и други типични характеристики на спам съобщенията – голямо наличие на връзки и html код, наличието на характерни ключови думи (viagra, sex, buy now, on sale, promotion и др.). Всички характеристики и статистически натрупана информация формират т.нар. „spam score“ – число, което оценява съобщението по дадена скала. От тук насетне спрямо „нивото на защита“, избрано от потребителя, се прави филтриране и съобщенията с „spam score“ над определен праг биват класифицирани като „спам“;
6. Изпитание и отговор – това е малко популярен метод при комуникацията с електронна поща, но е силно популярен при формите за изпращане на поща по сайтове, книгите за гости и анонимните коментари в блогове и сайтове. Особено популярен пример е captcha. В т.нар. Instant Messengers (IM) обикновено се поддържа разрешителен режим (бял списък), като при първоначално получаване на съобщение от неизвестен подател се задава въпрос към изпращача на съобщението. При правилен отговор изпращача се добавя към белия списък. Този метод е добър само тогава, когато въпросът е уникален – в противен случай „ботовете“ се „научават“ и лесно прескачат системата. Колкото до електронната поща този метод на защита не е много популярен, но е наличен. Обикновено се използват т.нар. „Ham Passwords“ – когато изпратите съобщение то се „задържа“, а сървъра автоматично изпраща обратно отговор със съобщение, че оригиналното писмо е блокирано. Обикновено от потребителят се изисква да копира някакъв текст (парола) и да я върне като отговор по определен начин (обикновено в subject), за да отблокира съобщението си и то да бъде доставено до получателя. Понякога това се осъществява и с отиване на уеб сайт и извършване на потвърждение за доставка на съобщението (например с captcha). Този метод не е много популярен при електронната поща, защото значително затруднява изпращачите на съобщения;
7. Graylisting – преведено това са „сиви списъци“. Те винаги се конфигурират на ниво „сървър“ и клиентските приложения нямат отношение към тях. Чудили ли сте се защо понякога като изпратите писмо до свой приятел, то идва при него след известно закъснение? Това определено в днешни дни рядко се дължи на „бавен интернет трафик“ или „пренатоварен сървър“, а по-скоро именно на тези антиспам филтри. Защитата се състои в това, че сървъра временно „отхвърля“ съобщения, получени от неизвестен подател. Един легитимен и работещ по стандартите SMTP сървър би трябвало да повтори опита за доставка на това отхвърлено съобщение след определен период от време (обикновено няколко минути). Обикновено при втори или трети опит получаващия сървър приема изпращача за валиден и го добавя в „бял списък“. Разчита се, че обикновено „спамърите“ не правят повторение на опита си за доставка на съобщението. Колкото по-популярен става този метод обаче, толкова по-безсмислен е той, тъй като „спамърите“ се научават да изпращат пощата си по стандартите. Очаква се в един момент той да се обезсмисли;
8. SMTP tarpitting – в духа на идеята за greylisting, tarpitting се използва за забавяне на комуникацията между сървъри. Идеята е връзката да се забави възможно най-дълго. Оригинално това решава редица проблеми, като например brute force атаки, но също така умело редуцира количеството спам. Наистина е значително по-трудно на спамърите да доставят десетки хиляди съобщения, при положение, че това ще им отнеме много дълго време;
9. Quit detection – по стандарт SMTP протокола изисква всяка връзка да бъде затваряна. Често спамърите просто изпращат информацията и оставят връзките в отворено състояние. Такива съобщения могат да бъдат блокирани;
10. Sender Policy Framework – т.нар. SPF записи са едно доста модерно обновяване на стандартите за комуникация по електронна поща, което впрочем се оказа, че се справя доста добре и с голямо количество спам. По принцип SPF се справя с друг вид проблем – т.нар. „spoofing“ на e-mail адреси. Нормален SMTP сървър е конфигуриран така, че всеки автентикиран към него потребител може да изпрати поща от какъвто си иска e-mail адрес. С други думи чрез такъв SMTP сървър вие можете съвсем лесно да изпратите съобщение например от bill@microsoft.com. SPF е защита на две нива – на първо място самия домейн (microsoft.com от примера) трябва да добави т.нар. TXT запис, в който да укаже кои са хостовете/IP адресите, които имат право да изпращат поща от негово име. Също така получаващия сървър трябва да бъде конфигуриран така, че при получаване на съобщение да провери този списък и ако получава съобщение от непозволен хост, то да не го допусне до пощата на клиента. В днешно време SPF получава изключително широка популярност и повечето сериозни mail сървъри са конфигурирани така, че да го използват. Ако вие използвате електронна поща и често ви се случва да получавате т.нар. bounceback съобщения от адреси, на които вие никога не сте изпращали e-mail, то най-вероятно някой спамър изпраща съобщения от ваше име, а вашия домейн няма SPF запис;
11. Checksum базирано филтриране – този метод е изключително прост, логичен и много често използван при големи сървъри приемащи електронна поща. Състои се в това, че обикновено спам съобщенията се изпращат едни и същи към всички потребители. Така на сървъра започваме на пазим за определено време хеш код на текста от всяко подадено съобщение. Когато към сървъра се подадат над определен брой еднакви съобщения (обикновено разумно голям, за да не бъдат блокирани валидни mail листи), то те спират да се доставят. Естествено изпращачите на спам вече са свикнали с това и вече изпращат своите съобщения с известни разлики (можете често да видите някакъв произволен и нелогичен текст някъде вътре в съобщенията). Така този вид филтриране е изправено пред още една тежка задача – да може да определя съществената от несъществената информация в едно съобщение;
12. Адреси-капани – обикновено подход на крайните потребители от даден домейн, които създават специален e-mail адрес с обикновено (например peter@domain.dom), който не се използва и не се промотира никъде в официална комуникация с клиенти. Тъй като се очаква, че никой легитимен потребител не би изпратил писмо до този адрес, то всяко получено съобщение на него влиза в „черен списък“ за всички останали адреси от този домейн. Този метод не е особено ефективен, защото се справя единствено със спамърите, които изпращат безразборно поща от тип „налучкване на адреси“. Това е стар и неефективен подход за изпращане на спам към малки домейни – той работи само върху домейни с много e-mail адреси (а при тях възможността за грешка на легитимен изпращач се увеличава значително). Друга по-удачна тактика е за създаване отново на такъв адрес-капан и масовото му записване по известни mail листи на спамъри. По този начин можете да защитите работните си e-mail адреси от доста голямо количество еднотипен търговски спам (но не и от всеки);
13. Spamming the spammers – все още непопулярен и спорен метод за борба със спам. Основава се на това при получаването на всяко съобщение да се прави обратна връзка до IP адреса на изпращача и „занимаването му“ с определени дейности. Това може да е поредица от ping заявки например. Очакването е, че ако бъде масово имплементиран, то спам машината ще бъде задръстена от заявки и по този начин ще направи DoS атака сама на себе си. Така обаче често се засягат и нищо неподозиращите „zombie computers“ – тези на инфектирани с вирус потребители;
14. Проверка на валидност на HELO/EHLO – въпреки, че не е по стандартите, понякога сървърите проверяват достоверността на HELO заявките към тях. Например те проверяват дали при заявка „HELO domain.dom“ този домейн наистина отговаря на IP адреса, който я изпраща. По принцип стандартите казват, че просто този домейн трябва да отговаря (на ping), но не и на IP адреса на изпращача. Истината е, че много администратори на сървъри тъй или иначе не спазват стандартите (например забраняват ping към сървърите си поради някакви съображения за сигурност) и така с подобна проверка бихме блокирали и легитимни съобщения. Затова и такъв вид защита все още не е въведен масово – това може би ще стане тогава, когато бъде приет като стандарт (което пък ще доведе и до други специфични ограничения – затова въвеждането е спорно). Може да се направи и т.нар. PTR checking, т.е. проверка на reverse DNS записа на IP адреса на изпращача, но и в този случай положението е спорно. Все пак често се прилага проверка поне на MX записите на домейна – добре е като получавате поща от даден домейн, то този домейн да има mail сървър, на който да може да се отговаря. В противен случай състоянието му е много съмнително;
15. Open relay капани – това са сървъри в големи мрежи, които привидно приличат на open relays. Когато спамърите търсят такива сървъри със скенери, то те попадат на този сървър-капан и се опитват да изпратят поща чрез него. Така администраторите на тези мрежи ги блокират в DNSbl;
16. Потребителска статистика – понякога големите доставчици на електронна поща въвеждат статистически методи за вкусовете на потребителите си. Например ако забележат, че вие много често изтривате еднотипни съобщения идващи от един източник, без да ги четете, то е вероятно да преместят следващи съобщения автоматично в папка „спам“ или „съмнителни съобщения“. Също така ако един потребител често маркира едни и същи съобщения като „спам“, но други потребители не го правят, то се въвежда филтър само за този конкретен потребител (явно той има личен проблем с изпращача на дадените писма).

VI. Технология за борба със спам при изпращача

Естествено важна е и защита, която „добрите доставчици“ и изпращачите на съобщения трябва да имплементират:

1. Активно следене на потребителите във вашата компютърна мрежа и броя съобщения за определен период от време, които те изпращат. Логично е нормален потребител във вашата мрежа да не трябва да изпраща хиляди съобщения;
2. Потвърждение за услуга – има много честни фирми (неспамъри), които позволяват на потребителите да се записват към техни т.нар. newsletters или mailing lists. Не е рядкост злонамерена атака към такива фирми, която записва масово e-mail адреси на неподозиращи трети страни. Така тези записани потребители получават съобщенията на фирмата и логично ги класифицират като „спам“ и така дескридитират името й в DNSbl листите (може да се достигне до неприятни последствия за самата фирма и това не е рядкост). Затова винаги имплементирайте система за „потвърждение“ на записването. Това обикновено е първоначално изпращане на e-mail с текст „получихме заявка за записване към нашата услуга X – натиснете на този -> линк <- за да потвърдите записването“. Освен това никога не изпращайте подобен e-mail за потвърждение до един и същи е-mail адрес два или повече пъти – рискувате от друг вид flood атака;
3. Следене на нови акаунти в системата на hosting и internet service providers – обикновено спамърите не са стари и утвърдени потребители. Най-често те са многократно изхвърляни от различни мрежи и регистрират винаги нови и нови акаунти. Затова новите потребители трябва да бъдат следени за известно време;
4. Филтриране на изходящата поща – някои от сървърните филтри могат да се прилагат към изходящата поща от вашия сървър/мрежа – например Bayesian или филтри по ключови думи/фрази;
5. Отказване за доставка на backscatters – вече намекнахме за проблема за т.нар. e-mail forgery, когато описвахме SPF записите. Добре е вашия e-mail сървър да не доставя bounceback известия за съобщения, които вие никога не сте изпращали. Дори вие да имате коректни TXT записи за SPF record – все още има много сървъри, които не го поддържат и те могат да връщат bounceback на forged e-mails. Това би могло да се използва включително за flood срещу вас;
6. Блокиране на порт 25 – малко остарял метод, но все пак доставчиците на интернет понякога с цел на защита от ботове блокират порт 25 и дават на потребителите си друг порт за изпращане на поща (обикновено 587). В общи линии това води до повече затруднения отколкото ползи.

VII. Заключение

Накрая искаме да дадем няколко съвета за това как да намалите чисто практично количеството спам във вашата поща. На първо място – не купувайте нищо от случайни писма попаднали във ващата електронна поща! Не им отговаряйте и се правете пред тях, че не съществувате! Не си давайте e-mail-а „под път и над път“! Когато се регистрирате за някакви временни, краткосрочни или непознати услуги си направете временен нов e-mail адрес, който след изтичане на услугата го закривайте. Пишете на доставчика на спамърите! Пишете до DNSbl листите когато получите спам. Използвайте „спам“ бутона в е-mail клиентите си. Не на последно място – никога не маркирайте легитимна поща като „спам“ – ако просто не желаете да получавате известия за услуга, която сте спряли да ползвате, то трябва да последвате процедурата за легитимно отписване. В противен случай (с блокиране и филтриране на тези e-mail-и) вие създавате проблеми на други потребители, които биха искали да получават въпросните писма.

Използвани източници: Предимно личен опит и Wikipedia.

Наскоро прочетох малко статистики за captcha и нейния ефект върху бизнеса. Според това скромно социологическо проучване има вероятност да изгубите около 3.2% от реалните коментари при използването на Captcha срещу алтернативният метод. Тук веднага бих дал и формулата според която да изчислим „дали да използваме Captcha или пък друга услуга като Askimet“. Когато стартирате подобен бизнес трябва да прецените кое от двете е с по-голяма икономическа тежест за вас:

• Загубата на 3.2% потенциални клиенти – captcha;
• Загубата на пари при даване на заплата (или закупуване на платена услуга) за модериране на изпуснат spam и „false positive“ коментари.

Моето скромно мнение казва, че всичко зависи от големината на бизнеса. Колкото по-големи са печалбите и се увеличава трафика – толкова повече captcha губи смисъл. С други думи един естествен ход на един бизнес ориентиран блог би тръгнал от ръчно модериране от собственика и използване на филтри (това е моментът, в който блогът не е много популярен и все още не се радва на сериозен интерес – като моя например), през слагане на captcha (когато собственика на блога започне да изпитва затруднение в модерирането на коментарите), до премахване на captcha и връщане към филтри с платен персонал за контрол (когато приходите са достатъчни, за да бъде оправдана такава заплата).

Междувременно през страницата със статистиките попаднах на много интересна идея, която впрочем не е кой знае колко нова – honeypot captcha. Накратко идеята е да вкарате допълнително поле във вашите HTML форми, което обаче е скрито чрез използване на CSS. По този начин ботовете биха попълнили това поле с някаква информация, докато потребителите – не (понеже не го виждат).

Смятам тази стратегия за изключително добра при използването на популярен софтуер. Ако например използвате WordPress, то спокойно можете да го приложите към коментарите на блога си, като например направите някое от стандартните полета (например „website“) скрито с honeypot captcha. Естествено е нужно да бъдете уникални в конкретната реализация.

Когато става дума за частен продукт обаче тази техника не е приложима. Простата причина е, че ботовете тъй или иначе не знаят структурата на системата ви за коментари/заявки. При частните продукти винаги спам атаките са съставени ръчно, тоест атакуващия няма да се „хване в капана“.

Все пак „honeypot catpcha“ (което всъщност няма нищо общо с captcha) заслужава нашето внимание. Бих препоръчал тази техника на програмистите на средноголями и голями популярни сайтове използващи стандартни платформи.

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

П.П.2. Приятел разшири темата като предложи дори „скрита captcha“. Това според мен е спорен елемент. Не съм съвсем сигурен, че ботовете са чак толкова напреднали, че да търсят уязвимости в нестандартни форми. По-склонен съм да мисля, че ботовете атакуват само стандартен софтуер. Да, на такъв бихте могли да скритете стандартната captcha :)

Задача: Реализирайте HTML форма с HoneyPot captcha чрез използване на CSS, JavaScript или друга функционалност.

Най-грубо казано картите с чип имат предимството да бъдат четени доста по-трудно. Когато поставите картата в устройство, тя трябва да бъде поставена абсолютно точно под четеца. Освен това е нужно технологично време за захранване и предаване на информацията – това забавя процеса, но го прави и по-сигурен. Така изключително много се затруднява използването на ATM skimmers. При банкоматните системи бих казал, че става почти невъзможно използването на допълнителни устройства.

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

ATM картите с чип не решават всички проблеми. Атаката с използване на фалшиви устройства, за която споменах в първата статия от серията, е напълно действаща и при картите с чип. Това за съжаление въобще не е малко звено от измамите с кражба на банкови карти.

Тук е момента да спомена, че с навлизането на банкови карти с чип се забелязва една друга тенденция на банките – самия PIN код да не бъде съхраняван на самата ATM карта.  На нея се пази единствено информация за номера на сметката на притежателя. Това е колкото полезно, толкова и опасно. От една страна ако откраднат вашата карта вие сте убеден, че PIN кода ви няма да е известен на престъпниците. От друга страна базата данни с PIN кодове се съхранява при банката и по този начин евентуална кражба на такава база може да доведе до фатални за банката последици. Така има възможност (чрез множество допълнителни условия естествено) крадците сами да си генерират банковите карти без въобще да се налага копиране на оригиналната!

Теоретично съм разглеждал възможността кодирания PIN код да се раздели на две части. Едната част да се съхранява на картата, а другата част – в базата данни на банката. Това не решава проблема напълно (ако крадците имат едновременно банковата карта и копие на базата на сървъра на банката, то те имат всичко), но все пак утежнява нещата значително.

Другата ми идея (едва ли е революционна, но поне не намерих подобна информация в интернет) е за „ATM Flash“ карти. Идеята е при всяко успешно автентикиране на легитимен банкомат, банката да генерира нов master key за вашата карта и да записва обновен криптиран PIN код на нея. По този начин копието, с което разполагат крадците ще бъде валидно за ограничено време, т.е. ние сериозно ги затрудняваме в процеса на производтво на копие на вашата банкова карта.

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

При ATM картите най-често се използва 4 цифрен PIN код. Така възможните комбинации са общо 10 000 – от 0000 до 9999. Повечето банкови системи дават право на до три грешни опита за въвеждане на PIN код, след което блокират картата. По този начин опитите за „налучкване“ са сведени до вероятност от 0.3%.

PIN кода на масово използваните ATM карти се „складира“ на магнитната лента. Той е криптиран с ключ, който се пази от банката, издала картата. Отделно от това преди криптирането на кода, той се превръща в шеснадесетичен формат (цифри от 0-9 и букви A-F). За декриптирането му по-късно се използва т.нар. „decimalization“ таблица, която превръща криптирания код от шестнадесетичен в десетичен (например като превърне A в 0, B в 1 и т.н.).

Когато поставите картата си в банкомат първоначално избирате сума, която искате да изтеглите. След това от вас се иска да въведете PIN код. След като въведете PIN кода си, той заедно с кодирания код на банковата карта се изпрачща към ATM Controller до т.нар. Hardware Security Module (HSM). Той дешифрира подадения низ, след което чрез decimalization таблицата той дешифрира шестнадесетичния код. Така полученото число се сверява с въведеното от клавиатурата на банкомата. След това се изпраща отговор до банкомата дали въведения код е верен или не. Трябва да се отбележи, че важен елемент в този модел на сигурност е, че практически никой не знае вашия PIN код – дори хората в самата банка, тъй като той се складира само и единствено на вашата банкова карта.

Първият сериозен пробив в сигурността на банкоматната система е открит през 2002г. Той е свързан с широко използвани и до днес HSM системи на IBM. Пробивът в сигурността се осъществява от вътрешен за банката човек, който има достъп до ATM контролера. Той подменя „decimalization“ таблицата, която се подава към HSM контролера и по този начин значително намалява броя нужни опити за налучкване на PIN код. Този метод повишава вероятността за налучкване на PIN код до 6.6%. Виждате, че това е 660 пъти по-голяма вероятност от стандартната. За щастие продължава да е достатъчно малка за реална атака и не предизвиква сериозни проблеми в сигурността на банковите системи.

Проблеми с ATM конролера за сигурност обаче все пак има и то изключително сериозен. Когато вътрешен служител на банката има достъп до HSM контролера, то той има възможност да открадне ключа за декриптиране на кодовете, подавани от картите. Така когато бъде открадната банкова карта на същата банка, то крадците могат да си съставят таблица от вече криптирани ключове и да сравняват с този, който са откраднали. Такава таблица се състои от комбинациите между всички възможни decimalization таблици и 10000 възможни PIN кода. За съвременната компютърна техника това не е проблем.

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

По-обиграните атаки работят с разбиване на кодовете без достъп до банковата система. Един пример е с подмяната на данни. Според стандартите PIN кода освен криптиран с т.нар. „master key“, той трябва да се криптира допълнително и при „транзит“ (тоест при преминаване между различни устройства) – това често се налага, когато например използвате банкомат на друга банка. Именно чрез добавяне на такава допълнителна транзитна точка или имащи достъп до такава атакуващите имат възможност да използват множество открити уязвимости в HSM устройствата.

Такива уязвимости за съжаление има много, тъй като банкоматите са длъжни да работят и с по-стари стандарти за банкови карти. Също така те трябва да работят и с банки от други държави, които може да поддържат остарели стандарти. Има доказани случаи при които чрез външно устройство е била открадвана важна информация за master key на банката, която издава картата. Такива уязвимости се премахват постепенно чрез обновяване на банковите системи, но за съжаление все още са налице. Конкретен пример за сериозността на този проблем е залавянето на 11 хакера миналата година, които са обвинени в кражбата на над 40 милиона криптирани ключа от TJ Maxx и други подобни мрежи в САЩ.

Атаките с конкретно налучкване на master key като че ли са в миналото, когато алгоритмите за криптиране са били слаби. Въпреки това такива атаки са напълно реална заплаха, тъй като често се използват масивни botnets за търсене на такива ключове. Банките от своя страна не са в състояние да подменят своите ключове често, защото е нужно да подменят огромно количество ATM карти.

1. Общите загуби на САЩ от кибер престъпления (които в по-голямата си част включват именно кражба на ATM карти) е 1.5 милиарда долара за 2008г;
2. Оплакванията в „Internet Complaint Center (IC3)“ са над 200 000 за година;
3. Най-масовата кражба е в диапазона от 100 до 1000 долара;
4. По-възрастните хора стават по-често жертви на кражба, но тенденцията е с времето процентите да се изравнят. Това се обяснява с фактът, че възрастните хора работят по-малко с електронни устройства и интернет;
5. Съотношението на измамени мъже и жени е 60:40;
6. В световен мащаб най-много киберпрестъпления има в САЩ. Тенденцията обаче е измамите в ЕС да се засилват;
7. Престъпниците обикновено са от източна Европа и най-вече Русия.

Как работи една престъпна група? Досега разбитите групировки за кражба на ATM карти показват, че структурата им следва общата ни представа за мафия. Начело на групировките винаги има един човек, който се нарича шеф (boss). От долу следва доста строга структура, която включва програмисти, специалисти по пробиви в сигурността, брокери на лични данни, фалшификатори, „мулета“ (хора, които теглят самите суми), „човешки ресурси“ (хора набиращи „персонал“ за престъпната схема), както и хора, които се грижат за сигурността вътре в организацията.

Интересно е, че мулетата взимат значителна част от парите – до 50%. Те обикновено са наркозависими или хора с финансови затруднения. Въпреки големите суми който получават, при тях рискът е най-голям. Разкриваемостта на „мулетата“ е доста голяма. За съжаление полицията рядко успява да се свърже с хора „по-високо“ в схемата.

Като един пример можем да дадем вече разбита руска организация за източване на дебитни карти, която през 2007г е направила опит за над 15 000 транзакции за 30 минути на стойност над 10 милиона долара, като от тях около 14 500 са били успешни. Общата сума на откраднатите пари е била 9.7 милиона долара. За удара са използвани над 2100 банкомата в 28 държави (общо в 49 града). Виждате, че измеренията на кражбите въобще не са малки.

Този пример е действал напълно по схемата описана в предишната статия. ATM Skimmers устройства са записали съдържанието на магнитната лента на ATM карти, PIN кода е бил записан или „разбит“ (ще погледнем този въпрос по-късно) и в Русия са произведени копия на дебитните карти. Тези копия на карти са изпратени по мулета по цяла Европа и транзакциите са извършени едновременно, за да се създаде ефект на паника.

В тази статия ще пиша главно относно начините за кражба на ATM карти. На първо време трябва да спомена, че има две възможности за изтегляне на пари от банкова карта – online и offline:

- Online тегленето на пари е най-познато – вкарвате дебитната си карта в устройство, което иска въвеждането на ваш секретен код (наречен PIN код). По този начин работят всички банкомати и повечето магазини. Предполагам, че повечето от вас са запознати с този метод на работа с ATM карти.

- Offline транзакциите дават възможност за изтегляне на пари от банкова карта без въвеждането на PIN код. Това може да стане както в магазин, така и по Интернет. Такива са картите VISA, Mastercard, American Express и др. За сигурността на транзакцията в самия магазин се разчита на записи от видео камери и директния контакт с продавача. За сигурността в Интернет обаче няма сериозна защита.

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

Колкото до online транзакциите – там измамниците са затруднени. Освен физическо копие на вашата карта, на тях им е нужен и вашия PIN код. Как може да се случи това? Ще дам няколко примера от т.нар. „ATM skimming“ от банкомат. Снимките са взети от сайта на полицейското управление в Остин -  Тексас:

На горната снимка виждате как изглежда оригиналния процеп на банкомата. Устройството, което записва информацията от ATM картата е изключително тънко и трудно забележимо.

Виждате, че поставено на място то не подбужда сериозно съмнение. Нормален човек едва ли би забелязал, че има прикачено допълнително устройство.

Краденето на вашия PIN код е трудно, понеже е технически трудно да се дублира клавиатурата на банкомата (но не невъзможно). Затова по-честата практика е да се поставят безжични камери, насочени към клавиатурата.

Вие бихте ли се усъмнили в банкомата на горната снимка? В нормалния живот – по-скоро не. Истината е, че такива устройства се продават дори по интернет. Показаното по-горе е с „едри“ размери (размер normal, като има small и дори slim с големина не много по-голяма от процепа за самата карта). Ето един друг пример от центъра за сигурност на Commonwealth bank:

Друг пример за ATM skimmer

Колкото до заснемането и краденето на вашия PIN код – и тук има множество варианти:

Ето и как изглежда устройство за прихващане на PIN код от клавиатурата:

Кражбата на карти чрез банкомати обаче е по-малкото перо на проблема. Почти всички банкомати вече са оборудвани с видео наблюдение и се проверяват редовно от служители на банката. Банкоматите обикновено се използват в последствие – когато крадецът има копие на вашата карта и знае вашия PIN код. Спорен остава въпроса обаче, когато самите служители на банката са замесени в престъпна схема. Ето още няколко снимки на типичен ATM skimmer:

Типичен банкомат приличащ на българските

Ето как се заснема вашия PIN код

Устройството за запис на данните от картата изглежда съвсем достоверно

Още един пример

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

Най-масовият случай на кражба на ATM карти е в търговската мрежа. Има два начина – единият е чрез поставяне на четец върху истинско устройство (много подобно на представеното за банкомат по-горе, но по-миниатурно). Понякога измамниците дори правят цяла нова „опаковка“ на електрониката на истинското устройство така, че да може да се вкара допълнителното четящто устройство.

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

Друг изключително популярен начин е чрез така наречените „mobile ATM skimmers“. Това са миниатюрни устройсва, които измамникът държи в ръката си. Когато вие му подадете картата той я прекарва през устройството незабелязано, а после я слага в истинския апарат. В последствие ви гледа в ръцете, за да научи вашия PIN код. Ето как изглеждат няколко такива устройства (снимки от jheary.com):

За нещастие защитата от кражби в търговската мрежа е изключително трудна. Вярвате ли в честността на сервитьорката в ресторанта? А продавачката в магазина за обувки? Проблемът ще се задълбочава с все по-масовото използване на „електронни пари“. С днешното ниво на сигурност на ATM картите единственият начин да сте напълно убедени, че няма да откраднат пари от вас, е като редовно сменяте PIN кода си на банкомати, които познавате като сигурни. За съжаление това е изключително рядка практика при нормалния човек и затова се търсят по-иновативни решения. В по-следващи статии ще се запознаем с технически детайли за ATM картите и съвремените методи за защита на информацията в тях.

Файлът за настройки на Apache е с име httpd.conf. Понякога този файл зарежда свои дъщерни (httpd-vhosts.com, httpd-aliases.conf, и т.н.). Обикновено специфичните настройки на сървъра се слагат във файл httpd-default.conf. Подобно на настройките за MySQL, за които споменахме по-рано, и тук всичко се променя изключително лесно с проста промяна на стойност:

1. HostnameLookups Off

Ако HostnameLookups е включен, то за всеки един „hit“ към сървъра се прави DNS lookup, за да се транслира IP адреса на клиента в hostname. От една страна това е добре, защото по този начин сме сигурни, че информацията не е подменена (spoofed). На практика обаче това най-вероятно не ви трябва. Често администраторите правят въпросния DNS lookup в последствие, чрез софтуер за преглеждане на log файлове. Разликата в бързодействието на сървъра, особено при много натоварени машини, е значително.

2. ServerSignature Off

Когато клиента попадне на някоя от стандартните страници на Apache (directory listing, 404, 401, и т.н.), то обикновено сървъра изписва името и версията си най-отдолу. Едва ли искаме да даваме тази информация на който и да е. Въпреки, че въобще не е трудно да се познае, че сървъра е Apache, то въобще няма нужда да даваме информация за конкретната версия.

3. ServerTokens Prod

Същото, което казахме за ServerSignature важи и за всеки HTTP header, който се изпраща към клиента. Ако тази стойност е FULL се дава информация дори за операционната система. Prod е възможно най-минималната информация за системата, която е нужна, за да може да се функционира нормално.

4. KeepAlive On

Обикновено на една HTML страница има свързани редица обекти (javascript файлове, картинки, флаш анимации, и т.н.). Ако KeepAlive е изключено, то за всеки един файл ще бъде правена нова връзка към сървъра. Това естествено води до забавено бързодействие. При натоварени сървъри е задължително да бъде включен KeepAlive – така клиентът изтегля повече от един файл с една връзка.

5. KeepAliveTimeout 3

Колкото и да помага, KeepAlive естествено си има и своите минуси. Най-големия е, че може клиенти да отварят връзки и да не ги приключват. Това се случва често при DoS атаки. Затова е нужен таймер за затваряне на връзката – това се явява KeepAliveTimeout. Стойността 3 секунди е приемлива за съвременните интернет връзки. Въпреки това при клиенти, които имат бавна връзка и са прекалено много отдалечени от сървъра би се получило така, че връзката ще се затвори преди да успеят да направят следваща заявка за файл.

6. MaxKeepAliveRequests 100

Максимална стойност за поискани файлове с една връзка. Например ако имате html страница с 100 снимки, то клиентът трябва да свали 101 файла (1 html + 100 jpg), т.е. при „MaxKeepAliveRequests 100″ ще са му нужни две връзки.

7. MaxClients 2000

Когато се свърже към сървъра, за него се стартира работен процес. Всеки един от тях обработва по няколко клиентски заявки, след което се изключва. Ако имате много клиенти едновременно, то е добре да увеличите тази стойност. Тя контролира максималният брой процеси, които се стартират. Добра формула е следната:

RAM памет отделена за Apache = MaxClients * Max child process size

8. StartServers 10

Тази опция дефинира колко процеса да бъдат стартирани първоначално.

9. MinSpareServers 10

Колко да бъдат максимално свободните процеси (т.е. такива, които не обработват клиентски заявки, а чакат). Добре е да пазим поне 5. Стремежът ни все пак е да не се стартират повече от 4 Apache процеса за една секунда – ако това стане, то е добре да увеличаваме тази стойност.

10. MaxSpareServers 30

От друга страна не е добре да имаме прекалено много свободни процеси. Добре е да ги затворим и да дадем оперативна памет на други програми.

11. MinSpareThreads 25

Минималното количество от обработващи нишки, за всеки свободен процес.

12. ThreadsPerChild 25

Константно количество нишки за всеки процес

13. MaxRequestsPerChild 8000

По подразбиране стойността е 0, т.е. „безкрайност“. Важно е обаче да сложим такъв лимит за дъщерните процеси. Ако имаме „утечка на памет“ (memory leak), то при достигане на MaxRequestsPerChild тя ще бъде „пресечена“.

14. Timeout 60

Максималното време, което Apache ще отдели за една връзка към него (в секунди). Например при качване на много голям файл през POST показаното в примера може да не е достатъчно. Стойността по подразбиране е 300.

Освен изброените по-горе стандартни настройки, има и редица допълнителни модули за Apache, които са изключително важни. Такива са например mod_deflate (отговорен за компресирането на данни), mod_cache (за кеширане на данни), mod_expires и mod_headers (за кеширане на HTTP headers). Повечето от полезните модули са включени в стандартната инсталация.

Има обаче един модул, на който искаме да обърнем специално внимание – това е известният mod_dosevasive. Чрез него можете да блокирате заявки от дадени клиенти за определено време. Например при flood от едно IP вие не бихте искали всеки път да бъде компилиран PHP файл. Чрез mod_dosevasive модула можете да укажете например, че ако от даден IP адрес се получат повече от 20 заявки за една секунда, то да бъде блокиран достъпа му за определено време (например 5-6 секунди). По принцип стойността се слага така, че сървъра да може да обслужи най-голямата си страница за една секунда, без клиента да бъде блокиран. Затова от примера по-горе, при html страница с 100 картинки, бихме сложили стойност на mod_dosevasive над 100. Този модул има изключително положителен ефект при DoS атаки!

Друг много известен модул свързан със сигурността е mod_security. Той действа като firewall за Apache, като следи за известни атаки или съмнителна активност на даден клиент. Силно препоръчваме включването на този модул въпреки, че по принцип намалява бързодействието на сървъра в нормална ситуация (без атака срещу него).

В настоящата статия ще разгледаме някои важни настройки за мрежовия адаптер и още други свързани със сигурността на системата. Повечето от тях ще подобрят сигурността на системата и ще я направят много по-малко уязвима от слаби DDoS атаки. Разгледаните настройки са само за системи работещи под FreeBSD. Други операционни системи имат свои алтернативни опции.

1. security.bsd.see_other_uids=0

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

2. net.inet.tcp.msl=15000

MSL е съкращение от „Maximum Segment Life“ за TCP/IP. Това е максималното време в милисекунди, което ще се изчаква за един ACK в отговор на SYN-ACK или FIN-ACK. Ако след изтичане на това време не се получи отговор, то сегмента се счита за загубен и мрежовата връзка се освобождава. RFC стандарта дефинира MSL да бъде 120000ms, което в днешно време с бързи интернет връзки е напълно неоправдано. Стандартната стойност за FreeBSD е 30000, но статистиката показва, че дори намалявайки я наполовина няма никакви проблеми. Ако обаче често изпитвате силни DoS атаки, то можете да го намалите и под 8000.

3. net.inet.tcp.blackhole=2

Знаете ли какво се случва, когато се изпрати TCP пакет към затворен порт на системата? Истината е, че при стандартната стойност 0 се връща отговор до запитващия, с който му съобщаваме, че порта е затворен. Ако сложите стойност 1, то всички SYN заявки ще бъдат просто пропуснати и отговор няма да се върне. Това е подгодящо при известният SYN FLOOD. Стойност 2 означава, че всякакви заявки ще бъдат пропускани напълно. Поради тази причина променливата се нарича и черна дупка (blackhole).

4. net.inet.udp.blackhole=1

С абсолютно аналогично действие като миналата променлива, но тук става въпрос за UDP връзки.

5. net.inet.icmp.icmplim=50

Отново важна опция за защита срещу DoS атаки и също така скенери на портове. Чрез нея задавате лимит на максималния брой ICMP заявки, на които системата ще отговори за една секунда.

6. kern.ipc.somaxconn=16384

Чрез тази променлива се контролира броят на „слушащите“ сокети в системата, които очакват нови TCP заявки. Стандартната настройка е едва 128, което е изключително лесна за запълване дори чрез слаба SYN FLOOD атака. Повечето администратори предпочитат да не слагат повече от 1024. Истината е, че съвременната техника и хардуер нямат проблем да се справят и с много по-големи стойности.

7. kern.ipc.maxsockets = 32768

Чрез тази настройка се контролира максималния брой sockets, които могат да се поддържат отворени едновременно.

8. net.inet.tcp.maxtcptw=8192

Когато TCP връзка премине в TIME_WAIT статус нейният сокет се освобождава и се отваря нова структура, която пази възможно най-минимална информация. Тази структура се нарича „компресиран TCP TIME_WAIT статус“. Понеже големината е значително по-малка от нормалния сокет, то можем да спечелим значително количество памет. Провенливата net.inet.tcp.maxtcptw контролира максималният брой от такива структури, които могат да се инициализират. В общи линии гледаме да е между 4 и 5 пъти по-малка стойност от maxsockets.

9. net.inet.tcp.nolocaltimewait=1

Трябва ли да очакваме връзки от localhost да изпадат в TIMEWAIT статус? По-скоро не.

10. net.inet.ip.portrange.first=1024
net.inet.ip.portrange.last=65535

Тук просто разширяваме полето на възможни изходящи портове от стандартното 49152 – 65535 на доста по-широкия интервал 1024 – 65535.

11. net.inet.ip.portrange.randomized=0

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

12. net.inet.tcp.finwait2_timeout=30000

Контролира максималното време за прекъсване на връзка напълно.

13. net.inet.tcp.fast_finwait2_recycle=1

По подразбиране тази опция също е спряна. Това решава рядък, но много неприятен flood на системата, които може да остави хиляди затворени peers, които не са затворени във FIN_WAIT_2 статус за много дълго време.

14. net.inet.ip.fw.dyn_buckets=4096
net.inet.ip.fw.dyn_syn_lifetime=5
net.inet.ip.fw.dyn_max=16384

Тук се контролират стартовия брой на слотове в хеш таблизата за динамични правила на IPFW, както и максимално допустимият им брой.

15. net.inet.ip.forwarding=0

Искате ли IP Forwarding между интерфейси? Стандартно най-вероятно не.

16. net.inet.icmp.drop_redirect=1
net.inet.icmp.log_redirect=0

По този начин ще забраните всякакви ICMP пренасочвания.

17. net.inet.ip.intr_queue_maxlen=512

Контролира максималната дължина на входната опашка за IP.

18. net.inet.ip.random_id=1

Чрез тази опция правите така, че ID полето на IP пакетите ще бъде с произволна стойност, вместо да се увеличава винаги с 1. На практика това спестява минимално количество изтичане на статистическа информация, тъй като е възможно някой да следи големината на вашия трафик чрез брояча.

19. net.inet.tcp.drop_synfin=1

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

20. net.inet.ip.redirect=0

В стандартна система едва ли ви трябват IP пренасочвания.

21. net.inet.tcp.syncookies=1

Нека да използваме TCP SYN cookies ако „syncache“ се запълни.

22. net.inet.tcp.delayed_ack=0

Delayed ACK означава, че TCP не отговаря моментално с ACK на всеки единичен TCP сегмент. След като се получи самотен TCP сегмент то ще се изчака около 100-150ms с презумцията, че приложението ще даде някакъв отговор. Например в SSH връзка при натискането на клавиш обикновено очакваме да получим в отговор със изписан символ от конзолата. Не бихме искали да изпращаме празни ACK, последвани от TCP пакет с информация веднага след това. Затова забавяме изпращането на ACK с надеждата да ги изпратим заедно. В реални условия се оказва, че това може да е в по-голяма вреда, отколкото полза. Доказани са редица възможни проблеми, затова се препоръчва да се изключи.

23. net.inet.udp.maxdgram=57344
net.inet.udp.recvspace=57344

Максимална големина на изходящ и входящ UDP datagram.

24. kern.ipc.maxsockbuf=2097152,
net.inet.tcp.sendspace=2097152
net.inet.tcp.recvspace=2097152

Дефинират максималната големина в байтове, която може да се задели за изпращащ и приемащ буфер. Първата променлива (maxsockbuf) може да се приеме като глобална лимитираща променлива за другите две.

25. net.inet.ip.rtexpire=3

Стандартно време за „забравяне“ на динамично маршрути.

26. net.inet.ip.rtminexpire=2

Минимално време за задържане на в динамични маршрути.

27. net.inet.ip.rtmaxcache=256

Максимален лимит за брой динамични маршрути.

28. net.inet.icmp.maskrepl=0

Забрана за отговаряне на ICMP Mask заявки.

29. net.icmp.bmcastecho=0

Това ни защитава от т.нар. SMURF атаки. Тези атаки изпращат ICMP пакети до broadcast адрес от spoofed IP адрес.

30. net.inet.tcp.icmp_may_rst=0

Така ще игнорираме всички ICMP пакети, които са генерирани от филтриране на gateway/router между вас и крайната точка. Това е някаква минимална защита от атака с „човек в средата“, където рутер на атакуващия може да блокира избирателно изходящи пакети от вашата машина. Също така това може потенциално да доведе и до DoS атака.

31. kern.ipc.nmbclusters=32768

NMBClusters указва в ядрото какво количество буфери са налични за системата. Такова увеличение се използва само за силно натоварени системи. Всеки клъстер е около 2KB памет, т.е. тази стойност отнема 64MB оперативна памет от системата. Такава стойност е подходяща за сървъри обслужващи около 1000 едновременни връзки.

32. kern.maxfiles=65536

Тази променлива контролира колко е максималният брой файлове, които могат да бъдат отворени едновременно в системата.
П.С. Никога не се пробвайте да го сложите „unlimited“. Резултатът е, че всъщност ще станат 0 и системата ще блокира напълно.

33. net.inet.ip.sourceroute=0
net.inet.ip.accept_sourceroute=0

Забранява използването и приемането на „source routed IP packets“.

Надявам се, че с тези настройки ще бъда полезен. Не гарантирам, че те са оптимални. Препоръчвам ги за наистина натоварени сървъри и такива, които често страдат от DoS атаки. Също така се предполага, че се използва модерен хардуер и поне 2GB RAM.

Първото и основно правило за защита срещу brute force атаки е да използваме колкото се може по-сложни пароли. Обикновено тези атаки изпробват набор от речникови думи, имена и понякога цифри. Освен това, независимо колко сложна е вашата парола, не е добра идея да я използвате за всички сайтове, на които влизате (най-малкото администратора на чуждият уеб сайт ще може да проникне във вашия личен).

Независимо колко стриктна и добра политика използваме за паролите ние не бихме искали да позволим някой да изпробва стотици комбинации от имена и пароли върху вашата система. Най-малкото не сме сигурни дали някой от нашите потребители не използва лесна за разгадаване парола – например името си в комбинация с годината на раждане: „Иван1978″. Една целенасочена атака срещу този потребител би изпробвала различни комбинации от данни, които са свързани с потребителя Иван. Паролата от своя страна изглежда сигурна (съдържа и думи и цифри) и би преминала вашия валидатор. Поради тази причина е наложително да се защитите, като едновременно с това не затруднявате потребителя излишно.

1. Captcha: вече разгледахме използването на Captcha за целта за спиране на автоматизирани brute force атаки. Това е може би най-ефективният разработен досега метод за справяне с проблема на автоматизирани атаки. За съжаление този подход определено затруднява потребителите, като отнема допълнително време при всяко влизане в системата. Captcha е подходяща за защита на форми, които се попълват еднократно (например форми за регистрация). Когато става дума за форми за автентикация, които се попълват ежедневно, то въпросът е спорен. Всичко зависи от това до колко конфиденциална информация пазите и дали си заслужава да затруднявате потребителя с попълването на форма с captcha всеки път. Освен това captcha не решава друг проблем – не е казано, че една brute force атака трябва да е автоматизирана. Не е изключено човек ръчно да изпробва различни комбинации от имена и пароли. Все пак не говорим за ограничения във времето…

2. Блокиране на IP след определен брой неуспешни опита за влизане: можете да си съставите база от данни със списък от IP адреси, които са направили неуспешен опит за влизане в системата. За всеки IP адрес трябва да се пази и втора колона със брой неуспешни опити за достъп. По този начин, преди да извършите проверка за автентикация на данните, може да проверите дали текущото IP не е „прекалило“ с грешните опити за вход в системата и ако това е така – да го пренасочите към друга страница, която му предоставя информация как да си поиска от вас загубената парола. В зависимост от типа потребители на вашата система можете да блокирате не само отделни IP адреси, но и цели зони (IP range). При успешно автентикиране в системата от даден IP адрес, неговите записи в базата от данни за неуспешни влизания трябва да бъдат изтрити, за да се избегне натрупване на случайни грешки през големи интервали от време. Чрез метода за блокиране на IP се справяте не само с автоматизираните атаки, но и с атаките извършвани от човек. Честа практика (с цел редуциране на заявките за отблокиране на IP адреси към екипа за техническа поддръжка) е да не блокирате потребителите перманентно, а само за определено време (например един час). Така обаче защитата само „отлага“ атаката, а не я предотвратява.

3. Лимит на максималния брой заявки към сървъра чрез защитна стена: един IP адрес би могъл да изпрати множество заявки за автентикация към сървъра едновременно. По този начин ние все още няма да имаме запис за това IP и бихме могли да позволим на заявките да преминат „бариерата“ от предишната точка. Обикновено не е разумно да натоварвате самото приложение със следене на броя заявки към него. Добре е да сложите такъв лимит на вашия http сървър и на вашата защитна стена (firewall). Например за iptables може да използвате модула „connlimit“.

4. Лимит на максималния брой заявки към сървъра чрез приложението: ако все пак искате да се подсигурите и да предотвратите напълно едновременно подадените заявки за автентикация, то може да организирате приложение от тип „опашка за автентикация“. Всяка заявка за автентикиране се вкарва в структура от данни тип FIFO (first in – first out) и така сме сигурни, че никога няма да бъдат изпълнени няколко едновременни заявки към базата от данни. Този метод обаче трябва да се използва изключително внимателно и изисква сериозна оптимизация с цел бързодействие. Добре е да се погрижите да има равностойно бързодействие на базата от данни спрямо http сървъра. В противен случай рискувате да получите претрупване на опашката и много клиенти да получават timeout. Затова е добре в http сървъра да пазите cache от познати „лоши“ IPта и да не им позволявате да влизат в опашката за автентикация повторно. Периодично трябва да филтрирате сървъра чрез защитната стена от подобни IP адреси, които правят постоянни заявки. Това ще бъде разгледано в темата за DDoS атаки. При мултипроцесорни сървъри (каквито са почти всички нови компютри в днешно време) е добре да се възползвате от използването на нишки за съставянето на няколко опашки за автентикация (в зависимост от броя процесори на сървъра за базата от данни). Не е разумно да се лишавате напълно от бързодействието и функционалностите на сървъра си само и единствено с цел защита. Ползата от „опашка за автентикация“ по принцип е спорна и в повечето случаи се оказва излишна.

5. Политика за блокиране на акаунти: става дума за атаки от т.нар. „bot nets“. Това са мрежи от различни IP адреси, които атакуват сървъра. Често това са инфектирани с вирус компютри на нищо неподозиращи потребители в Интернет. Мащабът на такава мрежа може да бъде огромен. Също така не е задължително те да атакуват по едно и също време  (което всъщност би причинило по-скоро DDoS атака), а през кратки интервали. Тук тактиката с блокиране на отделно IP след неуспешен брой опити за вход би била неуспешна, защото всяко едно IP от атакуващата мрежа само за себе си има определен брой опити. Ако например сме сложили лимит от 5 неуспешни опита за IP адрес, то една мрежа от 1000 IPта би имала 5000 опита. Когато те атакуват определен акаунт (администраторския или на някой определен потребител), то би трябвало да се почувстваме застрашени, защото ще изпробват прекалено много различни комбинации от възможности (тъй като това е „targeted“ атака, то атакуващите обикновено са разузнали за определена информация за дадения потребиел). За да се защитим от такава атака е добре да пазим допълнително поле в базата от данни, в която се съхраняват имената и паролите. Това поле трябва да съдържа общия брой неуспешни опити за влизане към дадения акаунт. Когато се извършва автентикацията е нужно да се провери този запис и ако броя опити за пробив е голям, то е добре да се направи т.нар. „заключване на потребителския акаунт“ (account lockdown). Системата няма да позволи достъп до такъв потребителски акаунт, докато администратор не „отключи“ акаунта. По този начин можете да съставите списък от атакувани акаунти и да се погрижите техните пароли да са достатъчно сигурни или да търсите индивидуално решение на тяхната защита.

6. Фиксиране на акаунт по IP адрес: в случай на зачестили атаки към определен акаунт може да въведете функционалност за стриктно следене на IP адреса, от който влиза. Това е честа практика при администраторските акаунти.

Задача: Реализирайте описаните практики на някой език за web програмиране. Помислете за допълнителни варианти за защита.

- Защитава форми, които попълват информация в база от данни от автоматични скриптове, които запълват базата от данни с невалидни данни.

- Не позволява на компютър да изпробва произволни комбинации от имена и пароли и по този начин защитава потребителските акаунти.

Изпълнението на модула за защита преминава през няколко етапа:

а) Генериране на произволен код, обикновено съставен от букви и цифри;

б) Записване на генерирания код в потребителската сесия;

в) Използвайки модул за генериране на графични изображения (например в PHP това е GD2) се създава картинка, на която се изобразява генерирания код. Обикновено се добавя „шум“ (distortion), чрез който затрудняваме автоматизираното разпознаване на кода от машина. Обикновено е добре да се изобразяват букви с различни шрифтове, като самите те се завъртат под произволен (в дадени граници) ъгъл. Размерите на самата картинка и големината на буквите също могат да варират в даден интервал. Крайната цел е да се затруднят компютърните алгоритми за разпознаване на изображения, но до такава степен, че да не затрудняват истинския потребител прекалено много;

г) Картинката се отпечатва на екрана на потребителя до формата, която ще бъде попълвана. В самата форма се слага допълнително текстово поле, в което потребителя трябва да въведе кода от картинката за валидация;

д) Кода от формата, заедно с останалите данни, се изпращат чрез метода POST и системата сравнява стойноста на кода въведен във формата с този, записан в потребителската сесия. Ако двете стойности съвпадат, то приемаме, че заявката е попълнена от човек, а не машина.

Въвеждането на CAPTCHA е първата важна стъпка за предпазване на формите от brute force атаки. Ето няколко лоши практики, които не трябва да се използват:

- Използване на предварително зададени комбинации от кодове. Учудващо е, че все още се срещат форми, които са „защитени“ чрез предварително генерирана серия от картинки и записана комбинация от техните кодове. Това действително пести системни ресурси (генерирането на изображение е тежка операция), но в никакъв случай не може да бъде разглеждано дори като значима защита. Атакуващият може да си изгради собствена база от данни, в която да записва името на подадена картинка със съответващия й код – до пълно изчерпване;

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

- Използването на двусмислени символи ще обърка потребителите. Избягвайте да използвате буквата „O“, защото тя може да бъде объркана с „0″. Същото важи за „l“, „I“ и „1″.

Ето едно изображение, на което са демонстрирани различни Captcha варианти:

Варианти на Captcha

Друг често използван подход е да се зададе проста задача на потребителя - например „колко е две плюс три“ или „напишете фамилното име на Петър Иванов“. За съжаление тук ще се нуждаем от значително количество въпроси в базата от данни, а това ще е трудна задача (те трябва да са прости, защото едва ли можем да очакваме всеки потребител да може да решава интеграли). Съществуват и редица изключително интересни варианти, като например puzz captcha.

При Captcha основният проблем е фактът, че колкото по-добра е защитата, толкова по-трудно е за крайният потребител.

Нека разгледаме няколко примера:

1. Нека разгледаме следният елементарен уебсайт:

index.php:

<?php
	if (isset($_GET['page'])){
		if ($handle = @fopen($_GET['page'], "r")){
			while (!feof($handle)) {
				$line = fgets($handle);
				echo $line;
			}
			fclose($handle);
			return;
		}
		else{
			echo '404 Not Found';
			return;
		}
	}
?>
<html>
<head>
	<title>WorldBank.dom code injection page</title>
</head>
<body>
	This is the index page.<br><br>
	1. <a href="index.php?page=products.html">products</a><br>
	2. <a href="index.php?page=contacts.html">contact us</a>
</body>
</html>

products.html:

<html>
<head>
	<title>WorldBank.dom products page</title>
</head>
<body>
	Hello, this is the products page!
</html>

contacts.html:

<html>
<head>
	<title>WorldBank.dom contact page</title>
</head>
<body>
	Hello, this is the contacts page!
</html>

На пръв поглед резултатите са задоволителни – ако отворите „http://worldbank.dom/index.php“ ще се отвори страницата с двете хипер връзки. Ако отворите „http://worldbank.dom/index.php?page=products.html“ ще се отпечата страницата с продуктите, а като отворите „http://worldbank.dom/index.php?page=contacts.html“ ще се отвори страницата за контакти. Ако пък отворим несъществуващ файл, то ще се изведе „404 Not Found“.

Функцията fopen обаче има функционалност, която позволява отварянето на външни ресурси. Опитайте да отворите „http://worldbank.dom/index.php?page=http://cphpvb.net“ – с изненада ще видите, че ще се зареди информация от сайта, който четете в момента. Очевидно това е опасен източник за XSS атака, тъй като атакуващият може да зареди информация директно от трети източник.

Първото решение на проблема е да забраним allow_url_fopen в конфигурационният файл php.ini:

	allow_url_fopen = on

Вторият важен момент е премахването на “лошите символи“ от съдържанието на променливата:

<?php
	if (isset($_GET['page'])){
		$badChars=array("/","\\","\"",";");
		$page=str_replace($badChars,"",$_GET['page']);
		if ($handle = @fopen($page, "r")){
			while (!feof($handle)) {
				$line = fgets($handle);
				echo $line;
			}
			fclose($handle);
			return;
		}
		else{
			echo '404 Not Found';
			return;
		}
	}
?>
...

Това не е правилен подход! Вече сме споменавали, че премахването на „лошите символи“ не е правилен вариант за защита. По-добрият подход е за следене за валиден формат:

<?php
	if (isset($_GET['page'])){
		if (preg_match('/(\w+)\.html$/', $_GET['page'])){
			$page=$_GET['page'];
		}
		else{
			$page = '404.html;
		}
		if ($handle = @fopen($page, "r")){
			while (!feof($handle)) {
				$line = fgets($handle);
				echo $line;
			}
			fclose($handle);
			return;
		}
		else{
			echo '404 Not Found';
			return;
		}
	}
?>
...

Накрая бихме предпочели да не рискуваме въобще с отварянето на файлове от външни източници. За целта може да използваме функцията file_exists($file), която проверява дали локален файл съществува или не:

<?php
	if (isset($_GET['page'])){
		if (preg_match('/(\w+)\.html$/', $_GET['page'])){
			$page=$_GET['page'];
		}
		else{
			$page = '404.html;
		}
		if (file_exists($page)){
			$handle = @fopen($page, "r");
			while (!feof($handle)) {
				$line = fgets($handle);
				echo $line;
			}
			fclose($handle);
			return;
		}
		else{
			echo '404 Not Found';
			return;
		}
	}
?>
...

Неразумното използване на fopen() води до нежелани XSS атаки. Показаната система е валидна само ако файловете, които добавяме са в чист HTML формат. В много случаи се налага да използваме „include“ за добавяне на php код от други страници. Там проблемът вече се прехвърля от XSS атака към възможност за уязвимост на самия сървър! Представете си следният код:

<?php
	if (isset($_GET['page'])){
		// Никога не правете това!!!
		include $_GET['page'];
	}
?>

Резултатът на горният код може да бъде унищожителен за вашето приложение. Имайте в предвид, че съществува конфигурационен параметър „allow_url_include“, който позволява добавянето на файлове от външни източници. Отново, както в по-горният пример, би трябвало да се погрижим да отваряме само локални файлове:

<?php
	if (isset($_GET['page'])){
		if (file_exists($_GET['page'])){
			include $_GET['page'];
			return;
		}
		else{
			echo '404 Not Found';
			return;
		}
	}
?>

Чрез този пример имаме възможност за „вмъкване“ на PHP код.

Трябва да споменем обаче, че представената защита (забрана на външни файлове) в никакъв случай не решава всички проблеми. Дали само „вмъкването“ на външни файлове води до проблеми? Дали не съществуват и локални файлове, до които ние не бихме искали да позволяваме достъп?

Във всички примери дотук ние можем да добавяме който и да е файл в текущата директория (напр. topsecretfile.txt, config.php, и др.), дори когато „public“ правата за четене и запис до него са забранени. Дори да няма такива конфиденциални данни в текущата директория – опитайте се да отворите „http://worldbank.dom/index.php?page=index.php“. Ще се получи изключително неприятен безкраен цикъл. В допълнение – от последния пример можем да добавим не само файлове в текущата директория, а който и да е файл от локалната система, до който php процесът има права (напр. при лошо организирани права за достъп можем да прочетем и файлове от други директории, чрез пълния път до тях: /home/worldbank.dom/www/.passwd и т.н.).

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

1. Сигурно добавяне на HTML код с fopen:

<?php
	if (isset($_GET['page'])){
		$pages=array("products.html", "contacts.html");
		if (in_array($_GET['page'], $pages)){
			if (file_exists($_GET['page'])){
				$handle = @fopen($_GET['page'], "r");
				while (!feof($handle)) {
					$line = fgets($handle);
					echo $line;
				}
				fclose($handle);
				return;
			}
			else{
				echo 'File is missing<br>';
				echo 'Please contact the admin';
				return;
			}
		}
		else{
			echo '404 Not Found';
			return;
		}
	}
?>
...

2. Сигурно добавяне на PHP код с include:

<?php
	if (isset($_GET['page'])){
		$pages=array("products.php", "contacts.php");
		if (in_array($_GET['page'], $pages)){
			if (file_exists($_GET['page'])){
				include $_GET['page'];
				return;
			}
			else{
				echo 'File is missing<br>';
				echo 'Please contact the admin';
				return;
			}
		}
		else{
			echo '404 Not Found';
			return;
		}
	}
?>
...

Чрез демонстрирания метод можем да сме уверени, че могат да бъдат добавени само локални файлове и то единствено тези, които са указани в масива $pages.

Видяхме, че атаките за вмъкване на нежелан код са значително по-комплексни отколото си представяхме. Филтрирането на входните данни не винаги е достатъчна защита. Винаги се стремете да създавате колкото се може по-рестриктивен режим на работа.

Трябва да отбележим, че описаното в статията е изключително честа практика при програмирането на PHP, а именно – когато правите заявка от един скрипт към самия него, то програмистите използват за улеснение $_SERVER['PHP_SELF']. Тази environment променлива записва текущия локален път към скрипта. Следните форми могат да бъдат видяни в изключително много PHP приложения:

	echo '<form action="'.$_SERVER['PHP_SELF'].'">';

Както вече е описано в статията по-горе, този код е уязвим от потенциална XSS атака, като просто се добавят кавички, затваряща ъглова скоба и последващ html код или javascript чрез URL (от примера в сайта „/%22%3E%3Cscript%3Ealert(‘xss’)%3C/script%3E%3Cfoo“).

За превенция на подобни уязвимости ще повторим вече казани принципи:

1. Не използвайте GET за попълване на форми;

2. Защитавайте формите от XSRF;

3. Не вярвайте на environment променливите;

4. Третирайте environment променливи и ги филтрирайте по същия начин, както обикновените променливи.

Задача: Потърсете open source приложения, написани на PHP, които използват несигурно PHP_SELF.

Както се вижда от видеото Forced Browsing включва в себе си и един друг елемент – сканиране на приложението. Това е изключително труден за предотвратяване проблем. В никакъв случай не разчитайте на това, че атакуващия няма да влезе във вашия административен панел, понеже не знае адреса му!

При създаване на система с привилегии използвайте следните препоръки:

1. Винаги правете проверката на страната на сървъра и не разчитайте на клиента да се „самоавторизира“.

2. При преминаване между страници, изискващи различни права на достъп, винаги изисквайте допълнителна автентикация. Не разчитайте на предварително инициализираната сесия (тя може да е фиксирана или открадната).

3. Избягвайте използването на GET заявки, когато става дума за важна информация. Те са значително по-лесни за атака със скенери.

4. Не използвайте тривиални имена на важните файлове и раздели в системата (config.php, /admin, /logs, /system, …). Затруднете атакуващият колкото се може повече.

5. Въведете защити срещу brute force атаки, като блокирате атакуващите след определен брой заявки. Ще разгледаме такива техники при изследването на един по-тежък проблем – Denial Of Service атаките.

Ясно е, че когато използваме комерсиални приложения, то сканирането не е проблем с който трябва да се борим, защото атакуващият най-вероятно е запознат в детайли със самото приложение още преди да предприеме атака. При системи с отворен код обаче си заслужава поне да промените имената на важни директории, файлове и пътища. По този начин не решавате проблемите (дупките в сигурността остават отворени), но поне ще изолирате системата си от най-елементарните автоматизирани атаки.

Като един от най-големите осъществени пробиви ще споменем, че почти 18 милиона потребители са загубили лична информация през февруари 2008 от пробив в корейският eBay (информация от webappsec.org).

Остава въпросът – дали ако се защитим от всички XSS атаки, то ще бъдем защитени и от XRSF атаки? Не бихме се обвързали с потвърдителен отговор на този въпрос. Сега обаче ще демонстрираме един метод за защита на форми, чрез който можем ефективно да предотвратяваме XSRF атаки. Нека разгледаме следната примерна форма:

<html>
<head>
	<title>WorldBank.dom XSRF vulnerable page</title>
</head>
<body>
<?php
	if( isset($_REQUEST['submit'])){
		echo 'Form is submitted';
	}
	else {
		echo '<form action="xsrf.php" method="POST">';
		echo '<input type="submit" name="submit">';
		echo '</form><br><br><br>';
	}
?>
</body>
</html>

Предполагаме, че този пример няма нужда от разяснения. Нека приемем, че той е качен на адрес worldbank.dom/xss.php. Когато отворите адреса в браузера и натиснете бутона, то ще се изпълни кода показващ „Form is submitted“ на екрана.

HTML формите обаче имат едно свойство, че не проверяват източника на подаване на информацията. Направете следния опит – напишете следния html файл и го изпълнете от собствения си компютър:

<html>
<head>
	<title>XSS attacker</title>
</head>
<body>
	<form action="http://worldbank.dom/xsrf.php" method="POST">
	<input type="submit" name="submit">
	</form><br><br><br>
</body>
</html>

Пуснете файла на личния си компютър и натиснете бутона. Ще изпратите POST информацията към worldbank.dom сървъра и ще попълните формата. Това очевидно не би трябвало да се случва – проверката на формата на сървъра би трябвало да очаква информацията към нея да бъде попълнена от сигурен източник. Как може да се уверим, че информацията е изпратена от самата форма?

Може би най-ефективният вариант е чрез използване на потребителска сесия. Като скрито поле вътре във формата трябва да запишем произволно генерирано число. Това число се записва и в потребителската сесия . Когато скрипта получи заявка, той трябва да сравни числото предадено чрез $_POST и да го сравни с това, записано в $_SESSION. Ето как бихме реализирали това с горния скрипт:

<?php
	function security_start_session($ssl, $timeout, $maxtime, $ip){
		// ... security checks
		session_start();
		session_regenerate_id(true);
		return 1;
	}
	if (security_start_session(0, 6*60, 20*60, 1) != 1){
		echo "<br>session destroyed!";
		return;
	}
?>
<html>
<head>
	<title>WorldBank.dom XSRF protected page</title>
</head>
<body>
<?php
	if( isset($_REQUEST['submit'])){
		if ($_SESSION['token']!=$_POST['token'] || !isset($_SESSION['token']) || !isset($_POST['token'])){
			session_unset();
			session_destroy();
			echo "Invalid session</body></html>";
			return;
		}
		else{
			echo 'Form is submitted';
		}
	}
	else{
		echo '<form action="xsrf.php" method="POST">';
		$_SESSION['token'] = uniqid(rand(), true);
		echo '<input type="hidden" name="token" value="'.$_SESSION['token'].'">';
		echo '<input type="submit" name="submit">';
		echo '</form><br><br><br>';
	}
?>
</body></html>

Тук обезателно се налага стартирането на потребителска сесия (което тъй или иначе се прави в повечето случаи). Обърнете внимание на удебелените линии, където се генерира случайният token. Чрез него сме сигурни, че формата е попълнена именно от нашият сървър.

Другият често използван подход е проверката на „HTTP referer“. За PHP това става чрез environment променливата, записана като „$_SERVER['HTTP_REFERER']„. В нея се записва информацията откъде е дошла заявката. Вече споменахме, че тези HTTP header променливи не са надежден носител на данни (може да се направи spoof над тях). Въпреки това не можем да пуснем една такава допълнителна защита:

<?php
	function security_start_session($ssl, $timeout, $maxtime, $ip){
		// ... security checks
		session_start();
		session_regenerate_id(true);
		return 1;
	}
	if (security_start_session(0, 6*60, 20*60, 1) != 1){
		echo "<br>session destroyed!";
		return;
	}
?>
<html>
<head>
	<title>WorldBank.dom XSRF protected page</title>
</head>
<body>
<?php
	if( isset($_REQUEST['submit'])){
		if ($_SESSION['token']!=$_POST['token'] || !isset($_SESSION['token']) || !isset($_POST['token'])){
			session_unset();
			session_destroy();
			echo "Invalid session</body></html>";
			return;
		}
		else{
			if (isset($_SERVER['HTTP_REFERER']) && $_SERVER['HTTP_REFERER']!="http://worldbank.dom/xsrf.php"){
				echo 'You are redirected by third party form - probably you are a XSRF attack victim!';
				return;
			}
			else{
				echo 'Form is submitted';
			}
		}
	}
	else{
		echo '<form action="xsrf.php" method="POST">';
		$_SESSION['token'] = uniqid(rand(), true);
		echo '<input type="hidden" name="token" value="'.$_SESSION['token'].'">';
		echo '<input type="submit" name="submit">';
		echo '</form><br><br><br>';
	}
?>
</body></html>

Имайте обаче в предвид, че сравнението по HTTP_REFERER header може да пропадне при някои proxy сървъри или ако клиента има строги настройки на своята защитна стена или антивирусна програма. Поради тази причина би трябвало да използвате тази допълнителна защита само при системи със конфиденциална информация (където едва ли очакваме анонимни потребители).

XSRF е проблем често срещан в приложения, които позволяват на потребителите си да „вмъкват“ външни ресурси в системата. Това е често срещано при форуми, където потребителите могат да избират avatar от външен адрес, да вкарват снимки или видео клипове в своите posts. Проблемът с XSS там се решава лесно, като се забранят HTML символите, а вместо това се разреши единствено BBCode. За XSRF обаче решението не е толкова лесно.

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

XSS атаките са най-общо три вида:
1. Директни: Атакуващият предоставя връзка или друг вид „маскиран“ код към клиента. Когато клиента последва такава връзка той попада на оригиналният уебсайт на дадената услуга, но вече с модифициран от атакуващия код. Възможно е и възползването от уязвимост на софтуера, с който жертвата преглежда подаденото му съобщение, с цел атакуващия да добие достъп до неговата административна част. Директните атаки се реализират най-често чрез изпращане на писма по електронната поща към жертвата или чрез съобщения в различни чат приложения.
2. Статични: Атакуващият успява да вмъкне нежелания код в база данни и само изчаква жертвата сама да отвори уязвимата страница. Това са най-честите атаки при т.нар. социални мрежи – форуми, блогове, дискусионни групи, и т.н.
3. DOM: Това са XSS атаки от т.нар. локално ниво. Обикновено се използва уязвимост в скрипт на продукта, чрез който самият софтуер да предизвика директна XSS атака към жертвата.

Почти няма приложение в Интернет, което да няма или да не е имало XSS уязвимост. В днешно време, с навлизането на все повече технологии като Action Script на Flash или AJAX скриптовете, XSS атаките все повече добиват популярност. На практика всички тези проблеми се зараждат в момента, когато сървърите придобиват функционалност за директно изпълнение на код при клиента (напр. JavaScript).

Нека като пример да разгледаме следната елементарна форма:

<html>
<head>
	<title>WorldBank.dom XSS vulnerable page</title>
</head>
<body>
<?php
	echo '<form action="xss.php" method="POST">';
	echo 'data:';
	echo '<input type="text" name="data">';
	echo '<br><input type="submit" name="submit">';
	echo '</form><br><br><br>';
	if( isset($_REQUEST['submit'])){
		echo $_REQUEST['data'];
	}
	else {
		echo 'Type something';
	}
?>
</body>
</html>

Удебеленият ред „echo $_REQUEST['data']“ демонстрира XSS уязвимост. Очевидно ние отпечатваме на екрана директно всичко, което е въведено от формата, без да правим никакви проверки. Въведете обикновен текст (например думата „test“) и тествайте приложението. Нищо не подсказва, че има проблем. Следващият път въведете някакъв изпълним код, например:

	test<Script language='JavaScript'>alert("XSS HACK")</Script>

Отново ще се отпечата думата „test“, но вече ще имаме и изпълнен java script, което определено не е желано!

Първото нещо, което привлича вниманието (но не е непременно свързано с XSS атака), е използването на $_REQUEST, вместо $_POST. Много програмисти обичат да смесват използването на POST с GET заявки и за улеснение използват общият $_REQUEST масив. Това е първа и много основна грешка, която не трябва да се допуска! Опитайте се да отворите следния адрес:

	http://worldbank.dom/xss.php?data=test&submit=1

Ще забележите, че все едно сме въвели текст във формата, а ние все още не сме го направили. Затова избягвайте програмна логика, използваща $_REQUEST.

Сега да се фокусираме върху самата XSS атака. Първата стъпка е да забраним извеждането на какъвто и да е HTML код на екрана на потребителя. Първият подход е да използваме готови функции на езиците за програмиране. Например в PHP съществува функция htmlentities, която подменя всички специални HTML символи с техни еквиваленти за отпечатване на екрана (например ‘<’ се заменя с ‘&lt;’):

<html>
<head>
	<title>WorldBank.dom XSS vulnerable page</title>
</head>
<body>
<?php
	echo '<form action="xss.php" method="POST">';
	echo 'data:';
	echo '<input type="text" name="data">';
	echo '<br><input type="submit" name="submit"';
	echo '</form><br><br><br>';
	if( isset($_POST['submit'])){
		$data = htmlentities($_POST['data'], ENT_QUOTES, 'UTF-8');
		echo $data;
	}
	else {
		echo 'Type something';
	}
?>
</body>
</html>

Опитайте отново XSS атаката описана по-горе. Ще забележите, че тя няма вече да работи.

Вторият подход е да направим стриктно филтриране, както беше демонстрирано с regular expressions в статията за препълване на буфери. Опитайте – напишете горния пример така, че да позволява въвеждането само на букви (a-z, A-Z) и цифри. Комбиниран подход между тези два естествено е най-правилното решение!

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

Предлагаме ви да разгледате и следните анимации, в които се демонстрират различни видове рискове от XSS атаки:
xss демонстрация 1 – крадене на cookie на друг потребител чрез статична атака.
xss демонстрация 2 – придобиване на административна информация от сървъра чрез статична атака.

Видяхме, че XSS атаките използват уязвимост в приложението, което цели да компрометира потребителя. В следващата статия ще разгледаме подобен подход с обратно действие – Cross Site Request Forgery (XSRF).

1. История: SSL започва своето развитие с версия 1.0, разработена от Netscape през 1993. Тя никога не излиза за публичен достъп, тъй като още в процеса на разработка са открити множество пробиви в сигурността.

През 1994г. се появява втората версия SSL 2.0. За нещастие много бързо са открити редица пробиви в сигурността, като:
- Слаби кодове за автентикация;
- Методи за насочване на двете страни да използват по-слаб алгоритъм за криптиране;
- Липса на защита по време на „договарянето“;
- Множество други атаки.

През 1995г. Microsoft правят опит за внедряване на тяхна алтернатива – PCT. Не придобива широка популярност, но все още съществува като стандарт.

През 1996г. отново Netscape изваждат най-популярният и най-широко използван досега стандарт SSL 3.0. В момента почти всички уеб сървъри, подържащи https криптиран канал за комуникация, поддържат SSL 3.0.

През 1999г. излиза TLS (Transport Layer Security) – още известен като SSL 3.1. Това всъщност е обединение на SSL и PCT (тоест може да работи и с двата стандарта). Този протокол добавя и подобрения в сигурността над SSL 3.0, но те засега са само препоръчителни, тъй като TLS е напълно съвместим със „стари“ клиенти, използващи SSL 3.0.

2. Принцип на действие: Вече обяснихме проблема с подслушването на трафик. Всяка една мрежа е застрашена от злонамерени хора, целящи да откраднат информация. И така – как SSL решава този проблем?

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

За нещастие самият процес на криптиране не е единствения проблем, с който се сблъскваме в реално време. Чрез криптография ние наистина сме изолирали подслушващите трафика, но не сме решили проблема с „подменящите“ трафика (т.е. когато стои „човек по средата“ на комуникацията – пред клиента се представя за сървър, а пред сървъра за клиент). Тези атаки биха били успешни, ако няма начин за удостоверяване на автентичността на сертификата (атакуващият просто предава своя публичен ключ и на двете страни и използва своя частен за дешифриране на целия трафик):

Клиент <—> Атакуващ <—> Сървър

Очевидна е нуждата от удостоверение за автентичност на сертификат. За щастие SSL се справя с този проблем, като в сертификата се записва и ключа на т.нар. „CA“ (съкратено от Certificate Authority). Всеки сертификат се издава за даден уебсайт (на строго определен статичен IP адрес) от някоя трета страна, наречена CA. В публичният интернет това са организации като Verisign, Comodo, Geotrust, Globalsign и др. При локални мрежи това може да е централният сървър или компютъра на системия администратор. CA одобрява сертификатът на сървъра, като специално указват за кой hostname е издаден. Ето например сертификата на Google:

SSL Сертификат на Google

Ако сървър се опита да предложи сертификат, който не е с одобрен hostname то ще бъде изведена грешка в браузъра на клиента. Още повече – дори ако легитимния сървър смени своя IP адрес, то отново сертификатът ще стане невалиден. Валидацията по хост и IP при CA се счита за достатъчно добра защита. Както казахме при използване на „невалиден“ сертификат в браузъра на клиента излиза съобщение за грешка. Той обаче все пак има възможност да продължи на своя отговорност. Ето един пример:

Използва чужд сертификат

Публичните сертификати от Verisign, Comodo, и т.н. сравнително скъпа услуга. Обикновено малките уеб сайтове, предлагащи безплатни услуги (както например моят cphpvb.net) не могат да си позволят закупуването на такъв сертификат (света все пак се върти от бизнеса). Браузъра на клиента ще приеме за валиден само сертификат, който е верифициран от един от т.нар. root сертификати (тези на големите CA). Ако ние сами издадем сертификат за себе си (например чрез втори наш сайт, който да се яви като CA), ще е нужно да накараме всичките си клиенти да вкарат нашия CA сертификат като „trusted“ в своя браузър. В Интернет среда това е нереалистично. За локалните мрежи обаче това е честа практика – както споменахме просто една от машините в мрежата става CA и чрез нейният сертификат се валидира криптираната информация в мрежата. Използвайки domain controller можем лесно да накараме клиентите да приемат нашия сертификат за един от т.нар. „root“ сертификати.

3. Проблеми с SSL:

а) Понижаването на версия: Преди няколко години беше често явление сървъра да поддържа едновременно SSL 3.0 и SSL 2.0, с цел да донесе обратна съвместимост с по-стари браузъри. Това веднага можем да приемем като пробив в сигурността, тъй като атакуващият може да накара двете страни да се „споразумеят“ да използват по-старата версия. След това, подслушвайки трафика им, той ще може да използва уязвимостите в по-стария протокол.

б) Отново с цел обратна съвместимост се срещат сървъри, които поддържат слабо криптиране (56 или по-малко битове). Такова криптиране с днешната техника може да бъде дешифрирано с brute force атака за няколко дни. При използването на 128 или по-високо ниво можем все още да се чувстваме сравнително спокойни.

в) Използването на ненадеждни hash алгоритми е един също възможен проблем. Тъй като md5 и ssh1 са достатъчно популярни стандарти, вие можете да изключите всички по-малко надеждни алгоритми за вашия сървър.

г) Пренасочване към некриптиран канал, ако „споразумението“ между страните пропадне – това е най-често срещания проблем, който на практика обезсмисля всякаква защита. Ако една услуга трябва да бъде криптирана, то никога не я пускайте през некриптиран канал!

д) Всеки сертификат има срок на валидност. По предтекст, че има минимален период от време за който можем да приемем, че една brute force атака би намерила нашия частен ключ, големите CA ни взимат парите за подновяване на двойката публичен/частен ключ. Това всъщност е един доста реален аргумент – би било хубаво да подменяме сертификатите си колкото се може по-често. Изтеклите сертификати довеждат до съобщения за грешки, много подобни на тези на напълно невалидните сертификати. По този начин клиентите започват да свикват с тях и няма да обърнат внимание ако съобщението за грешка се смени (атакуващият е застанал по средата). Подновявайте сертификатите си!

е) Уязвимост при машината на клиента може да доведе до презаписване на неговия публичен/частен ключ или добавянето на невалиден root CA в браузъра му. Тук протокола SSL е безсилен, а и не би трябвало да му влиза в работата да следи за чужди грешки.

ж) Вече споменахме за проблемите при прехвърляне на session ID през некриптиран канал. Надяваме се, че ги помните. SSL няма да ви помогне при наличие на session fixation или session hijacking.

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

й) Възможно е използването на статистически методи за намиране на често срещани думи при прехвърлянето на информация. Такъв е например низа „GET / HTTP/1.0″, предаван от клиент към сървър. Очевидно е, че той ще бъде прехвърлян всеки път криптиран по един и същи начин. Прихващайки тази информация атакуващият е улеснен в опитите си с brute force атака, тъй като вече знае какъв резултат трябва да очаква при дешифриране на дадения низ. Засега SSL и TLS не решават този проблем.

В разгледаният вариант за комуникация може би сте забелязали, че само една от страните на комуникацията е защитена от CA – това е сървърът. При тази комуникация сертификатът на клиента не се автентикира за достоверност. Възможна е естествено и комуникация между две валидиращи се взаимно страни (обикновено това е комуникация между два сървъра).

4. Процедура за регистриране на SSL сертификат:

За да регистрирате SSL сертификат е нужно първо да генерирате CSR (certificate signing request). Той включва следните данни:
- Common Name: hostname, за който искате сертификат;
- Organisation: име на вашата фирма (сертификатите се предполага, че се използва от фирми);
- Organisation Unit: отдел на вашата фирма, например „support“, „marketing“, …;
- City: град, в който е регистрирана вашата фирма;
- Region: щат или област, в която е регистрирана фирмата;
- Country: държава;
- E-mail: адрес за връзка с вашата фирма.

Самият CSR се изпраща в криптиран вид към CA. Допълнително трябва да представите и информация за типа на вашия сървър, например apache mod_ssl, openssl, internet information server, и т.н. В замяна вие ще получите три файла – ca.crt, domain.crt и domain.key. Двата crt файла са съответно публичния ключ на CA и вашият собствен публичен ключ. Файлът завършващ с разширение key е вашият частен ключ (който трябва да бъде пазен със всички възможни средства). Следвайте инструкциите на сървъра, който използвате за да настроите вашия SSL сертификат.

5. Passphrase:

Passphrase е нещо като парола, защитаваща вашия частен ключ, така че той да не може да бъде използван ако бъде откраднат (eдин вид криптиране на частния ключ). Ползата от използването на passphrase е спорна, защото повечето хора приемат, че ако някой успее да пробие вашата система дотам, че да открадне частния ключ, то той би имал достъп и до процеса на web сървъра. Тъй като web сървъра трябва да „знае“ passphrase, тъй като той използва частния ключ, то атакуващия тъй или иначе има достъп до желаната информация. Въпреки това считаме, че passphrase е ценно допълнение към защитата на системата. За съжаление има един голям недостатък, поради който почти никъде не е добил популярност – при всяко стартиране/рестартиране на сървъра вие трябва да въвеждате тази парола. Затова passphrase се използва само със системи, които са под постоянно наблюдение.

Задача: Националният осигурителен институт към момента (Декември 2008) не криптира данните при проверка на здравно осигурителен статус по ЕГН (healthinsurance.nssi.bg). Потърсете други представителни български институции, при които се предава конфиденциална информация и е възможно подслушването на трафик.