Кто сказал, что для атаки обязательно выполнять JavaScript?

Мы потратили много времени на обсуждение XSS, включая различные способы выполнения XSS, техники защиты и методы обхода. С точки зрения веб-фронтенда, самое серьезное, что может быть сделано с веб-страницей, это по сути выполнение JavaScript кода.

В примерах атак мы в основном предполагали "возможность внедрения HTML" как предпосылку, а затем искали способы преобразовать его в XSS. Хотя мы использовали только эту простую полезную нагрузку в предыдущих примерах: <img src=x onload=alert(1)>, на практике это может быть не так просто.

Например, ранее мы кратко упоминали, что есть еще одна линия защиты под названием WAF, Web Application Firewall, это специальный бранмауэр для приложений. Он использует заранее написанные правила для блокировки "кажущихся вредоносными" полезных нагрузок.

Например, Dcard(социальная платформа в Тайване) использует WAF от Cloudflare. Вы можете попробовать перейти по этой ссылке: https://www.dcard.tw/?a=%3Cscript%3E

Вы увидите сообщение о блокировке:

Наиболее известный открытый WAF - это ModSecurity, который предоставляет инфраструктуру для инженеров, с возможностью добавления своих собственных правил или использовать правила написанные другими.

Например, OWASP ModSecurity Core Rule Set (CRS) - это открытая коллекция правил. Давайте взглянем на небольшой раздел:

Источник: coreruleset/rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf

## -=[ XSS Filters - Category 1 ]=-# 
http://xssplayground.net23.net/xssfilter.html#
 script tag based XSS vectors, e.g., <script> alert(1)</script>#SecRule REQUEST_COOKIES|!
REQUEST_COOKIES:/__utm/|REQUEST_COOKIES_NAMES|REQUEST_FILENAME|REQUEST_HEADERS:User-Agent|REQUEST_HEADERS:Referer|ARGS_NAMES|ARGS|XML:/*
## -=[ XSS Filters - Category 1 ]=-# 
http://xssplayground.net23.net/xssfilter.html#

script tag based XSS vectors, e.g., <script> alert(1)</script># 

SecRule REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|REQUEST_COOKIES_NAMES|REQUEST_FILENAME|REQUEST_HEADERS:User-Agent|REQUEST_HEADERS:Referer|ARGS_NAMES|ARGS|XML:/*
"@rx (?i)<script[^>]*>[\s\S]*?" \
"id:941110,\
 phase:2,\
 block,\
 capture,\
 t:none,t:utf8toUnicode,t:urlDecodeUni,t:htmlEntityDecode,t:jsDecode,t:cssDecode,t:removeNulls,\
 msg:'XSS Filter - Category 1: Script Tag Vector',\
 logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',\
 tag:'application-multi',\
 tag:'language-multi',\
 tag:'platform-multi',\
 tag:'attack-xss',\
 tag:'paranoia-level/1',\
 tag:'OWASP_CRS',\
 tag:'capec/1000/152/242',\
 ver:'OWASP_CRS/4.0.0-rc1',\
 severity:'CRITICAL',\
 setvar:'tx.xss_score=+%{tx.critical_anomaly_score}',\
 setvar:'tx.inbound_anomaly_score_pl1=+%{tx.critical_anomaly_score}'"

Это правило использует регулярное выражение <script[^>]*>[\s\S]*?, чтобы найти код, содержащий <script и блокирует его. Поэтому <script>alert(1)</script> будет обнаружен и заблокирован.

Есть и другие правила, соответствующие нашему любимому <img src=x onerror=alert()>, поэтому на практике мы часто сталкиваемся с ситуациями, когда мы думаем, что веб-сайт легко атаковать, но он оказываемся заблокированными из-за WAF. Мы продолжаем видеть окна ошибок, хотя уязвимость существует, но мы не можем ее использовать из-за WAF.

Эта игра в кошки-мышки между хакерами и веб-сайтами - одна из интересных сторон кибербезопасности, и она подчеркивает важность опыта и знаний. Что касается WAF, то часто на Twitter появляются полезные нагрузки для обхода WAF. Например:

<details/open=/Open/href=/data=; ontoggle="(alert)(document.domain)

На самом деле, содержимое, которое намеревается выполнить эту полезную нагрузку, - это <details open ontoggle=alert(document.domain)>, но он использует кучу других ключевых слов для его маскировки. Поскольку многие WAF полагаются на регулярные выражения для обнаружения, если полезная нагрузка не легко узнаваемая для WAF, то его можно обойти с помощью этого метода.

Но что, если его нельзя обойти?

Даже если веб-сайт может внедрять HTML, что с того? Если полезная нагрузка, которая может выполнить XSS, не может быть встроена, это значит, что решения нет? Не обязательно.

Такой род мышления обычно происходит из-за ограниченного понимания безопасности веб-фронтенда, где XSS - это единственная известная атака. Часто мы полагаемся на то, что непосредственное выполнение кода необходимо для выполнения атаки. На самом деле есть много других методов "косвенной атаки", и некоторые техники атаки даже не требуют выполнения JavaScript.

Как я уже упоминал в начале этого цикла, безопасность веб-фронтенда - это огромная вселенная. Мы уже потратили много времени на изучение XSS, поэтому пришло время войти в новую вселенную Client-Side атак!

В предстоящем контенте я представлю больше техник атак, помимо XSS.

Эта часть будет развиваться шаг за шагом, от "косвенного влияния на выполнение JavaScript" до "не нуждающегося в JavaScript вообще", и даже "не только JavaScript, но и без CSS". Мы будем непрерывно исследовать пределы атак веб-фронтенда.

Наконец, давайте немного потренируемся. Боб реализует многопользовательскую игру в котором можно рисовать, используя двумерный массив для представления холста. Игроки могут рисовать любой цвет на любой сетке, и массив обновляется с помощью onmessage. Реализация выглядит следующим образом:

onmessage = function(event){  const { x, y, color } = event.data  // for example, screen[10][5] = 'red'  screen[y][x] = color}

В чем проблема с этим кодом? Мы рассмотрим это далее.