Web Applications Security

1. ИКОНОМИЧЕСКИ УНИВЕРСИТЕТ - ВАРНА
ЦЕНТЪР „МАГИСТЪРСКО ОБУЧЕНИЕ”
Катедра „Информатика”
РЕФЕРАТ
по
Безопасност и защита
на тема
Безопасност и защита на Web-
приложения
Разработил:Пламена Иванова Митева, ф.н. 9505, гр. 51, спец. Информатика
Дата: 01.05.2011 г. Проверил:
................................... /доц. д-р Стефан Дражев/
1

2. Съдържание
Въведение..............................................................................................3
1. Web-приложения...............................................................................3
1.1.Какво представляват Web-приложенията?............................................3
1.2. Предимства и недостатъци на Web-приложенията............................4
2. Защитна стена за Web-приложенията......................................5
3. Безопасност и защита на Web-приложенията.........................6
3.1. Cross-Site Scripting (XSS)..............................................................................9
3.2. Cross-Site Request Forgery (CSRF).............................................................12
3.3. SQL инжекция................................................................................................14
3.4. Distributed denial of Services (DDoS)..........................................................16
3.5. Buffer Overflaw...............................................................................................18
3.6. Source Code Disclosure (SCD).....................................................................20
Заключение..........................................................................................21
Използвана литература...................................................................22
Въведение
2

3. Сигурността във Web-приложенията не е трудна за реализиране,
но трябва да бъде замислена, проектирана и внедрявана от самото
начало на разработката, а не като допълнение или кръпка към
даденото приложение.
Много разработчици на Web-приложения не осъзнават тяхното
ключово значение за сигурността на организацията, в която работят.
Анализ на атаките показва, че именно Web-приложенията са тези,
които позволяват пробиви в сигурността. Тук, в повечето случаи,
защитните стени са неефективни, тъй като контролът на достъпа до
приложенията, който те осъществяват, е главно на мрежово ниво
(Network layer, OSI Reference Model), докато атаките срещу Web-
приложенията са на приложно ниво (Application layer, OSI Reference
Model).
Повечето слабости в сигурността са в следствие на един или
друг вид доверие във въведените от потребителя данни. Основен
принцип при разработката на сигурни приложения е, че не трябва да
се гласува доверие на нищо и никого.
1. Web-приложения
1.1. Какво представляват Web-приложенията?
Разделянето на различните видове Web-приложения в различни
категории и подкатегории обуславя ясно и точно дефиниране на
самото понятие „Web-приложения". То се състои от две думи, всяка
от които носи важна информация. Под Web, което се използва за
съкратено представяне на World Wide Web, се разбира Интернет
или необятното информационно поле на световната мрежа. Самият
Internet представлява набор от информация, услуги, ресурси,
средство за обмен на данни, място за получаване на знания.
Думата „приложение" според сайта Whatis.com е програма,
проектирана да изпълнява специфични функции за потребителя
или, в някои случаи, за друга приложна програма. Например за
приложения като обработка на текст, програми за бази от данни,
браузъри за Internet, инструменти за разработка и комуникационни
програми. Приложенията използват услугите на операционната
система на компютъра и други поддържащи приложения. Накратко
Web-приложение означава Internet базиран специфичен код. В това
кратко определение може да се допълни, че този код е със строго
определена цел. Това означава, че Web-приложението изпълнява
една или повече зададени задачи.
3

4. Web-приложенията са работна логика, която позволява действия
на потребителя с web сайт, обмяна и взаимодействие с всички
крайни системи. Пример за такива системи са сайтовете за
получаване на информация за състоянието на банкова сметка,
пазаруване on-line и други.
Друг важен елемент на Web-приложенията са специфичните им
черти, които ги разделят от традиционните понятия за приложения и
Web-сайт:
 Web-приложението установява уникална сесия и
взаимодействие с всеки посетител (представител на
приложение от този тип е сайтът на Hotmail);
 Web-приложението предоставя възможност на
