1. ИКОНОМИЧЕСКИ УНИВЕРСИТЕТ – ВАРНА
Реферат
по
Безопасност и защита
на тема
API-автентификация и безопасност и защита на
web-приложения
Разработил: Поля Петкова
специалност Информатика, група 59, ф.н. 10611

2. Съдържание
Въведение................................................................................................3
1. Какво е Web API и защо му е нужна автентификация?................................3
2. Видове API...............................................................................................................4
3. Сигурност и автентификация на API.................................................................5
3.1. Идентификация..............................................................................................6
3.2. Автентификация............................................................................................7
3.2.1. Потребителски имена и пароли........................................................7
3.2.2. Автентификация базирана на сесиен достъп................................8
3.2.3. OAuth......................................................................................................8
3.2.4. OpenID автентификация....................................................................9
4. Десет потенциални опасности и заплахи за API............................................10
5. Web-приложения...................................................................................................12
5.1. Web-приложенията? Какво знаем за тях?...............................................12
5.2. Предимства и недостатъци на Web-приложенията...............................12
5.3. Видове Уеб приложения..............................................................................13
6. Методи за атаки и защита на web приложения...............................................14
6.1. Препълване на буфера..................................................................................14
6.2. Cross-site scripting (XSS)................................................................................16
6.3. SQL инжекции................................................................................................17
6.4. Distributed Denial of Services (DDoS) атака................................................18
6.5. Source Code Disclosure (SCD)........................................................................19
Заключение................................................................................................20
Използвана литература и източници...................................................21
2

3. Въведение
Използването на интернет с времето става все по неразривна част от нашия
живот. Всекидневно се налага извършването на какви ли не действия изискващи
автентификация. Тя е нужна, защото колкото и удобно нещо да е интернет, то се
превръща и в огромна заплаха. Причината е, че хакерските атаки стават все повече и
по- професионални. В следствие на тяхното развитие изтичането на данни в интернет
се превръща в един от най-големите страхове на съвременното общество. Кражбата на
лични данни и самоличност може да причини невъобразими щети на пострадалия
потребител. От финансови загуби до много лоши последствия. Изискванията за
сигурност са неразривна част от процеса на програмиране. Повечето хора дори не
подозират колко време, планиране и усилие се отделят за подсигуряване на всички
процеси, с които клиента комуникира. За да използват хората спокойно услугите,
програмите и приложенията, които се създават всекидневно и особено тези, които
изполват интернет, трябва да се подсигури тяхната безопосност. Важен момент в този
процес е използването на проверки на въведените данни. За съжаление има
разработчици, които си спестяват работа по тази част и така излагат на потенциален
риск бъдещите си клиенти.
1. Какво е Web API и защо му е нужна автентификация?
API (Application Programming Interface) или Приложният програмен интерфейс е
набор от кодове и стандарти за достъпване на уеб-базирани приложения и услуги.
Според Josh Walker анализатор в Forrester Research Inc. Cambridge, Mass.
изграждането на приложение без API е равносилно на построяване на къща без врати.
Ако приложението има API то може да комуникира с други приложения и да използва
информация от тях. По този начин функциалността на приложението или услугата,
която се предлага може лесно да бъде разширена, което да доведе до по-голям
потребителски интерес. За да стане по-ясна връзката и възможностите, които се
използват ще дадем пример с http://geotweeter.com/ това е приложение, което използва
данните от GoogleMaps API и Twitter API като позволява да се добави точното ви
географско положение, когато публикувате нещо ново в Twitter.
От маркетингова гледна точка използването на API може да се използва за
разпространение на марката. Например когато Facebook пуска своето API, много
сайтове интегрират техния Like бутон и така използват лесен начин за допълнителна
реклама, както на своята фирма, така и на самия Facebook.
Тъй като API се използват за събиране, записване и опресняване на
информацията (update) важен момент е автентификацията. Чрез нея всеки потребител
след регистрация може да докаже пред системата своята самоличност и да достъпи
съответните ресурси, които се предлагат. Често срещан метод да автентификация е
използването на име и парола за достъп, но съществуват и други техники, които ще
разгледаме по-нататък.
3

