프론트엔드 개발자가 신경 써야 할 보안

보안 기능 측정

구글 lighthouse를 사용해서 성능, SEO, 접근성 점수를 측정할 수 있는 것처럼 비슷하게 보안 기능을 측정할 수 있는 사이트가 있다.

 

Security Headers는 response header를 기반으로 보안 점수를 제공해 준다.

 

구글

 

네이버

적절한 response 헤더를 반환하도록 구성하는 것이 프론트엔드 책임이다.

내가 만드는 웹어플리케이션의 클라우드 호스팅 제공 업체가 어떤 response 헤더를 사용하는지 이에 대한 작동하는 방식을 배우고 적절하게 구성하면 된다.

 

컨텐츠 보안 정책(CSP) 사용

컨텐츠 보안 정책 (CSP, Content-Security-Policy)은 front-end 애플리케이션의 안전을 위해 시작할 수 있는 첫 단계라고 할 수 있다. CSP는 Mozila 재단에서 만든 표준인데, XSS (Cross-Site Scripting) 및 클릭 재킹 (clickjacking)을 포함하여 특정 유형의 코드 삽입 공격을 탐지하고 막아준다.

 

강력한 CSP는 잠재적으로 유해한 인라인 코드 실행을 비활성화해주고 외부 리소스가 로드되는 도메인을 제한하는 것이 가능하다. Content-Security-Policy 헤더를 세미콜론으로 구분지어서 사용할 수 있다. 아래는 웹 사이트가 외부 리소스에 액세스 할 필요가 없는 경우 헤더 설정이다.

Content-Security-Policy: default-src 'none'; script-src 'self';
img-src 'self'; style-src 'self'; connect-src 'self';

여기서는 script-src, img-src, style-src 및 connect-src 지시어를 self로 설정했다.

 

그러니까 이렇게 하게 되면 document를 로드할 때 css, script, image 같은 리소스들은 HTML 문서가 제공되는 곳과 불러오는 곳이 동일해야 한다는 것이다. Defualt CSP 지침은 default-src로 설정하면 된다. 기본 동작이 URL에 대한 연결을 제한해야 하기 때문에 none으로 설정했다.

 

그러니까 보통 콘텐츠 보안정책은 동일 출처 원칙이 기본이긴 하다. 예를 들어 https://csp.com은 https://csp.com의 데이터에만 액세스 할 수 있는 권한이 있다. https://psc.com 에는 액세스 권한이 없다.

 

그런데 웹어플리케이션을 만들다 보면 대부분 다 알겠지만, 요즘 어플리케이션을 만들 때에는 다른 곳에서 자원을 가져다 쓰기 마련이다. Google developer 콘솔에서 API를 가져오든, AWS S3에서 가져오든 말이다. 하지만 나중에 이런 곳의 도메인을 허용하도록 설정하더라도 일단 가장 엄격하게 설정해 놓는 것이 필요하다.

 

XSS 보호 모드 사용

사용자 입력에서 악성 코드가 입력되는 것을 감지한다면 "X-XSS-Protection": "1; mode = block"헤더를 사용하면 된다. 이는 브라우저가 response를 차단하도록 만들 수 있다.

 

물론 요즘 최신 브라우저들은 XSS 보호 모드가 기본으로 되어있긴 하다. 하지만 CSP 헤더를 지원하지 않는 브라우저들(IE라던지...)을 위해서 X-XSS-Protection 헤더를 포함해주는 것이 좋다.

 

클릭재킹 공격을 방지하기 위해 iframe Embed 막기

클릭재킹 공격을 막기 위해서 iframe 임베딩을 막는 것이 필요하다. 클릭재킹 공격은 요즘 뉴스에도 나와서 핫한 공격이다. 쉽게 말하면 다른 사이트 인척 속이는 것이다. 국민은행 피싱사이트가 예이다.

출처: 프론트엔드 개발자를 위한 10가지 보안 관련 팁 / Yohan Kim

 

이것 역시 헤더에 X-Frame-option을 줌으로써 해결할 수 있다.

"X-Frame-Options": "DENY"

 

referrer 값 노출시키지 않기

웹 사이트에서 다른 곳으로 이동하는 링크를 클릭하면, 가고자 하는 웹 사이트는 웹 사이트에서 마지막 위치의 URL을 referrer 헤더로 받는다. 그런데 이 URL에는 세션 토큰이나 사용자 ID와 같은 민감한 데이터가 포함될 수 도 있기 때문에 노출하면 안 된다.

 

이걸 막기 위해선 Referrer-Policy헤더를 no-referrer로 설정한다.

"Referrer-Policy": "no-referrer"

이렇게 만드는 것이 좋긴 한데, 세상 일이 그렇든 방문 유입경로나 코드 logic에 따라 referrer를 갖고 있어야 할 때도 있다.
Scott Helme article에서 referrer 헤더를 어떻게 설정해야 하는지 알려준다.

 

유저로부터 입력값을 받는 곳에 innerHTML 사용하지 말기

크로스사이트 스크립팅(XSS 공격)은 다양한 곳에서 사용되지만 그래도 가장 많이 사용되는 곳은 바로 “innerHTML”이다.

 

innerHTML을 유저로부터 필터링되지 않은 채로 설정하면 안 된다. 사용자가 직접 조작할 수 있는 값(입력 필드의 텍스트, URL의 파라미터 또는 로컬 스토리지 항목)은 먼저 검사해야 한다. innerHTML보다 textContent을 쓰는 것이 더 바람직하다. 만약 게시판처럼 긴 글을 작성할 수 있게 하려면 좋은 라이브러리를 사용해야 한다.

 

 

 

 

 

 

출처

- 프론트엔드 개발자를 위한 10가지 보안 관련 팁 / Yohan Kim

- 10 security tips for frontend developers / gitconnected