потребителите да променят данните за постоянно
(създаване, обработване и съхраняване). Данните могат да се
вземат от формата за завършена транзакция на продажба, от
E-mail съобщение и други. Типичен пример е сайтът на
Amazon.
Това показва,че не всеки web сайт е типично Web-приложение. В
обществото на световната мрежа за целта има разделение между
Web-приложение и web сайт, като под web сайт се разбира сайт,
който е основан на съдържанието си (content-based website).
1.2. Предимства и недостатъци на Web-приложенията
Предимства на Web-приложенията
 Не е нужно инсталиране на компютър – Това е огромно
предимство особено, ако става въпрос за по-големи фирми с
много компютри;
 По-ниски разходи;
 Централизирано съхранение на данните – лесно се прави
back-up на базата данни, което позволява да се възстановят
данните в случай на проблем;
 Програмата е достъпна от всеки компютър в целия свят (стига
да е свързан с Internet);
 Достъпност 24 часа, 7 дни в седмицата;
 Винаги ползвате последната версия на web програмата (за
разлика от другите програми, които трябва да се
преинсталират или обновят една по една на всеки компютър);
 Online обучение.
Ползи за бизнеса от Web-приложенията
4

5.  Web-приложенията могат да имат публична част, която се
вижда от всички (не само от служителите във фирмата) и там
да се изнася дадена информация;
 Служители или представители, без значение къде се намират,
имат пряк достъп до актуална информация;
 Лесно менежиране чрез всякакъв вид справки и статистики.
Недостатъци на web приложенията
 По-бавно, защото информацията протича през Internet;
 Рискове за сигурността.
2. Защитна стена за Web-приложенията
Много разработчици на Web-приложения не осъзнават тяхното
ключово значение за сигурността на организацията, в която работят.
Анализ на атаките показва, че именно Web-приложенията са тези,
които позволяват пробиви в сигурността. Тук, в повечето случаи,
защитните стени са неефективни, тъй като контролът на достъпа до
приложенията, който те осъществяват, е главно на мрежово ниво
(Network layer, OSI Reference Model), докато атаките срещу Web-
приложенията са на приложно ниво (Application layer, OSI Reference
Model).
Предприятиятa/организациите, втурнали се да отговорят на
изискванията за съвместимост с PCI (Payment Card Industry)
нормите, могат се окажат в сериозно затруднение, когато започнат
да избират защитна стена за Web-приложенията си (Web Application
Firewall - WAF). Защитната стена за Web-приложения или защитна
стена на приложен слой е устройство или софтуер, разработени, за
да защитят Web-приложенията срещу атаки и „изтичане„ на
информация. Стената е разположена между web клиента и web
сървъра и анализира съобщенията на приложното ниво за наличие
на нарушения в програмираната политика за сигурност.
5

6. Най-често решенията от този клас представляват хардуерно-
софтуерни комплекси, прилагащи набор от правила и политики за
сигурност към наблюдавания HTTP трафик, идващ от приложенията
към базата данни и в обратното направление. Тези решения
позволяват да се контролират такива известни типове атаки, като
Cross-Site Scripting (XSS) или SQL-инжекции. С настройване на
правилата спрямо бизнес приложенията, могат да се откриват и
блокират множество атаки. Обаче обемът на работа във връзка с
тези настройки може да се окаже доста голям, а освен това при
изменения в приложенията, трябва да се правят нови
настройки. Влияние за появата на решенията от този клас
определено оказа стандартът PCI DSS, изискващ защита на
информацията в публичните Web приложения, поне по един от
следните 2 метода:
- анализ на кода на Web приложенията - ръчно, със сканиране на
изходния код или с оценка на уязвимостите;
-установяване на точка на прилагане на политиката за
сигурност. Решенията от клас WAF често се наричат и Deep Packet
Inspection Firewalls, т.е. защитни стени с дълбок анализ на пакетите,
тъй като те анализират всяка заявка и всеки резултат от заявка на
нива HTTP/ HTTPS/SOAP/XML-RPC/ Web-услуга. При това, самите
данни в базата остават незащитени, тяхното използване не се
следи – фактически се инспектира само частта от мрежовите заявки
към базата данни, идваща от сървъра за приложения. Както и
традиционните firewall за защита на периметъра, WAF са
необходими, но не винаги са достатъчни.
3. Безопасност и защита на Web-приложенията
Осъзнаването на риска е една много важна част то правилната
превенция от атаки и злонамерен код. Не би могъл да се изгради
план на действие, преди да бъде осъзнат и оценен потенциалния
риск.
В днешно време най-простият начин за компрометиране на
конфиденциалната корпоративна информация е използването на
уязвимостите на Web-приложенията. Как да се открият и отстранят
тези от тях, които са недостатъчно надеждни?
Логиката на съвременния бизнес е тясно свързана с обработката
на конфиденциална информация, в това число и такава, която е
достъпна чрез Интернет. Потенциален достъп до тайните на
компанията може да се получи даже през обикновен браузър. Ако в
6