4. Казано накратко API е вратата, през която трябва да минете, за да използвате
приложения. Ако имате правилния ключ, ще имате възможност да достъпите продукти
и услуги използвайки различни устройства.
Много облачни услуги са достъпни чрез използване на прости REST Web
Services интерфейси. Те са обикновено се нарича API, тъй като са подобни на старите,
по-тежка категория C + + или Visual приложни програмни интерфейси (API). API
интерфейсите обаче са много по-лесни да се заредят от уеб страница или от мобилен
телефон, а оттам нараства тяхната популярност.
Компаниите често искат да свържат своите бизнес приложения към облачни
услуги и облачни услуги към облачни услуги. Това е възможно, но крие своите
рискове, защото връзките трябва да са подсигурени максимално.
2. Видове API
Съществуват два вида API: частни и публични. Противно на очакванията частните Аpi-
ta са най-разпространени. API с публичен достъп са свобони да бъдат използвани от
всеки с малки или почти никакви договорни условия. Частните API се използват по
различни начини, например като връзка с други такива. Такива се предлагат и на
големи кръгове от хора, но със съответните договорни споразумения за ползване. Често
разработването и замисъла на едно API е като частно, но с времето може то да бъде
изменено така че да предоставя частичен или пълен публичен достъп, но с някои
ограничения. В други случаи може да бъде разработено API с публичен достъп, но
разработчиците да осъзнаят, че то ще изпълнява прекалено важна роля и в крайна
сметка, за да се извлекат ползите от него, то се превръща в частно. Предлагането на
различни видове API особено ако са гъвкаво разработени за различни групи клиенти
привличат по-голям интерес. Например за публични клиенти едно API може да
предлага търсене на статии, но да показва само част от текста им, а когато се ползва
като частно се визуализира целия текст. С публичен или с частен достъп API почти
гарантирано увеличават трафика от потребители към вашия сайт. Компании като
Google, Amazon, Twitter и много други използват всякакви API за да променят и
развият своя бизнес. В един от постовете си блогърът Robert Scoble обобщава
различните ери през годините по следния начин:
- През 1994 интернет е бил в ерата на “купете си domain и си направете страница”
- През 2000 интернет е бил в ерата на “направети си странците интерактивни, за
да привлечете хората в тях”
- През 2010 интернет е бил в ерата на “отървете се от страниците и залепете
хората и APIта заедно”
Определено нещата са точно така и в наши дни, когато за много неща хората използват
различни API. Като едно от най-често използваните е това, което се базира на
геолокация. Ето как Google Maps става неразривна част от нашия живот, предлагайки
ни бърз и лесен достъп до информацията, която ни вълнува.
4

5. 3. Сигурност и автентификация на API
Мисълта за ефективна защита на API трябва да бъде заложена още в процеса на
формулиране на дизайна. Методите, които се използват за сигурност трябва да бъдат
съобразени с бизнеса или вида потребители, които ще достъпват API. Ако то използва
финансови данни през публични мрежи, е задължително да се вземат много сериозни
мерки за сигурност. Има няколко важни въпроса на които трябва да се даде отговор
преди преди да се изгради дизайна:
- Какви аспекти и данни ще трябва да бъдат подсигурени? Колко точно трябва да
е нивото на сигурност за тези аспекти?
- Дали мерките за сигурност, които се предвиждат ще забавят изпълнението или
затруднят реализирането на кода?
- Кой ще използва API? Трябва ли потребителите да се идентифицират преди да
използват приложението, което използва API?
- Достатъчно ли е да се идентифицира само приложението, което се използва или
трябва и потребителя да се идентифицира?
Много малко API работят без никаква автентификация, като регистрация например.
Повечето API използват една или повече техники за сигурност:
Идентификация
Кой прави запитване към API?
Автентификация
Наистина ли е този, който твърди че е потребителя?
Ауторизация
Разрешено ли е на този, който опитва да достъпи съответните ресурси да го
направи?
Дали има нужда от тези три заедно? Вероятно не. Всичко зависи от това за кого е
предназначено API и какво има да другия му край, тоест услугата или програмата,
която ще се стартира. След отговор на първичните въпроси, естествено следват
различни допълнителни подвъпроси към всяка категория от изброените горе.
5

6. 3.1. Идентификация
Една от първите стъпки, за да се подсигури едно API е да се избегне
неоторизиран достъп. Един от начините да се определи кое приложение използва API е
като се използва API ключ.
Такъв вид ключ се появява още с първите публични уеб услуги на Yahoo! и
Google. Разработчиците искат да имат начин да идентифицират приложенията, които се
обръщат към тях, без сложността на паролите. API ключовете са прости, произволни
идентификатори работещи с HTTP заявки и параметри или нещо друго равностойно, но
просто, което да се използва във всяка API заявка. За да може разработчика да създаде
приложение с API трябва да използва уникален ключ, който да използва всеки път. Тъй
като могат да се използват метрики базирани на използването на API ключа, може да се
следи как се използва приложението и колко често. От гледна точка на
идентификацията API ключа е мощно средство и предпочитан избор, заради своите
възможности за проследяване на активността.
Тъй като тези ключове са прости и лесни за използване, те често не са
криптирани, което ги прави сравнително лесни за откриване и атакуване от хакери. По
тази причина използването им като средство за защита не е препоръчително, но от
гледна точка на анализите и наблюденията е добро средство. Въпреки това за някои
API подобен ключ е всичко, от което се нуждаят.
Въпреки че API ключа не е средство за автентификация, той може да се използва
за други дейсности свързани със сигурността. Например това е подходящ метод за
изключване на достъпа на зловредни приложения, които само пълнят системата със
заявки и запитвания. Филтрирането или блокирането на трафик от такива приложения е
ефективен начин за защита от тях.
Например Facebook след автентификация на потребителя дава възможност за
контрол на личните данни, които трети страни могат да виждат. Но много други API не
изискват потребителя да се впише в системата. Такива примери са Google Maps и
Yahoo! Maps.
6

