# Discourse는 사용자 에이전트를 통한 SQL 주입을 어떻게 방지하나요?
**URL:** https://meta.discourse.org/t/how-does-discourse-guard-against-sql-injections-via-the-user-agent/177251
**Category:** Feature
**Created:** [1월 26, 2021, 12:43오전 UTC](https://meta.discourse.org/t/how-does-discourse-guard-against-sql-injections-via-the-user-agent/177251 "2021-01-26T00:43:01Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@mbaker341997](https://meta.discourse.org/u/mbaker341997)
#### Post date: [1월 26, 2021, 12:43오전 UTC](https://meta.discourse.org/t/how-does-discourse-guard-against-sql-injections-via-the-user-agent/177251/1 "2021-01-26T00:43:01Z")
Discourse가 몇몇 테이블에 사용자 에이전트를 저장한다는 것을 알게 되었습니다. 예를 들어 [web\_crawler\_requests](https://github.com/discourse/discourse/blob/master/app/models/web_crawler_request.rb#L86) 테이블이 있습니다. 공격자들은 [Sleepy User Agent](https://blog.cloudflare.com/the-sleepy-user-agent/) 공격과 같이 악성 코드를 주입하기 위해 “user-agent” 필드를 악용하는 것으로 알려져 있습니다. Discourse가 이러한 유형의 공격에 대비하여 어떤 조치를 취하고 있는지 궁금합니다.
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [1월 26, 2021, 1:23오전 UTC](https://meta.discourse.org/t/how-does-discourse-guard-against-sql-injections-via-the-user-agent/177251/2 "2021-01-26T01:23:52Z")
Discourse는 Rails 앱이므로, 프로젝트에서 프레임워크의 보안 기능을 활용합니다:
> **[7.2. SQL Injection - Securing Rails Applications — Ruby on Rails Guides](https://guides.rubyonrails.org/security.html#sql-injection)**
>
> Web application frameworks are made to help developers build web applications. Some of them also help you with securing the web application. In fact one framework is not more secure than another: If you use it correctly, you will be able to build...
---
### Author:  [@neounix](https://meta.discourse.org/u/neounix)
#### Post date: [1월 26, 2021, 9:32오전 UTC](https://meta.discourse.org/t/how-does-discourse-guard-against-sql-injections-via-the-user-agent/177251/3 "2021-01-26T09:32:35Z")
> [@mbaker341997](#):
>
> 이런 유형의 공격을 방지하기 위해 Discourse에 어떤 조치가 마련되어 있는지 궁금합니다.
@mbaker341997 님, 안녕하세요.
Rails 보안 가이드는 좋은 개요를 제공하지만, 제 생각에는 Rails 보안 가이드가 SQL 인젝션 공격을 완화하기 위해 많은 사람들이 (논쟁의 여지가 있지만) 가장 중요한 제어 수칙으로 간주하는 내용을 충분히 다루지 못하고 있습니다.
"SQL 인젝션"에 대한 첫 번째 방어선은 강력한 입력 데이터 검증입니다.
위에서 언급한 Rails 보안 가이드에서 직접적인 예를 들어 보겠습니다.
Rails 보안 가이드는 다음과 같은 간단한 예를 보여줍니다:
```plaintext
Project.find(:all, :conditions => "name = '#{params[:name]}'")
```
이는 입력 파라미터에 다음과 같이 주입되어 악용될 수 있습니다:
```plaintext
’ OR 1=1’
```
그러나 모델에 강력한 검증을 구현하면 이를 방지할 수 있습니다. 예를 들어:
```plaintext
before_validation :filter_name_param
private
def filter_name_param
### 특수 문자 및 기타 "위험한
### 코드"가 데이터베이스 근처에 접근하지 않도록 보장하기 위한 사용자 정의 파라미터 필터 코드를 여기에 작성하세요.
end
```
Rails에는 데이터베이스에 입력되기 훨씬 전에 입력 파라미터가 검증되도록 모델을 포함할 수 있는(그리고 포함해야 하는) “기본 제공” 검증 기능이 많이 있습니다.
Rails 검증에 대한 더 자세한 내용은 아래 링크에서 확인하실 수 있습니다:
> **[Active Record Validations — Ruby on Rails Guides](https://guides.rubyonrails.org/active_record_validations.html)**
>
> This guide teaches you how to validate Active Record objects before saving them to the database using Active Record's validations feature.After reading this guide, you will know: How to use the built-in Active Record validations and options. How to...
많은 사람들이 SQL 인젝션 공격에 대한 첫 번째 방어선이 입력 데이터 검증이라는 점을 잊곤 합니다. 이는 Ruby, PHP, Python 등 모든 서버 측 웹 개발 코드에 해당합니다. 일반적으로 클라이언트 측 검증은 악용될 수 있으므로 서버 측에서도 반드시 검증해야 합니다.
특히 “Custom Validations”(사용자 정의 검증) 섹션을 읽으시는 것을 권장합니다:
> **[7. Performing Custom Validations - Active Record Validations — Ruby on Rails...](https://guides.rubyonrails.org/active_record_validations.html#performing-custom-validations)**
>
> Here's an example of a very simple validation: | This guide teaches you how to validate Active Record objects before saving them to the database using Active Record's validations feature.After reading this guide, you will know: How to use the...
도움이 되셨길 바랍니다.