7. допълнение към това от Web-приложенията се изисква да
съответстват на стандартите за безопасност (PCI DSS, NIST и
други), международните критерии (ISO/IEC 27005:2008, ITIL, COBIT
и други) и законодателните норми, става ясна необходимостта от
провеждане на редовен анализ на защитеността.
Може да се намерят много материали, посветени на анализа на
защитеността на Web-приложенията. Най-интересните от тях са
библиотеката с документи Open Web Application Security Project
(OWASP), съдържаща пълно ръководство за търсене на
всевъзможни уязвимости, тяхната класификация и препоръки към
процеса на провеждане на анализ на защитеността.
От гледна точка на класификацията на уязвимостите, ценни са
материалите на проекта Web Application Security Consortium
(WASC). Трябва да се отбележи и отвореният стандарт Open Source
Security Testing Methodology Manual (OSSTMM), който разглежда
анализа на защитеността на Web-приложенията в контекста на
комплексния процес на тестовете за проникване.
Най-общо казано от препълването на буферите до SQL
инжекциите хакерите имат много методи на разположение за атака
на Web-приложения, като непрекъснато се появяват все по-нови и
нови методи. Атаките срещу Web-приложенията може да струват
много време и пари на организациите, както и да доведат до скъпи и
неприятни пробиви на сигурността на данните, което прави
изчерпателните стратегии и механизми за защита задължителни.
В тази връзка съществуват няколко съвета за защита срещу атаки
към Web-приложенията – от появата им до идентифицирането на
известни и неясни атаки, в това число:
 Cross-Site Scripting (XSS);
 Cross-Site Request Forgery (CSRF);
 Distributed Denial of Services (DDoS);
 SQL инжекция;
 Buffer Overflow;
 Source Code Disclosure (SCD);
 и други.
Фигура 1.
7

8. Фигура 2.
3.1. Cross-Site Scripting (XSS)
8

9. Какво представлява Cross-Site Scripting (XSS)?
Най-общо казано Cross-Site Scripting (XSS) представлява начин за
инжектиране на код в генериран HTML. Това става с помощта на
променливите, предавани чрез метода GET или при нефилтрирано
(непроверено) поле за специални символи, използвани в HTML.
Основно XSS се използва за крадене на сесия или „бисквитки”
(“cookies”).
XSS е атака, която използва уязвимост при приложението и
„вмъква” нежелан код, който се изпълнява в браузера на крайния
потребител. По този начин атаката цели да намери място в
програмата, в което се отпечатва стойността на дадена променлива
и не се проверява конкретно нейното съдържание. Почти няма
приложение в Internet, което да няма или да не е имало XSS
уязвимост. В днешно време с навлизането на все повече технологии
като ActionScript на Flash или Ajax скриптовете, XSS атаките все
повече добиват популярност. На практика всички тези проблеми се
зараждат в момента, когато сървърите придобиват функционалност
за директно изпълнение на код при клиента (например JavaScript).
9

