Discourse는 사용자 에이전트를 통한 SQL 주입을 어떻게 방지하나요?

기여 기능
1

Discourse가 몇몇 테이블에 사용자 에이전트를 저장한다는 것을 알게 되었습니다. 예를 들어 web_crawler_requests 테이블이 있습니다. 공격자들은 Sleepy User Agent 공격과 같이 악성 코드를 주입하기 위해 “user-agent” 필드를 악용하는 것으로 알려져 있습니다. Discourse가 이러한 유형의 공격에 대비하여 어떤 조치를 취하고 있는지 궁금합니다.

2

Discourse는 Rails 앱이므로, 프로젝트에서 프레임워크의 보안 기능을 활용합니다:

6개의 좋아요
3

@mbaker341997 님, 안녕하세요.

Rails 보안 가이드는 좋은 개요를 제공하지만, 제 생각에는 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 등 모든 서버 측 웹 개발 코드에 해당합니다. 일반적으로 클라이언트 측 검증은 악용될 수 있으므로 서버 측에서도 반드시 검증해야 합니다.

특히 “Custom Validations”(사용자 정의 검증) 섹션을 읽으시는 것을 권장합니다:

도움이 되셨길 바랍니다.

2개의 좋아요