OWASP или Open Web Security Project е благотворителна организация с нестопанска цел, фокусирана върху подобряване на сигурността на софтуера и уеб приложенията.
Организацията публикува списък с най-добрите уязвимости в уеб защитата въз основа на данните от различни организации за сигурност.
Уязвимостите на уеб защитата се приоритизират в зависимост от използваемостта, откриваемостта и въздействието върху софтуера.
- Експлоатационност -
Какво е необходимо, за да се използва уязвимостта на сигурността? Най-висока използваемост, когато атаката се нуждае само от уеб браузър, а най-ниската е усъвършенствано програмиране и инструменти.
- Откриваемост -
Колко лесно е да се открие заплахата? Най-високата е информацията, показана в URL, формуляр или съобщение за грешка, а най-ниската е изходният код.
- Въздействие или повреда -
Колко щети ще бъдат нанесени, ако уязвимостта на защитата бъде изложена или атакувана? Най-високата е пълна срив на системата, а най-ниската е изобщо нищо.
Основната цел на OWASP Top 10 е да обучи разработчиците, дизайнерите, мениджърите, архитектите и организациите за най-важните уязвимости в сигурността.
Топ 10 уязвимости в сигурността според OWASP Топ 10 са:
- SQL инжекция
- Cross Site Scripting
- Счупено удостоверяване и управление на сесии
- Несигурни препратки към директни обекти
- Фалшифициране на заявки между сайтове
- Неправилна конфигурация на сигурността
- Несигурно криптографско съхранение
- Неуспех при ограничаване на достъпа до URL
- Недостатъчна защита на транспортния слой
- Невалидни пренасочвания и пренасочвания
SQL инжекция
Описание
Инжектирането е уязвимост в защитата, която позволява на нападателя да променя бекенда SQL изрази чрез манипулиране на предоставените от потребителя данни.
Инжектирането се случва, когато потребителският вход се изпраща на интерпретатор като част от команда или заявка и подвежда интерпретатора да изпълнява неволни команди и дава достъп до неоторизирани данни.
Командата SQL, която, когато се изпълнява от уеб приложение, също може да изложи фоновата база данни.
Импликация
- Нападателят може да инжектира злонамерено съдържание в уязвимите полета.
- Чувствителни данни като потребителски имена, пароли и др. Могат да се четат от базата данни.
- Данните от базата данни могат да бъдат модифицирани (Insert / Update / Delete).
- Административни операции могат да се изпълняват в базата данни
Уязвими обекти
- Полета за въвеждане
- URL адреси, взаимодействащи с базата данни.
Примери:
- SQL инжекция на страницата за вход
Влизане в приложение, без да имате валидни идентификационни данни.
Налице е валидно потребителско име и парола не е налична.
Тестов URL: http://demo.testfire.net/default.aspx
Потребителско име: sjones
Парола: 1 = 1 'или пас123
SQL заявка, създадена и изпратена до Interpreter, както по-долу
ИЗБЕРЕТЕ * ОТ Потребители, КЪДЕ Име на потребителя = sjones И Парола = 1 = 1 'или pass123;
Препоръки
- Бял списък с полетата за въвеждане
- Избягвайте да показвате подробни съобщения за грешка, които са полезни за нападателя.
Cross Site Scripting
Описание
Cross Site Scripting е известен също като XSS.
XSS уязвимостите са насочени към скриптове, вградени в страница, които се изпълняват от страна на клиента, т.е. потребителски браузър, а не от страна на сървъра. Тези недостатъци могат да възникнат, когато приложението взема ненадеждни данни и ги изпраща до уеб браузъра без подходяща проверка.
Атакуващите могат да използват XSS, за да изпълняват злонамерени скриптове на потребителите, в този случай браузъри жертви. Тъй като браузърът не може да разбере дали скриптът е надежден или не, скриптът ще бъде изпълнен и нападателят може да отвлече бисквитки на сесията, да изкриви уебсайтове или да пренасочи потребителя към нежелани и злонамерени уебсайтове.
XSS е атака, която позволява на нападателя да изпълнява скриптовете в браузъра на жертвата.
Последица:
- Използвайки тази уязвимост на сигурността, нападателят може да инжектира скриптове в приложението, може да краде бисквитки на сесията, да изкривява уебсайтове и да пуска злонамерен софтуер на машините на жертвата.
Уязвими обекти
- Полета за въвеждане
- URL адреси
Примери
1. http://www.vulnerablesite.com/home?" < script > alert(" xss") script >
Горният скрипт, когато се изпълнява в браузър, ще се покаже поле за съобщение, ако сайтът е уязвим за XSS.
По-сериозната атака може да бъде извършена, ако нападателят иска да покаже или съхрани бисквитката на сесията.
2. http://demo.testfire.net/search.aspx?txtSearch
Горният скрипт при стартиране браузърът ще зареди невидим кадър, сочещ към http://google.com .
Атаката може да стане сериозна чрез стартиране на злонамерен скрипт в браузъра.
Препоръки
- Полета за въвеждане на бял списък
- Входно изходно кодиране
Счупено удостоверяване и управление на сесии
Описание
Уебсайтовете обикновено създават сесийна бисквитка и идентификатор на сесия за всяка валидна сесия и тези бисквитки съдържат чувствителни данни като потребителско име, парола и др. Когато сесията приключи или чрез излизане или внезапно затваряне на браузъра, тези бисквитки трябва да бъдат обезсилени, т.е. за всяка сесия трябва да има нова бисквитка.
Ако бисквитките не са обезсилени, чувствителните данни ще съществуват в системата. Например потребител, който използва публичен компютър (Cyber Cafe), бисквитките на уязвимия сайт седят в системата и са изложени на атакуващ. Нападателят използва същия публичен компютър след известно време, чувствителните данни са компрометирани.
По същия начин, потребител, който използва публичен компютър, вместо да излезе, той затваря рязко браузъра. Нападателят използва същата система, когато преглежда същия уязвим сайт, ще се отвори предишната сесия на жертвата. Нападателят може да прави каквото иска от кражба на информация за профила, информация за кредитни карти и т.н.
Трябва да се направи проверка, за да се установи силата на удостоверяването и управлението на сесията. Ключовете, сесийните символи, бисквитките трябва да бъдат внедрени правилно, без да се нарушават паролите.
Уязвими обекти
- Идентификаторите на сесии, изложени на URL, могат да доведат до атака за фиксиране на сесия.
- Идентификаторите на сесията са същите преди и след излизане и влизане.
- Времето за изчакване на сесията не се прилага правилно.
- Приложението присвоява един и същ идентификатор на сесия за всяка нова сесия.
- Удостоверените части на приложението са защитени с помощта на SSL и паролите се съхраняват в хеширан или криптиран формат.
- Сесията може да бъде използвана повторно от потребител с ниска привилегия.
Импликация
- Използвайки тази уязвимост, нападателят може да отвлече сесия, да получи неоторизиран достъп до системата, което позволява разкриване и модифициране на неоторизирана информация.
- Сесиите могат да бъдат високо вдигнати с помощта на откраднати бисквитки или сесии, използващи XSS.
Примери
- Приложението за резервация на авиокомпания поддържа пренаписване на URL адреси, поставяне на идентификатори на сесии в URL адреса:
http://Examples.com/sale/saleitems;jsessionid=2P0OC2oJM0DPXSNQPLME34SERTBG/dest=Maldives (Продажба на билети до Малдивите)
Удостоверен потребител на сайта иска да уведоми приятелите си за продажбата и изпраща имейл. Приятелите получават идентификатора на сесията и могат да бъдат използвани за неоторизирани модификации или злоупотреба със запазените данни за кредитна карта.
- Приложението е уязвимо за XSS, чрез което нападателят може да осъществи достъп до идентификатора на сесията и може да се използва за отвличане на сесията.
- Времето за изчакване на приложенията не е зададено правилно. Потребителят използва публичен компютър и затваря браузъра, вместо да излиза и се отдалечава. Атакуващият използва същия браузър известно време по-късно и сесията се удостоверява.
Препоръки
- Всички изисквания за удостоверяване и управление на сесии трябва да бъдат дефинирани съгласно стандарта за проверка на защитата на приложенията на OWASP.
- Никога не излагайте никакви идентификационни данни в URL адреси или регистрационни файлове.
- Трябва също така да се положат големи усилия за избягване на недостатъци на XSS, които могат да се използват за кражба на идентификатори на сесии.
Несигурни препратки към директни обекти
Описание
Това се случва, когато разработчикът изложи препратка към вътрешен обект на изпълнение, като файл, директория или ключ на базата данни, както е в URL или като параметър FORM. Нападателят може да използва тази информация за достъп до други обекти и може да създаде бъдеща атака за достъп до неоторизирани данни.
Импликация
- Използвайки тази уязвимост, нападателят може да получи достъп до неоторизирани вътрешни обекти, може да модифицира данни или да компрометира приложението.
Уязвими обекти
- В URL адреса.
Примери:
Промяната на „идентификатор на потребителя“ в следния URL може да накара нападателя да прегледа информацията на други потребители.
http://www.vulnerablesite.com/userid=123 Променено на http://www.vulnerablesite.com/userid=124
Атакуващият може да преглежда информацията на другите, като променя стойността на потребителския идентификатор.
Препоръки:
- Прилагане на проверки за контрол на достъпа.
- Избягвайте да излагате препратки към обекти в URL адреси.
- Проверете разрешението за всички референтни обекти.
Фалшифициране на заявки между сайтове
Описание
Подправяне на заявка между сайтове е фалшива заявка, дошла от кръстосания сайт.
CSRF атака е атака, която възниква, когато злонамерен уебсайт, имейл или програма кара браузъра на потребителя да извърши нежелано действие на надежден сайт, за който потребителят в момента е удостоверен.
CSRF атака принуждава влезлия в браузъра на жертвата да изпрати подправена HTTP заявка, включително бисквитката на сесията на жертвата и всяка друга автоматично включена информация за удостоверяване, до уязвимо уеб приложение.
Нападателят ще изпрати връзка към жертвата, когато потребителят щракне върху URL адреса, когато влезе в оригиналния уебсайт, данните ще бъдат откраднати от уебсайта.
Импликация
- Използването на тази уязвимост като нападател може да промени информацията за потребителския профил, да промени състоянието, да създаде нов потребител от името на администратора и т.н.
Уязвими обекти
- Страница на потребителския профил
- Потребителски акаунти
- Страница за бизнес транзакции
Примери
Жертвата е влязла в уебсайт на банка, като използва валидни идентификационни данни. Той получава поща от нападател, казвайки „Моля, кликнете тук, за да дарите $ 1, за да предизвикате“.
Когато жертвата щракне върху нея, ще бъде създадена валидна заявка за дарение на $ 1 за определен акаунт.
http://www.vulvablebank.com/transfer.do?account=cause&amount=1
Атакуващият улавя тази заявка и създава заявка отдолу и вгражда в бутон с надпис „I Support Cause“.
http://www.vulvablebank.com/transfer.do?account=Attacker&amount=1000
Тъй като сесията е удостоверена и заявката идва през уебсайта на банката, сървърът ще преведе $ 1000 долара на нападателя.
Препоръка
- Упълномощавайте присъствието на потребителя, докато извършвате чувствителни действия.
- Внедрете механизми като CAPTCHA, повторно удостоверяване и уникални токени за заявки.
Неправилна конфигурация на сигурността
Описание
Конфигурацията на защитата трябва да бъде дефинирана и внедрена за приложението, рамки, сървър на приложения, уеб сървър, сървър на база данни и платформа. Ако те са правилно конфигурирани, нападателят може да има неоторизиран достъп до чувствителни данни или функционалност.
Понякога такива недостатъци водят до пълен компромис на системата. Актуализирането на софтуера също е добра сигурност.
Импликация
- Използвайки тази уязвимост, атакуващият може да изброи основната информация за технологията и версията на сървъра на приложения, информация за база данни и да получи информация за приложението, за да монтира още няколко атаки.
Уязвими обекти
- URL
- Полета за формуляри
- Полета за въвеждане
Примери
- Администраторската конзола на сървъра за приложения се инсталира автоматично и не се премахва. Акаунтите по подразбиране не се променят. Нападателят може да влезе с пароли по подразбиране и да получи неоторизиран достъп.
- Списъкът с директории не е деактивиран на вашия сървър. Attacker открива и може просто да изброи директории, за да намери всеки файл.
Препоръки
- Силна архитектура на приложенията, която осигурява добро разделяне и сигурност между компонентите.
- Променете потребителските имена и пароли по подразбиране.
- Деактивирайте списъците с директории и внедрете проверки за контрол на достъпа.
Несигурно криптографско съхранение
Описание
Несигурното криптографско съхранение е често срещана уязвимост, която съществува, когато чувствителните данни не се съхраняват сигурно.
Потребителските идентификационни данни, информация за профила, здравни данни, информация за кредитни карти и др. Попадат под информация за поверителни данни на уебсайт.
Тези данни ще се съхраняват в базата данни на приложението. Когато тези данни се съхраняват неправилно, като не се използва криптиране или хеширане *, те ще бъдат уязвими за нападателите.
(* Хеширането е преобразуване на символите на низа в по-къси низове с фиксирана дължина или ключ. За да дешифрирате низа, алгоритъмът, използван за формиране на ключа, трябва да е на разположение)
Импликация
- Използвайки тази уязвимост, нападателят може да открадне, модифицира такива слабо защитени данни, за да извърши кражба на самоличност, измама с кредитна карта или други престъпления.
Уязвими обекти
- База данни за приложения.
Примери
В едно от банковите приложения базата данни с пароли използва несолени хешове *, за да съхранява паролите на всички. Грешка при SQL инжектирането позволява на нападателя да извлече файла с паролата. Всички несолени хешове могат да бъдат грубо принудени за нула време, докато посолените пароли ще отнемат хиляди години.
(* Несолени хешове - Солта е произволна информация, добавена към оригиналните данни. Солта се добавя към паролата преди хеширане)
Препоръки
- Осигурете подходящи силни стандартни алгоритми. Не създавайте собствени криптографски алгоритми. Използвайте само одобрени публични алгоритми като AES, RSA криптография с публичен ключ и SHA-256 и др.
- Уверете се, че резервните копия извън сайта са криптирани, но ключовете се управляват и архивират отделно.
Неуспех при ограничаване на достъпа до URL
Описание
Уеб приложенията проверяват правата за достъп до URL, преди да изобразяват защитени връзки и бутони. Приложенията трябва да извършват подобни проверки за контрол на достъпа всеки път, когато имат достъп до тези страници.
В повечето приложения привилегированите страници, местоположения и ресурси не се представят на привилегированите потребители.
По интелигентно предположение, нападателят може да има достъп до страници с привилегии. Нападателят може да осъществява достъп до чувствителни страници, да извиква функции и да преглежда поверителна информация.
Импликация
- Използването на тази атака на уязвимост може да получи достъп до неоторизирани URL адреси, без да влиза в приложението и да използва уязвимостта. Нападателят може да осъществява достъп до чувствителни страници, да извиква функции и да преглежда поверителна информация.
Уязвими обекти:
- URL адреси
Примери
- Атакуващият забелязва, че URL адресът посочва ролята като "/ user / getaccounts." Той се променя като "/ admin / getaccounts".
- Нападателят може да добави роля към URL адреса.
http://www.vulnerablsite.com може да бъде модифициран като http://www.vulnerablesite.com/admin
Препоръки
- Внедрете силни проверки за контрол на достъпа.
- Политиките за удостоверяване и упълномощаване трябва да се основават на роли.
- Ограничете достъпа до нежелани URL адреси.
Недостатъчна защита на транспортния слой
Описание
Занимава се с обмен на информация между потребител (клиент) и сървър (приложение). Приложенията често предават чувствителна информация като подробности за удостоверяване, информация за кредитни карти и токени на сесии по мрежа.
Използването на слаби алгоритми или използване на изтекли или невалидни сертификати или не използване на SSL може да позволи комуникацията да бъде изложена на ненадеждни потребители, което може да компрометира уеб приложение или да открадне чувствителна информация.
Импликация
- Използвайки тази уязвимост на уеб защитата, нападателят може да подуши легитимни идентификационни данни на потребителя и да получи достъп до приложението.
- Може да открадне информация за кредитна карта.
Уязвими обекти
- Данни, изпратени по мрежата.
Препоръки
- Активирайте защитен HTTP и налагайте прехвърляне на идентификационни данни само през HTTPS.
- Уверете се, че вашият сертификат е валиден и не е изтекъл.
Примери:
1. Приложение, което не използва SSL, нападателят просто ще наблюдава мрежовия трафик и наблюдава удостоверена бисквитка на сесия на жертва. Нападателят може да открадне тази бисквитка и да извърши атака „Човек в средата“.
Невалидни пренасочвания и пренасочвания
Описание
Уеб приложението използва няколко метода за пренасочване и пренасочване на потребители към други страници по предназначение.
Ако няма правилна проверка при пренасочване към други страници, нападателите могат да се възползват от това и да пренасочат жертвите към сайтове за фишинг или злонамерен софтуер или да използват препратки за достъп до неоторизирани страници.
Импликация
- Нападателят може да изпрати URL на потребителя, който съдържа истински URL адрес, приложен с кодиран злонамерен URL адрес. Потребителят само като види истинската част от изпратения URL адрес на нападателя, може да го разглежда и може да стане жертва.
Примери
1. http://www.vulnerablesite.com/login.aspx?redirectURL=ownsite.com
Променено на
http://www.vulnerablesite.com/login.aspx?redirectURL=evilsite.com
Препоръки
- Просто избягвайте да използвате пренасочвания и препращания в приложението. Ако се използва, не включвайте използване на потребителски параметри при изчисляване на дестинацията.
- Ако параметрите на местоназначението не могат да бъдат избегнати, уверете се, че предоставената стойност е валидна и разрешена за потребителя.
Тази статия е предоставена от Prasanthi Eati