Меню

Тестване на сигурността (Пълно ръководство)

security testing

Опитайте Нашия Инструмент За Премахване На Проблемите

Как да тестваме сигурността на приложенията - Техники за тестване на сигурността на уеб и настолни приложения

Необходимостта от тестване на сигурността?

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

В наши дни уебсайтовете не са предназначени само за публичност или маркетинг, но те са превърнати в по-силните инструменти за задоволяване на бизнес нуждите.

Как да тестваме техниките за тестване на сигурността на приложенията в мрежата и на работния плот

Уеб-базирани системи за заплати, търговски центрове, банково дело, приложение на стоковата търговия не само се използват от организациите, но и днес се продават като продукти.

Това означава, че онлайн приложенията са спечелили доверието на клиентите и потребителите по отношение на тяхната жизненоважна функция, наречена СИГУРНОСТ.

Без съмнение коефициентът на сигурност е от първостепенно значение и за настолни приложения.

Въпреки това, когато говорим за мрежата, значението на сигурността нараства експоненциално. Ако онлайн система не може да защити данните за транзакциите, никой никога няма да се сети да ги използва. Сигурността все още не е нито дума в търсене на нейното определение, нито е фина концепция. Бих искал обаче да изброя някои комплименти за сигурността.

най-добрият youtube към mp4 конвертор

Примери за недостатъци на сигурността в приложението

  • Система за управление на студентите е несигурна, ако клонът „Прием“ може да редактира данните на клон „Изпит“
  • ERP системата не е сигурна, ако DEO (оператор за въвеждане на данни) може да генерира „Отчети“
  • Онлайн търговски център няма сигурност, ако данните на кредитната карта на клиента не са криптирани
  • Персонализираният софтуер притежава неадекватна сигурност, ако SQL заявка извлича действителни пароли на своите потребители

Сигурност

Сега ви представям най-простата дефиниция за сигурност със собствени думи.

„Сигурността означава, че се предоставя разрешен достъп до защитени данни и неразрешен достъп е ограничен“ .

И така, има два основни аспекта; първият е защитата на данните, а вторият е достъпът до тези данни. Освен това, независимо дали приложението е настолно или уеб-базирано, сигурността се върти около двата гореспоменати аспекта.

Нека имаме преглед на аспектите на сигурността както за настолни, така и за уеб базирани софтуерни приложения.

Какво ще научите:

Тестване на десктоп и уеб сигурност

Приложението за настолни компютри трябва да бъде защитено не само по отношение на достъпа му, но и по отношение на организацията и съхранението на неговите данни.

По същия начин уеб приложението изисква, още повече, сигурност по отношение на достъпа си, заедно със защитата на данните. Уеб разработчик трябва да направи приложението имунизирано срещу SQL инжекции, Brute Force Attacks и XSS (скриптове между сайтове). По същия начин, ако уеб приложението улеснява отдалечени точки за достъп, те също трябва да са защитени.

Освен това имайте предвид, че Brute Force Attack не е свързан само с уеб приложения, софтуерът за настолни компютри също е уязвим за това.

Надявам се този предговор да е достатъчен и сега нека да стигна до въпроса. Моля, приемете извинението ми, ако досега сте смятали, че четете по темата на тази статия. Въпреки че накратко обясних софтуерната сигурност и основните проблеми, моята тема е „Тестване на сигурността“.

Препоръчително четене => Тестване на сигурността на уеб приложения

Сега ще обясня как се прилагат функциите на защитата в софтуерно приложение и как те трябва да бъдат тествани. Моят фокус ще бъде върху Whats and Hows на тестовете за сигурност, а не на сигурността.

Препоръчителни инструменти за тестване на сигурността

# 1) Net parker

Netsparker банер

Netsparker е решение за тестване на сигурността на уеб приложения с възможности за автоматично обхождане и сканиране за всички видове наследени и модерни уеб приложения като HTML5, Web 2.0 и приложения за една страница. Използва Proof-Based Scanning Technology и скалируеми сканиращи агенти.

Тя ви дава пълна видимост, въпреки че имате голям брой активи за управление. Той има много повече функционалности като управление на екип и управление на уязвимости. Той може да бъде интегриран в CI / CD платформи като Jenkins, TeamCity или Bamboo.

=> Опитайте най-добрия инструмент за тестване на сигурността на Netsparker

# две) Киуван

kiuwan банер

Намерете и коригирайте уязвимости във вашия код на всеки етап от SDLC.

Киуван е в съответствие с най-строгите стандарти за сигурност, включително OWASP, CWE, SANS 25, HIPPA и др. Интегрирайте Kiuwan във вашата IDE за незабавна обратна връзка по време на разработката. Kiuwan поддържа всички основни езици за програмиране и се интегрира с водещите инструменти DevOps.

