Реферат на тема: Безопасност и защита на уеб приложения

1. ИКОНОМИЧЕСКИ УНИВЕРСИТЕТ-Варна
Катедра “Информатика”
Център „Магистърско обучение“
Реферат
ТЕМА:
Безопасност и защита на уеб приложения
Изготвил: Проверил:
Мартин Николаев Кенаров
ф.н. 99836, 7 курс
спец. ПИНФ
доц. д-р Стефан Дражев
ас. Радка Начева
Варна 2015

2. Съдържание
1.Увод
1.1 Какво представляват уеб приложенията
2.Безопасност и защита на уеб приложения
2.1 Заплахи за уеб приложенията
2.2 Стандарти при сигурността
2.3 Технологии при защитата на уеб приложенията
3.Заключение

3. 1. Въведение
Web приложение, означава Интернет базиран специфичен код. В това кратко
определение може да се допълни, че този код е със строго определена цел. Това означава, че
Web приложението изпълнява една или повече зададени задачи.
Web приложенията са работна логика, която позволява действия на потребителя с
Web сайт и обмяна и взаимодействие с всички крайни системи.
Като пример за такива системи се посочват сайтове за получаване на информация за
състоянието на банкова сметка, пазаруване онлайн.
2. Безопасност и защита на уеб приложения
2.1 Заплахи за уеб приложенията
С появяването на web 2.0, нарастването на споделяне на информация чрез
социалните мрежи и все по-разпространеното приемане на интернет като средство за
предоставяне на услуги от страна на бизнеса, интернет сайтовете се превръщат в цел за
хакерите. Като резултат се обръща все по-голямо внимание на сигурността на уеб
приложенията в допълнение към сигурността на компютърните мрежи и операционни
системи.
По-голяма част от атаките стават чрез SQL инжекции и крос-сайт скриптинг (XSS).
MySQL Injection, които обикновенно са в резултат от грешки при програмирането и лошо
филтриране на входните данни.
2.2 Стандарти при сигурността
Open web application security project е неправителствена огранизация която се
фокусира върху подобряването на сигурността на уеб приложенията. Тя предоставя списък с
най-често срещаните уязвимости в уеб приложенията. За 2013 година този списък включва:
1. Невалидирани входни данни
2. Грешки при контрола на достъпа
3. Грешки при управлението на сесиите и идентификацията
4. Cross-site scripting (XSS)
5. Препълване на буфери
6. Злонамерено вмъкване на код (code injection)
7. Проблеми при обработка на грешки
8. Несигурно използване на криптография
9. Denial of services
10. Грешки при конфигурация

4. - Невалидирани входни данни – Обработката на входни данни е важна част от всяко
приложение. Тук често допускани грешки са : предполагане, че постъпилите данни са
коректни, проверяване за “грешни данни” вместо за коректни, не проверяване за валидност
на формата на данните, реализиране на ненадеждни проверки. Частни случай на този
проблем са уязвимостите от тип : cross-site scripting, препълване на буфери, злонамерено
вмъкване на код(code injection). Този тип уязвимост се проявява когато не проверяваме
входните данни или тази проверка не я правим коректно. Можем да се защитим като
проверяваме за валидни, а не за невалидни данни, не трябва да се разчита на проверки при
клиента, получените данни трябва внимателно да бъдат проверявани за типа на данните,
разрешена кодова таблица, минимална и максимална дължина, произволен интервал,
дефиниционно множество, разрешена ли е null стойност, задължителен ли е даден параметър,
позволени ли са дублиращи данни и др.
- Грешки при контрола за достъп – контрола за достъп е това което дава различни
права на потребителите на едно уеб приложение. Тук обикновенно при реализацията се
допускат често следните грешки – подценява се сложността на задачата, контрола на достъпа
се “разхвърля” на много места, в самия дизайн на приложението се пропуска да се добави.
Разбираме, че сме уязвими когато нямаме яснота как точно работи контролът за достъп,
реализацията не е ясно написана и документирана, в идеята на проложението не е залегнал
контрол на достъпа. Можем да се защитим чрез ясна дефиниция и централизация на
контрола на достъп. Спецефични проблеми за които трябва да се внимава са несигурно
използване на идентификатори, file permissions, path traversal, кеширане от страна на клиента.
- Сесии и идентификация – тъй като HTTP протоколът не поддържа сесии, се налага
да се разлизират от разработчиците собствени механизми и това води до грешки. Тук често се
допускат грешки чрез несигурно използване на методи за идентификация, пазене на повече
от нужното при клиента, използване на предвидими сесийни идентификатори, съхраняване
на нехеширани пароли, “Lost password” изисква твърде малко данни. Може да разберем, че
сме уязвими към подобен тип атаки чрез проследяване на всички процеси, при които се
използва идентификация и сесия. Начини на защита тук са – налагане на използването на
“силни” пароли, механизъм на защита от brute force атаки на паролата, сигурни механизми
при смяна на паролата и свързаната с нея информация, съхранение на паролите, защита на
предаваните данни чрез криптиране, обвързване на сесийният идентификатор с
допълнителни данни на потребителя, избягване на даване на информация за други
потребители, неизползването на GET при идентификация и предаване на сесийна
информация, всеки компонент трябва да проверява идентификацията, а не да вярва на
другите компоненти.
- Крос сайт скриптинг - Атаките от типа крос-сайт скриптинг (XSS) са един от
днешните основни вектори на атака, експлоатиращи уязвими уеб сайтове и използващи
браузъри, за да крадат кукита или да започнат финансова транзакция. Пробойните тип ХSS са
широко разпространени и изискват от организацията да внедри изчерпателно разработен
жизнен цикъл на сигурността, който включва моделиране на заплахите, сканиращи
инструменти и усилена бдителност към сигурността, за да постигне най-добрата възможна