10. Как работят XSS атаките?
XSS позволява на нападателите да изпращат злонамерен код към
друг потрбител, като се възползват от пробойна или слабост в
Internet сървъра. Нападателите се възползват от XSS средства, за
да инжектират злонамерен код в линк, който изглежда, че заслужава
доверие. Когато потребителят щракне върху линка, вграденото
програмиране се включва и се изпълнява на компютъра на
потребителя, което предоставя на хакера достъп, за да открадне
чувствителна информация. Нападателите използват XSS, за да се
възползват от уязвимостите на машината на жертвата и от
зловредния код в трафика вместо да атакуват самата система.
Нападателите имат възможност да променят HTML кода, който
контролира страницата, като използват web форми, които връщат
съобщение за грешка при въвеждане на данни от потребителя.
Хакерът може да вмъкне код в линка на спам съобщение или да
използва E-mail измама с цел да подмами потребителя да смята, че
източникът е легитимен.
Например нападател може да изпрати на жертвата E-mail
съобщение с URL, което сочи към Web сайт и го снабдява със
скрипт за влизане, или публикува злонамерен URL в блог или сайт
на социална мрежа като Facebook или Twitter. Когато потрбителят
щракне върху линка, зловредният сайт, както и скриптът, заработват
в браузера му. Обаче браузерът не знае, че скриптът е злонамерен
и сляпо изпълнява програмата, която на свой ред позволява на
10

11. скрипта на нападателя да получи достъп до функционалността на
сайта, за да открадне „бисквитките” или да извърши транзакции,
представящи се за легитимен потребител.
Минимални изисквания, за да се стартира XSS атака
 Web-приложение, което показва данни директно въведени от
потребителите без необходимото филтриране или коректна
трансформация;
 Ако атаката се провежда чрез JavaScript, VBScript, ActiveX
браузер, който поддържа някоя от тези технологии;
 HTML injection атаката работи със всички браузери.
До какво може да доведе една XSS атака?
 Крадене на акаунти, промяна на потребителски настройки,
крадене на „бисквитки”, подправяне на „бисквитки”,
непозволено рекламиране, Denial of Services атаки, използване
на клиента като трамплин за атака на други сайтове и т.н.;
 Използване на FORM за крадене на информация (подвеждане
на потребителя, ако ползва SSL);
 Добиване на достъп до данни, до които атакуващият няма
права;
 Единственото ограничение е въображението на атакуващия.
Защити, приложени от програмистите на web-приложения
 Подсигуряване, че динамично генерираните страници не
съдържат потребителски данни, които не са проверени;
 Твърдо оказване на character set-а, който ползва страницата;
 Използване на POST,а не GET във формите;
 Използване на HTTP ONLY „бисквитки”.
Защити, приложени от администраторите
 Обновяване на web сървърите, които позволяват XSS атаки да
се провеждат през страниците за грешки на самите сървъри.
11

12. 3.2. Cross-Site Request Forgery (CSRF)
Какво представлява Cross-Site Request Forgery (CSRF)?
Cross Site Request Forgery (CSRF) е подход, който често използва
XSS уязвимост в приложението, чрез която се достига
компрометиране на самото приложение. Обикновено се използва
потребител, на който приложението има „доверие“ (например такъв
с административни права). Така атакуващият, като обикновен
потребител, не би могъл сам да предизвика желания резултат и
поради тази причина използва XSS уязвимост за изпълнение на
заявка чрез друг потребител (с по-високи права).
CSRF е широко използвана уязвимост на web страниците. В тази
атака атакуващият нарушава цялостта на потребителската сесия с
web страницата като инжектира заявка по мрежата посредством web
браузера на потребителя. Политиката на сигурност на браузерите
позволява web адресите да изпращат HTTP заявка до който и да е
мрежови адрес. Последната политика позволява атакуващ, който
контролира съдържание, което потребителя зарежда, да използва
ресурси, които иначе не са под негов или нейн контрол:
 Мрежови достъп: Например, ако потребителят е зад защитна
стена (firewall), атакуващият е в състояние да накара браузера
на потребителя да изпрати мрежови заявки до други машини
12

13. зад защитната стена, които машини може да не са пряко
достъпни от машината на атакуващия.
 Прочитане на състоянието на браузера: Заявки, изпратени
чрез браузера по принцип включват състоянието на браузера
като „бисквитки”, клиентски сертификати и основни
удостоверационни хедъри. Web страници, които разчитат на
тези удостоверения може да бъдат объркани от такива заявки.
 Промяна на състоянието на браузера: Когато атакуващият
