Security considerations for browser extensions

hahwul

Dec 21, 2020

브라우저 확장 기능의 보안 관련하여 테스트할게 필요하여 제가 알던 내용에 조금 더 리서치하여 글로 작성해 봅니다. 우선 브라우저 확장 기능은 웹 브라우저에 추가되는 작은 단위의 앱으로 Chrome / Safari / Firefox 등등 다수 브라우저에서 웹 브라우징, 광고차단, 각종 테스트 기능 등 여러 사용자들에게 서비스되고 있습니다. 이는 앱 생태계와 동일하게 개인/기업 등등의 개발자가 규격에 따라 만들고 스토어에 업로드 후 승인 절차를 통해 등록되는 것으로 알고 있습니다.

다만 브라우저 확장 기능을 통해 악성코드가 많이 유포되고 있다는건 많은 사람들이 알고 있는 내용인데요, 오늘은 조금 다른 관점으로 이야기를 풀려고 합니다. 브라우저 확장 기능의 보안성을 테스트하기 위한 엔지니어 그리고 브라우저 확장 기능을 만들 때 고려해야할 사항들, 즉 개발자의 관점에서의 이야기입니다.

Point of testing, develop

우선 대다수 브라우저의 큰 구조적 부분은 비슷합니다. 물론 자세한 동작 방식은 Chrome / Safari / Firefox 모두 다 다르겠지만, 큰 구조는 아래와 같이 3가지로 나뉩니다.

Content Script / Extension Core / Native Binary

여기서 Extension Core와 Native Binary는 브라우저 확장기능의 코어적인 부분, 브라우저를 개발하는 입장에서의 포인트이고, 우리는 취약점 점검을 위한, 또는 개발을 위한 입장이기 때문에 Content Script 영역에서의 보안관점이 가장 중요합니다. (보통 말하는 확장 기능 개발은 Content Script 영역에서 이루어집니다. 만들어보면 별거 없어요. / 위 그림은 크롬 기준의 그림이긴한데, 다른 브자라우저도 비슷합니다)

Policy

브라우저 확장 기능은 사용자의 브라우저에서 동작하기 때문에 만약에 취약점이 발견됬을 경우 리스크가 상당합니다. 이미 설치된 확장 기능은 어느정도 신뢰받는 위치에 있기 때문에 사용자/시스템적으로 많은 권한을 가지게될 수도 있습니다. 그래서 확장 기능을 만들 때 권한과 정책적인 측면에서 세심한 설정이 필요합니다.

Extension Permissions and Access Control

우선 각 브라우저사 별로 확장 기능들은 퍼미션을 가지게 됩니다. 이 퍼미션은 해당 확장 기능이 수행할 수 있는 권한의 범위를 의미하며, 너무 과도하지 않은 권한을 할당하여 혹여나 문제가 발생하여도 추가적인 피해를 예방할 수 있도록 설정이 필요합니다.

보통 확장기능이 어떤 기능을 수행할 수 있는지 명시합니다. (예를들면, 웹 요청을 전송할 수 있음, 현재 사용자 페이지를 제어할 수 있음 등)

개발자 계정 보호

이건 확장 기능 자체의 정책적인 측면은 아니지만 대다수 권장되고 있는 방법입니다. 우선 스토어에 등록된 확장 기능은 개발자 계정을 기준으로 서명되어 사용되는데, 개발자 계정이 탈취됬을 때 리스크는 엄청나게 높습니다. 그래서 확장 기능을 등록하고 관리하는 계정은 2FA 인증 등 조금 더 높은 보안 요구조건을 가집니다. 되도록이면 적용하는게 좋을 것 같긴합니다. (따지고 보면 개인 계정도 2FA또는 OTP를 쓰는 상태인데, 중요한 권한을 가진 계정은 당연한 부분이겠죠.)

Limit Manifest fields 제한하기

이것도 브라우저들이 비슷하게 사용하는 정책인데요, 확장 기능이 호출할 수 있는, 구동할 수 있는 도메인 등의 리스트를 지정할 수 있습니다. 제가 회사에서 확장 기능을 만들 때 잘 인지하지 않고 있다가 고생한 부분이기도 하네요.. (옛날에 개인적으로 만들었을땐 없었는데 😭)

아무튼 브라우저 확장 기능에서 사용할 수 있는 리소스를 제한할 수 있습니다. Chrome 기준으로 예시를 들어보면 아래와 같습니다. Manifest에 web_accessible_resources 부분으로 명시해주어 제한할 수 있습니다.

{
  "web_accessible_resources": [
    "images/my-image.png"
  ]
}

Secure Coding

이제 만드는 과정에서 고려해야할 부분들에 대해 이야기하겠습니다. 당연히 그 뒤에 있는 Threat Model , Vulnerability 부분과도 밀접하며 이 부분도 굉장히 중요하기 때문에 적절한 구현이 필요할거라 생각되네요. 다만 이 영역은 일반적인 웹 보안과 거의 동일합니다.

전구간 HTTPS 사용

우선 브라우저 확장기능 또한 웹 기반으로 사용자의 브라우저의 DOM 위에 동작하기 때문에 API, Resource 등의 요청으로 HTTP 포맷을 사용하는 경우가 많습니다. (물론 간혹 Raw 통신하는 케이스도 있었어요. 분석하는 사람 입장에선 짜증…)

