Анализ на сигурността: опасности от използването на външни скриптове във вашата система

Когато работите с код ежедневно, е много лесно да се съсредоточите само върху това да го накарате да „работи“ и да забравите нещо ключово: Какво се случва, когато приложението ви започне да комуникира с код, който не контролирате?Скриптове на трети страни, външни библиотеки, реклами, аналитични джаджи, интеграции с доставчици… всичко това е удобно за разработчика, но също така отваря вратата към някои от най-опасните и трудни за откриване атаки.

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

Какво точно е външен скрипт (и защо е толкова чувствителен)?

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

Когато говорим за външни скриптове в контекста на сигурността, имаме предвид главно два сценария: код, който идва от мрежата (JavaScript, скриптове, вградени в PDF файлове, макроси на Office, HTA и др.) и скриптов код, който се изпълнява на самата система (PowerShell, bash, VBScript, Python и др.), управлявани от потребителя, от друга програма или чрез експлойт.

Красотата (и проблемът) на тези скриптове е, че Те разчитат на напълно легитимни инструментиВашият браузър трябва да изпълнява JavaScript; Windows включва PowerShell и WMI; много компании автоматизират администрирането със скриптове. Нападателят просто трябва да проникне в този работен процес и да използва повторно същите възможности, които използвате вие, но за далеч по-неблагородни цели.

Свързана статия:

FileFort Backup, създайте резервно копие на всички документи, снимки и музикални папки на FTP сървъра

Компрометирани легитимни сайтове: най-коварната страна на проблема

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

Този код обикновено е замъглено и добре камуфлирано сред легитимни библиотеки, реклами или джаджи на трети страни. В много случаи това е част от експлоатационни комплекти (Neutrino, Angler по онова време и други по-модерни), способни автоматично да откриват уязвимости в браузъра, в плъгини (Flash, Java, PDF) или дори в операционната система и спомагателните приложения.

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

Злонамерена реклама: рекламата като троянски кон

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

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

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

Скриптове от страна на клиента: мощност и повърхност за атака

Клиентското програмиране – JavaScript, TypeScript, HTML5, CSS и други уеб езици – е двигателят на съвременния уеб. Благодарение на него, ние имаме динамични формуляри, SPA, интерактивни карти, табла за управление в реално време и др. Но цялата тази мощ идва с една уловка: този код се изпълнява в браузъра на всеки потребител, напълно видим и модифицируем.

Това означава, че всеки клиентски скрипт е директна мишена за нападателяМожете да го инспектирате, да го реконструирате, да го манипулирате по време на изпълнение, да прехващате API извиквания или дори да инжектирате свой собствен код, като използвате XSS, CSRF уязвимости или лоши имплементации на CORS и CSP.

Типични проблеми, свързани с несигурни клиентски скриптове, включват: Кроссайт скриптове (XSS)Фалшифициране на заявки между сайтове (CSRF), излагане на токени и чувствителни данни на фронтенда, инжектиране на код чрез DOM и директно манипулиране на състоянието на приложението от конзолата на браузъра.

XSS: Когато вашият собствен фронтенд се обърне срещу вас

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

Типични вектори са полета за коментари, потребителски профили, параметри в URL адреси или всякакви данни, които приложението отразява без дезинфекция и без правилно кодиранеАко този изход се вмъкне в HTML кода като такъв – или още по-лошо, в атрибути като onclick или от innerHTML „Нападателят може да промъкне етикет.“ <script> или по-сложен полезен товар.

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

Скриптове в Office, PDF файлове и други документи

Външните скриптове не пристигат просто през браузърите. Нападателите експлоатират това от години. макроси и механизми за скриптове в документи на Office, PDF файлове и други на пръв поглед безобидни форматиИмейл с прикачен файл, който „трябва да бъде отворен“, си остава много печеливша възможност.