=> Сканирайте кода си безплатно

# 3) Indusface БЕШЕ безплатна проверка на злонамерен уебсайт

Indusface-WAS

Indusface БЕШЕ осигурява както ръчно тестване за проникване, в комплект със собствен автоматизиран скенер за уязвимост на уеб приложения, който открива и отчита уязвимости въз основа на OWASP топ 10 и също така включва проверка на репутацията на уебсайта на връзки, злонамерен софтуер и проверки за деформация на уебсайта при всяко сканиране

как да видите .eps файлове

=> Стартирайте бързо сканиране на уебсайт безплатно

=> Свържете се с нас да предложите списък тук.

Списък на Топ 8 техники за тестване на сигурността

# 1) Достъп до приложението

Независимо дали става дума за настолно приложение или уебсайт, сигурността на достъпа се осъществява от „Роли и управление на правата“. Често се прави имплицитно, докато покрива функционалността,

Например, в болнична система за управление рецепционистът е най-малко загрижен за лабораторните изследвания, тъй като неговата работа е просто да регистрира пациентите и да назначи срещите им с лекари.

Така че всички менюта, формуляри и екрани, свързани с лабораторни тестове, няма да бъдат достъпни за Ролята на „Рецепционист“. Следователно правилното изпълнение на ролите и правата ще гарантира сигурността на достъпа.

Как да тествате: За да се тества това, трябва да се извърши задълбочено тестване на всички роли и права.

Тестерът трябва да създаде няколко потребителски акаунта с различни, както и множество роли. След това той трябва да използва приложението с помощта на тези акаунти и трябва да провери дали всяка роля има достъп само до своите модули, екрани, формуляри и менюта. Ако тестващият открие някакъв конфликт, той трябва да регистрира проблем със сигурността с пълна увереност.

Това може да се разбира и като тестване за удостоверяване и упълномощаване, което е много красиво изобразено на изображението по-долу:

Достъп до приложението

Така че по принцип трябва да тествате за „кой си“ и „какво можете да направите“ за отделни потребители.

Някои от тестовете за удостоверяване включват тест за правила за качество на паролата, тест за вход по подразбиране, тест за възстановяване на парола, тест captcha, тест за излизане от функционалност, тест за промяна на паролата, тест за защитен въпрос / отговор и т.н.

По същия начин някои от тестовете за оторизация включват тест за обхождане на пътека, тест за липсващо оторизиране, тест за хоризонтални проблеми с контрола на достъпа и т.н.

# 2) Защита на данните

Има три аспекта на сигурността на данните. Първото е това потребителят може да преглежда или използва само данните, които трябва да използва . Това се осигурява и от роли и права

Например, TSR (представител на телепродажбите) на компания може да преглежда данните за наличните наличности, но не може да види колко суровина е закупена за производство.

И така, този аспект на тестването на сигурността вече е обяснен по-горе. Вторият аспект на защитата на данните е свързан с как тези данни се съхраняват в DB .

Допълнително четене = >> Какво е тестване на сигурността на базата данни

Всички чувствителни данни трябва да бъдат криптирани, за да бъдат защитени. Шифроването трябва да бъде силно, особено за чувствителни данни като пароли на потребителски акаунти, номера на кредитни карти или друга критична за бизнеса информация.

Третият и последният аспект е продължение на този втори аспект. Трябва да се предприемат подходящи мерки за сигурност, когато възникне поток от чувствителни или критични за бизнеса данни. Независимо дали тези данни се носят между различни модули на едно и също приложение или се предават на различни приложения, те трябва да бъдат криптирани, за да бъдат защитени.

Защита на данни

Как да тестваме защитата на данните: Изпитателят трябва да направи заявка в базата данни за „пароли“ на потребителския акаунт, информация за фактуриране на клиенти, други критични за бизнеса и чувствителни данни и трябва да провери дали всички такива данни са записани в криптирана форма в DB.

По същия начин той трябва да провери дали данните се предават между различни форми или екрани само след правилно криптиране. Освен това тестващият трябва да гарантира, че криптираните данни са правилно декриптирани в местоназначението. Специално внимание трябва да се обърне на различни действия „подаване“.

Тестерът трябва да провери, че когато информацията се предава между клиента и сървъра, тя не се показва в адресната лента на уеб браузър в разбираем формат. Ако някоя от тези проверки се провали, тогава приложението определено има недостатък в сигурността.

Тестерът също трябва да провери за правилното използване на осоляване (добавяне на допълнителна секретна стойност към крайния вход като парола и по този начин го прави по-силен и по-труден за разбиване).

