How does Discourse guard against SQL injections via the user agent?

Feature
1

Noticed that Discourse persists the user agent in some tables, web_crawler_requests for instance. Attackers have been known to use the “user-agent” field to inject malicious code like in Sleepy User Agent attacks. I was wondering if Discourse has any measures in place to guard against these kind of attacks?

2

Discourse is a Rails app, so we leverage the framework protections in our project:

6 Likes
3

Hi @mbaker341997

The Rails security guide is a good overview, but in my view, the Rails security guide does not adequately cover what many consider (arguably) the most important control for mitigating against an SQL injection attack.

The first line of defense against “SQL injection” is strong input data validation.

Let me give you a direct example from the Rails security guide (above);

The Rails security guide shows this simple example:

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

which can be exploited by injecting into the input params:

’ OR 1=1’

However, this can be prevented by having strong validation in the model, for example:

before_validation :filter_name_param

private

def filter_name_param

   ###  your custom params filter code here to insure special chars and other "dangerous 
   ###  code" is not permitted anywhere near the database

end

Rails has a lot of “out of the box” validations which can (and should) be included in models to insure input params are validated long before they have a chance to enter the DB.

Here is more on Rails validation here:

Many people forget that input data validations are the first line of defense against SQL injection attacks, and this is true of all server side web-dev code like Ruby, PHP, Python, etc. Generally speaking, client-side validation can be exploited and must be also validated on the server side.

In particular, I recommend reading the “Custom Validations” section:

HTH

2 Likes