[Ruby on Rails]보안 기초

jinsu6688·2021년 3월 4일
0

rails

목록 보기
2/2
post-thumbnail

보안에 기초가 되는 점을 Rails관점에서 공부하여보았습니다.
번역하고 공부한 사이트는 아래의 사이트 입니다(일본어)

레일즈 가이드

1.XSS

2. CSRF : 사이트 간 요청 위조 (Cross-site request forgery)

✏️ CSRF 개요

✏️ 이 공격방법은 유저에 따라 인증을 종료했다고 생각되어져 Web 어플리케이션의 페이지에 악의가 있는 코드나 링크를 속에 넣는 것을 말한다.

이 Web어플리케이션에 섹션이 타임아웃해 있지 않으면 공격자는 본래인증되어져있지 않을 것이다라는 Command가 실행가능해져버립니다.

Rails의 특이한점은 많은 Rails 어플리케이션이 cookie베이스의 섹션을 사용하고 있는 것이다. 이 때 센션 ID를 cookie에 보존하여 서버쪽에 섹션해쉬를 갖게 하는 방법 또는 모든 섹션 해쉬를 클라이언트(브라우저)쪽에 갖도록 합니다. 어느쪽이라도 브라우저는 리퀘스트를 보낼 때마다 cookie를 자동적으로 도메인에 송신한다(도메인에 이용가능한 cookie가 있을 경우). 여기서 문제가 되는 것은 다른 도메인에 소속해있는 사이트에서 리퀘스트가 있던 경우에도 브라우저가 cookie를 송신해버리는 점입니다.

아래에 예시로 확인하여 보자

Bob는 게시판을 브라우저에서 바라보고 있었던 이라고 하는 해커에 의한
글을 보게 된다. 그 글에는 속임수가 있는 HTML image요소가 포함되어 있다. 그 요소가 실제로 참조하고 있는 것은 영상파일이 아닌 Bob의 프로젝트 관리 어플리케이션을 목표로 한 코맨드 <img src="http://www.webapp.com/project/1/destroy">이다.

Bob는 몇분동안 로그아웃하고 있지 않기 때문에 www.webapp.com에 대하여 Bob 의 섹션은 아직 기한 만료로 되어 있지 않다.

해커에 의한 글이 브라우저에 표시되어지면 브라우저는 image태그를 발견한다. 그렇게 브라우저는 www.webapp.com에서 의심스러운 영상을 읽기시작하려고 한다. 이전에 설명했던 것처럼 이 때의 유현한 섹션 id를 포함한 cookie도 함께 송신 되어진다.

www.webapp.com의 Web 어플리케이션은 리퀘스트에 대응하여 섹션 해쉬에 포함되어있는 유저 정보가 유효가 되었다는 것을 인정하고 지시에 따라서 ID 1의 프로젝트를 삭제한다. 브라우저는 결과페이지를 표시하여 무언가의 문제가 일어났다는 것을 표시한다. 영상은 표시되어지지 않는다.

Bob는 공격에 눈치채지 못하고 있습니다. 그러나 몇일 후에는 프로젝트 No.1가 삭제되어졌다는 것을 눈치 챕니다.

여기서 중요한 것은 속임수가 있는 영상이나 링크를 두는 장소는 Web 어플리케이션의 도메인에 한정되어 있지 않다는 것입니다. 포럼, 블보그, email 등 어디에도 놀 수 있다.

CSRF는 CVE(Common Vulnerabilities and Exposures)에 보고 되어진 것은 거의 없지만(2006년에도 0.1% 이하) 그래도 Grossman가 말하는 「잘자고 있는 거인」이고 위험한 것에는 틀림없다. 저자는 다른 보안 전문가에 의해 보안 간련의 실적에 등록하고 있는것은 거의 없지만 CSRF는 매우 중요한 보안 문제인 것임을 틀림없다고 강하게 인식하고 있다고 말하고 싶습니다.

🎇 CSRF에의 대응책

  1. 첫번째로는 W3C가 요구하고 있는 것 처럼 GET과 POST를 적절히 사용합시다!
  2. 두번째로는 GET이외의 리퀘스트에 보안토큰을 추가하는 것으로 Web 어플리케이션을 CSRF에을 막는 것이 가능합니다.

HTTP 프로토콜은 2개의 기본적인 리퀘스트인 GET과 POST(DELETE, PUT, PATCH는 POST와 똑같이 사용하여야 한다)를 제공하고 있습니다. World Wide Web Consortium(W3C)는 HTTP의 GET이나 POST를 선택할 때에 체크리스트를 제공하고 있습니다.

이하의 경우 GET을 사용하자

  • 주고받음이 기본적인 조회(문의)인 경우(쿼리, 데이터를 읽는 동작, 검색과 같은 안전한 동작)

이하의 경우는 POST를 사용하자

  • 주고 받음이 기본적으로 명령인 경우
  • 주고 받음에 의해 유저에게 이해할 수 있는 형태의 리소스의 상태가 변하는 경우(서비스에 신청) 등
  • 주고 받음에 의해 일어나는 결과를 유저가 파학 가능한 경우

Web 어플리케이션이 RESTful이라면 PATCH, PUT, DELETE등의 HTTP메소드가 사요오디어지고 있을 것입니다. 그러나 일부의 브라우저는 이런 메소드를 서포트하고 있지 않습니다. 확실히 서프트 되어지고 있는 것은 GET과 POST만이다. Rails에서는 _method라고 하는 숨겨져있는 필드를 사용하여 이런 HTTP 메소드를 서포트 하고 있습니다.

