Икономически университет - Варна

ЦЕНТЪР „МАГИСТЪРСКО ОБУЧЕНИЕ”

Катедра „Информатика”

РЕФЕРАТпо

Безопасност и защита

на тема

Разработил: Проверил:...................

Биляна Иванова Александрова /доц.д-р. Стефан Дражев/

спец. Информатика,5 курс,

59 гр. ф.н 10640

26

Съдържание

Въведение...................................................................................................................3

1. WеЬ-приложения....................................................................................................4

1.1.Що е то WеЬ-приложение?..................................................................................4

1.2. Предимства на WеЬ-приложенията...................................................................4

1.3. Пприложение на WеЬ-приложенията в бизнеса...............................................5

2.Безопасност и защита на web-приложенията.......................................................6

2.1.Подходи за анализ на защитеността на уеб приложенията............................6

2.1.1.Инструментален анализ....................................................................................6

2.1.2.Ръчен анализ.....................................................................................................7

2.1.3.Анализ на кода..................................................................................................8

2.1.4.Комплексна оценка..........................................................................................10

2.1.5 Организация на процеса на анализа.............................................................11

2.2. Защитна стена на web – приложения..............................................................12

2.3.Съвети за защита на уеб приложения срещу атаки...................................... 13

2.3.1 SQL Инжекция..................................................................................................15

2.3.2. Dіѕtrіbuted denial of Services (DDoS)..............................................................17

2.3.3.Buffer Overflow..................................................................................................18

2.3.4. Croѕѕ-Ѕіte Scripting (XSS)...............................................................................21

2.3.5. Cross-Site Requesf Forgery (CSRF)................................................................23

2.3.6. Source Code Disclosure (SCD)........................................................................25

Заключенuе...............................................................................................................27

Използвана литература

Биляна Александрова ф.н. 10640

26

Въведение

В днешно време много разработчици на web-приложения не осъзнават,

че от ключово значение за сигурността на конфеденциалните данни към

развиэана дейност е проектирането и използването на различни методи и

техники за защита на използваните системи. Потенциален достъп до тайните

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

множество стандарти за безопасност (PCI DSS, NIST и др.), международните

критерии (ISO/IEC 27005:2008, ITIL, COBIT и др.) и законодателните

норми. Сигурността на web- приложенията трябва да бъде добре замислена ,

проектирана и реализирана, а не в последствие добавяна. Може да се намери

много материали, посветени на анализа на защитеността на уеб приложенията,

като някои от тях ще бъдат разгледани в настоящата тема.

1. Web – приложения

Биляна Александрова ф.н. 10640

26

1.1Що е то web-приложение?

Уеб приложение е софтуер, който работи в браузъра.Традиционните

приложения се инсталират или се стартират от диск или друга медиа. Те

разчитат на дадена среда, която в общия случай се осигурява от

операционната система, а в други случаи е допълнително инсталирана на

съответния компютър (напр. Java, .NET и др.). Стартирайки едно традиционно,

т.нар. настолно приложение, то зарежда интерфейс, посредством използвате

съответното приложение.При уеб приложенията, за да стартирате

приложението използвате браузер. В общия случай отваряте приложението

като пишете уеб адреса в браузера, а в по-редки случай файловете на

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

обаче, за работа с уеб приложения се използва браузер.Web приложение,

означава Интернет базиран специфичен код. В това кратко определение може

да се допълни, че този код е със строго определена цел. Това означава, че Web

приложението изпълнява една или повече зададени задачи.

1.2.Предимства на уеб приложенията

Трудно може да се обобщи и еднозначно да се определят предимствата,

защото в определени случаи би могло да бъде по-подходящо приложението да

бъде настолно, а не уеб-базирано, но съществуват няколко сравнително

универсални предимства на уеб приложенията, а именно:

ниски разходи за разработка

 И като време и като ресурси, разработката на уеб приложения е

значителни по-евтина от тази на настолен софтуер. В общия случай уеб

приложенията се пишат на същите програмни езици, които се използват

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

много популярни и има много програмисти, които умеят да пишат на

тях, а от друга - съществуват и много готови ресурси, които могат да

намалят времето за разработка и съответните необходими ресурси.

независими от операционната система

Биляна Александрова ф.н. 10640

26

Понеже работят в браузер, уеб приложенията са общо взето

независими от конкретната операционна система.

не изискват инсталация

За да използва дадено уеб приложение, потребителят не се налага да

го инсталира, както е с много от настолните приложения.

Приложението се стартира директно без предварителна инсталация.

достъпни отвсякъде посредством Интернет

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

Интернет и са достъпни от всяко устройство, свързано с Интернет.

Ограничаването и регулирането на достъпа, разбира се е въпрос на

избор на администратора на приложението и е не само възможно, но и

в някои случаи наложително.

достъпност 24 часа, 7 дни в седмицата;

централизирано съхранение на данните – лесно се прави бекъп на

базата данни, което позволява да се възстановят данните в случай на

проблем;

винаги ползвате последната версия на web програмата (за разлика

от другите програми, които трябва да се преинсталират или обновяват

една по една на всеки компютър)

online обучение;

1.3.Приложение на web- приложенията в бизнеса

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

информационно-комуникационни системи, за да функционира оптимално, а в

