Discourseはユーザーエージェント経由のSQLインジェクションをどのように防いでいますか？

貢献 特徴
1

Discourse がいくつかのテーブル（例えば web_crawler_requests など）に User-Agent を永続化していることに気づきました。攻撃者が「user-agent」フィールドを利用して悪意のあるコードを注入する事例（Sleepy User Agent 攻撃など）が知られています。Discourse はこうした種類の攻撃から防御するための対策を講じているのでしょうか？

2

Discourse は Rails アプリケーションであるため、プロジェクト内でフレームワークの保護機能を活用しています。

「いいね！」 6
3

mbaker341997 さん、こんにちは。

Rails のセキュリティガイドは良い概要を提供していますが、私の見解では、SQL インジェクション攻撃を緩和するために多くの人々が（議論の余地はありますが）最も重要だと考える制御について、十分にカバーしていないと感じています。

「SQL インジェクション」に対する最初の防御線は、強力な入力データ検証です。

上記の Rails のセキュリティガイドから、具体的な例を示しましょう。

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 などのすべてのサーバーサイドの Web 開発コードに当てはまります。一般的に、クライアントサイドの検証は悪用される可能性があるため、サーバーサイドでも再検証を行う必要があります。

特に、「カスタム検証」セクションを読むことをお勧めします：

参考になれば幸いです。

「いいね！」 2