5. позиция за защита и превенция от XSS.
Крос-сайт скриптингът (XSS) позволява на нападателите да изпращат злонамерен код
към друг потрбител, като се възползват от пробойна или слабост в интернет сървър.
Нападателите се възползват от XSS средства, за да инжектират злонамерен код в линк, който
изглежда, че заслужава доверие. Когато потребителят щракне върху линка, вграденото
програмиране се включва и се изпълнява на компютъра на потребителя, което предоставя на
хакера достъп, за да открадне чувствителна информация. Нападателите използват XSS, за да
се възползват от уязвимостите на машината на жертвата и от зловредния код в трафика вмсто
да атакуват самата система.
Нападателите имат възможност да променят HTML кода, който контролира
страницата, като използват уеб форми, които връщат съобщение за грешка при въвеждане на
данни от потребителя. Хакерът може да вмъкне код в линка на спам съобщение или да
използва имейл измама с цел да подмами потребителя да смята, че източникът е легитимен.
Например нападател може да изпрати на жертвата имейл съобщение с URL, което сочи
към уеб сайт и го снабдява със скрипт за влизане, или публикува злонамерен URL в блог или
сайт на социална мрежа като Facebook или Twitter. Когато потрбителят щракне върху линка,
зловредният сайт, както и скриптът, заработват в браузъра му. Браузърът не знае, че скриптът
е злонамерен и сляпо изпълнява програмата, която на свой ред позволява на скрипта на
нападателя да получи достъп до функционалността на сайта, за да открадне кукита или да
извърши транзакции, представящи се за легитимен потребител.
Някои общоприети най-добри практики за предотвратяване на крос-сайт скриптинг
включват тестване на кода на приложението преди внедряване и патчване на пробойните и
уязвимостите по най-бързия начин. Уеб разработчиците трябва да филтрират въвежданията
на потребителите, за да премахнат възможни злонамерени знаци и скриптове и да инсталират
код за филтриране на потребителските данни. Администраторите могат също да
конфигурират браузърите да приемат само скриптове от доверени сайтове или да изключат
скриптовете на браузъра, макар че това може да доведе до уеб сайт с ограничена
функционалност.
Колкото времето върви напред, толкова подобри стават хакерите, използвайки колекция от
набори с инструменти, за да ускорят процеса на експлоатиране на уязвимостите. Това
означава, че простото внедряване на тези общи XSS практики за защита вече не е достатъчно.
Процесът на защита и предотвратяване трябва да започне от основата и да се изгражда
нагоре. Процесът на предотвратяване трябва да започне по време на разработването. Уеб
приложенията, които са изградени с използване на солидна методология за сигурно
разработване на жизнения цикъл, е по-малко вероятно да покажат уязвимости в
окончателната версия. Това ще подобри не само сигурността, но също и ефективността и
общата цена за притежание, тъй като поправянето на проблема на живо е по-скъпо, отколкото
по време на разработването.
Моделирането на заплахите е важен аспект на предотвратяването на XSS, който трябва да
бъде внедрен в жизнения цикъл на сигурността във всяка организация. Моделирането на
заплахите оценява и идентифицира всички рискове за приложението по време на етапа на