някои конкретни случаи, дори за да функционира изобщо.Когато се установи

нуждата от определено ИКТ решение, първо се търси нещо готово. Търси се

готово решение, което да пасне на потребностите, по възможност да е евтино

или дори безплатно. Често, обаче, използването на готово решение е свързано

с компромиси, по отношение на приложимостта му .Понякога пък готово

Биляна Александрова ф.н. 10640

26

решение изобщо не съществува или съществуващите са твърде скъпи, т.к.

предполагат използване в по-комплексни или просто по-големи организации.

Когато готово решение, което да върши работа не съществува или когато

желаем да постигнем максимално оптимални резултати, решението е да се

обърнем към фирма за разработка на софтуер по поръчка, за да бъде

изработено решение отговарящо на нашите конкретни нужди.Именно, когато

става въпрос за софтуер по поръчка, уеб приложенията имат най-голямо

приложение за бизнеса. Ниската цена за изработка, както и останалите

изброени по-горе предимства, правят уеб приложенията най-удачния и най-

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

2. Безопасност и защита на web-приложенията

2.1.Подходи за анализ на защитеността на уеб приложенията. 

2.1.1.Инструментален анализ

Този начин предвижда преди всичко използване на скенери за

безопасност, както и допълнителни инструменти, автоматизиращи някои

сценарии от експлоатацията и откриването на уязвимостите. Сред най-

популярните скенери за безопасност са Acunetix Web Security Scanner, HP Web

Inspect и Positive Technologies MaxPatrol (преди известен като XSpider).

Допълнително може да се използва програмата sqlmap, изследваща за

инфекции в SQL, както и различен софтуер от типа на fuzzing, същността на

който се състои в подаването на преднамерено некоректни данни на входа на

приложенията и анализ на връщаните от тях данни.

Инструменталното изследване е най-простия и като следствие най-

разпространения метод за анализ на защитеността на уеб приложенията. За

простотата обаче се плаща с грешки „от втори род" (false negative) - пропускане

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

Например, днес скенерите не могат самостоятелно (т.е., без използване на

сигнатури) да откриват такива уязвимости, като небезопасно възстановяване на

пароли (Weak Password Recovery Validation), липса на тайм-аут сесии 

Биляна Александрова ф.н. 10640

26

(Insufficient Session Expiration) или логически атаки. 

Ако обект на атаката е програма, използваща работен процес, който на свой

ред реализира някаква бизнес задача, тя може да се окаже уязвима ако не се

осъществява проверка на изпълнението на всички предишни етапи на процеса.

Да предположим, че съществува уеб приложение, което използва някакъв

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

процес приложението се уверява в коректността на данните, въведени от

потребителя, след това се прави проверка дали тази карта е притежание на

някой от клиентите на банката и съответства ли исканата сума на сметката. При

отрицателен резултат, потребителят получава съобщение за грешка. На

последния етап от този процес балансът на сметката на потребителя се

променя в съответствие с въведените данни на първия етап.  Успешна атака на

такова приложение може да бъде осъществена в случай, че съществува

възможност за достъп до последния етап на процеса (захранване на сметката)

с изпращане на произволна сума за промяна на баланса. Скенерът за

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

изпълнена операция за захранване на сметката с произволна сума. Всичко, с

което разполага скенерът за безопасност е това, че при заявка към "някаква

страница", на нея се променя „някакво" значение - от негова гледна точка това

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

приложение, например новинарска страница или сайт за обяви. 

Трябва да отбележим, че независимо от някои ограничения на метода

инструментален анализ на защитеността, той удовлетворява изискванията на

стандарта Payment Card Industry Data Security Standard (PCI DSS) при

провеждане на оценка на защитеността на възлите, достъпни в Интернет. 

2.1.2.Ръчен анализ

Ръчното търсене в повечето случаи позволява да се открият уязвимости,

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

много време. При това, качеството на анализа силно зависи от знанията на

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

Биляна Александрова ф.н. 10640

26

операции. Важно е да се разбере, че когато повечето проверки се правят на

ръка, нараства риска във връзка с „човешкия фактор". Но съществуват уеб

приложения, на които не може да се приложи инструментално изследване,

например приложения от банковата сфера, използващи модел за защита срещу

уязвимости, базирани на  така наречената „междусайтова подмяна на заявките"

(Cross-Site Request Forgery, CSRF). В този случай единственият начин за

анализ на защитеността е ръчното изпълнение на всички проверки.

2.1.3.Анализ на кода

За разлика от ръчния анализ, анализът на изходния код позволява да се

провери защитеността на уеб приложенията, без да се засяга неговата работа.

Изследването може да се изпълнява без достъп до самия уеб сървър, ако не се

налага проверка за експлоатация на уязвимостите. Това е най-безопасният

начин за провеждане на подобни дейности. Един от недостатъците му е

невъзможността да се прави оценка на защитеността на състоянието на уеб

ресурса - тук е нужен непосредствен достъп до него. 

Анализът на кода позволява да се открият много уязвимости в уеб

приложението, но това може да отнеме доста време, което зависи от

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

съществуват множество комерсиални приложения, разработчиците на които

разпространяват своите продукти само в бинарни файлове (например, с

използване на  Zend кодиране или технологията ASP.NET), което не позволява