7. Като цяло защитата, чрез някаква форма на идентификация е добро решение и не
трябва да се пренебрегва при изграждане на дизайна. Да се разчита обаче само на API
ключ не е удачен избор, когато се разбори с важни данни и услуги.
3.2. Автентификация
Автентификацията е начин да се покаже, кой сте вие за системата. Чрез този
метод се показва дали някой, който се опитва да достъпи API е този, за който се
представя. Методът за автентификация често използва потребителски имена и пароли,
както и по-често използвания метод OAuth.
3.2.1. Потребителски имена и пароли
Когато се работи с важни данни обикновено API ключа не е достатъчно
средство. Той е имплантиран в изходния код на мобилните приложения и може да бъде
изпратен в текстово съобщение през мрежата без никакво кодиране. Това не
представлява проблем, когато ключа се използва за наблюдения и анализи, но тъй като
излагането на ключа в мрежата може да засегне милиони устройства, не е добре да се
разчита на него, когато се работи с данни. Алтернатива е използването на потрбителски
имена и пароли, като тази схема на автентификация се използва от много сигурни
сайтове.
Лесен начин за автентификация е използването на HTTP, който почти всички
клиенти и услуги поддържат. Този метод не се нуждае от специална обработка ако
потребителят спази известни правила за сигурност, за да запази паролата си в тайна.
Използването на протокола SSL за всички комуникации спомага за предотвратяване на
разбиването на паролата от недоброжелатели.
Потребителските имена и пароли се използват успешно и при комуникацията
между две приложения. Единственото препятствие от потребителска гледна точка е
съхранението на паролите. Ако съхранявате потребителските имена и паролите си в
файл е добра идея да го криптирате по някакъв начин, за да предпазите информацията в
него.
Използването на потребителски имена и пароли крие риск, защото потребителят
може да стане жертва на “phishing”. Това е начин за кражба на пароли, електронни
адреси на пощи и дори информация за кредитни карти като се прави имитация на
разпространени и надеждни сайтова и услуги в интернет. Маскираните сайтове
подлъгват потребителите да си попълнят личните данни в полета, които изглеждат като
оригиналните в истинския сайт, а последиците от това могат да бъдат много тежки.
Истината е, че дори използването на SSL за защита може да се окаже недостатъчно
средство за защита.
7

8. 3.2.2. Автентификация базирана на сесиен достъп
Много от ранните Аpi поддържат автентификация базирана на сесиен достъп.
Реализирането на този метод започва с идентифицирането на потребителя с име и
парола, които се вземат на входа и в замяна се получава сесиен ключ. Този ключ
идентифицира потребителя и неговите действия и когато се приключи работа е
необходимо потребителят да се отпише, за да прекрати сесията. Много от първите
случаи в които се е ползвал този метод са използвали cookie или бисквитка, по този
начин се е осигурявал контрол и над броя потребители, които са достъпвали
съответното API. Използването на сесии свързани с бисквитки позволява Аpi да остане
без състояние, тоест избягват се всякакви състояния и действия, които да изисват
променливи, които могат да бъдат разкодирани от хакери и да застрашат сигурността.
3.2.3. OAuth
OAuth е отворен протокол, който позволява сигурна API автентификация на
десктоп и уеб приложения чрез прост и стандартен метод. Много от големите
разпространители на API са имплементирали OAuth като начин за достъп до техните
API. Принципа на работа на OAuth е управлението на достъпа до системата чрез
“handshakes” (ръкостискане) между приложенията. Осъщесвява се връзка, която
позволява да използвате услуги и приложения, които изискват автентификация, без те
да могат да “видят” вашата парола.
Пример за използване на OAuth е заложен във връзките между социалните
мрежи като Facebook и Flickr. Нека за вземем следния пример: потребител иска да
вземе снимки от Flickr и да ги публикува в Facebook, но без да се налага да си пише
паролата за Flickr във Facebook. В миналото, когато се е използвала HTTP
автентификация Facebook щеше да се наложи да съхранява потребителската парола
някъде. Това би било голям проблем особено за потребителя, защото ако реши да смени
своята парола, а тя се съхранява от много различни сайтове, може да доведе до
проблеми с достъпа.
Вместо да се разчита на една парола като основен ключ за всички приложения
които достъпват API, OAuth създава token или символен низ. Принципа на работа е
като допълнителен ключ на колата, който може да отваря само вратата и да запали
двигателя, но без да може да отваря багажника или нещо друго. В случая един OAuth
token дава достъп на едно приложение до едно API свързано с действията на един
потребител. За разлика от този метод паролата би дала достъп на всяко приложение до
всичко, което паролата може да отключи. Това се превръща в опасност, защото много
потребители си избират една парола за много приложения и сайтове и ако тя бъде
разбита, потребителят ще пострада сериозно.
8