6. проектиране, за да помогне на уеб разработчиците да разберат какъв вид защити са
необходими и как успешна атака срещу това приложение ще засегне организацията. За да се
определи нивото на заплахата спрямо определено приложение, важно е да се вземат под
внимание неговите активи, както и до колко чувствителна информация има достъп.
Минаването през този процес на моделиране на заплахите ще осигури стратегическото
вграждане на сигурността в проектирането и разработването на приложението и ще повиши
бдителността по отношение на сигурността на уеб разработчиците.
- Препълване на буфери - Пробойните и уязвимостите, свързани с препълване на
буферите, могат да причинят сериозни вреди на организациите чрез причиняване на пробиви
в данните, както и чрез даване възможност на нападателите да превземат уеб приложението и
да получат контрол над корпоративни машини.Буферът е временна област за съхранение на
данни. Когато там се поставят повече данни, отколкото е предвидено първоначално от даден
програмен и системен процес, допълнителните данни ще го препълнят, откъдето произлиза и
името, причинявайки част от данните да изтекат към други буфери, което може да разруши
данните, които те съдържат или да запише върху тях.
При атака за препълване на буферите препълващите данни понякога съдържат специфични
инструкции за дейности, проектирани от хакери или злонамерени потребители. Например
данните могат да превключат отговор, който уврежда файловете, променя данните или
разкрива частна информация.Хакерите биха използвали буферното препълване, за да се
възползват от програма, която очаква въвеждане от потребителя. Има два типа буферно
препълване – стек базирани и хип базирани. Хип (от heap – купчина) базираните са по-
трудни за изпълнение и затова се срещат по-рядко. Те атакуват приложението чрез
„наводняване“ на пространството памет, запазено за програмата. Стек (от stack – купчина)
базираното препълване на буфера, което се среща по-често сред хакерите, експлоатира
приложения или програми, като използва това, което е известно като стек – пространство от
паметта, използвано за съхранение на потребителски въвеждания.
Един стек може да поддържа само определено количество данни и ако входният низ е по-
дълъг от резервираното пространство, резултатът е препълване, създаващо дупка в
сигурността. Хитрите злонанерени хакери търсят такива пробойни със специално написани
команди, които причиняват препълване и задействат атаката. След като злонамерената
команда е причинила препълване, хакерът все още трябва да изпълни командата, като посочи
адрес за връщане, който сочи към командата. Препълването на буфера „счупва“ частично
приложението, но то се опитва да се възстанови, като отива към адреса за връщане, който е
бил пренасочен към злонамерената команда от хакера.
Когато атаката с препълване на буфера задейства командата, намерена в новия адрес за
връщане, програмата смята, че все още работи.
Това означава, че командният прозорец, който е бил отворен, работи със същия набор
изпълними разрешения, както приложението, което е било компрометирано, позволявайки на
хакера да получи пълен контрол над операционната система.
След като знаете как работи атаката с препълване на буфера, по-лесно ще разберете как да я
спрете да не се инфилтрира във вашата система и да поеме контрол над приложенията. Тук са

7. дадени няколко начина за подсилване на вашата защита и предотвратяване на буферното
препълване.
Библиотечните файлове, които се използват в езиците за програмиране и по природа са
несигурни, са цел за хакерите по време на атаките срещу приложенията. Всяка слабост,
намерена от хакера в библиотечния файл, ще съществува също във всички приложения, които
използват библиотечни файлове, давайки на хакерите блестяща цел за потенциална атака.
Филтрирайте вероятни опасни HTML кодове и знаци, които могат да причинят проблеми с
базата данни. Например в ASP кода апострофът, кавичките, амперсантът са запазени
символи. Тези запазени символи не могат да се включват в данните, въвеждани от
потребителите или те ще причинят счупване на приложението. Филтрирайте ги и ги заменете
с нещо друго, за да избегнете усложнения и проблеми.
Тествайте приложенията преди внедряването им. Опитайте се да пробиете всяко приложение,
за да си осигурите сигурни кодове. Ако приложението бъде пробито, ще е ясно, че има
проблем, който се нуждае от поправка, преди да се даде възможност на хакерите да се
възползват от него.
Злонамерено вмъкване на код - уеб разработчиците често използват пригоден код, за
да засилят динамичната функционалност на уеб сайта, но този код може да изложи уеб
сървърите на риск чрез много пробойни и уязвимости. Това е особено опасно, когато уеб
приложението се използва, за да предостви интерфейс към стоящата отзад база данни.
Нападателите получават достъп до уеб приложенията чрез SQL инжекция, като добавят
Structured Query Language (SQL) код към кутийка на уеб форма за въвеждане под формата на
SQL заявка, което е искане към базата данни да изпълни специфично действие. Обикновено
по време на потребителското удостоверяване се въвеждат потребителско име и парола и се
включват в запитване. След това на потребителя или му се предоставя, или му се отказва
достъп в зависимост дали е дал правилни данни. Уеб форумите обикновено нямат никакви
инструменти за блокиране на въвеждане освен потребителското име и паролата, което
означава, че хакерите могат да изпълнят атака с SQL инжекция, като използват входните
полета, за да изпратят заявка към базата данни, която е много вероятно да им предостави
достъп.
Има нчколко стъпки, които всяка организация може да предприеме , за да намали
вероятността да стане жертва на атака с SQL инжекция.
• Да ограничи привилегиите за достъп на потребителите: Давайте на служителите и
потребителите само достъп до информация, от която се нуждаят, за да изпълнят своите
задачи.
• Осигурете бдителност на потребителите по отношение на сигурността: Убедете се, че
служителите, които имат нещо общо с разработването на уеб сайта (както и
специализираните уеб разработчици), съзнават заплахите от SQL инжекции и познават
добрите практики, с които да обезопасяват сървърите ви.