да се прилага този способ. Впрочем, бинарен анализ на приложението също

може да бъде направен (с това в частност се занимава компанията Veracode).

На практика, цялостен анализ на кода се прави само за отделни модули или

функции на изследваното приложение. Когато е необходим анализ на кода за

уязвимости на цялото приложение, се използва автоматизиран статичен или

динамичен начин.

Търсенето по метода на статичния анализ на изходния код е базиран

на използване на сигнатури, които на свой ред са базирани на регулярни

изрази. Заради своята простота, този метод е получил най-голямо

Биляна Александрова ф.н. 10640

26

разпространение. Но при използване на статичния анализ са неизбежни грешки

от първи и втори род, когато анализиращото приложение не може да открие

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

Възможни са и различни лъжливи съобщения за наличие на уязвимост. 

Грешките от първи род -  (false positive - ненамерени пробиви) при използване

на статичния анализ на кода, възникват заради следните причини:

При програмирането на уеб приложения се използва сложен

синтаксис

Проверките на променливите се извършват с използване на

собствените функции на програмите

Липсват съответните сигнатури

Динамичният анализ е по-ефективен в сравнение със статичния.

Средството, позволяващо да се изпълни динамичен анализ на кода, много

добре разбира синтаксиса на програмния език, на който е написано

изследваното приложение, и прави редица проверки за откриване на

необработени данни от страна на потребителя и влизащи в потенциално

опасни функции на приложението в качеството на аргументи. Този анализ

позволява бързо да се открият всички груби грешки, допуснати от

програмистите и да създаде отчет с минимално количество грешки от първи и

втори род. Но поради сложността на реализация на подобни средства, както и

заради необходимостта от поддръжка на множество програмни езици (PHP,

ASP, Perl, Python, Java и др.), на които могат да бъдат написани уеб

приложенията, тези средства не са много. Най-голямо разпространение са

получили Coverity, Valgrind и Fortify PTA.

Трябва да се има предвид, че на автоматизираните анализатори на код са

присъщи същите недостатъци, както и при скенерите за безопасност.

Например, не могат да бъдат засечени уязвимостите „Небезопасно

възстановяване на паролата", „Липса на тайм-аут сесия", „Логически атаки" и

т.н. По тази причина, при всестранен анализ на изходния код се налага да се

комбинира използването на един или два метода за автоматизиран анализ на

текстовете, както и да се направи експертен анализ на отделните модули на

приложенията - аутентификация, авторизация, възстановяване на пароли,

Биляна Александрова ф.н. 10640

26

извършване на транзакции и др. 

От най-известните разработчици на комерсиални продукти за автоматизиран

анализ на изходния код на уеб приложенията, можем да посочим компаниите

Armorize Technologies, Fortify и Ounce Labs.

2.1.4.Комплексна оценка

Този начин позволява да се извърши анализ на защитеността на уеб

приложението от позицията на средата на неговото функциониране, което е

полезно при (SOA) ориентираните към услуги архитектури и при провеждане на

одит на информационната система като цяло. Всъщност, изброените методи за

анализ на защитеността могат в различна степен да бъдат комбинирани, като

допълват процеса на изследване с такива възможности, като например

Compliance (оценка за съответствие с някакви критерии). При провеждане на

анализ могат да се използват следните принципи:

Принцип на „черната кутия"  (black-box). Оценяване на защитеността на

приложението без предварително получаване на каквато и да е информация за

него. Това е полезно, когато е необходимо да се оцени защитеността от

позицията на хакера, обикновено разполагащ с минимални знания за

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

„тестове за проникване" (penetration testing). Всички изследвания могат да се

провеждат както с предупреждаване на обслужващия персонал за планираните

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

прецени, колко време след началото на изследването персоналът ще засече

инцидента, както и до колко адекватни ще бъдат неговите действия за

минимизиране на неговото въздействие или предотвратяване.

Принцип на „сивата кутия"  (gray-box). Провеждане на изследване с

предоставяне на цялата необходима информация за приложението, освен

осигуряване на непосредствен достъп до самия сървър, на който то

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

структура на приложението, данни за авторизиран достъп (например, име на

Биляна Александрова ф.н. 10640

26

потребител, парола и еднократните пароли за извършване на транзакции),

изходния код на някои файлове или функции и т.н.

Принцип на „бялата кутия" (white-box). Този принцип подразбира предаване

на цялото приложение и неговото инсталиране при консултанта, провеждащ

анализ, или организиране на аналогично копие на приложението в собствената

информационна система с предоставяне на пълен достъп от страна на

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

приложението реагира на всяка подавана към него заявка. Това е най-

продуктивният метод за анализ на защитеността на уеб приложенията, който

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

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

позицията на атакуващия. 

2.1.5 Организация на процеса на анализа

Преди всичко трябва да се изясни, каква цел преследва анализът, а

след това да се определи областта на изследване и да се формира списък с

проверки, ръководейки се от стратегията за управление на информационните

рискове и допустимия бюджет.  Ако целта на анализа е в демонстрацията на

възможностите за проникване, нарушението на стандартния режим за работа

на приложенията или демонстрация на потенциален достъп до чувствителна

информация, тогава процедурите трябва да се организират по принципа на

„черната кутия", без ограничения на провежданите проверки. 