Несигурната случайност също трябва да бъде тествана, тъй като това е вид уязвимост. Друг начин за тестване на защитата на данните е да се провери за слабо използване на алгоритъма.

Например, тъй като HTTP е протокол с ясен текст, ако чувствителните данни като потребителски идентификационни данни се предават чрез HTTP, тогава това е заплаха за сигурността на приложението. Вместо HTTP, чувствителните данни трябва да се прехвърлят чрез HTTPS (защитени чрез SSL, TLS тунел).

HTTPS обаче увеличава повърхността на атаката и по този начин трябва да се тества дали конфигурациите на сървъра са правилни и валидността на сертификата е гарантирана.

# 3) Атака с груба сила

Brute Force Attack се извършва най-вече от някои софтуерни инструменти. Концепцията е, че чрез използване на валиден потребителски идентификатор s oftware се опитва да отгатне свързаната парола, като се опитва да влезе отново и отново.

Един прост пример за сигурност срещу такава атака е спирането на акаунта за кратък период от време, както правят всички пощенски приложения като ‘Yahoo’, ‘Gmail’ и ‘Hotmail’. Ако определен брой последователни опити (най-вече 3) не успеят да влязат успешно, тогава този акаунт се блокира за известно време (30 минути до 24 часа).

Атака с груба сила

Как да тестваме Brute-Force Attack: Изпитателят трябва да провери дали е налице някакъв механизъм за спиране на акаунта и работи ли точно. (S) Той трябва да се опита да влезе с невалидни потребителски идентификатори и пароли, за да се увери, че софтуерното приложение блокира акаунтите, ако се правят непрекъснати опити за влизане с невалидни идентификационни данни.

Ако приложението го прави, то е защитено срещу груба сила. В противен случай тази уязвимост на сигурността трябва да бъде докладвана от тестера.

Тестването за груба сила също може да бъде разделено на две части - тестване на черна кутия и тестване на сива кутия.

При тестване в черна кутия методът за удостоверяване, използван от приложението, се открива и тества. Освен това тестването на сивата кутия се основава на частично познаване на подробности за пароли и акаунти и атаки за компромиси с памет.

Щракнете тук за изследване на тестване на груба сила на черна кутия и сива кутия заедно с примери.

Горните три аспекта на сигурността трябва да се вземат предвид както за уеб, така и за настолни приложения, докато следващите точки са свързани само с уеб базирани приложения.

# 4) SQL инжектиране и XSS (скриптове между сайтове)

SQL инжекция

Концептуално казано, темата и на тези опити за хакерство е сходна, така че те се обсъждат заедно. При този подход, злонамерен скрипт се използва от хакери, за да манипулира уебсайт .

Има няколко начина за имунизиране срещу подобни опити. За всички полета за въвеждане на уебсайта дължините на полетата трябва да бъдат определени достатъчно малки, за да ограничат въвеждането на всеки скрипт

как да отворите jnlp файлове в Windows 8

Например, Фамилното име трябва да има дължина на полето вместо 255. Възможно е да има някои полета за въвеждане, където е необходимо въвеждане на големи данни, за такива полета трябва да се извърши правилна проверка на въвеждането, преди да се запазят тези данни в приложението.

Освен това в такива полета трябва да бъдат забранени всякакви HTML тагове или въвеждане на тагове на скриптове. За да предизвика XSS атаки, приложението трябва да отхвърли пренасочванията на скриптове от неизвестни или ненадеждни приложения.

Как да тествайте SQL инжекция и XSS: Тестерът трябва да гарантира, че са дефинирани и изпълнени максималните дължини на всички полета за въвеждане. (S) Той също така трябва да гарантира, че определената дължина на полетата за въвеждане не побира никакви въведени скриптове, както и въвеждане на таг. И двете могат лесно да бъдат тествани

Например, Ако 20 е максималната дължина, посочена за полето „Име“, и въведете низ „

thequickbrownfoxjumpsoverthelazydog ”може да провери и двете тези ограничения.

Също така трябва да бъде проверено от тестера, че приложението не поддържа анонимни методи за достъп. В случай че съществува някоя от тези уязвимости, приложението е в опасност.

По принцип тестването на SQL инжектиране може да се извърши по следните пет начина:

  • Техники за откриване
  • Стандартни техники за инжектиране на SQL
  • Отпечатък на базата данни
  • Техническа експлоатация
  • Техники за инвазия на подпис на SQL инжекции

Щракнете тук да прочетете подробно за горните начини за тестване на SQL инжектиране.

XSS също е вид инжекция, която инжектира злонамерен скрипт в уебсайт. Щракнете тук да проучи задълбочено относно тестването за XSS.

# 5) Точки за достъп до услуги (запечатани и защитени отворени)