В случая с Office, класическият метод е документ с обфуциран VBA макрос и рискове, свързани също с Скриптове за офисаМакросът се изпълнява, когато потребителят активира активно съдържание и обикновено извиква PowerShell скриптове, WScript, HTA или други системни компоненти да изтегли и стартира зловредния полезен товар в паметта. Много семейства рансъмуер са проникнали в системата по този начин.

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

PowerShell, bash и компания: скриптове в системата без докосване на диска

В системна среда езици като PowerShell, VBScript, bash, Python или Perl са изключително мощни инструменти за администриране. Именно затова, Групите за напреднали заплахи и безфайловият зловреден софтуер ги обожаватВместо да пускат изпълним файл, те просто инжектират или изтеглят скрипт, който се изпълнява изцяло в паметта.

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

Същото важи и за bash или Python скриптове в Linux среди и AppleScript на macOS. Една проста команда, копирана от форум, или скрипт, изтеглен от ненадеждно хранилище, може да се изпълни на вашата система. много повече, отколкото изглежда, от отваряне на задните врати до промяна на критични настройки.

Безфайлови атаки и заобикаляне на класически антивирусен софтуер

Ключово предимство за нападателя е, че скриптовете му позволяват да стартира атаки. практически без да записва нищо на дискЕксплойтът пристига през интернет, имейл или RDP, изпълнява PowerShell или JavaScript команда, която изтегля допълнителен код директно в паметта, инжектира го в легитимен процес и това е всичко. Когато рестартирате, повечето от следите изчезват.

Според проучвания от последните години, До 40% от наблюдаваните атаки вече са „безфайлови“ или силно базирани на скриптове.Злонамереният полезен товар се намира в паметта, използва процеси, подписани от Microsoft или други доставчици, и разчита на легитимни инструменти като mshta.exe, wscript.exe, powershell.exe, rundll32.exe и др.

В този сценарий, продукти, които зависят почти изключително от подписи на файлове на диск Те играят в неизгодно положение; струва си да се прегледат сравнения, като например Сравнение на сигурността на Windows Defender да се разберат ограниченията и алтернативите. Откриването тогава зависи от евристични техники и поведенчески анализ: подозрителни командни низове, извиквания на интерпретатори с обфускирани параметри, странни мрежови връзки, използване на чувствителни API и др.

Прекомерни разрешения и лоша конфигурация: най-добрият приятел на злонамерения скрипт

Един аспект, който често се подценява, е влиянието на акаунти с прекомерни привилегииВ много Windows среди повечето потребители все още работят като локални администратори или с контрол на потребителските акаунти (UAC) на абсурдно ниски нива. Ако злонамерен скрипт се изпълни с тези идентификационни данни, той има пълна свобода да инсталира драйвери, услуги, да променя системния регистър или да деактивира контролите за сигурност.

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

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

Основни опасности от използването на външни скриптове във вашата система

Всичко гореизброено се превръща в поредица от доста конкретни рискове, когато вашето приложение или инфраструктура зависи от външни скриптове:

• Изпълнение на произволен код (RCE): Чрез XSS, макроси, PowerShell скриптове, HTA или експлойти в четци и браузъри, атакуващият може да изпълнява команди с привилегиите на потребителя или дори на системата.
• Кражба на данни и идентификационни данни: Скриптовете в браузъра могат да четат „бисквитки“, localStorage и API отговори; системните скриптове могат да събират пароли, токени, API ключове, чувствителни файлове и да ги изхвърлят на отдалечен сървър. За да проверите за течове на акаунти, препоръчително е Проверете дали вашите акаунти са били изтекли след подозрение.
• Отвличане на сесия и самоличност: Добре внедрен XSS или компрометиран скрипт на трета страна може да открадне токени за сесия, JWT-ове и бисквитки. незащитен или дори да прихващат идентификационни данни във фалшиви формуляри.
• Странично движение и постоянство: Веднъж влезли вътре, административните скриптове (PowerShell, WMI, bash) ви позволяват да изследвате мрежата, да разпространявате вируси към други машини, да инсталирате задни вратички и да поддържате постоянен достъп. Прегледайте ръководствата за управление на постоянните заплахи помага за смекчаване на тези сценарии.
• Добив на криптовалути и злоупотреба с ресурси: Злонамерени скриптове на уебсайтове или инжектирани разширения могат да използват процесора и графичния процесор на вашите потребители или вашите сървъри за копаене без вашето съгласие, влошавайки производителността и съкращавайки живота на оборудването.
• Повреда на уебсайтове и манипулиране на съдържание: XSS, компрометирани плъгини или модифицирани външни скриптове могат да променят това, което потребителят вижда, да вмъкват реклама, фишинг или измамно съдържание във вашия собствен сайт.
• Избягване на контрол и сложен криминалистичен анализ: Тъй като се изпълняват в паметта и използват легитимни инструменти, атаките, базирани на скриптове, оставят по-малко ясни следи на диска и в лог файловете, което ги прави по-трудни за откриване и анализ по-късно.