Резултатите от подобно изследване показват текущото състояние на

безопасността на изследваните обекти. В случай на ниска защитеност на уеб

приложенията, подобни дейности нагледно демонстрират реални заплахи от

страна на външен нарушител. След такава констатация може да се отдели

допълнителен бюджет за минимизиране на рисковете. 

Когато целта на анализа е повишаване на нивото на безопасност на

приложенията в условия на ограничен бюджет, най-добре е да се организира

процес на анализ на ресурса по метода на „сивата кутия" с използване на

инструментален подход за изследване с частични ръчни проверки. 

Биляна Александрова ф.н. 10640

26

Който и вариант за провеждане на изследването да бъде избран, важно е да се

направи резервно копиране на ресурса преди началото на операциите. 

Широкото разпространение на Интернет позволява да се използват еднотипни

сценарии за експлоатация на уязвимостите едновременно за множество

ресурси, а небезопасното програмиране, ниската компетентност или

недостатъчната мотивация на обслужващия персонал, може да породи

критични уязвимости. 

Добра практика на системите за управление на информационната безопасност,

е използването на „превантивни" подходи, затова анализът на защитеността и

преди всичко на приложенията, обработващи критични за бизнеса данни,

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

2.2. Защитна стена на web – приложения

Защитната стена за уеб приложения или защитна стена на приложен слой е

устройство или софтуер, разработени, за да защитят уеб приложенията срещу

атаки и „изтичане„ на информация. Стената е разположена между уеб клиента

и уеб сървъра и анализира съобщенията на приложното ниво за наличие на

нарушения в програмираната политика за сигурност. Защитните стени за уеб

приложения се ползват за решаване на проблеми на сигурността, различни от

тези на мрежовите защитни стени и системите за разкриване/предотвратяване

(IDS/IPS) на проникване, които са разработени да защитят мрежовия

периметър.

За да се избере защитен механизъм, такъв, какъвто е защитната стена за уеб

приложения, трябва да се отговори на следните въпроси:

• Какви функции трябва да има тя въз основа на целите на политиката за

сигурност и законовите изисквания?

• Кои допълнителни услуги ще бъдат много ценни?

• Как ще се разположи защитната стена в съществуваща мрежа - има ли

вътрешнофирмени умения да се ползва коректно и ефективно?

Биляна Александрова ф.н. 10640

26

• Какво влияние ще окаже тя върху съществуващите услуги и потребители и на

каква цена?

Функциите на защитната стена трябва да са в състояние да инспектират и

управляват съдържание на уеб страницата, като HTML, Dynamic HTML (DHTML)

и CSS (cascading style sheets), както и протоколите, които вашите приложения

ползват, като HTTP и HTTPS.

Уеб приложенията никога няма да бъдат защитени на 100 процента. Дори да не

е налице вътрешен натиск за по-бързото внедряване на уеб приложения,

винаги ще има уязвимости, които са отворени за заплахите. Защитната стена

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

уязвимост и наличието на време и място да се реши проблема с уязвимостта.

2.3.Съвети за защита на уеб приложения срещу атаки

В днешно време най-простият начин за компрометиране на

конфиденциалната корпоративна информация е използването на уязвимостите

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

обработката на конфиденциална информация, в това число и такава, която е

достъпна чрез Интернет. Потенциален достъп до тайните на компанията може

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

приложенията се изисква да съответстват на стандартите за безопасност (PCI

DSS, NIST и др.), международните критерии (ISO/IEC 27005:2008, ITIL, COBIT и

др.) и законодателните норми, става ясна необходимостта от провеждане на

редовен анализ на защитеността. 

Може да се намери много материали, посветени на анализа на

защитеността на уеб приложенията. Най-интересните от тях са библиотеката с

документи Open Web Application Security Project (OWASP), съдържаща пълно

ръководство за търсене на всевъзможни уязвимости, тяхната класификация и

препоръки към процеса на провеждане на анализ на защитеността. 

От гледна точка на класификацията на уязвимостите, ценни са материалите на

Биляна Александрова ф.н. 10640

26

проекта Web Application Security Consortium (WASC). Трябва да се отбележи и

отвореният стандарт Open Source Security Testing Methodology Manual

(OSSTMM), който разглежда анализа на защитеността на уеб приложенията в

контекста на комплексния процес на тестовете за проникване.

OWASP (Open Web Application Security Project) Top Ten е списък на 10-те

настоящи най-опасни слабости в сигурността на уеб приложенията, заедно с

ефективни методи за справяне с тях(Показани на фигура 1)

Фиг.1. OWASP TOP 10

Съществуват множество съвети за защита срещу атаки към web-приложенията:

Cross-Site Scripting (XSS) Cross-Site Request Forgery (CSRF) SQL инжекция Disttibuted Denial of Services (DDOS) Buffer Overflow Source Code Disclosure (SCD) И много други.

Биляна Александрова ф.н. 10640

26

2.3.1 SQL Инжекция

Sql инжекциите са уязвимости с начина на обработка на заявките към

sql сървъра. Бива подаван параметър, който освен информацията с ключа за

конкретен запис, съдържа и допълнител код. По този начин хакерите могат да

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

които след това се използшат за спам цели, администраторски профили и друга