Post 리퀘스트도 자동적으로 전송되어지는 경우가 있을 수 도 있습니다. 브라우저는 스테이터스 Bar에 www.harmless.com이라고 하는 Web 사이트에 링크가 표시되어저 있다고 합시다. 이 링크에 속임수가 있고 POST 리퀘스트를 몰래 송신하는 새로운 폼을 동적으로 작성하도록 되어 있다고 합시다.

<a href="http://www.harmless.com/" onclick="
  var f = document.createElement('form');
  f.style.display = 'none';
  this.parentNode.appendChild(f);
  f.method = 'POST';
  f.action = 'http://www.example.com/account/destroy';
  f.submit();
  return false;">To the harmless survey</a>

또는 공격자가 이 코드를 영상에 onmouseover 이벤트 핸들러에 넣어났다고 생각해봅시다.

<img src="http://www.harmless.com/img" width="400" height="400" onmouseover="..." />

script태그를 사용하여 JSON이나 JavaScript의 응답을 따라 특정의 URL에 크로스사이드 리퀘스트를 작성하는 등 공격방법을 다종다양하다. 이 리스폰스(응답)은 공격자가 실행방법을 찾아낸 코드이고 기밀 데이터를 추출해낼수 있는 가능성이 있습니다. 이런 데이터 유출을 방지하기 위해서는 스로스 사이트의 <script> 태그를 무효로 합니다. 단지 Ajax 리퀘스트는 브라우저의 동일-출처 정책에 따라서 동작하기 때문에(XmlHttpRequest를 개시 가능한 것은 자기의 자기의 사이트 뿐이다)
JavaScript 응답을 반환하는 것을 안전하게 허가 하는 것이 가능합니다.

Note: <script> 태그의 origin이 같은 사이트가 악의가 있는 사이트인지는 구별 할 방법이 없습니다. 이 때문에 <script> 태그는, 예를들어 실제로는 자신의 사이트에서 동일한 origin 스크립트라고 해도 전면적으로 차단해야합니다. 이런 경우 <script>를 대상으로 JavaScript를 사용하는 작업에 대해서는 명시 적으로 CSRF 보호를 건너 뛰십시오.

이런 다양한 종류의 리퀘스트를 모두 방지하기 위해서는 필수 보안트큰을 보입합니다. 이 토큰은 자신의 사이트 만이 알고 있어 다른 사이트는 모릅니다. 리퀘스트에는 이런 보안 토큰을 포함하고, 서버 쪽에 이것을 검증합니다. 이하의 1줄 코드는 어플리케이션의 콘트롤러에 추가하는 것이고 Rails에 신규작성한 어플리케이션에는 이 코드가 디폴트로 포함되어 있습니다.

protect_from_forgery with: :exception

이 코드가 있으면 Rails에서 생성된 모든 폼과 Ajax 리퀘스트에 보안 토큰이 자동적으로 포함되어 집니다. 보안토큰이 매치 하지 않은 경우네느 예외가 던져 집니다.

Rails에 Defalt로 포함된 unobtrusive scripting adapter이 추가 하는 X-CSRF-Token이라는 헤더에는 GET 이외의 모든 Ajax 호출에서 보안 토큰이 포함됩니다. 이 헤더가 없으면 Rails는 GET 이외의 Ajax 요청을 받지 못하게 됩니다. 아약스 호출에 다른 라이브러리를 사용하는 경우 해당 라이브러리의 아약스 호출의 디폴트의 헤더에 보안토큰을 추가할 필요가 있습니다. 이 토큰을 얻으려면 어플리케이션의 뷰에 <%= csrf_meta_tags %>에서 출력되는 태그를 봐주세요.

일정한 cookie에 유저 정보를 보존하는 것은 자주 있는 일입니다. 이런 경우 cookie는 소거 되지 않는다는 것 이전의 보호기관의 밖에는 CSRF에서의 보호를 받지 못한 다는 것에 주의하여 주세요. 무언가에 이유로 이런 정보를 섹션이외의 cookie 스토어에 보관(보존)하고 있는 경우에는 필요한 조작을 개발자 자신이 행하지 않으면 안됩니다.

rescue_from ActionController::InvalidAuthenticityToken do |exception|
  sign_out_user # 유저의 cookie를 삭제하는 메소드의 예
end

위의 메소드는 ApplicationController에 두는 것이 가능합니다. 그렇게 비 GEET 리퀘스트에는 CSRF 토큰이 없는 경우나 토큰이 무효한 경우에 이 메소드가 불려집니다.

신경써야할 점은 크로스 사이드 스크립팅(XSS) 취약점은 모든 CSRF보호를 우회해버리고 만다는 점입니다. XSS 취약성이 존재하면 공격자는 Web 페이지의 모든 요소에 접근할 수 있게 되어집니다. 때문에 폼에서 CSRF 보안 토큰을 읽어들여서 폼을 직접전송하는것이 가능해져버리고 맙니다.
뒤에 나오는 글에는 XSS 상세도 읽어 봐 주세요

3, SQL injection

4, Open redirect

5, command injection

6, Directory Traversal

7. authentication과 authorization 의 차이

authentication과 authorization 의 차이를 명확히 이해하는 게 좋습니다.

그외 기초적인 지식 +

서버 접근권한 제한
로그인 비밀번호 암호화 방식

profile
Rails로 첫 커리어를 시작하였습니다! ruby, js에 관심이 많습니다.

관심 있을 만한 포스트

0개의 댓글