9. Друга полза от OAuth token е когато потребителя използва мобилен телефон,
защото тогава не се налага той всеки път да въвежда паролата си. Телефонът съхранява
token вместо паролата и ако телефонът бъде откраднат, крадецът няма да може да
разгадае паролата, а само token, който ако е настроен ще изтече след известно време.
Тъй като се разчита на token за сигурност вместо на споделена парола, OAuth
прави API много по-надеждни. Тоест ако потребител на Facebook например се съмнява,
че някой е разбрал паролата му и се притеснява за всички приложения, който
комуникират с Facebook са застрашени, ако те използват OAuth е достатъчно да се
смени паролата само на Facebook и всичко ще е наред.
За да работи OAuth handshake всяко приложениев, което използва API се нуждае
от удостоверения подобни на API ключа, за който има обяснение по-нагоре. Това
позволява на API разпространителя да упражнява контрол над достъпа до API.
Например ако Flickr е атакуван от хакери и неговата сигурност е под въпрос, то
администраторите на Facebook имат възможността да отмени достъпа на Flickr OAuth
акредитацията и така да спре достъпа на всичките си потребители до Flickr през
Facebook.
Тъй както съхранението на пароли на сървър се нуждае от сериозна защита, така
и съхранението на OAuth tokens представлява въпрос, който има своята важност.
Криптирането на данните когато са на сървър е начин за предпазването им от
злоупотреби и атаки.
3.2.4. OpenID автентификация
OpenID съществува, за да разреши споделена идентичност, където потребителя
може да се автентикира с една и съща самоличност в много сайтове. Потребителя и уеб
приложенията имат доверие в Google, Yahoo! и Facebook като способни да пазят
информация за профилите и да аутентификират потребителите на приложенията. Това
елиминира нуждата за всяко уеб приложение да се изгражда отделна система за
автентификация и прави много по-лесно и бързо за потребителите да се идентифицират
пред сайтове в мрежата. Начинът по който OpenID и OAuth работят заедно е следния.
1. Приложение се обръща към OAuth за ауторизация за един или повече OpenID
елемента (email, адрес) като пренасочва потребителя към сайт, който разполага с
идентичности на потребителите като Google, Yahoo! и Facebook.
2. След като потребителя потвърди запитването за ауторизация, браузъра на
потребителя се пренасочва към приложението. Приложението прави запитване
към Check ID крайна точка. Тази проверка връща идентификационните данни на
потребителя (user_id) както и други битове с данни, които да бъдат потвърдени
от клиента, за да се подсигури валидната автентификация.
9

10. 3. Ако клиента изисква допълнителна информация за потребителя, като цяло име,
снимка, електронна поща, клиента може да направи запитване към UserInfo
Endpoint.
4. Десет потенциални опасности и заплахи за API
1. Инжектиране на зловреден код: засягат се услугите, които използват SQL /
LDAP / XPath / XQuery механизми за входните данни, подавани от
потребителите. Политиките за откриване на инжектиран код е да филтрирате
SQL, LDAP, XPath, XQuery инжекция или да използвате XPath и XSD
технологии, за да филтрирате допълнително заявките. Филтърът също така може
да се интегрира с антивирусни продукти, за да сканира за вирус в заявките на
API.
2. DOS Attacks: Denial of Service (DoS): цели се предпазването на API или
услуга от умишлени неправомерни действия от страна на потребителя. Това
могат да бъдат огромни съобщения, рекурсивни съобщения и голям брой други
опити да се претовари системата. The ServiceNet Message Payload е политика за
сигурност, която засича повечето опити за DoS атаки и предпазва доста
успешно.
3. Изтичане на инфомация: API може да дава инфомация за настройките,
вътрешната работа или съобщения за грешки, без да го прави нарочно.
Например дългите и информативни съобщения за грешки, могат да доведат до
изтичане на данни и разкритата информация може да се използва от хакери за
по-сериозни атаки. Има политики за сигурност, които ако се приложат правилно
могат да изкоренят проблема и да предпазят от атаки.
4. Повредена автентификация, сесиен номер или ключ: От особено значение
е правилното управление на автентификацията, API ключа и сесийния достъп.
Пропуски в тази област може да доведат до грешки при автентификация, лесни
за разпознаване сесийни стойности, които позволяват на хакера да копира или
подправи ключовете и token-ите.
5. Грешки при защитата на API и съответния достъп до данни: Често
оторизацията се базира само на API. Хакера може да насочи атаките си към
различни параметри на API операциите и да получи достъп до данни, за които не
е оторизиран. Използването на повече от един вид оторизация може да предпази
от подобни атаки.
10