конфенденциална информация. Важно е да се използват силни пароли за

защита. Те се пазят в базата данни в криптиран вид. Всеки един програмен език

е уязвим към SQL инжекция. Обикновено те се срещат при PHP, Perl, ASP.NET.

Как работят атаките с SQL инжекции?

Нападателите получават достъп до уеб приложенията чрез SQL

инжекция, като добавят Structured Query Language (SQL) код към кутийка на уеб

форма за въвеждане под формата на SQL заявка, което е искане към базата

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

потребителското удостоверяване се въвеждат потребителско име и парола и се

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

се отказва достъп в зависимост дали е дал правилни данни. Уеб форумите

Биляна Александрова ф.н. 10640

26

обикновено нямат никакви инструменти за блокиране на въвеждане освен

потребителското име и паролата, което означава, че хакерите могат да

изпълнят атака с SQL инжекция, като използват входните полета, за да

изпратят заявка към базата данни, която е много вероятно да им предостави

достъп. 

Предотвратяване и избягване на хакерски атаки с SQL инжекция

Има няколко стъпки, които всяка организация може да предприеме , за да

намали вероятността да стане жертва на атака с SQL инжекция.

• Да ограничи привилегиите за достъп на потребителите: Давайте на

служителите и потребителите само достъп до информация, от която се

нуждаят, за да изпълнят своите задачи.

• Осигурете бдителност на потребителите по отношение на

сигурността: Убедете се, че служителите, които имат нещо общо с

разработването на уеб сайта (както и специализираните уеб разработчици),

съзнават заплахите от SQL инжекции и познават добрите практики, с които да

обезопасяват сървърите ви.

• Намалете информацията за отстраняване на бъговете: Когато един

уеб сървър сигнализира грешка, осигурете подробната информация за нея да

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

хакерите да извършат злонамерени действия и да се сдобият с информацията,

която им е нужна, за да атакуват успешно сървъра.

• Тествайте уеб приложението: Тествайте уеб приложението и

проверете работата на уеб разработчиците чрез изпращане на информация

през уеб сървъра – ако резултатът е съобщение за грешка, то е вероятно

приложението да е податливо на атака с SQL инжекция.

Биляна Александрова ф.н. 10640

26

2.3.2. Dіѕtrіbuted denial of Services (DdoS)

Атаката с рапределен отказ от обслужване (DDOS) може да бъде пагубна

за една организация, струвайки й време и пари, като по същество изключи

корпоративните системи.

Как работят атаките с разпределен отказ от обслужване?

Хакерите извършват DDoS атака, като експлоатират пролуки и уязвимости

в компютърната система (често уеб сайт или уеб сървър), за да се

позиционират като главна система. След като веднъж са се поставили в

положение на главна система, хакерите могат да идентифицират и комуникират

с другите системи за по нататъшно компрометиране.

След като нарушителят е поел контрол над множество компрометирани

системи, той може да възложи на машините да започнат някоя от многото атаки

за препълване, докато целевата система се препълни с фалшиви искания за

трафик, което ще доведе до отказ на услуга за ползвателите на тази система.

Потокът от входящите съобщения от компрометираните системи, ще причини

спиране на системата цел и отказ от услуги към нея, което води до

невъзможност за достъп на потребителите до каквото и да било, и

следивателно ще струва на организацият време и пари.

DDoS атаките умишлено възпрепятстват достигането до

информационните ресурси на Internet потребителя, обикновено чрез

претоварване на мрежата чрез изпращане на излишен трафик от много

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

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

често това нещо се извършва от ботове, които на ден използват средно между 4

и 6 милиона потребителски станции, за да разпространяват именно този код.

Такъв вид атаки силно натоварват трафика, като крайната им цел е всяка

следваща станция, докато не се стигне до някой сървър.

Биляна Александрова ф.н. 10640

26

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

услуги (DDoS)?

Предотвратяването на DDoS атака може да бъде трудно, тъй като тя е

предизвикателство за това как да се направи разграничение между зловредна

заявка за трафик и легитимна такава, тъй като те използват еднакви протоколи

и портове. Все пак има няколко стъпки, които могат да се предприемат за

защита на вашите системи от разпределени атаки, предизвикващи отказ от

услуги:

• Уверете се, че имате излишък от честотна лента във връзката на

организацията с интернет: Това е една от най-лесните защити срещу DDoS, но

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

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

ниско ниво DDoS атаки. Също така, колкото по-широка честотна лента има

организацията, толкова повече трябва да направи нападателят, за да запуши

връзката й.

• Уверете се, че използвате система за откриване на прониквания

(Intrusion Detection System, IDS). Няколко от наличните днес системи за

откриване на прониквания са снабдени с технологии за защита на системите от

DDoS атаки, като използват методи за проверка и потвърждаване на връзката и

за предотвратяване достигането до корпоративните сървъри на определени

заявки.

• Използвайте продукт за защита от DDoS. Няколко производители

предлагат устройства за DDoS защита и предотвратяване, които са

конструирани специално за откриване и осуетяване на DDoS атаки.

• Подгответе се за отговор. Използването на регулиращи и ограничаващи

технологии може да намали въздействието от DDoS атаката.

• Поддържайте резервна интернет връзка с отделна база с интернет