Точки за достъп до услуги (запечатани и защитени отворени)

Днес бизнесът зависи и си сътрудничи помежду си, същото важи и за приложенията, особено за уебсайтовете. В такъв случай и двамата сътрудници трябва да дефинират и публикуват някои точки за достъп един за друг.

Засега сценарият изглежда съвсем прост и ясен, но за някои уеб базирани продукти като търговия с акции нещата не са толкова прости и лесни.

Когато има голям брой целева аудитория, точките за достъп трябва да бъдат достатъчно отворени, за да улеснят всички потребители, да бъдат достатъчно подходящи, за да изпълнят заявките на всички потребители и да бъдат достатъчно сигурни, за да се справят с всяко изпитание за сигурност.

Как да тествате точки за достъп до услугата: Позволете ми да го обясня с пример на уеб приложението за търговия с акции; инвеститорът (който иска да закупи акциите) трябва да има достъп до текущи и исторически данни за цените на акциите. Потребителят трябва да получи съоръжението да изтегли тези исторически данни. Това изисква приложението да бъде достатъчно отворено.

Подходящ и сигурен, имам предвид, че приложението трябва да улесни инвеститорите да търгуват свободно (съгласно законодателните разпоредби). Те могат да купуват или продават 24/7, а данните за транзакциите трябва да бъдат защитени от всяка хакерска атака.

Освен това голям брой потребители ще взаимодействат едновременно с приложението, така че приложението трябва да предоставя достатъчно точки за достъп, за да забавлява всички потребители.

В някои случаи тези точките за достъп могат да бъдат запечатани за нежелани приложения или хора . Това зависи от бизнес домейна на приложението и неговите потребители,

Например, Персонализирана уеб-базирана система за управление на Office може да разпознае своите потребители въз основа на IP адреси и отказва да установи връзка с всички други системи (приложения), които не попадат в обхвата на валидните IP адреси за това приложение.

Тестерът трябва да гарантира, че всички междумрежов и вътрешно-мрежов достъп към приложението е от доверени приложения, машини (IP) и потребители.

За да провери дали отворената точка за достъп е достатъчно сигурна, тестерът трябва да се опита да получи достъп до нея от различни машини, които имат както надеждни, така и ненадеждни IP адреси. Различни видове транзакции в реално време трябва да бъдат изпробвани на едро, за да имате добра увереност в работата на приложението. По този начин капацитетът на точките за достъп на приложението също ще се наблюдава ясно.

Тестерът трябва да гарантира, че приложението разглежда всички заявки за комуникация от надеждни IP адреси и приложения само докато всички други заявки са отхвърлени.

По същия начин, ако приложението има някаква отворена точка за достъп, тогава тестерът трябва да гарантира, че позволява (ако е необходимо) качване на данни от потребители по сигурен начин. По този сигурен начин имам предвид ограничението на размера на файла, ограничението на типа файл и сканирането на качения файл за вируси или други заплахи за сигурността.

Това е всичко, как изпитателят може да провери сигурността на приложението по отношение на точките за достъп.

# 6) Управление на сесията

Управление на сесията

Уеб сесията е последователност от HTTP заявки и транзакции за отговор, свързани със същия потребител. Тестовете за управление на сесии проверяват как се управлява сесията в уеб приложението.

Можете да тествате за изтичане на сесията след определено време на неактивност, прекратяване на сесията след максимален живот, прекратяване на сесия след излизане, проверка за обхват и продължителност на бисквитките на сесията, тестване дали един потребител може да има множество едновременни сесии и т.н.

# 7) Обработка на грешки

Обработка на грешки

Тестването за обработка на грешки включва:

Проверете за кодове за грешки : Например, тест 408 изчакване на заявка, 400 лоши заявки, 404 не са намерени и т.н. За да ги тествате, трябва да направите определени заявки към страницата, така че тези кодове за грешки да бъдат върнати.

Кодовете за грешки се връщат с подробно съобщение. Тези съобщения не трябва да съдържат критична информация, която може да се използва за хакерски цели

Проверете за следи от стека : Това включва основно даване на някои изключителни данни за приложението, така че върнатото съобщение за грешка да съдържа следи от стека, които имат интересна информация за хакерите.

# 8) Специфични рискови функции

Основно са двете рискови функционалности плащания и качване на файлове . Тези функционалности трябва да бъдат тествани много добре. За качване на файлове трябва преди всичко да проверите дали всяко нежелано или злонамерено качване на файлове е ограничено.

За плащания трябва първо да тествате за уязвимости при инжектиране, несигурно криптографско съхранение, препълване на буфери, познаване на парола и т.н.

=> Свържете се с нас да предложите списък тук.

Допълнителна информация:

Препоръчително четене

^