11. 6. „Подслушване“ на данните на API: Грешки при криптирането на API
връзки и комуникации дава възможност на хакера да следи и “подслушва”
трафика през интернет и да добие достъп до ценна информация, която се
използва от API. Използването на криптирани връзки и следене на трафика,
може да помогне да се избегнат такива пробиви.
7. Подправяне на API запитвания и отговори: Атаки базирани на
манипулации на заявките за запитване и отговор между клиента и услугата с цел
промяна данните на приложението са много сериозна заплаха. С такава атака
могат да се изменят прозволенията на клиента или цени и суми с които той
борави. Тъй като се използва част от HTTP частта на заявките, трябва да се
внимава много и да се предвиди политика за сигурност от подправяне на API
запитвания и отговори.
8. „Гръмнали“ заявки: заявки които могат да нарушат работата на API и да
доведат до дефекти, които могат да засегнат работата на сървъра. Използването
на техники за защита от претоварване и различни видове заявки може да
помогне да се избегнат повреди на сървъра и данните, които съхраанява.
9. Одит –Ако API е проектирано да управлява парични суми, то е задължително
да се използват специфични практики и регулации на работата. Наблюдението
на цели или части от заявки и отговори от системата както и работата на
11

12. оторизирани и неоторизирани потребители е част от тези практики.
Използването на Log файлове в случая спомага за наблюднието.
10. Откриване и анализиране на заплахите: Анализирането на данните
заплашени от атаки е важно за откриването на грешки и поправянето на
слабостите в API инфраструктурата. Използването на средства, които да
визуализират и анализират различни грешки в API особено ако са подредени по
степен на сериозност, помагат на архитектите и разроботчиците на API да се
справят с проблемите.
5. Web-приложения
5.1. Web-приложенията? Какво знаем за тях?
Разделянето на различните видове приложения в различни категории и подкатегории
обуславя ясно и точно дефиниране на самото понятие „Web-приложения". То се състои
от две думи, всяка от които носи важна информация. Под Web, което се използва за
съкратено представяне на World Wide Web, се разбира Интернет или необятното
информационно поле на световната мрежа. Думата „приложение" според сайта
Whatis.com е програма, проектирана да изпълнява специфични функции за
потребителя или, в някои случаи, за друга приложна програма. Например за
приложения като обработка на текст, програми за бази от данни, браузъри за Internet,
инструменти за разработка и комуникационни програми. Приложенията използват
услугите на операционната система на компютъра и други поддържащи приложения.
Накратко Web-приложение е софтуер, който работи в интернет браузъра. В това кратко
определение може да се допълни, че този код е със строго определена цел. Това
означава, че Web-приложението изпълнява една или повече зададени задачи.
5.2. Предимства и недостатъци на Web-приложенията
Предимства на Web-приложенията
- Независими от операционната система – Понеже работят в браузър, уеб приложенията
са общо взето независими от конкретната операционна система. Това е огромно
предимство особено, ако става въпрос за по-големи фирми с много компютри;
- По-ниски разходи - И като време и като ресурси, разработката на уеб приложения е
значителни по-евтина от тази на настолен софтуер. В общия случай уеб приложенията
се пишат на същите програмни езици, които се използват за изработка на уеб сайтове.
От една страна тези програмни езици са много популярни и има много програмисти,
12

13. които умеят да пишат на тях, а от друга - съществуват и много готови ресурси, които
могат да намалят времето за разработка и съответните необходими ресурси.;
- Централизирано съхранение на данните – лесно се прави back-up на базата данни,
което позволява да се възстановят данните в случай на проблем;
- Уеб приложението е достъпно от всеки компютър в целия свят (стига да е свързан с
Internet), защото не се нуждае от инсталация. В общия случай уеб приложенията се
намират на сървър;
- Достъпност 24 часа, 7 дни в седмицата - Ограничаването и регулирането на достъпа,
разбира се е въпрос на избор на администратора на приложението и е не само
възможно, но и в някои случаи наложително;
- Винаги ползвате последната версия на web програмата (за разлика от другите
програми, които трябва да се преинсталират или обновят една по една на всеки
компютър);
Недостатъци
Като всички програмни продукти и уеб приложенията имат своята слабост изразена в
сигурността, която могат да предложат, за да гарантират ако се борави с лични данни
на потребителя, то те да бъдат предпазени от зловредни атаки.
5.3. Видове Уеб приложения
Обща класификация на Web приложения използвани в литературата:
- информационни – съдържание само за четене с навигация и връзки;
- за сваляне (dоwnlоads) – информация, която може да се сваля от потребителя;
- по поръчка – съдържанието може да се изработи според нуждите на потребителя;
- за взаимодействие – комуникация между потребителите чрез чат стаи, бюлетини или
моментни съобщения;
- с потребителски вход – комуникация чрез онлайн формуляр;
- транзакционно ориентирани – последователност от действия (продукти и услуги);
- ориентирано спрямо услугите – приложението осигурява онлайн услуга (плащане);
- портал – стартова точка, която насочва потребителя към друго Web приложение извън
домейна на порталното приложение;
- достъп до бази от данни – запитване към база от данни и връщане на резултат;
- хранилища за данни – запитване към колекция от големи бази от данни и получаване
на резулта
13