Най-добри практики за сигурна работа с външни скриптове

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

Свързана статия:

Как да защитите Windows 11: съвети и професионални настройки

1. Подсилете фронтенда и контролирайте какво се изпълнява

От страна на клиента, целта е да се минимизират щетите, които може да нанесе злонамерен скрипт, независимо дали е ваш собствен или от трета страна:

• Валидира и дезинфекцира входните данни на клиента и сървъра. Филтрите от страна на клиента подобряват потребителското изживяване, но истинската сигурност се крие на сървъра. Въпреки това, филтрирането, където е възможно, помага за смекчаване на много тривиални XSS и вектори за инжектиране.
• Избягвайте и винаги кодирайте изхода. Всички потребителски данни, които показвате в HTML, трябва да бъдат правилно екранирани. Избягвайте изграждането на HTML чрез innerHTML със сурови струни.
• Избягвайте онлайн скриптове. Не поставяйте JavaScript директно в HTML атрибути или блокове <script> Вградете файлове, ако е възможно. Използвайте външни файлове и се възползвайте от по-строгите политики за сигурност на съдържанието.
• Внедрете приличен CSP. Дефинирайте политика за сигурност на съдържанието, която ограничава откъде могат да се качват скриптове, забранява eval и блокиране inline-script освен когато е строго необходимо.
• Използвайте защитени бисквитки с HttpOnly и SameSite. За сесии, маркирайте бисквитките като Secure, HttpOnly y SameSite=Lax o Strict за да ги защити от XSS и CSRF.
• Приложете заглавки за сигурност. HSTS, X-Content-Type-Options, X-Frame-Options и подобни инструменти помагат за затваряне на лесни врати, които много атаки, базирани на скриптове, експлоатират.

2. Укрепва управлението на скриптове от страна на клиента

В допълнение към логиката на приложението, зависимостите от front-end интерфейса трябва да бъдат наблюдавани:

• Минимизирайте броя на скриптовете на трети страни. Всеки допълнителен уиджет, CDN или SDK е нова повърхност за атака. Зареждайте ги само ако са наистина необходими.
• Задайте версии и използвайте целостта на подресурси (SRI). Когато зареждате скриптове от CDN мрежи, използвайте атрибути integrity y crossorigin за да се гарантира, че съдържанието не е било променено.
• Поддържайте библиотеките и фреймворците актуални. Много XSS и подобни уязвимости са поправени в по-новите версии на React, Angular, Vue, jQuery и др. Придържането към по-стари версии оставя известните уязвимости отворени.
• Проверявайте редовно разширенията и плъгините си. Както в корпоративните браузъри, така и в сървърите (CMS плъгини), той премахва всичко, което не е от съществено значение, и следи за предупреждения за сигурност.

3. Осигурете използването на скриптове в системата (PowerShell, bash…)

В сферата на операционните системи ключът се крие в прилагайте принципа на най-малките привилегии и наблюдавайте поведението:

• Това ограничава кой какво може да изпълни. Сегментирайте потребителите според техните нужди: такива, които се нуждаят от скриптове ежедневно, такива, които се нуждаят само от време на време, и такива, които никога. Блокирайте ненужните интерпретатори в профили, които не ги изискват.
• Ограничава PowerShell и други интерпретатори. Използвайте Execution Policy, AppLocker или еквивалентни алтернативи, за да разрешите само подписани скриптове или скриптове, разположени в контролирани пътища.
• Деактивирайте макросите по подразбиране. Те трябва да бъдат активирани само за потребители и документи, които ги изискват, и за предпочитане цифрово подписани.
• Не работете с администраторски акаунти, освен ако не е абсолютно необходимо. Изпълнявайте ежедневни задачи със стандартни акаунти и запазвайте привилегировани идентификационни данни за специфични, контролирани задачи.
• Следи за подозрителни команди. PowerShell последователности с Base64 низове, изтегляния от необичайни домейни, изпълнение на mshta, wscript o rundll32 Необичайните явления са ясни признаци, че нещо не е наред.

4. Защитете чувствителните данни на клиента и сървъра

Тъй като скриптовете са средството, данните са наградата. Направете го трудно:

• Избягвайте да излагате токени и ключове на фронтенда. Не крийте тайни в JavaScript, глобални променливи или статичен код. Всичко от страна на клиента е видимо.
• Криптирайте правилно и използвайте силни ключове. За данни в движение използвайте добре конфигуриран TLS; за данни в покой използвайте текущи алгоритми и режими (AES-GCM, Argon2/bcrypt за пароли и др.).
• Използвайте правилно удостоверяване, базирано на токени. JWT и подобни протоколи трябва да бъдат подписани със защитени ключове, да имат разумни дати на валидност и да не използват несигурни алгоритми. Винаги използвайте HTTPS.
• Разчитайте на криптографията или обфускацията „бяла кутия“ само като допълнителен слой. Обфускацията на скриптове прави обратното инженерство по-трудно, но не е заместител на сигурния дизайн.

5. Инструменти за поддръжка: не се опитвайте да видите всичко „на око“

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

• Статични анализатори (SAST) и предпазни линтери. ESLint с плъгини за сигурност, Semgrep и др., може да открива опасни модели, като например използването на eval, опасно конкатениране на HTML или shell команди.
• Скенери за уязвимости и SCA. Те анализират вашите зависимости (както от фронтенда, така и от бекенда) за библиотеки с известни CVE и препоръчват безопасни версии.
• WAFs и мониторинг на трафика. Една добра защитна стена за уеб приложения може да блокира типичните XSS и опити за инжектиране в движение и да ви даде видимост за необичайни модели; струва си да се допълни с персонализирани правила в защитната стена.
• Инструменти за закаляване и рашпили. Самозащитата по време на изпълнение, обфускацията, неправилното използване и мониторингът на целостта добавят защитни слоеве към силно изложените на риск клиентски приложения.
• Удобни за разработчици платформи за сигурност. Съвременните решения интегрират SAST, SCA, секретно сканиране и CI/CD конфигурация, предлагайки ранно откриване и често автоматично коригиране на уязвимости, свързани със скриптове и зависимости.

Организационни промени: сигурността на скриптовете не е само за „ИТ“ специалисти

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

• Периодично обучение. Че хората знаят как да разпознават подозрителни имейли, неочаквани макроси, странни изскачащи прозорци и „магически“ скриптове във форумите.
• Ясни правила за ползване. Какво може да се инсталира, откъде да се изтеглят скриптове, как се управляват макросите, кой може да използва интерактивен PowerShell и т.н.
• Сегментиране на мрежи и устройства. Ако даден скрипт успее да компрометира компютър, този компютър не трябва да има директна връзка с цялата вътрешна мрежа.
• 24/7 наблюдение и реакция. Колкото по-рано откриете злонамерен скрипт в процес на изпълнение, толкова по-малко време ще има за преместване, криптиране или извличане на данни.

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

Свързана статия:

OSX Mavericks няма да ви позволи да инсталирате определено приложение на вашия Mac, научете как да го направите

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