Когато става въпрос за сигурност на корпоративния стек, софтуерните приложения са най-слабото звено. В Състоянието на сигурността на приложенията, 2020 г, Forrester казва, че по-голямата част от външните атаки се извършват или чрез използване на софтуерна уязвимост (42%) или чрез уеб приложение (35%).
Разработчиците са под натиск да пуснат функции възможно най-скоро, тъй като приложенията стават по-сложни и сроковете за разработка се свиват. За да постигнат диференцирана и завладяваща функционалност на приложението, разработчиците все повече разчитат на библиотеки на трети страни.
Тази промяна към компоненти с отворен код прави сигурност по-сложни за компаниите практики. Нови рамки като контейнери и API допълнително усложняват сигурността на приложенията.
Тъй като разработчиците са принудени да пускат непрекъснато нови функции, организациите са изправени пред много реален риск сигурността да не успее да поддържа темпото. Сигурността може да бъде постигната чрез включване на най-добрите практики за сигурност на приложенията в жизнения цикъл на разработка на софтуер и тяхното прилагане.
Защо тестването на уеб сигурността е важно?
Тестването на уеб приложения и техните конфигурации за уязвимости в сигурността е целта на тестването на уеб сигурността. Атаките на приложния слой (т.е. насочване към базирани на HTTP приложения) са основните цели.
Обичайно е да се подават различни типове входни данни към уеб приложение, за да се провокират грешки и да се предизвика неочаквано поведение. При тези така наречени „отрицателни тестове“ системата се проверява за поведение, което не е предвидено.
Важно е също да се отбележи това Тестване на уеб сигурността не е просто за тестване на функциите за защита, които са внедрени в приложението (напр. удостоверяване и оторизация).
Също така е необходимо да се тества дали други функции (напр. бизнес логика и валидиране на входа и изхода) са внедрени по сигурен начин. Сигурният достъп до функциите на уеб приложението е целта.
Какви са различните видове тестове за сигурност?
- Динамичен тест за сигурност на приложението (DAST). За съответствие с регулаторните оценки на сигурността, този автоматизиран тест за сигурност на приложенията е идеален за вътрешно изправени, нискорискови приложения. Комбинация от ръчно тестване на уеб сигурността и DAST е най-добрият подход за приложения със среден риск и критични приложения, които претърпяват малки промени.
- Статичен тест за сигурност на приложението (SAST). Този подход към тестовете за сигурност на приложението както ръчно, така и автоматично. Едно приложение може да бъде тествано по този начин, без да се налага да се изпълнява в производствена среда. Освен това позволява на разработчиците систематично да откриват и елиминират уязвимостите в сигурността на софтуера чрез сканиране на изходния код.
- Тест за проникване. Специално за приложения, които претърпяват големи промени, този ръчен тест за сигурност на приложението е идеален. Оценките включват бизнес логика и тестване на базата на противници за идентифициране на сценарии за напреднали атаки.
- Самозащита на приложенията по време на изпълнение (RASP). Редица технологични техники се използват в този развиващ се подход към сигурността на приложенията за инструментиране на приложение по такъв начин, че атаките да могат да бъдат наблюдавани, докато се изпълняват и, в идеалния случай, блокирани в реално време.
Как тестването за сигурност на приложенията намалява риска за вашата организация?
По-голямата част от атаките на уеб приложения
- Техниката на SQL инжектиране
- Кроссайт скриптове (XSS)
- Изпълнение на команди от разстояние
- Преминаване на пътя
Резултати от атаките
- Съдържание, което е ограничено
- Профили, които са били компрометирани
- Инсталиране на злонамерен софтуер
- Загубени приходи
- Клиентите губят доверие
- Репутационни щети
- Както и много повече
Днешната уеб среда е предразположена към широк спектър от проблеми. Освен че знаете как може да се експлоатира дадено приложение, познаването на потенциалните резултати от атаката ще помогне на вашата компания превантивно да адресира уязвимостите и да ги тества точно.
Смекчаващите контроли могат да бъдат приложени по време на ранните етапи на SDLC след идентифициране на основната причина за уязвимостите. Освен това тестът за сигурност на уеб приложенията може да се възползва от знанията за това как работят тези атаки, за да се насочат към известни точки на интерес.
За да управлявате риска на вашата фирма, трябва да разберете въздействието на атаката, тъй като тя може да се използва за оценка на общата тежест на уязвимостта.
В резултат на тест за сигурност, определянето на тежестта на откритите проблеми може да ви помогне да приоритизирате усилията за отстраняване ефективно и ефективно. Минимизирайте риска на вашата фирма, като започнете с проблеми с критична тежест и преминете към проблеми с по-ниско въздействие.
Оценката на потенциалното въздействие на всяко приложение в библиотеката с приложения на вашата фирма преди идентифициране на проблем може да помогне за приоритизиране на тестването за сигурност на приложението.
Когато тестването на уеб сигурността има установен списък с приложения с висок профил, ние можем да планираме тестването така, че първо да се насочи към критичните приложения на вашата фирма, така че рискът за вашия бизнес да може да бъде намален.
Какви функции трябва да бъдат прегледани по време на тест за сигурност на уеб приложението?
Няколко функции трябва да бъдат разгледани по време на тестване за сигурност на уеб приложенията, но списъкът не е изчерпателен. Вашата организация може да бъде изложена на сериозен риск от неподходящо изпълнение на всеки от тях.
- Конфигурация на приложения и сървър- Дефектите могат да бъдат свързани с конфигурация на криптиране, конфигурации на уеб сървър и др.
- Валидиране на въвеждане и обработка на грешки- Най-често срещаните уязвимости при инжектиране, включително SQL инжектиране и междусайтови скриптове (XSS), са резултат от лошо управление на входа и изхода.
- Удостоверяване и управление на сесиите- Уязвимостите могат да доведат до представяне на потребители. От съществено значение е и силната политика за удостоверяване.
- упълномощаване- Проверка на способността на приложението да предотвратява вертикална и хоризонтална ескалация на привилегии.
- Бизнес логика - Този тип логика е от съществено значение за повечето бизнес приложения.
- Логика от страна на клиента - Този тип функции стават все по-разпространени в съвременните уебсайтове с JavaScript, както и в уебсайтове, използващи други технологии от страна на клиента (напр. Silverlight, Flash, Java аплети).
Топ 10 най-добри практики за сигурност на уеб приложения
Следват десетте най-добри практики за сигурност на приложенията, които вашата организация вече трябва да прилага.
#1 Проследете своите активи
Ако не знаеш какво имаш, не можеш да го защитиш.
За кои функции или приложения използвате конкретни сървъри? В кои уеб приложения използвате компоненти с отворен код?
Мислите ли, че не е важно да следите активите си? Много е важно да запомните кой софтуер работи във всяко приложение – просто попитайте Equifax, който беше глобен с 700 милиона долара за неуспех да защити данните на над 145 милиона клиенти.
Един от клиентските уеб портали на агенцията за кредитен рейтинг беше компрометиран, след като компонент с отворен код, Apache Struts, не беше коригиран. Компанията казва, че не е знаела, че клиентският портал е използвал уязвимия компонент с отворен код.
Колкото по-рано започнете да проследявате активите си, толкова по-малко главоболия и бедствия ще имате по-късно. Тъй като организациите мащабират своето развитие, този процес може да се почувства като сизифова задача.
Трябва също така да класифицирате активите си, като отбелязвате тези, които са критични за функциите на вашия бизнес, и тези, които са с по-малко значение. След това можете да оцените заплахите и да ги отстраните по-късно.
#2 Извършете оценка на заплахата
Ако направите списък с това, което трябва да защитите, тогава можете да идентифицирате заплахите, пред които сте изправени, и как те могат да бъдат смекчени.
Как хакерите биха могли да проникнат във вашето приложение? Какви съществуващи мерки за сигурност имате? Какви допълнителни инструменти са необходими?
Трябва да отговорите на тези и други въпроси като част от вашата оценка на заплахата.
Все пак трябва да сте реалисти относно нивото на сигурност, на което можете да се насладите. Без значение колко сигурна сте направили системата си, все още можете да я хакнете. Освен това трябва да сте честни относно мерките, които вашият екип може да поддържа с течение на времето.
Можете да рискувате вашите стандарти и практики за сигурност да бъдат игнорирани, като настоявате за твърде много. Вземете сигурността сериозно и не бързайте.
Използвайте следната формула, за да оцените риска си:
Риск = Вероятност от атака x Въздействие от атака.
Рискът може да се разглежда и като вероятността нещо да се случи спрямо тежестта на последствията.
Въпреки че би било катастрофално, ако кит падне от небето и ви смаже, е малко вероятно това да се случи.
От друга страна, ухапване от комар по време на поход е доста вероятно, но не е вероятно да причини значителна вреда освен няколко сърбящи подутини.
#3 Останете в крак с поправките
Инсталирате най-новите пачове на вашите операционни системи? Използвате ли софтуер на трети страни? Вероятността е да изоставате, което означава, че сте изложени.
Една от най-важните стъпки, които трябва да предприемете, за да гарантирате сигурността на вашия софтуер, е да актуализирате софтуера или от търговски доставчик, или от общност с отворен код.
Когато уязвимостта бъде открита и отговорно докладвана на собствениците на продукта или проекта, тя се публикува на сайтове и бази данни със съвети за сигурност, като например базата данни за уязвимости на WhiteSource.
Ако е възможно, корекцията трябва да бъде създадена и пусната преди публикуването, предоставяйки на потребителите възможност да защитят своя софтуер.
Ако обаче не приложите корекция, когато такава стане налична, няма да се възползвате от подобрената сигурност.
Ако се притеснявате, че актуализирането до най-новата версия може да повреди вашия продукт, автоматизирани инструменти може да помогне много. Всеки ден от седмицата трябва да дадете приоритет на актуализирането и корекцията като част от най-добрите практики за сигурност на вашите приложения.
#4 Управлявайте вашите контейнери
През последните години популярността на контейнерите нарасна, тъй като все повече организации приемат технологията поради нейната гъвкавост, която опростява процеса на разработване, тестване и внедряване на компоненти в различни среди през целия жизнен цикъл на разработка на софтуер (SDLC).
Общоприето е, че контейнерите предлагат предимства за сигурност, които им дават предимство. Освен това, поради тяхната самостоятелна операционна среда, те са сегментирани по дизайн, като по този начин се понижава нивото на риска.
И все пак контейнерите продължават да са уязвими за експлоати, като например пробивна атака, при която изолацията е нарушена. Контейнерите може също да съдържат уязвимост в кода, съхранен в тях.
За сигурност на CI/CD конвейера трябва да сканирате за уязвимости от началото до края, включително във вашите регистри.
В допълнение към тези сканирания, най-добрите практики за сигурност на приложенията при работа с контейнери включват и важни задачи като подписване на собствени изображения с инструменти като Docker Content Trust, ако използвате Docker Hub, или Shared Access Signature, ако вашият екип използва Microsoft Azure.
#5 Дайте приоритет на вашите операции за възстановяване
През последните години има нарастващ брой уязвимости и тази тенденция не показва признаци на забавяне в скоро време.
Следователно, разработчиците са заети с саниране. За екипи, които се надяват да запазят своите приложения защитени, като същевременно са здрави, приоритизирането е от съществено значение.
Оценките на заплахите се извършват въз основа на тежестта на уязвимостта (CVSS рейтинг), критичността на засегнатото приложение и редица други фактори.
Трябва да знаете дали уязвимостта с отворен код действително влияе на вашия собствен код, когато става въпрос за уязвимости с отворен код.
Неефективен и не е с висок риск, дори ако CVSS рейтингът на уязвимия компонент е критичен, ако той не получава обаждания от вашия продукт.
Интелигентните стратегии са тези, които първо дават приоритет на най-належащите заплахи въз основа на наличните фактори и оставят нискорисковите за по-късно.
#6 Шифроване, криптиране, шифроване
Топ 10 на OWASP включва криптиране на данни в покой и по време на пренос от години, което го прави изискване за всеки списък с най-добри практики за сигурност на приложения.
Атаките на човек в средата и други форми на проникване могат да разкрият чувствителни данни, когато не успеете да заключите правилно трафика си.
Когато съхранявайте пароли и потребителски идентификатори в обикновен текст, например, излагате клиентите си на риск.
Уверете се, че използвате SSL с актуализиран сертификат като част от основния ви контролен списък за криптиране. Не позволявайте да бъдете изоставени сега, когато HTTPS е стандартът. Хеширането също се препоръчва.
Освен това никога не трябва да „въртите собствената си крипто“, както се казва. Помислете за продукти за сигурност, които се поддържат от специален екип с опит, за да свърши работата правилно.
#7 Управление на привилегиите
Не е нужно да давате достъп до всичко на всички във вашата организация. Приложенията и данните са достъпни само от тези, които се нуждаят от тях, като следват най-добрите практики за мрежова сигурност и най-добрите практики за сигурност на приложенията.
Има две причини за това. Първото нещо, което трябва да направите, е да попречите на хакер да използва маркетингови идентификационни данни, за да получи достъп до система, която съдържа други по-чувствителни данни, като финансови или правни.
Вътрешните заплахи също са проблем, било то неволни – като загуба на лаптоп или изпращане на грешен прикачен файл към имейл – или злонамерени.
Принципът на най-малкото привилегия за предоставяне на служителите само с данните, от които се нуждаят, когато става въпрос за достъп до данни, може да намали вашето излагане в сравнение с липсата на контрол.
#8 Прегърнете автоматизацията за управлението на уязвимостите си
Сигурността на техните приложения става все по-важна за разработчиците през последните няколко години, особено когато става въпрос за задачи като управление на уязвимостите.
За да се справят с изместването на сигурността наляво, екипите на разработчиците тестват рано и често, налагайки колкото се може повече от своите проверки за сигурност в началото на процеса на разработка, когато е по-лесно и по-евтино да се коригират уязвимостите.
За да управляват тромавия процес на тестване поради огромното количество уязвимости, разработчиците се нуждаят от автоматизирани инструменти.
За да откриете потенциални уязвимости в сигурността във вашия собствен код, статично тестване на сигурността на приложенията (SAST) и динамично тестване на сигурността на приложенията (DAST) могат да бъдат използвани по време на разработката.
Дупките в сигурността се затварят със SAST и DAST, но собственият код съставлява сравнително малка част от цялостния ви код.
В повече от 92% от всички съвременни приложения компонентите с отворен код съставляват 60-80% от вашата кодова база. Контролният списък за сигурност на приложението ви трябва да дава приоритет на осигуряването на компоненти с отворен код.
Използвайки инструменти за анализ на софтуерния състав, екипите могат да изпълняват автоматизирани проверки за сигурност и отчети в целия SDLC, идентифицирайки всеки компонент с отворен код в тяхната среда и посочвайки кой от тях има известна уязвимост, която представлява риск за сигурността на вашите приложения.
Можете по-добре да управлявате уязвимостите си, като преместите автоматичното тестване за проблеми със сигурността с отворен код наляво.
#9 Тестване за проникване
Списъкът с най-добри практики за сигурност на приложенията би бил непълен без да се споменава тестването с писалка, въпреки че автоматизираните инструменти помагат да се уловят по-голямата част от проблемите със сигурността.
Тестването с писалка и хартия ви позволява да блъскате и натискате приложението си, за да откриете слабости. Ако решителен хакер се опита да проникне във вашето приложение, добрите тестери на писалки знаят точно какви стъпки трябва да предприемат.
Могат да бъдат наети хакерски фирми или фрийлансъри могат да участват в програми за награждаване на грешки като BugCrowd и HackerOne. Вашата компания трябва да спонсорира награда за грешки, ако все още не сте го направили.
Ако наемете тестери за писалки, много по-добре е да платите за тях, отколкото да се справяте с последствията от истинско нарушение.
#10 Бъдете внимателни с жетоните
Въпреки факта, че това е лесно за защита, много разработчици не осигуряват правилно своите токени за трети страни.
Чрез търсене в популярни уебсайтове за разработчици можете лесно да намерите незащитени токени онлайн. Вместо да съхраняват подробности за токените другаде, разработчиците просто ги включват в своите хранилища с отворен код.
Основна най-добра практика за сигурност на приложенията е правилното осигуряване на вашите токени на трети страни. Не трябва да оставяте токени, които сте закупили, да лежат в кода си, за да може някой да вземе.
Най-добрите практики за сигурност на приложенията като основни практики
Всяка от най-добрите практики, описани тук, трябва да бъде интегрирана в непрекъснатия процес на развитие на вашата организация. Приложенията и данните на вашата компания са изложени на риск, ако не минимизирате риска. Следвайте тези стъпки, за да сведете до минимум риска.
Избягването на грешките, които е вероятно да направят другите, е един от начините да останете пред хакерите, така че е по-трудно да бъдете насочени за атаки. Никога няма да има мярка за сигурност на периметъра или приложението, която да е напълно защитена от хакване.
Въпреки това, следването на тези основни най-добри практики може да измине дълъг път към запазването на приложението ви да не си струва труда на хакерите.