14. 6. Методи за атаки и защита на web приложения
От препълване на буферите до SQL инжекциите хакерите имат много методи на
разположение за атака на уеб приложения, като непрекъснато се появяват и нови
методи. Атаките срещу уеб приложенията може да струват много време и пари на
организациите, както и да доведат до скъпи и неприятни пробиви на сигурността на
данните. Това прави изчерпателните стратегии и механизми за защита задължителни.
Често използвани методи за атаки на web приложения са:
- препълване на буфера;
- cross-site scripting;
- SQL инжецкии;
- DDoS атаки;
- Source Code Disclosure (SCD);
6.1. Препълване на буфера
Ще започнем с препълване на буфера. Буферът е временна област за съхранение на
данни. Когато там се поставят повече данни, отколкото е предвидено първоначално от
даден програмен и системен процес, допълнителните данни ще го препълнят. Това
причинява част от данните да изтекат към други буфери, което може да разруши
данните, които те съдържат или да запише върху тях. Последователността от действия
в една атака насочена към препълване на буфера е следната:
1. Копират се данни в буфера
2. Данните препълват буфера
3. Оригиналната процедура на адреса за връщане се препокрива от данните
препълващи буфера
4. Адреса който трябва да се върне се изменя от новите данни
5. Новите инструкции, които се зареждат могат да бъдат злонамерени и да
активират вирус
При атака, целяща препълване на буферите, препълващите данни понякога
съдържат специфични инструкции за дейности, проектирани от хакери или
злонамерени потребители. Например данните могат да превключат отговор, който
уврежда файловете, променя данните или разкрива поверителна информация.
Има два типа буферни препълвания – стек базирани и хип базирани.
- Хип (от heap – динамична памет) базираните са по-трудни за изпълнение и затова
се срещат по-рядко. Те атакуват приложението чрез „наводняване“ на пространството
памет, запазено за програмата.
14

15. - Стек (от stack – купчина) базираното препълване на буфера, което е по-често
използвано, експлоатира приложения или програми, като използва това, което е
известно като стек – пространство от паметта, използвано за съхранение на
потребителски въвеждания.
Един стек може да поддържа само определено количество данни и ако входният низ
е по-дълъг от резервираното пространство, резултатът е препълване, създаващо дупка в
сигурността. Хитрите злонанерени хакери търсят такива пробойни със специално
написани команди, които причиняват препълване и задействат атаката. След като
злонамерената команда е причинила препълване, хакерът все още трябва да изпълни
командата, като посочи адрес за връщане, който сочи към командата. Препълването на
буфера „счупва“ частично приложението, но то се опитва да се възстанови, като отива
към адреса за връщане, който е бил пренасочен към злонамерената команда от хакера.
Когато атаката с препълване на буфера задейства командата, намерена в новия адрес за
връщане, програмата смята, че все още работи. Това означава, че командният прозорец,
който е бил отворен, работи със същия набор изпълними разрешения, както
приложението, което е било компрометирано, позволявайки на хакера да получи пълен
контрол над операционната система.
Съществуват три основни начина за защита на web приложенията от препълване на
буфера.
- Да се избягва използването на библиотечни файлове - библиотечните
файлове, които се използват в езиците за програмиране са несигурни и са цел на
хакерите по време на атака. Всяка слабост, намерена от хакера в библиотечния
файл, ще съществува също във всички приложения, които използват
библиотечни файлове, давайки на хакерите блестяща цел за потенциална атака.;
- Да се филтрират въвежданията от потребителите - филтриране на
потенциално опасни HTML кодове и знаци (апострофи, кавички, амперсант),
които могат да причинят проблеми с базата данни. Филтрирайте ги и ги
заменете с нещо друго, за да избегнете усложнения и проблеми.;
- Тестване на приложенията преди да бъдат внедрени – Опитайте се да
пробиете всяко приложение, за да си осигурите сигурни кодове. Ако
приложението бъде пробито, ще е ясно, че има проблем, който се нуждае от
поправка, преди да се даде възможност на хакерите да се възползват от него.
15

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