адреси за критични потребители. Това ще ви предложи алтернативен път, ако

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

Биляна Александрова ф.н. 10640

26

2.3.3. Buffer Overflow (Препълване на буфер)

Пробойните и уязвимостите, свързани с препълване на буферите, могат

да причинят сериозни вреди на организациите чрез причиняване на пробиви в

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

приложението и да получат контрол над корпоративни машини.

Какво е препълване на буфер и как работи?

Буферът е временна област за съхранение на данни. Когато там се

поставят повече данни, отколкото е предвидено първоначално от даден

програмен и системен процес, допълнителните данни ще го препълнят,

откъдето произлиза и името, причинявайки част от данните да изтекат към

други буфери, което може да разруши данните, които те съдържат или да

запише върху тях.

При атака за препълване на буферите препълващите данни понякога

съдържат специфични инструкции за дейности, проектирани от хакери или

злонамерени потребители. Например данните могат да превключат отговор,

който уврежда файловете, променя данните или разкрива частна информация.

Хакерите биха използвали буферното препълване, за да се възползват

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

препълване – стек базирани и хип базирани. Хип (от heap – купчина)

базираните са по-трудни за изпълнение и затова се срещат по-рядко. Те

атакуват приложението чрез „наводняване“ на пространството памет, запазено

за програмата. Стек (от stack – купчина) базираното препълване на буфера,

което се среща по-често сред хакерите, експлоатира приложения или програми,

като използва това, което е известно като стек – пространство от паметта,

използвано за съхранение на потребителски въвеждания.

Биляна Александрова ф.н. 10640

26

Един стек може да поддържа само определено количество данни и ако

входният низ е по-дълъг от резервираното пространство, резултатът е

препълване, създаващо дупка в сигурността. Хитрите злонанерени хакери

търсят такива пробойни със специално написани команди, които причиняват

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

причинила препълване, хакерът все още трябва да изпълни командата, като

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

„счупва“ частично приложението, но то се опитва да се възстанови, като отива

към адреса за връщане, който е бил пренасочен към злонамерената команда от

хакера.

Когато атаката с препълване на буфера задейства командата, намерена

в новия адрес за връщане, програмата смята, че все още работи.Това

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

набор изпълними разрешения, както приложението, което е било

компрометирано, позволявайки на хакера да получи пълен контрол над

операционната система.

Как да спрем препълването на буфера от атакуващи приложения

След като знаете как работи атаката с препълване на буфера, по-лесно ще

разберете как да я спрете да не се инфилтрира във вашата система и да поеме

контрол над приложенията. Тук са дадени няколко начина за подсилване на

вашата защита и предотвратяване на буферното препълване.

Избягвайте да използвате библиотечни файлове.

Библиотечните файлове, които се използват в езиците за програмиране

и по природа са несигурни, са цел за хакерите по време на атаките

срещу приложенията. Всяка слабост, намерена от хакера в

библиотечния файл, ще съществува също във всички приложения, които

използват библиотечни файлове, давайки на хакерите блестяща цел за

потенциална атака.

Филтрирайте въвежданията от потребителите.

Биляна Александрова ф.н. 10640

26

Филтрирайте вероятни опасни HTML кодове и знаци, които могат да

причинят проблеми с базата данни. Например в ASP кода апострофът,

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

могат да се включват в данните, въвеждани от потребителите или те ще

причинят счупване на приложението. Филтрирайте ги и ги заменете с

нещо друго, за да избегнете усложнения и проблеми.

Тествайте приложенията.

Тествайте приложенията преди внедряването им. Опитайте се да

пробиете всяко приложение, за да си осигурите сигурни кодове. Ако

приложението бъде пробито, ще е ясно, че има проблем, който се

нуждае от поправка, преди да се даде възможност на хакерите да се

възползват от него.

2.3.4. Croѕѕ-Ѕіte Scripting ( XSS )

Атаките от типа крос-сайт скриптинг (XSS) са един от днешните основни

вектори на атака, експлоатиращи уязвими уеб сайтове и използващи браузъри,

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

ХSS са широко разпространени и изискват от организацията да внедри

изчерпателно разработен жизнен цикъл на сигурността, който включва

моделиране на заплахите, сканиращи инструменти и усилена бдителност към

сигурността, за да постигне най-добрата възможна позиция за защита и

превенция от XSS. Cross Site Scripting (XSS) е атака, която използва уязвимост

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

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

програмата, в което се отпечатва стойността на дадена променлива и не се

проверява коректно нейното съдържание. Обикновено в съдържанието на

променливата се записва HTML, XHTML, JavaScript, ActiveX, VBScript, Flash, и

др видове изпълним код. Възможностите за цел на атаката може да са много –

придобиване на достъп до защитена зона на сайта (чрез постигане на session

hijacking), подвеждане на потребителя да въведе информация към трети

източник (physhing), инсталиране на нежелани програми на компютъра на

Биляна Александрова ф.н. 10640

26

потребителя (virus, worm, trojan, …), и др. Според изследване на Symantec

около 80% от проблемите в сигурността на уеб-базираните приложения са

свързани именно с XSS уязвимости. Също така се прави статистическо

предположение, че поне 70% от динамичните уеб-сайтове в световната мрежа

притежават такава уязвимост. Обикновено крайния потребител не може да

