Как да намерите XSS уязвимост
Скриптове между сайтове (XSS) е вид уязвимост на сигурността, открита в уебсайтове и уеб приложения.
XSS уязвимостипозволяват на злонамерените участници да инжектират злонамерен код (скриптове от страна на клиента) в уеб страници, гледани от потребителите. Веднъж изпълнен от браузъра на потребителя, този код може да извършва действия като промяна на поведението или външния вид на уебсайта, кражба на чувствителни данни, извършване на действия от името на потребителя и други
Основната причина за уязвимостта на XSS произтича от неуспеха да се валидира правилно или да се избегне въвеждането от потребителя или динамичното съдържание, което позволява инжектирането на JavaScript от страна на клиента по начин, който ще му позволи да се изпълни. Следователно вашето приложение е изложено на риск от XSS уязвимост, където и да обработва потребителско въвеждане. XSS се предлага в много различни форми, които могат да бъдат категоризирани в следните групи:
- Отразен (непостоянен) XSS: Точно както подсказва името, отразеният XSS възниква, когато резултатите от инжектирания злонамерен скрипт се покажат или незабавно се отразят от потребителя, без адекватно да се дезинфекцира съдържанието.
- Съхранен (постоянен) XSS: Това е по-опустошителен вариант на грешка в скриптове между сайтове. Това се случва, когато данните, предоставени от нападателя, се запазят от сървъра и след това се показват постоянно на „нормални“ страници, върнати на други потребители в хода на редовното сърфиране, без правилно HTML екраниране.
- DOM базиран XSS: базиран на DOM XSS възниква, когато инжектираният зловреден код не стигне до уеб сървъра. Вместо това се отразява от клиентския JavaScript код от страна на клиента.
XSS е една от най-честите уязвимости, открити в уеб приложенията. Ако не бъде коригиран, XSS може да изложи вашето приложение на различни рискове за сигурността, които оказват негативно влияние върху организацията и крайните потребители. XSS уязвимост, която позволява на атакуващ да промени баланса на количеството на продукта на клиента или баланса по банковата сметка, може да повлияе на репутацията на компания или да отслаби доверието на потребителите. Това е нещо, което не можете да си позволите да пренебрегнете. Ето защо е важно да идентифицирате и премахнете тази уязвимост от вашето уеб приложение, преди да го изложи на сериозни проблеми със сигурността. Тази статия ще обясни как да намерите XSS в уеб приложения, включително какво можете да направите, за да го предотвратите.
Ръчни прегледи и тестване на кода
Прегледът на кода има за цел да идентифицира пропуски в сигурността на приложенията, заедно с точните първопричини. Това включва проверка на изходния код на приложение, за да се гарантира, че то се самозащитава в дадената среда. Според OWASP, „Ако кодът не е прегледан за дупки в сигурността, вероятността приложението да има проблеми е почти 100%”. За изпълнение на тази задача могат да се използват инструменти. Все още, за съжаление, те не разбират контекста (винаги се изисква човешка проверка) и тук влиза в действие ръчният преглед на кода за сигурност.
Ако ръчният преглед на кода е направен правилно, тестът за проникване след това с помощта на автоматизирани инструменти трябва да открие малко или никакви уязвимости. Интересното е, че OWASP предоставя подробно ръководство за ръчно преглеждане код за XSS уязвимости , включително пълно ръководство за ръчно тестване за отразен XSS , съхранен XSS , и Базирани на DOM XSS уязвимости за твое сведение. Следните ръчни процеси могат да се използват за идентифициране на често срещани XSS уязвимости:
Идентифицирайте кода, който извежда въведеното от потребителя: Кодове, които извеждат въведени от потребителя данни без подходяща дезинфекция, рискуват XSS уязвимост. Натиснете Ctrl + U, за да видите източника на изход на страницата от браузъра, за да видите дали вашият код е поставен в атрибут. Ако е така, инжектирайте следния код и тествайте, за да видите изхода:„onmouseover= предупреждение („здравей“);“
Можете да тествате, за да видите изхода, като използвате този скрипт:;
Ако обаче кодът, за който преглеждате, филтрира
Проверете дали изходът е кодиран: Проверете дали HtmlEncode се използва за кодиране на HTML изход, който включва всякакъв тип вход. Също така проверете дали UrlEncode се използва за кодиране на URL низове. Входните данни могат да идват от низове на заявки, полета на формуляри, бисквитки, HTTP заглавки и входни данни, прочетени от база данни, особено ако други приложения споделят базата данни. Ако тези кодировки липсват, вашето приложение е изложено на риск от XSS уязвимост. В допълнение, чрез кодиране на данните вие не позволявате на браузъра да третира HTML като изпълним скрипт.
Идентифицирайте кода, който обработва URL адреси: Кодът, който управлява URL адресите, може да изложи на риск XSS и други уязвимости. Прегледайте своя код и системи, както следва:
- Проверете дали вашият уеб сървър е актуализиран. Ако вашият уеб сървър не е актуален с най-новите корекции за сигурност, той може да е уязвим на атаки при преминаване на директория :
- Ако вашият код филтрира „/“, нападателят може лесно да заобиколи филтъра, като използва URL кодиране (процентно кодиране ) за същия персонаж. Например, процентното кодиране за „/“ е „%c0f%af“, което може да се използва за заобикаляне на филтъра, както е показано в следния URL адрес: http://www.abc.com/..%c0f%af ../winnt.
- Ако вашият код обработва въвеждане на низ на заявка, проверете дали той ограничава входните данни и извършва проверки на границите. Също така проверете дали кодът не е уязвим, ако атакуващ инжектира огромно количество данни чрез параметър на низ на заявка като URL адреса, показан тук: http://www.abc.com/test.aspx?var=InjectHugeAmountOfDataHere.
Единичен тест на вашите кодове: Единичното тестване е метод за тестване на софтуер, чрез който се тестват отделни единици от изходния код, за да се определи дали са годни за употреба. Единичното тестване има за цел да изолира всяка част от програмата и да покаже, че отделните компоненти са правилни. Използвайте модулно тестване, за да се уверите, че определен бит от данни е правилно екраниран. Единичното тестване помага да се идентифицират XSS и други недостатъци в началото на цикъла на разработка. Ако е възможно, тествайте единица всяко място, където се показват предоставени от потребителя данни. След като намерите и поправите XSS грешка във вашия код, помислете за добавяне на регресионен тест за нея.
Извършете тези основни тестове на вашето приложение : Създайте тестов потребителски профил и използвайте този профил за взаимодействие с вашето приложение. Вмъкнете низове, които съдържат HTML и JavaScript метасимволи като >’>”>във всички входни данни на приложението, като формуляри, URL параметри, скрити полета или стойности на бисквитки.
Ако приложението ви не избягва правилно този низ, ще видите предупреждение и ще знаете, че нещо не е наред. Навсякъде, където приложението ви обработва URL адреси, предоставени от потребителя, въведете следния код на JavaScript: alert(0) или data:text/html,. Всичко това може да помогне за идентифициране на съхранени XSS грешки.
Автоматизирано тестване на приложения
Стандартен техники и инструменти за тестване на сигурността може да се използва за тестване и откриване на XSS уязвимости в уеб приложения. Някои от популярните техники за тестване, които могат да се използват, включват:
- Статично тестване за сигурност на приложението (SAST): SAST се използва за защита на приложения чрез преглед на изходния код за идентифициране на уязвимости или доказателства за известни несигурни практики, когато не се изпълнява. Значително предимство на статичния анализ на кода е, че не е необходимо да чакате, докато приложението бъде разгърнато в среда за етапи с тестови данни. Вместо това можете просто да тествате кода. Това дава на проверката за уязвимости 100% покритие на кода и прави намирането на уязвимости по-бързо и по-евтино. Инструментите SAST използват стратегия за тестване на бяла кутия, която сканира изходния код на приложенията и техните компоненти, за да идентифицира потенциални пропуски в сигурността.
- Динамично тестване на сигурността на приложенията (DAST): DAST инструментите комуникират с приложенията, за да идентифицират потенциални уязвимости в сигурността през предния край. DAST инструменти нямат достъп до изходните кодове; вместо това те извършват атаки, използвайки стратегията на черната кутия за откриване на уязвимости. С динамичния анализ се извършват проверки за сигурност, докато се изпълнява или изпълнява кодът или приложението, което се преглежда. Техника, известна като размиване, се използва в динамични тестове за подаване на произволни, неправилно формирани данни като входни данни към приложението, за да се определи дали то ще разкрие пропуски в XSS.
- Интерактивно тестване на сигурността на приложенията (IAST): IAST съчетава най-доброто от SAST и DAST. Той анализира кода за XSS и други уязвимости в сигурността, докато приложението се изпълнява от всяка дейност, взаимодействаща с функционалността на приложението.
С техниките, описани по-горе, можете бързо да тествате и откриете XSS уязвимости във вашите уеб приложения. Скенери за уеб уязвимости, като напрНепобедим,Акунетикс, Veracode , Checkmarx , а други са мощни инструменти, които могат да обходят целия ви уебсайт или приложение и автоматично да проверяват за XSS и други пропуски в сигурността. Въпреки че често не са оптимизирани за вашето конкретно приложение, те ви позволяват бързо и лесно да откриете по-очевидните уязвимости. В допълнение, те прилагат повечето от техниките за тестване на уеб приложения, обсъдени по-горе, и ще ви позволят да приложите тези техники, за да сканирате вашето уеб приложение за уязвимости. След това ще генерира отчет за откритите уязвимости и ще се опита да ги поправи автоматично. И Invicti, и Acunetix предлагат безплатни демонстрации.
Демонстрация на Invincible Access
Acunetix Access Demo
Какво можете да направите, за да предотвратите XSS
Този раздел предоставя някои препоръки как можете да минимизирате XSS уязвимостите. Те в никакъв случай не са изчерпателни; те обаче трябва да са добра отправна точка за защита на приложенията. Нищо не е безупречно. Технологиите се променят много бързо и атаките стават все по-сложни. Това, което работи днес, може да не работи напълно утре. Но като разберете основите, можете да сте подготвени да предотвратите бъдещи техники за атака, докато се развиват. Ето някои от нещата, които можете да направите, за да предотвратите XSS.
Използвайте сигурни практики за кодиране: Както при повечето уязвимости при инжектиране, ключът към защитата на вашето уеб приложение и предотвратяването на XSS атаки е да се придържате към гарантираните практики за кодиране. Сценарий на потребителско въвеждане, който трябва да имате предвид във вашите приложения, е когато вашето приложение приема вход от потребители и използва този вход, за да създаде изход за други потребители. Тук влизат в сила златните правила за въвеждане от страна на потребителя. Първото златно правило за потребителско въвеждане гласи, че всяка информация е подозрителна, докато не се докаже противното. Второто златно правило за потребителско въвеждане гласи, че данните трябва да бъдат филтрирани, когато пресичат границата между ненадеждни и надеждни домейни. В момента, в който пренебрегнете тези правила, отваряте вратата за XSS и други инжекционни атаки. OWASP предоставя технологично-агностичен документ, който определя набор от общ софтуер практики за кодиране на сигурността във формат на контролен списък, който може да бъде интегриран във вашия жизнен цикъл на разработка на софтуер. Прилагането на тези практики ще смекчи повечето често срещани уязвимости на приложенията, включително XSS.
Филтриране на потребителски данни: Един от най-простите начини за предотвратяване на XSS уязвимостта е преминаването на всички външни данни (въведени от потребителя) през филтър. Такъв филтър би премахнал опасни тагове и атрибути като
В HTML можете да избегнете опасни знаци, като използвате HTML обекти като последователност, последвана от кода на символа. Например, '<’ and ‘>“ са HTML кодирането за „<‘ and ‘>’ съответно знаци. Ако включите:в HTML на страница, скриптът ще се изпълни. Но ако включите кодовете на знаци в HTML на страница, както е показано тук:
Ще отпечата текста „”, но всъщност няма да изпълни скрипта. Като избяга от
Можете да направите цялото бягство, като напишете кода сами. Написването на вашия код за избягване на въвеждане от потребителя и адекватното и последователно прилагане обаче е изключително трудно. Затова препоръчваме да използвате съществуващи библиотеки като напр OWASP ESAPI , Microsoft AntiXSS (най-подходящ за среда на Microsoft) или рамки или шаблони за уеб разработка, които осигуряват автоматично екраниране в зависимост от контекста. Ако използвате шаблони за генериране на HTML в JavaScript, Шаблони за затваряне и Ъглова предоставят вградени възможности за бягство.
Други неща, които можете да направите, за да предотвратите XSS уязвимостта или да сведете до минимум шансовете за XSS атаки, включват:
- Изучаване на най-добрите практики за вашите технологии от страната на сървъра и клиента, като например използване HTML дезинфектант или конфигуриране на браузъра ви да използва прокси, което сканира и прихваща трафик като напр Burp прокси и ratproxy за да помогне за идентифициране на проблемите.
- Използване на система за уеб шаблони или рамка за уеб разработка с контекстно автоматично екраниране.
- Ръчно екраниране на въведеното от потребителя (ако шаблонната система с автоматично екраниране в зависимост от контекста не е осъществима)
- Разбиране на обичайното поведение на браузъра, което води до XSS.
Заключение
Няма сребърен куршум за откриване на XSS в уеб приложения. Вместо това намирането на XSS уязвимости изисква комбинация от човешки усилия (ръчни прегледи на код) и технологична поддръжка (автоматизирани инструменти като скенери за уязвимости). Разработчик и проверяващ сигурността на приложението ръчно проверяват кодове с текстов редактор в единия край на скалата. Експертен екип по сигурността с инструменти за разширен статичен анализ (SAST) е в другия край на скалата.
Инструментите са добри при оценката на големи количества код и посочването на възможни проблеми. Все пак, човек трябва да провери всеки резултат, за да определи дали той може да се използва и евентуално да оцени риска за организацията. Човешки рецензенти трябва да попълнят значителните слепи петна, които автоматизираните инструменти просто не могат да проверят. Никоя методология за тестване не е безпогрешна; така че извършването на комбинация от ръчни прегледи на кода и автоматизирано тестване ще намали шансовете за XSS уязвимост във вашето приложение.
ЧЗВ за междусайтови скриптове
Къде обикновено можете да намерите XSS уязвимости?
Междусайтовите скриптови атаки се изпълняват чрез потребителски полета за въвеждане в уебсайтове. Затова е важно да блокирате автоматичното публикуване в уебсайт. Таблата за обяви и секциите за коментари на уеб страниците са най-податливите уеб функции за XSS уязвимости.
Как се открива XSS?
Най-лесният начин за откриване на XSS уязвимости е да използвате скенер за уязвимости. Можете да приложите ръчни проверки на кода в уеб страница. Ако не сте експерт по кодиране, тази задача може да ви се стори трудна. Open Web Application Security Project (OWASP) препоръчва следното:
- Уверете се, че въвеждането не се пренася в същите HTTP отговори като HTML или JavaScript.
- Кодирайте всички данни за предаване, освен ако не са референтни стойности, които идват от вашата собствена база данни и сте сигурни, че не може да са били манипулирани.
- Внимавайте как данните се въвеждат в обектния модел на документа (DOM). обгръщане на данни в един от следните API:
- Node.textContent
- document.createTextNode
- Element.setAttribute (само втори параметър)
Може ли WAF да открие XSS?
Можете да очаквате, че защитна стена на уеб приложение (WAF) ще открие и блокира XSS атака. Ако обаче се случи такъв, това означава, че вашият уебсайт има слабости в кодирането, които правят възможни XSS атаките и те ще се появят отново, докато не пренапишете тези процеси, за да затворите уязвимостта. Използвайте скенер за уязвимости, за да откриете слабости в сигурността, които правят възможни скриптови атаки между сайтове, тогава няма да се налага да се притеснявате за всякакви опити, които могат да възникнат, защото те винаги трябва да са неуспешни.