Защита сайта от атак с использованием Nemesida WAF: от сигнатур до искусственного интеллекта

[equand]

Как оно играет против Cloudbric, Cloudflare или Sophos?

[RomanovR]

Мы не сторонники подхода «казаться лучше за счет привлечения внимания к недостаткам других решений», готовы честно соревноваться и выигрывать, но решение оставляем за нашими клиентами, поэтому можете сами оценить, как точно Nemesida WAF способен блокировать атаки.

Есть как минимум 3 варианта это сделать:
— можно получить демо-доступ к личному кабинету, посмотреть за атаками в реальном времени\самому попытаться атаковать, наблюдая за работой Nemesida WAF на примере vulns.pentestit.ru;
— получить триальную Standalone-версию Nemesida WAF и развернуть в своей инфраструктуре;
— бесплатно встать под защиту облачной версии на 2 недели.

[varvsn]

Пример атаки, которую пропустит NAXSI:
index.php?id=-1'+Union+Select+1,2,3,4,5+--+1

Открываем стоковый naxsi_core.rules, смотрим:
MainRule «str:'» «msg:simple quote» «mz:ARGS|BODY|URL|$HEADERS_VAR:Cookie» «s:$SQL:4,$XSS:8» id:1013;

Naxsi реагирует на кавычку. До «стоп слова» дело даже не доходит (как бы это ни звучало).
Проверил все примеры из статьи на nginx 1.13.4+naxsi — всё прекрасно детектируется.

[LukaSafonov]

Контекст применимости атаки относится к операторам MySQL, находящихся в запросе.

Naxsi реагирует на кавычку. До «стоп слова» дело даже не доходит (как бы это ни звучало).

Правило

MainRule «str:'» «msg:simple quote» «mz:ARGS|BODY|URL|$HEADERS_VAR:Cookie» «s:$SQL:4,$XSS:8» id:1013;

будет больше фолсить, чем приносить пользы (особенно в теле запроса |BODY|) и скорее всего может быть исключено из контекста.

В этом примере указывается на ошибку сравнения:

strncasechr(const char *s, int c, int len)
{
  int   cpt;
  for (cpt = 0; cpt < len && s[cpt]; cpt++)
    if (tolower(s[cpt]) == c)   // сравнение lowercase с возможным uppercase 
      return ((char *) s+cpt);
  return (NULL);
}

/*
** strstr: faster, stronger, harder
** (because strstr from libc is very slow)
*/
char *
strfaststr(unsigned char *haystack, unsigned int hl, 
         unsigned char *needle, unsigned int nl)
{
  char  *cpt, *found, *end;
  if (hl < nl || !haystack || !needle || !nl || !hl) return (NULL);
  cpt = (char *) haystack;
  end = (char *) haystack + hl;
  while (cpt < end) {
      found = strncasechr((const char *) cpt, (int) needle[0], hl);
      if (!found) return (NULL);
      if (nl == 1) return (found);
      if (!strncasecmp((const char *)found+1, (const char *) needle+1, nl-1))
    return ((char *) found);
      else {
      if (found+nl >= end)
        break;
      if (found+nl < end) {
        /* the haystack is shrinking */
        cpt = found+1;
        hl = (unsigned int) (end - cpt);
      }
    }
    }
  return (NULL);
}

[varvsn]

Я всего лишь хотел указать на то, что NAXSI с дефолтным конфигом ловит всё, о чем идет речь в статье. А то, что некоторые срабатывания, возможно, будут false-positive для каких-то проектов — вопрос немного другой.

[LukaSafonov]

NAXSI c дефолтным конфигом практически все фолсит, от легитимных кавычек и запятых до названий файлов (например, xxx_640x480.png). NAXSI хорош для изучения базисных принципов защиты веб-приложений, но абсолютно не подойдет для enterprise-решений.

У многих правил довольно широкое трактование, и как только начнете строить WhiteList (количество может привышать 2000 строк на каждое отдельное веб-приложение), то загоните себя в ловушку, из которой уже не сможете выбраться. Каждый новый блок (фолс) придется разблокировать созданием правил, а это значит что будут потеряны легитимные клиенты. Но, повторюсь, если хотите изучить базовые принципы защиты веб-приложений — NAXSI будет отличным помощником.