추가 정보

크로스 사이트 스크립팅 보호하기

레일스 2.0에서 application.rb 파일은 다음과 같이 생겼다:

1. class ApplicationController < ActionController::Base
     helper :all
   
     protect_from_forgery
   end

여기서 호출한 protect_from_forgery 메소드에 대해 알아보자.

크로스 사이트 스크립팅(Cross Site Scripting)이라는 기술에 대해 들어본 적이 있는가? 이것은 오늘날 웹상의 대부분의 사이트에서 손쉽게 찾아볼 수 있는 보안 취약점을 이용한 기술 이름이다. 이 방법을 이용하면 (할일 없고 사회성이라고는 전혀 없는 청소년들과 같은) 나쁜 사람들이 웹페이지의 내용을 바꾸거나 피싱 공격을 하거나 자바스크립트를 이용해서 브라우저를 조종할 수가 있게 된다. 대부분의 경우 사용자는 이러한 자각 없이 명령을 실행하게 된다. 위의 예들 중 마지막 유형을 크로스 사이트 요청 위조(cross-site request forgery)라고 부른다.

크로스 사이트 요청 위조는 정상적인 사용자들이 자신이 일련의 명령들을 실행시키고 있다는 사실을 알지도 못한 채 당하게 되는 그런 종류의 공격이다. 또한 Ajax를 점차 더 많이 사용하면서 점점 더 악화되고 있는 실정이다.

이 메소드는 웹애플리케이션이 받는 모든 폼은 다른 사이트에서 온 것이 아니라 애플리케이션 자체에서 온 것이라는 것을 확인하는 데에 사용된다. 레일스에서 생성한 모든 폼과 Ajax 요청에 세션에 기반해서 토큰을 만듦으로써 그렇게 한다. 그리고는 컨트롤러에서 그 토큰의 신뢰성을 검증하는 것이다.

GET 요청은 보호되지 않는데, 이는 데이터를 가져오는 데에만 사용하고 내용을 변경하거나 데이터베이스에 새로 저장하지 않으면 문제가 되지 않는다.

CSRF(Cross-Site Request Forgery)에 대해 더 알고 싶으면 아래에 있는 주소를 참고하기 바란다.

• http://www.nomedojogo.com/2008/01/14/como-um-garoto-chamado-samy-pode-derrubar-seu-site/isc.sans.org/diary.html?storyid=1750

• http://www.nomedojogo.com/2008/01/14/como-um-garoto-chamado-samy-pode-derrubar-seu-site/isc.sans.org/diary.html?storyid=1750

하지만 이 방법이 모든 문제를 해결할 수 있는 최종적 해결책은 될 수 없다는 점을 꼭 인지하고 있어야 한다.

Used method_missing, then don't leave loose ends

Due to Ruby's dynamic nature, the method respond_to? is crucial. How many times have you checked if a method exists in the object ? Or how often have you checked if the object is what we are expecting (is_a?)?

However there's something really important that many people forget. Look at this class's usage of the method method_missing:

루비의 동적인 특성 때문에 respond_to? 메소드는 매우 중요하다. 해당 객체 안에 메소드가 실제로 존재하는지 찾아본 적이 몇번이었던가? 혹은 이 객체가 우리가 기대하던 것이 맞는지 검사했던 적은(is_a?)?

많은 사람들이 잊곤 하는 중요한 것이 있다. 아래 클래스가 method_missing 메소드를 사용하는 것을 살펴보자:

1. class Dog
     def method_missing(method, *args, &block)
       if method.to_s =~ /^bark/
         puts "woofwoof!"
       else
         super
       end
     end
   end
   
   rex = Dog.new
   rex.bark #=> woofwof!
   rex.bark! #=> woofwoof!
   rex.bark_and_run #=> woofwoof!

method_missing에 대해서는 이미 잘 알고 있으리라 생각한다 (그렇지 않은가?). 위의 예에서는 Dog라는 클래스에서 bark, bark!, bark_and_run이라는 존재하지 않는 메소드를 호출하고 있다. 그러면 method_missing 메소드가 호출되고, 정규식을 이용해서 메소드 이름이 bark로 시작되면 항상 "woofwoof!"를 출력하도록 했다.

하지만 여기서 respond_to? 메소드를 사용하면 어떻게 될까?:

1. rex.respond_to? :bark #=> false
   rex.bark #=> woofwoof!

메소드가 실제로 존재하는 것이 아니므로 당연히 메소드 false를 반환한다. 그렇다면 직접 지정한 규칙까지 포함하도록 respond_to? 메소드를 고치는 것은 이제 나의 임무가 된 것이다. 클래스를 이렇게 변경하면 된다:

1. class Dog
     METHOD_BARK = /^bark/
   
     def respond_to?(method)
       return true if method.to_s =~ METHOD_BARK
       super
     end
   
     def method_missing(method, *args, &block)
       if method.to_s =~ METHOD_BARK
         puts "woofwoof!"
       else
         super
       end
     end
   end
   
   rex = Dog.new
   rex.respond_to?(:bark) #=> true
   rex.bark #=> woofwoof!

이제 좀 말이 되는군! 이것은 종종 발견할 수 있는 실수이다(심지어 레일스 코드베이스 자체에도 간간이 들어 있다). 가령 respond_to? 메소드를 이용해 find_by_name 같은 메소드가 있는지 확인하려고 하는 것이다.

루비는 굉장한 데다 고도로 유연한 언어이지만, 조심하지 않으면 이런 일이 벌어질 수도 있는 것이다.

물론 레일스 2.1에서는 이 문제가 해결되었고, respond_to? 를 이용해서 find_by_something과 같은 메소드의 존재를 확인하는 것이 가능해졌다.

PostgreSQL

레일스 2.0에서는 PostgreSQL 아답터가 버전 8.1부터 8.3까지만 지원했었다. 2.1에서는 버전 7.4부터 8.3까지에 대한 지원이 추가되었다.