17. линка, зловредният сайт, както и скриптът, заработват в браузъра му. Браузърът не
знае, че скриптът е злонамерен и изпълнява програмата, която позволява на скрипта на
нападателя да получи достъп до функционалността на сайта, за да открадне кукита или
да извърши транзакции като легитимен потребител.
Защита от Cross-Site Scripting (XSS)
- Подсигуряване, че динамично генерираните страници не съдържат
потребителски данни, които не са проверени;
- Твърдо оказване на character set-а, който ползва страницата;
- Използване на POST, а не GET във формите;
- Използване на HTTP ONLY „бисквитки”.
6.3. SQL инжекции
При този вид атака нападателите получават достъп до уеб приложенията като
добавят Structured Query Language (SQL) код към поле на уеб форма за въвеждане под
формата на SQL заявка, което е искане към базата данни да изпълни специфично
действие. Обикновено по време на потребителското удостоверяване се въвеждат
потребителско име и парола и се включват в запитване. След това на потребителя или
му се предоставя, или му се отказва достъп в зависимост дали е дал правилни данни.
Уеб формите обикновено нямат никакви инструменти за блокиране на въвеждане
освен потребителското име и паролата. Това означава, че хакерите могат да изпълнят
атака с SQL инжекция, като използват входните полета, за да изпратят заявка към
базата данни, която е много вероятно да им предостави достъп.
Предпазване от SQL инжекции
Има няколко стъпки, които всяка организация може да предприеме, за да намали
вероятността да стане жертва на атака с SQL инжекция:
- Да ограничи привилегиите за достъп на потребителите. Давайте на служителите и
потребителите само достъп до информация, от която се нуждаят, за да изпълнят своите
задачи.
- Осигурете бдителност на потребителите по отношение на сигурността. Убедете
се, че служителите, които имат нещо общо с разработването на Web сайта (както и
специализираните Web разработчици), съзнават заплахите от SQL инжекции и
познават добрите практики, с които да обезопасяват сървърите ви.
- Намалете информацията за отстраняване на бъговете. Когато един Web сървър
сигнализира грешка, осигурете подробната информация за нея да не се показва на
потребителя, тъй като тази информация може да помогне на хакерите да извършат
злонамерени действия и да се сдобият с информацията, която им е нужна, за да
атакуват успешно сървъра.
17

18. - Тествайте Web-приложението - Тествайте Web-приложението и проверете
работата на Web разработчиците чрез изпращане на информация през Web сървъра –
ако резултатът е съобщение за грешка, то е вероятно приложението да е податливо на
атака с SQL инжекция.
6.4. Distributed Denial of Services (DDoS) атака
Увеличената честота и сложност на Distributed Denial of Services (DDoS) атаките
рязко промениха представите за мрежова и информационна сигурност. Спирайки ги
чрез защитна стена те започнаха да се превръщат в едно все по-скъпо и все по-малко
ефективно начинание. В резултат, на което филтрирането и отстраняването на тези
атаки, се е превърнал в един от огрмните проблеми на всяка една организация.
Най-общо казано DDoS атаките умишлено възпрепятстват достигането до
информационните ресурси на Internet потребителя, обикновено чрез претоварване на
мрежата чрез изпращане на излишен трафик от много източници. Този вид атаки
обикновено се осъществяват като излишния трафик бъде инжектиран в онзи, който
трябва да стигне до самите потребители. Най-често това нещо се извършва от ботове,
които на ден използват средно между 4 и 6 милиона потребителски станции, за да
разпространяват именно този код. Такъв вид атаки силно натоварват трафика, като
крайната им цел е всяка следваща станция, докато не се стигне до някой сървър.
Хакерите извършват DDoS атака, като експлоатират пролуки и уязвимости в
компютърната система (често Web сайт или Web сървър), за да се позиционират като
главна система. След като веднъж са се поставили в положение на главна система,
хакерите могат да идентифицират и комуникират с другите системи за по нататъшно
компрометиране.
След като нарушителят е поел контрол над множество компрометирани системи,
той може да възложи на машините да започнат някоя от многото атаки за препълване,
докато целевата система се препълни с фалшиви искания за трафик, което ще доведе до
отказ на услуга за ползвателите на тази система. Потокът от входящите съобщения от
компрометираните системи, ще причини спиране на системата цел и отказ от услуги
към нея, което води до невъзможност за достъп на потребителите до каквото и да било.
Предпазване от DDoS атаки
Предотвратяването на DDoS атака може да бъде трудно, тъй като тя е
предизвикателство за това как да се направи разграничение между зловредна заявка за
трафик и легитимна такава, тъй като те използват еднакви протоколи и портове. Все
пак има няколко стъпки, които могат да се предприемат за защита на вашите системи
от разпределени атаки, предизвикващи отказ от услуги:
- Уверете се, че имате излишък от честотна лента във връзката на организацията с
интернет. Това е една от най-лесните защити срещу DDoS, но може да се окаже доста
скъпа. Просто като имате много честотна лента за обслужване на заявките за трафик,
18