намери визуален белег, по който да разкрие атаката.

Как работят ?

Крос-сайт скриптингът (XSS) позволява на нападателите да изпращат

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

слабост в интернет сървър. Нападателите се възползват от XSS средства, за

да инжектират злонамерен код в линк, който изглежда, че заслужава доверие.

Когато потребителят щракне върху линка, вграденото програмиране се включва

и се изпълнява на компютъра на потребителя, което предоставя на хакера

достъп, за да открадне чувствителна информация. Нападателите използват

XSS, за да се възползват от уязвимостите на машината на жертвата и от

зловредния код в трафика вмсто да атакуват самата система.

Нападателите имат възможност да променят HTML кода, който

контролира страницата, като използват уеб форми, които връщат съобщение за

грешка при въвеждане на данни от потребителя. Хакерът може да вмъкне код в

линка на спам съобщение или да използва имейл измама с цел да подмами

потребителя да смята, че източникът е легитимен.

Например нападател може да изпрати на жертвата имейл съобщение с URL,

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

злонамерен URL в блог или сайт на социална мрежа като Facebook или Twitter.

Когато потрбителят щракне върху линка, зловредният сайт, както и скриптът,

заработват в браузъра му. Браузърът не знае, че скриптът е злонамерен и

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

нападателя да получи достъп до функционалността на сайта, за да открадне

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

Биляна Александрова ф.н. 10640

26

XSS атаките са най-общо три вида:

1. Директни: Атакуващият предоставя връзка или друг вид “маскиран” код към

клиента. Когато клиента последва такава връзка той попада на оригиналният

уебсайт на дадената услуга, но вече с модифициран от атакуващия код.

Възможно е и възползването от уязвимост на софтуера, с който жертвата

преглежда подаденото му съобщение, с цел атакуващия да добие достъп до

неговата административна част. Директните атаки се реализират най-често

чрез изпращане на писма по електронната поща към жертвата или чрез

съобщения в различни чат приложения.

2.Статични: Атакуващият успява да вмъкне нежелания код в база данни и само

изчаква жертвата сама да отвори уязвимата страница. Това са най-честите

атаки при т.нар. социални мрежи – форуми, блогове, дискусионни групи, и т.н.

3. DOM: Това са XSS атаки от т.нар. локално ниво. Обикновено се използва

уязвимост в скрипт на продукта, чрез който самият софтуер да предизвика

директна XSS атака към жертвата.

2.3.5. Cross-Site Requesf Forgery (CSRF)

CSRF е широко използвана уязвимост в уеб приложенията. Тази атака,

атакуващия може да наруши цялостта на потребителската сесия с уеб

страница, като инжектира заявка по мрежата посредством браузъра на

потребителя. Политиката на сигурност на browser-ите позволява уеб адресите

да изпращат HTTP заявка до който и да е мрежови адрес. 

Накратко: CSRF е мястото, където злонамерен уеб сайт ще се опита да издаде

действия по отношение на друг сайт, без знанието на потребителя от него,

настъпили.

Биляна Александрова ф.н. 10640

26

Това е подход, който често използва XSS уязвимост в приложението,

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

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

административни права). Така атакуващият, като обикновен потребител, не би

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

SS уязвимост за изпълнение на заявка чрез друг потребител (с по-високи

права). CSRF e широко използвана уязвимост на web страниците. В тази атака

атакуващият нарушава цялостта на потребителската сесия с web страницата

като инжектира заявка по мрежата посредством web браузера на потребителя.

Политиката на сигурност на браузерите позволява web адресите да изпращат

НТТР заявка до който и да е мрежови адрес. Последната политика позволява

зад защитната стена, които машини може да не са пряко достъпни от машината

на атакуващия. : Прочитане на състоянието на браузера: Заявки, изпратени

чрез браузера по принцип вкпючват състоянието на браузера като ..бисквитки",

клиентски сертификати и основни удостоверационни хедъри. Web страници,

които разчитат на тези удостоверения може да бъдат объркани от такива

заявки.

➢ Промяна на състоянието на браузера: Когато атакуващият накара

браузера да изпрати мрежова заявка, браузерът също обработва отговора. Ето

и 2 модела на заплаха, различаващи се по възможностите на атакуващия:

• Публикация във форум: Много web страници като форумите

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

Например, страниците често позволяват на потребителите да качват пасивно

Биляна Александрова ф.н. 10640

26

съдържание като снимки и хиперлинкове. Ако атакува щ зададе злонаглерен U

RL на снимка, мрежовата заявка при зареждане на снимката може да доведе до

CSRF атака. :

• web атака: Атакува щият кара потребителя да посети web страница

управлявана от първия. Ако потребител посети такава страница, тя от своя

страна може да зареди CSRF атаки c GET unu POST HTTP методи. атакуващ,

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

ресурси, които иначе не са под негов или нейн контрол: i Мрежови достъп:

Например, ако потребителят е зад защитна стена (firewall), атакуващият е в

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

други машини.

Как да се защитим om CSRF?

Има разнообразни начини за защита от CSRF, но най-общото е повторно