накара браузера да изпрати мрежова заявка, браузерът също
обработва отговора.
Ето и 2 модела на заплаха, различаващи се по възможностите на
атакуващия:
 Публикация във форум: Много web страници като форумите
позволяват на потребителите да предлагат ограничени видове
съдържание. Например, страниците често позволяват на
потребителите да качват пасивно съдържание като снимки и
хиперлинкове. Ако атакуващ зададе злонамерен URL на
снимка, мрежовата заявка при зареждане на снимката може да
доведе до CSRF атака.
 web атака: Атакуващият кара потребителя да посети web
страница управлявана от първия. Ако потребител посети
такава страница, тя от своя страна може да зареди CSRF
атаки с GET или POST HTTP методи.
Как да се защитим от web атаката CSRF?
Има разнообразни начини за защита от CSRF, но най-общото е
повторно изпращане на удостоверяващата автентичност заглавна
част на заявката (в повечето случаи това са „бисквитки”) най-малко
за всички заявки, които водят до промяна на състояние на
потребителската сесия. Това се постига чрез скрити полета в HTML
формите или се влага в URL адреса на действието.
В CSRF атакуващият няма достъп до оторизационните данни (под
формата на уникален ключ за сесията, съдържаща се най-често в
„бисквитките”, който на сървъра отговаря на потребителя и така на
неговите данни и права), а само използва поведението на браузера
при заявка до даден адрес да прикача към заявката „бисквитките”,
принадлежащи към домейна на страницата.
13

14. 3.3. SQL инжекция
Какво представлява SQL инжекцията?
Има много начини една система да бъде пробита. Когато става
дума за web базиран софтуер, това най-често става със SQL
инжекции. Това е най-разпространения начин за атакуване на web
сайт.
В най-общи линии SQL инжекциите са уязвимости с начина на
обработка на заявките към SQL сървъра. Обикновено бива подаван
параметър, който освен информацията с ключа за конкретен запис,
съдържа и допълнителен код. По този начин хакерите могат да
извличат информация от базата данни. Това могат да бъдат e-mail
адреси, които след това се използват за спам цели,
администраторски профили и друга конфиденциална информация.
Ето защо е важно да бъдат използвани силни пароли. Те се пазят в
базата с данни в криптиран вид. От своя страна лесно се разбиват
(посредством Bruteforce и MD5 Hash databases) лесните пароли.
Обикновенно сложните не могат да бъдат декриптирани. Всеки един
програмен език е уязвим към SQL инжекции. Най-често те се срещат
при PHP, Perl, ASP.NET.
Как работят атаките с SQL инжекции?
Нападателите получават достъп до Web-приложенията чрез SQL
инжекция, като добавят Structured Query Language (SQL) код към
кутийка на web форма за въвеждане под формата на SQL заявка,
което е искане към базата данни да изпълни специфично действие.
Обикновено по време на потребителското удостоверяване се
въвеждат потребителско име и парола и се включват в запитване.
След това на потребителя или му се предоставя, или му се отказва
достъп в зависимост дали е дал правилни данни. Web формите
14

15. обикновено нямат никакви инструменти за блокиране на въвеждане
освен потребителското име и паролата, което означава, че хакерите
могат да изпълнят атака с SQL инжекция, като използват входните
полета, за да изпратят заявка към базата данни, която е много
вероятно да им предостави достъп.
Как да се справим с хакерските атаки с SQL инжекция?
Има няколко стъпки, които всяка организация може да
предприеме, за да намали вероятността да стане жертва на атака с
SQL инжекция:
• Да ограничи привилегиите за достъп на потребителите
Давайте на служителите и потребителите само достъп до
информация, от която се нуждаят, за да изпълнят своите задачи.
• Осигурете бдителност на потребителите по отношение
на сигурността
Убедете се, че служителите, които имат нещо общо с
разработването на Web сайта (както и специализираните Web
разработчици), съзнават заплахите от SQL инжекции и познават
добрите практики, с които да обезопасяват сървърите ви.
• Намалете информацията за отстраняване на бъговете
Когато един Web сървър сигнализира грешка, осигурете подробната
информация за нея да не се показва на потребителя, тъй като тази
информация може да помогне на хакерите да извършат
злонамерени действия и да се сдобият с информацията, която им е
нужна, за да атакуват успешно сървъра.
• Тествайте Web-приложението
Тествайте Web-приложението и проверете работата на Web
разработчиците чрез изпращане на информация през Web сървъра
– ако резултатът е съобщение за грешка, то е вероятно
приложението да е податливо на атака с SQL инжекция.
15