8. • Намалете информацията за отстраняване на бъговете: Когато един уеб сървър
сигнализира грешка, осигурете подробната информация за нея да не се показва на
потребителя, тъй като тази информация може да помогне на хакерите да извършат
злонамерени действия и да се сдобият с информацията, която им е нужна, за да атакуват
успешно сървъра.
• Тествайте уеб приложението: Тествайте уеб приложението и проверете работата на уеб
разработчиците чрез изпращане на информация през уеб сървъра – ако резултатът е
съобщение за грешка, то е вероятно приложението да е податливо на атака с SQL инжекция.
- Проблеми при обработка на грешки – тук проблеми могат да се появят като на
потребителя се даде твърде много информация при грешка, действието при грешка по
подразбиране се разрешава, не се пази информация за появили се грешки. За да открием
уязвимости може приложението да се подложи на crash testing. Подаване на комбинации на
валидни и невалидни данни. Защита може да стане чрез тестване на всички възможни
пътища за появяване на грешки, създаване на правила, коя част от информацията за
възникнала грешка се подава към потребителя и коя се запазва.
- Несигурно използване на криптография – повечето уеб приложения трябва да пазят
някои важни данни в бази от данни или във файлове и въпреки, че има добри библиотеки с
функции за криптиране се допускат се допускат основни грешки при реализацията. Тук
грешки се допускат като важни данни не се криптират, несигурно се съхраняват ключове,
сертификати и пароли, неправилно се съхраняват данни в паметта, лоши източници на
случайни числа, лош избор на алгоритъм за криптиране/хеширане, опити за създаване на
собствен алгоритъм за криптиране/хеширане. Програмистите занимаващи се с криптиране
трябва много добре да разбират какво правят. При разглеждане на кода трябва да се обърне
специално внимание на полжваните алгоритни, тяхната реализация и как защитените данни
се записват, четат и обработват. За да се защитим трябва да използваме готви и тествани
библиотеки, да подсигурим сигурното съхранение на паролите, ключовете и сертификатите.
- Denial of services - атаката с рапределен отказ от обслужване (DDOS) може да бъде
пагубна за една организация, струвайки й време и пари, като по същество изключи
корпоративните системи.
Хакерите извършват DDoS атака, като експлоатират пролуки и уязвимости в компютърната
система (често уеб сайт или уеб сървър), за да се позиционират като главна система. След
като веднъж са се поставили в положение на главна система, хакерите могат да
идентифицират и комуникират с другите системи за по нататъшно компрометиране.
След като нарушителят е поел контрол над множество компрометирани системи, той може да
възложи на машините да започнат някоя от многото атаки за препълване, докато целевата
система се препълни с фалшиви искания за трафик, което ще доведе до отказ на услуга за
ползвателите на тази система. Потокът от входящите съобщения от компрометираните
системи, ще причини спиране на системата цел и отказ от услуги към нея, което води до
невъзможност за достъп на потребителите до каквото и да било, и следивателно ще струва на
организацият време и пари.
Предотвратяването на DDoS атака може да бъде трудно, тъй като тя е предизвикателство за