изпращане на удостоверяващата автентичност заглавна част на заявката (в

повечето случаи това са .,бисквитки") най-малко за всички заявки, които водят

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

скрити полета в HTML формите или се впага в URL адреса на дейстеието. B

CSRF атакуващият няма достъп до оторизационните данни (под формата на

уникален ключ за сесията. съдържаща се най-често в бисквитките", който на

сървъра отговаря на потребителя и така на неговите данни и права), а само

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

заявката .,бисквитките", принадлежащи кьм домейна на страницата.

2.3.6. Source Code Disclosure (SCD)

SCD атаките позволяват на злонамерени потребители да получат

изходния код на server-side приложение. Това позволява на хакерите по-

дълбоко познаване на логиката на приложението.

Нападателите използват SCD атаките, за да се опитат да получат

изходния код на server-side приложенията. Основното правило на web

сървърите е да служат на файловете, както се изисква от клиентите. Файловете

Биляна Александрова ф.н. 10640

26

могат да бъдат статични, каквито са HTML файловете, или динамични, каквито

са ASP, JSP u РНР файповете. Когато браузерът изисква динамичен файл, web

сървърът първо екзекутира файла и тогава връ ща обратно резултата на

браузера. Следователна динамичните файлове са действително код

изпълними на web сървъра. С помощта на SCD атаката атакуващият може да

изтегли изходния код на server-side скриптовете като ASP, РНР u JSP.

Получаването на изходния код на server-side скриптовете предоставя на

хакерите по-дълбоко познаване на логиката на Web- приложенето, т.е. как

приложението ръководи исканията и техните параметри, структурата на базата

данни, уязвимостите в кода и коментарите относно изходния код. И майки

изходния код и евентуалното издаване на дубликат на припожението за

тестване, помагат на нападателя да се подготви за нападение на самото Web-

приложение. Всеки един хакер може да причини S CD, използвайки една от

следните методи:

✓ Използване на познати уязвимости за source disclosure;

✓ Експлоатиране на уязвимостите в приложението, което гложе да

позволи source disclosure;

✓ Разработване на подробни грешки, които могат понякога да включват

изходния код;

✓ Използване на други видове добре познати уязвимости, които могат да

бъдат полезни за source disclosure.

Биляна Александрова ф.н. 10640

26

Заключение

Широкото внедряване на компютрите във все повече дейности,

нарастването на изчислителната им мощ, използването на компютърни мрежи

от различен мащаб и все по свободния достъп до Интернет довеждат до това,

че заплахата от загуба на конфиденциална информация в системите за

обработка на данни е реална и неделима част от нашето високоразвито

технологично общество. Съществуват много методи за атака на web-

приложенията и непрекъснато излизат нови и нови. Атаките срещу уеб

приложенията може да струват много време и пари на организациите, както и

да доведат до скъпи и неприятни пробиви на сигурността на данните, което

прави изчерпателните стратегии и механизми за защита задължителни.

Съществуват множество съвети за защита срещу атаки към web-

приложенията:Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF),

SQL инжекция, Disttibuted Denial of Services (DDOS), Buffer Overflow, Source

Code Disclosure (SCD)и мн. други.

Биляна Александрова ф.н. 10640

26

Използвана литература

1.http://bg.wikipedia.org/wiki/%D0%90%D1%82%D0%B0%D0%BA%D0%B0_

%D0%B7%D0%B0_%D0%BE%D1%82%D0%BA%D0%B0%D0%B7_%D0%BD

%D0%B0_%D1%83%D1%81%D0%BB%D1%83%D0%B3%D0%B0

2. http://www.isportals.com/blog/2010/10/predimstva-na-web-bazi-danni/

3. http://blogs.citrix.com/2010/04/29/how-to-use-netscaler-application-firewall-

to-defend-against-csrf-attacks/

4. http://www.imperva.com/resources/glossary/source_code_disclosure.html

5. http://review.sagabg.net/izbor-na-podhodyashata-zashitna-stena-za-ueb-

prilo.html

6.http://cio.bg/

2990_zashtitata_na_na_ueb_prilozheniyata__prilozhete_prevantiven_podhod.1

7. http://www.thehackerspost.com/2013/02/owasp-top-10-2013-application-

security.html

8.http://edgesoft.com/

%D1%81%D1%82%D0%B0%D1%82%D0%B8%D1%8F/

%D1%83%D0%B5%D0%B1%D0%B4%D0%B8%D0%B7%D0%B0%D0%B9%D0%

BD/2011/12/20/%D0%BA%D0%B0%D0%BA%D0%B2%D0%BE-%D0%B5-

%D1%83%D0%B5%D0%B1%D0%BF%D1%80%D0%B8%D0%BB%D0%BE

%D0%B6%D0%B5%D0%BD%D0%B8%D0%B5

9. http://thecustomizewindows.com/2011/05/what-is-ddos-attack/

10. http://www.cphpvb.net/network-security/543xss%D0%B2%D0%BC%D1%8A

%D0%BA%D0%B2%D0%B0%D0%BD%D0%B5%D0%BD%D0%B0%D0%BD

%D0%B5%D0%B6%D0%B5%D0%BB%D0%B0%D0%BD-%D0%BA%D0%BE

%D0%B4/

11. http://nukerbg.blogspot.com/2012/02/xss.html

Биляна Александрова ф.н. 10640

26

Биляна Александрова ф.н. 10640