Как Discourse защищает от SQL-инъекций через user agent?

Внести вклад Функция
1

Заметил, что Discourse сохраняет строку User-Agent в некоторых таблицах, например в web_crawler_requests. Известно, что злоумышленники используют поле «user-agent» для внедрения вредоносного кода, как в атаках типа Sleepy User Agent. Хотелось бы узнать, есть ли в Discourse какие-либо меры защиты от подобных атак?

2

Discourse — это приложение на Ruby on Rails, поэтому мы используем встроенные механизмы защиты фреймворка в нашем проекте:

6 лайков
3

Привет, @mbaker341997

Руководство по безопасности Rails даёт хорошее общее представление, но, на мой взгляд, оно недостаточно подробно освещает то, что многие считают (возможно) самым важным механизмом защиты от SQL-инъекций.

Первая линия обороны от SQL-инъекций — это строгая валидация входных данных.

Приведу прямой пример из руководства по безопасности Rails (выше):

В руководстве показан такой простой пример:

Project.find(:all, :conditions => "name = '#{params[:name]}'")

который можно эксплуатировать, внедряя в параметры ввода:

' OR 1=1'

Однако это можно предотвратить, внедрив строгую валидацию в модель, например:

before_validation :filter_name_param

private

def filter_name_param

   ### здесь ваш код кастомной фильтрации параметров, чтобы гарантировать, что
   ### специальные символы и другой "опасный код" не попадут в базу данных

end

В Rails есть множество встроенных средств валидации, которые можно и нужно включать в модели, чтобы убедиться, что входные параметры проверяются задолго до того, как они попадут в БД.

Здесь подробнее о валидации в Rails:

Многие забывают, что валидация входных данных — это первая линия обороны от SQL-инъекций, и это справедливо для любого серверного веб-кода, будь то Ruby, PHP, Python и т. д. Как правило, клиентскую валидацию можно обойти, поэтому данные должны проверяться и на стороне сервера.

В частности, рекомендую прочитать раздел «Кастомная валидация»:

Надеюсь, это поможет.

2 лайка