9. това как да се направи разграничение между зловредна заявка за трафик и легитимна такава,
тъй като те използват еднакви протоколи и портове. Все пак има няколко стъпки, които могат
да се предприемат за защита на вашите системи от разпределени атаки, предизвикващи отказ
от услуги:
• Уверете се, че имате излишък от честотна лента във връзката на организацията с интернет:
Това е една от най-лесните защити срещу DDoS, но може да се окаже доста скъпа. Просто
като имате много честотна лента за обслужване на заявките за трафик, това може да помогне
за предпазване от ниско ниво DDoS атаки. Също така, колкото по-широка честотна лента има
организацията, толкова повече трябва да направи нападателят, за да запуши връзката й.
• Уверете се, че използвате система за откриване на прониквания (Intrusion Detection System,
IDS). Няколко от наличните днес системи за откриване на прониквания са снабдени с
технологии за защита на системите от DDoS атаки, като използват методи за проверка и
потвърждаване на връзката и за предотвратяване достигането до корпоративните сървъри на
определени заявки.
• Използвайте продукт за защита от DDoS. Няколко производители предлагат устройства за
DDoS защита и предотвратяване, които са конструирани специално за откриване и осуетяване
на DDoS атаки.
• Подгответе се за отговор. Използването на регулиращи и ограничаващи технологии може да
намали въздействието от DDoS атаката.
• Поддържайте резервна интернет връзка с отделна база с интернет адреси за критични
потребители. Това ще ви предложи алтернативен път, ако първичната верига е претоварена
със злонамерени заявки.
2.3 Технологии за защита - инструментите за сканиране на основния код и скенерите
на уязвимости на уеб приложенията винаги са една възможност за увеличаване на
ефективността и намаляване на работното натоварване на уеб разработчиците при големите
проекти. Скенерите на уеб уязвимости могат да идентифицират разпространените пробойни
и уязвимости – SQL инжекции, крос-сайт скриптинг, препълване на буфера, но клиентският
код на приложението трябва да се прегледа ръчно.
3. Заключение - от препълване на буферите до SQL инжекциите хакерите имат много методи
на разположение за атака на уеб приложения, като непрекъснато се появяват и нови методи.
Атаките срещу уеб приложенията може да струват много време и пари на организациите,
както и да доведат до скъпи и неприятни пробиви на сигурността на данните, което прави
изчерпателните стратегии и механизми за защита задължителни. Затова е необходимо да се
обърне голямо внимание на сигурността на уеб приложението при изграждането му. Колкото
по-добре бъдат запознати разработчиците със уязвимостите и начините на защита от тях,
толкова по-сигурно ще е дадено приложение.

10. това как да се направи разграничение между зловредна заявка за трафик и легитимна такава,
тъй като те използват еднакви протоколи и портове. Все пак има няколко стъпки, които могат
да се предприемат за защита на вашите системи от разпределени атаки, предизвикващи отказ
от услуги:
• Уверете се, че имате излишък от честотна лента във връзката на организацията с интернет:
Това е една от най-лесните защити срещу DDoS, но може да се окаже доста скъпа. Просто
като имате много честотна лента за обслужване на заявките за трафик, това може да помогне
за предпазване от ниско ниво DDoS атаки. Също така, колкото по-широка честотна лента има
организацията, толкова повече трябва да направи нападателят, за да запуши връзката й.
• Уверете се, че използвате система за откриване на прониквания (Intrusion Detection System,
IDS). Няколко от наличните днес системи за откриване на прониквания са снабдени с
технологии за защита на системите от DDoS атаки, като използват методи за проверка и
потвърждаване на връзката и за предотвратяване достигането до корпоративните сървъри на
определени заявки.
• Използвайте продукт за защита от DDoS. Няколко производители предлагат устройства за
DDoS защита и предотвратяване, които са конструирани специално за откриване и осуетяване
на DDoS атаки.
• Подгответе се за отговор. Използването на регулиращи и ограничаващи технологии може да
намали въздействието от DDoS атаката.
• Поддържайте резервна интернет връзка с отделна база с интернет адреси за критични
потребители. Това ще ви предложи алтернативен път, ако първичната верига е претоварена
със злонамерени заявки.
2.3 Технологии за защита - инструментите за сканиране на основния код и скенерите
на уязвимости на уеб приложенията винаги са една възможност за увеличаване на
ефективността и намаляване на работното натоварване на уеб разработчиците при големите
проекти. Скенерите на уеб уязвимости могат да идентифицират разпространените пробойни
и уязвимости – SQL инжекции, крос-сайт скриптинг, препълване на буфера, но клиентският
код на приложението трябва да се прегледа ръчно.
3. Заключение - от препълване на буферите до SQL инжекциите хакерите имат много методи
на разположение за атака на уеб приложения, като непрекъснато се появяват и нови методи.
Атаките срещу уеб приложенията може да струват много време и пари на организациите,
както и да доведат до скъпи и неприятни пробиви на сигурността на данните, което прави
изчерпателните стратегии и механизми за защита задължителни. Затова е необходимо да се
обърне голямо внимание на сигурността на уеб приложението при изграждането му. Колкото
по-добре бъдат запознати разработчиците със уязвимостите и начините на защита от тях,
толкова по-сигурно ще е дадено приложение.