16. 3.4. Distributed Denial of Services (DDoS)
Какво представлява Distributed Denial of Services (DDoS)?
Увеличената честота и сложност на Distributed Denial of Services
(DDoS) атаките рязко промениха представите за мрежова и
информационна сигурност. Спирайки ги чрез защитна стена те
започнаха да се превръщат в едно все по-скъпо и все по-малко
ефективно начинание. В резултат, на което филтрирането и
отстраняването на тези атаки, се е превърнал в един от огрмните
проблеми на всяка една организация.
Най-общо казано DDoS атаките умишлено възпрепятстват
достигането до информационните ресурси на Internet потребителя,
обикновено чрез претоварване на мрежата чрез изпращане на
излишен трафик от много източници. Този вид атаки обикновено се
осъществяват като излишния трафик бъде инжектиран в онзи, който
трябва да стигне до самите потребители. Най-често това нещо се
извършва от ботове, които на ден използват средно между 4 и 6
милиона потребителски станции, за да разпространяват именно
този код. Такъв вид атаки силно натоварват трафика, като крайната
им цел е всяка следваща станция, докато не се стигне до някой
сървър.
16

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

18. Няколко производители предлагат устройства за DDoS защита и
предотвратяване, които са конструирани специално за откриване и
осуетяване на DDoS атаки.
• Подгответе се за отговор
Използването на регулиращи и ограничаващи технологии може да
намали въздействието от DDoS атаката.
• Поддържайте резервна интернет връзка с отделна база с
интернет адреси за критични потребители
Това ще ви предложи алтернативен път, ако първичната верига е
претоварена със злонамерени заявки.
3.5. Buffer Overflow
Какво представлява Buffer Overflow и как работи?
Buffer overflow (или Препълване на буфер) се случва, когато в
буфер или друго място за съхранение на данни се сложи повече
отколкото буферът може да съхранява. Буферът е временна област
за съхранение на данни. Когато там се поставят повече данни,
отколкото е предвидено първоначално от даден програмен и
системен процес, допълнителните данни ще го препълнят, откъдето
произлиза и името, причинявайки част от данните да изтекат към
други буфери, което може да разруши данните, които те съдържат
или да запише върху тях.
По-горе посочената фигура изобразява най-основните поредици
от събития при една Buffer Overflaw атака:
18

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

20. Как да се справим с Buffer Overflaw атаките?
След като знаете как работи атаката с препълване на буфера, по-
лесно ще разберете как да я спрете да не се инфилтрира във
вашата система и да поеме контрол над приложенията. Тук са
дадени няколко начина за подсилване на вашата защита и
предотвратяване на буферното препълване:
1. Избягвайте да използвате библиотечни файлове.
Библиотечните файлове, които се използват в езиците за
програмиране и по природа са несигурни, са цел за хакерите по
време на атаките срещу приложенията. Всяка слабост, намерена от
хакера в библиотечния файл, ще съществува също във всички
приложения, които използват библиотечни файлове, давайки на
хакерите блестяща цел за потенциална атака.
2. Филтрирайте въвежданията от потребителите.
Филтрирайте вероятни опасни HTML кодове и знаци, които могат да
причинят проблеми с базата данни. Например в ASP кода
апострофът, кавичките, амперсантът са запазени символи. Тези
запазени символи не могат да се включват в данните, въвеждани от
потребителите или те ще причинят счупване на приложението.
Филтрирайте ги и ги заменете с нещо друго, за да избегнете
усложнения и проблеми.
3. Тествайте приложенията.
Тествайте приложенията преди внедряването им. Опитайте се да
пробиете всяко приложение, за да си осигурите сигурни кодове. Ако
приложението бъде пробито, ще е ясно, че има проблем, който се
нуждае от поправка, преди да се даде възможност на хакерите да се
възползват от него.
4.6. Source Code Disclosure (SCD)
В най-общи линии Source Code Disclosure (SCD) атаките
позволяват на злонамерения потребител да получи изходния код на
server-side приложение. Тази уязвимост предоставя на хакерите по-
дълбоко познаване на логиката на самото Web-приложение.
Нападателите използват SCD атаките, за да се опитат да получат
изходния код на server-side приложенията. Основното правило на
web сървърите е да служат на файловете, както се изисква от
клиентите. Файловете могат да бъдат статични, каквито са HTML
файловете, или динамични, каквито са ASP, JSP и PHP файловете.
Когато браузерът изисква динамичен файл, web сървърът първо
20

