왜 참여했을까?
현직이지만 사내 개발자들과만 교류하면 고인물이 되기 십상..
우물 안 개구리가 될 생각은 없기에 다른 개발자들과 어울릴 기회를 찾고자 했다.
우아콘이라거나 if(kakao)라거나 DEVIEW 같은 기술 컨퍼런스는 충분히 교류의 기회가 될 수 있다.
우아한 테크 세미나는 온라인으로 진행되었고, 애플리케이션 보안이 주제였다.
해킹을 배우기 위해선?
웹, 시스템, 모바일 등 타겟 시스템에 대한 공부가 필요하다.
보안을 뚫기 위해 cs 지식이 필요한 것은 물론이고, 보안 취약점을 발견하는 것 뿐 아니라 개발자들에 대안을 제시하기 위해 시스템에 대한 지식이 필요하다.
세미나 말미에서 레고 테스트를 했는데, 개발 vs 보안 적성찾기에 대한 테스트였다.
레고 바이럴(?)이라 디스 받기도 했지만 레고를 만드는 걸 좋아하면 개발, 남이 만든 레고를 부수는 걸 좋아하면 보안이 적성이라고..
재미로 보는 얘기지만 그리 따지면 난 개발에 가깝다.
웹해킹 공부용 사이트
https://portswigger.net/web-security
https://webhacking.kr/
https://dreamhack.io/
최근 서비스 개발 트렌드
-
서버 부하를 줄이기 위해 클라이언트에서 처리하는 기능이 증가
- 서버에서 처리해야 할 기능을 클라이언트에서 처리하면서 취약점 발생
-
효율적 개발을 할 수 있게 도움을 주는 Framework 사용
- Framework에서 제공하는 기능에 대한 설정을 부적절하게 하여 취약점 발생
- Framework 자체에서 발생하는 취약점으로 인한 영향도가 매우 커짐
-
On-premise 환경보단 인프라 구성이 쉽고, 서비스 확장성이 좋은 클라우드 환경 이용
- 클라우드 환경 특성으로 인한 공격 유입
보안 취약점 예시
IDOR 취약점
- IDOR(Insecure direct object reference) 취약점은 안전하지 않은 직접 객체 참조로 읽을 수 있고, '부적절한 인가'라고도 표현하는 취약점이다.
- OWASP TOP 10 1위인 Broken Access Control과 연관된 취약점
- 서버에서 수행해야 할 권한 검증 및 접근 제어를 클라이언트에서 수행하는 경우가 잦아지며 많이 발견됨
- 수평적/수직적 권한 상승이 발생하며, 이를 통해 타 사용자의 객체에 접근하여 정보를 유출시키거나, 기존 권한으론 사용이 불가한 기능을 멋대로 이용할 수 있다.
-
수평적 권한상승
- 동일한 권한을 가진 다른 사용자의 객체에 접근할 수 있을 때를 수평적 권한상승이라 함
-
수직적 권한상승
- 본인이 지닌 권한을 넘어서는 기능을 수행할 수 있을 때를 수직적 권한상승이라 함
IDOR 취약점 조치방안
- 클라이언트 사이드에서 검증을 수행할 경우 공격자가 모두 우회할 수 있기에 검증은 반드시 Session 또는 서버에서 발급한 Token을 통해 서버에서 수행해야 함
SSRF 취약점
- SSRF(Server-Side Request Forgery) 취약점은 '서버단에서 요청을 발생시켜 내부시스템에 접근하는 취약점'으로 내부 데이터를 외부로 유출시킬 수
있는 공격방법 - OWASP TOP 10에 새롭게 등재됨
- 서비스에서 URI를 전달받고, 서버에서 해당 URL에 직접 요청해서 데이터를 받아오는 형태의 기능에서 주로 발생(etc. 외부 이미지 불러오기 기능)
- Public Cloud 환경에선 가상서버의 메타데이터를 확인할 수 있는 API가 있어 SSRF를 통해 해당 API를 요청하여 가상서버의 정보를 확인할 수 있음
SSRF 취약점 조치방안
- 접근 가능한 주소를 whitelist 방식으로 필터링 필요
- 반드시 필요한 URI Scheme만을 사용하도록 whitelist 방식으로 필터링 필요
- Localhost, 127.0.0.1 등의 Loopback URI가 들어올 경우 필터링 필요
- Private IP, Link-local address 형태의 URI가 들어올 경우 필터링 필요
- 불필요한 특수문자(@, %0a 등)이 URI에 포함되어 있을 경우 필터링 필요
JWT를 이용한 인증
장/단점: Stateless Token으로 서버가 인증 작업을 수행하지 않는다.
장점: 그로 인해 부하 감소됨
단점: 서버가 인증 토큰에 대한 제어권을 잃어 관리할 방법이 없음
JWT의 단점에 대한 조치방안
- JWT Blacklist를 구현하여 운영하는 것으로 서버에서 Token에 대한 제어를 수행할 수 있도록 구현한다.
- JWT Payload 내 stateful한 token을 추가하여 서버에서 stateful token을 통해 제어를 수행할 수 있도록 구현한다.
- token에 대한 유효성 검증 로직에 서버에 추가되면서 기존 jwt에 비해 서버부하가 조금 증가할 수 있으나 stateful token만을 이용한 방식보단 부하가 적다.
Spring Boot Actuator Misconfiguration
- Spring boot Framework의 Sub-project
- Spring Boot를 이용하여 운영되고 있는 서비스를 모니터링하고 관리하기 위한 기능들을 포함하고 있음
- HTTP 방식과 JMX(Java Management eXtensions)란 Java API를 사용하는 방식이 있으며, 다양한 역할을 지닌
Endpoint들이 존재한다.(ex. health, metrics, prometheus etc...)
＊불필요한 Endpoint를 활성화하여 예상치 못한 Actuator의 기능으로 인해 서비스 기밀성, 무결성, 가용성을 침해당할 수 있음
Actuator Misconfiguration 취약점 예시
-
환경변수로 중요 정보를 저장해 둔 경우
Actuator env endpoint를 사용할 경우, 환경변수에 저장된 중요 정보를 확인할 수 있음 -
중요정보가 메모리에 올라가 있는 경우
Actuator heapdump endpoint를 사용할 경우, 현재 서비스가 점유 중인 heap 메모리 내 존재하는 데이터를 확인할 수 있음
Actuator Misconfiguration 보안 강화 방안
Actuator endpoint는 필요한 것만 enable 한다.
- Actuator는 shutdown endpoint 제외 나머지는 default로 enable 되어 있음
- default 설정은 불필요한 endpoint가 활성화되어 잠재적 위험이 될 수 있음
- default 설정을 따르지 않고, 모든 endpoint들을 disable 상태로 유지해야 함
- 필요한 endpoint만을 enable 해야 함
Actuator endpoint는 필요한 것만 expose 한다.
- JMX는 기본적으로 모든 endpoint가 expose되어 있으며, HTTP는 그와 반대로 health endpoint만이 기본적으로 expose 되어 있음
- 불필요한 endpoint를 expose할 경우 잠재적 위험이 될 수 있음
- JMX 형태로 Actuator 사용이 필요핮 않을 경우, 모든 endpoint가 JMX를 통해 사용 불가하게 설정해야 함
- 사용이 필요한 endpoint를 expose할 땐, Wildcard 문자인 Asterise(*)를 사용하지 않아야 함
Shutdown endpoint는 enable 하지 않는다.
- 시스템을 shutdown 시켜 서비스 가용성을 침해할 수 있다.
- 기본적으로 disable 되며, expose 되지도 않기에 설정을 enable 하지 않도록 주의한다.
서비스 운영 포트와 다른 포트를 사용한다
- Actuator가 다양한 기능을 가진만큼, 공격자들은 웹 사이트를 공격할 때, Actuator 관련 endpoint가 존재하는지 스캐닝한다.
- 서비스 운영 포트와 Actuator 포트를 분리할 경우, 외부에서의 접근을 차단하고 내부에서만 접근하도록 방화벽 설정이 가능하여 외부 공격자로부터 보호받을 수 있다.
Actuator에 접근할 수 있는 IP 주소를 제한한다.
- Actuator의 경우 서비스 운영자, 개발자가 주로 이용하기에 인가된 사용자만이 접근 가능하도록 IP 제어를 수행함으로써 내외부 공격자로부터 보호받을 수 있다.
- WAF, L7 방화벽, IP, (포트를 제한했을 경우) 방화벽 등의 방법으로도 제한할 수 있으며, Actuator 설정으로도 제한이 가능하다.
Actuator 기본 경로를 변경한다.
- Actuator의 경우 기본적으로 /actuator/[endpoint]와 같은 형태로 외부에 노출된다.
- 공격자는 이미 알려진 기본 형태를 이용하여 Actuator endpoint에 대해 스캐닝을 수행한다.
- Actuator 경로를 변경함으로써 공격자의 스캔으로부터 보호받을 수 있다.
- 경로 변경시 유추하기 어려운 문자열의 경로로 설정하는 게 좋다.
Actuator 접근시 권한 검증을 수행한다.
- Actuator는 많은 기능을 갖고 있기에 권한이 있는 인증된 사용자만 다루는 게 보안상 좋다.
- Session 또는 인증 Token을 이용하여 접근 권한이 있는지를 검증하는 로직을 추가하는 게 좋다.
- Spring Security를 사용할 경우 쉽게 적용할 수 있다.
Reference
- 개발자가 꼭 알아야 할 애플리케이션 보안: 입문부터 놓치면 안될 트렌드까지?! | 8월 우아한테크세미나(https://youtu.be/RQv86D0M5YY)