19. това може да помогне за предпазване от ниско ниво DDoS атаки. Също така, колкото
по-широка честотна лента има организацията, толкова повече трябва да направи
нападателят, за да запуши връзката й.
- Уверете се, че използвате система за откриване на прониквания (Intrusion Detection
System, IDS). Няколко от наличните днес системи за откриване на прониквания са
снабдени с технологии за защита на системите от DDoS атаки, като използват методи за
проверка и потвърждаване на връзката и за предотвратяване достигането до
корпоративните сървъри на определени заявки.
- Използвайте продукт за защита от DdoS
- Поддържане на резервна интернет връзка с отделна база с интернет адреси за
критични потребители - това ще предложи алтернативен път, ако първичната верига е
претоварена със злонамерени заявки.
6.5. Source Code Disclosure (SCD)
В най-общи линии Source Code Disclosure (SCD) атаките позволяват на
злонамерения потребител да получи изходния код на server-side приложение. Тази
уязвимост предоставя на хакерите по-дълбоко познаване на логиката на самото Web-
приложение.
Нападателите използват SCD атаките, за да се опитат да получат изходния код на
server-side приложенията. Основното правило на web сървърите е да служат на
файловете, както се изисква от клиентите. Файловете могат да бъдат статични, каквито
са HTML файловете, или динамични, каквито са ASP, JSP и PHP файловете.
Когато браузерът изисква динамичен файл, web сървърът първо екзекутира
файла и тогава връща обратно резултата на браузера. Следователна динамичните
файлове са действително код изпълними на web сървъра. С помощта на SCD атаката
атакуващият може да изтегли изходния код на server-side скриптовете като ASP, PHP и
JSP. Получаването на изходния код на server-side скриптовете предоставя на хакерите
по-дълбоко познаване на логиката на Web-приложенето, т.е. как приложението
ръководи исканията и техните параметри, структурата на базата данни, уязвимостите в
кода и коментарите относно изходния код. Имайки изходния код и евентуалното
издаване на дубликат на приложението за тестване, помагат на нападателя да се
подготви за нападение на самото Web-приложение.
Всеки един хакер може да причини SCD, използвайки една от следните методи:
- Използване на познати уязвимости за source disclosure;
- Експлоатиране на уязвимостите в приложението, което може да позволи source
disclosure;
- Разработване на подробни грешки, които могат понякога да включват изходния код;
- Използване на други видове добре познати уязвимости, които могат да бъдат полезни
за source disclosure.
19

20. Заключение
Средствата предложени в днешно време, чрез които можем да комуникираме,
работим и създаваме са неизброимо много. Използването на облачни улуги, които
позволяват използването на ресурси и осъществяването на връзки между услуги,
програми и приложения прави света ни още по- глобален с всеки изминал ден.
Положителните страни на тази технологична и софтуерна глобализация са очевидни и
всичко е в името на потребителя, който получава възможност да бъде мобилен и да
работи бързо и ефикасно. С днешните технологии човек става по-свободен, защото
обвързаността му с ходене до сгради като банките например, за да получи някаква
услуга или до магазините, за да получи стока сега е минимална. Въпреки хубавите
страни, трябва да отбележим и голямото НО което заплашва нищо неподозиращите
потребители. Защитата на личните данни, които попадат в мрежата е опасност, която на
която трябва да се обръща внимание непрекъснато. Истината е, че няма нищо сигурно,
ако някой реши, че вашето API или пък Web приложение трябва да пострада, то това
ще се случи по един или друг начин. Това не значи, че трябва да се примиряваме с този
факт и да не правим нищо по въпроса. Напротив, използването на методи и техники за
защита, както и непрекъснато следене на тенденциите и новите заплахи, както и
начините да се предпазим от тях ще помогнат за изграждането на по-надеждни
продукти.
Не се доверявайте сляпо на нищо и никой, подлагането на съмнение и тестове на
вашите приложения ще гарантира продукти, които потребителите ще използват
доверявайки личните си данни, ако се налага.
Видовете атаки разгледани в тази реферат са основни и могат да ви дадат идея
колко опасности се крият, които може и да не сте предвидили. Имайте предвид, че това
са само част от заплахите за вашето Web приложение. Ако искате надеждно
приложението, което потребителите да харесват и използват, не подценявайте защитата
и сигурността му.
20

21. Използвана литература и източници
1. APIs A strategy Guide - Daniel Jacobson, Greg Brail, and Dan Woods
2. http://www.hotscripts.com/blog/web-apis/
3. https://blog.apigee.com/detail/api_threat_protection_pack_10_xml_attacks_to_avoid
4. РЕФЕРАТ по Безопасност и защита на тема Безопасност и защита на Web-
приложения - Пламена Иванова Митева
21