21. екзекутира файла и тогава връща обратно резултата на браузера.
Следователна динамичните файлове са действително код
изпълними на web сървъра.
С помощта на SCD атаката атакуващият може да изтегли
изходния код на server-side скриптовете като ASP, PHP и JSP.
Получаването на изходния код на server-side скриптовете
предоставя на хакерите по-дълбоко познаване на логиката на Web-
приложенето, т.е. как приложението ръководи исканията и техните
параметри, структурата на базата данни, уязвимостите в кода и
коментарите относно изходния код. Имайки изходния код и
евентуалното издаване на дубликат на приложението за тестване,
помагат на нападателя да се подготви за нападение на самото Web-
приложение.
Всеки един хакер може да причини SCD, използвайки една от
следните методи:
 Използване на познати уязвимости за source disclosure;
 Експлоатиране на уязвимостите в приложението, което може
да позволи source disclosure;
 Разработване на подробни грешки, които могат понякога да
включват изходния код;
 Използване на други видове добре познати уязвимости, които
могат да бъдат полезни за source disclosure.
21

22. Заключение
В днешно време най-простият начин за компрометиране на
конфиденциалната корпоративна информация е използването на
уязвимостите на Web-приложенията. Как да се открият и отстранят
тези от тях, които са недостатъчно надеждни?
От препълване на буферите до SQL инжекциите хакерите имат
много методи на разположение за атака на Web-приложения, като
непрекъснато се появяват и нови методи. Атаките срещу Web-
приложенията може да струват много време и пари на
организациите, както и да доведат до скъпи и неприятни пробиви на
сигурността на данните, което прави изчерпателните стратегии и
механизми за защита задължителни.
В тази връзка съществуват няколко съвета за защита срещу атаки
към Web-приложенията – от появата им, идентифицирането на
известни и неясни атаки, включително Cross-Site Scripting (XSS),
Cross-Site Request Forgery (SCRF), SQL инжекция, разпределен
отказ от услуги или Distributed Denial of Service (DDoS), препълване
на буфер или Buffer Overflaw, Source Code Disclosure, както и много
други.
22

23. 1.http://download.pomagalo.com/435482/vidove+web+bazirani+prilojeniya/
2.http://www.referati.org/razrabotka-na-web-prilojeniq-s-java/22743/ref
3.http://www.isportals.com/blog/2010/10/predimstva-na-web-bazi-danni/
4.http://review.sagabg.net/izbor-na-podhodyashata-zashitna-stena-za-ueb-prilo.html
5.http://review.sagabg.net/kak-da-zashitim-ueb-prilozheniyata-predotvratyavan.html
6.http://cio.bg/2990_zashtitata_na_na_ueb_prilozheniyata__prilozhete_prevantiven_
podhod
7.http://www.securiteweb.org/jamsec_webdefenseur_2010_web_attack_protection/w
eb-attacks.html
8.http://www.acunetix.com/websitesecurity/cross-site-scripting.htm
9.http://community.citrix.com/display/ocb/2010/04/29/How+to+use+NetScaler+Applic
ation+Firewall+to+defend+against+CSRF+attacks
10.http://www.imperva.com/resources/glossary/source_code_disclosure.html
23