아무튼 https 사용은 거의 기본적인 부분이니 API, Resource 등 외부 서버와의 통신 시 무조건 https로 처리될 수 있도록 개발단에서 고려가 필요합니다. (단순 redirect를 이용한 http => https도 썩 좋은 방식은 아니에요. 어쩄던 네트워크 트래픽상에서 평문 통신이 일어나니깐요)

CSP

브라우저 확장 기능도 결국 웹 기반이기 때문에 CSP를 설정할 수 있습니다. CSP에 대한 내용과 우회 방법은 예전에 쓴 글에 있으니 참고하시고, 적용 방법에 대해서 가볍게 작성해봅니다.

Manifest에서 content_security_policy 지시자를 통해 일반 웹 페이지와 동일하게 CSP를 설정할 수 있습니다.

{
  "name": "Very Secure Extension",
  "version": "1.0",
  "description": "Example of a Secure Extension",
  "content_security_policy": "default-src 'self'"
  "manifest_version": 2
}

다만 유의해야할 점은 브라우저 확장기능의 주소는 확장 기능 관련 프로토콜+고유주소라서 일반 웹 도메인과는 약간 다른 형태의 URI를 가집니다. 이점 참고하셔서 적용하시는 게 좋을 것 같습니다.

XSS

네 당연히 웹 기반 동작이기 때문에 여러 웹 취약점에 영향을 받겠지만, 그 중 가장 발견 빈도가 높고 리스크 있다고 생각되는건 XSS 입니다. 이 부분에서 대해서는 조금 더 신경써서 대응이 필요할 것 같습니다.

만약에 Stored XSS 같이 영구/반영구 적으로 확장 기능에 악의적인 스크립트를 남길 수 있다면, UXSS처럼 특정 도메인이 아닌 광범위한 도메인과 페이지에 영향을 줄 수도 있습니다. (물론 이를 제한하기 위해 위 Policy 부분에서 정책을 거는겁니다)

XSS 관련해서 구글링해보면 많이 나올테니 참고하시고, 개인적으로 위키? 작성중인데 혹시라도 글을 보실 떄 완료 되었다면 요거 참고 하셔도 될 것 같습니다. https://www.hahwul.com/cullinan/xss/

대다수의 웹 취약점

XSS 이외에도 대다수의 웹 취약점과 동일하게 영향받기 떄문에 일반적인 웹 서비스 개발 시 고려해야할 부분들은 같이 고려해서 개발이 필요합니다.

⚡️ Threat Model and Attack vector

자 테스팅 입장에서도 간단히 써봅시다. 물론 위에서 구구절절 이야기드렸듯이 웹 서비스에 대한 테스팅과 거의 동일합니다. 다만 조금 더 고민하고 살펴봐야할 부분들은 따로 작성해둘테니 참고하시길 바래요.

XSS

위에서 이야기드렸듯이 이 취약점이 있는 경우 일반적인 웹에서의 XSS 보다는 높은 리스크를 가집니다. 이 부분에 대해서는 조금 더 심도있게 테스트가 필요하며, 한가지 팁을 드리자면 많은 확장 기능들이 Local Storage를 통한 데이터 관리를 하고있고(Stored XSS 대응에서 잘 놓치는 부분이죠), 프로토콜:고유주소 기반으로 Reflected XSS 또한 가능합니다. 고유주소는 마치 난수처럼 보이지만 고정값이니 크게 놀라지 않으셔도 됩니다.

Replacing Native APIs

요건 구글보안팀에서 이야기하는 부분 중 하나인데요, 확장 기능 내부적으로 쓰이는 API를 바꿔서 동작시킬 수 있는지에 대한 부분입니다. 공격자가 악성 웹 페이지를 만들고, 확장 기능의 DOM 영역을 일부 제어할 수 있어질 때 문제가 발생합니다.(확장 기능의 페이지의 DOM을 활용하는 경우 등)

다만 이러한 부분들은 브라우저에서 Object 신뢰부분에서 어느정도 제한하고 있기는 하나, 케바케라는 말이 있어서 개발단에서도 고려가 필요한 부분이라고 생각이 드네요.

Javascript Capability Leaks, Prototype Pollution

보통 Cross-origin javascript capability leakage로 부르는 부분이며,아래 문서 참고하시면 약간이나마 도움될 것 같습니다.

그리고 Javascript / HTML / CSS로 동작하기 때문에 당연히 Prototype Pollution에 영향을 받습니다. 이 부분도 테스팅이 필요합니다. https://www.hahwul.com/2019/05/01/jqeury-prototype-pollution-cve-2019-11358/

Mixed Contents(non-https)

네 위에서도 이야기헀듯이 https의 사용은 중요합니다.

API 서버 보안

마지막으로 확장 기능에 따라 API 서버와의 접점의 가능성이 있는데, 이런 경우 당연히 API 서버 또한 적절한 보안 테스팅과 대응이 되어있어야 합니다. API 서버 자체에선 리스크가 적거나 없는 문제라도 확장 기능의 특성(사용자의 브라우징에 개입하는)과 결합됬을 떈 문제가 될 수 있는 부분이 있으니 이러한 부분도 고민하고 고쳐나가는게 좋습니다.

🙏🏼 Conclusion

막상 정리하다 보니 제가 놓쳤던 부분도 있었습니다. 전반적으론 웹 서비스 자체와 거의 동일하지만, 나름의 특색이 있으니 혹시나 개발이던 보안 테스팅이던 관련된 업무를 하실 때 조금이나마 도움 됬으면 하는 바램입니다.

References

#security