작성자 : 토스 보안팀
마지막 수정일 : 2025. 01. 09.
안녕하세요. 토스 보안팀입니다.
토스 앱에는 보안을 위한 다양한 해킹 방어 로직들이 적용되어 있습니다. (토스에서 자체 제작한 앱보안솔루션 토스가드 및 토스피싱제로)
앱인토스 서비스 개발 시에도 아래 가이드를 활용하여 더욱 안전한 서비스를 함께 만들어가길 바라는 마음으로 본 문서를 제작했습니다.
1.
앱인토스 서비스를 개발할 때 보안 상 지켜야 하는 기본적인 내용들을 포함했어요.
토스와 서비스 제휴를 개발할 때 아래 사항들을 준수해주세요.
2.
외부 기관의 공식적인 개발 보안 가이드 소스자료 포함했어요.
한국인터넷진흥원, 행정안전부, 금융보안원 등의 개발 보안 가이드와 취약점 점검 목록 및 대응방안 등의 자료의 내용이 포함되어 있어요.
제휴사에서 서비스 취약점 점검 및 보안 검토를 하실때 활용해주세요.
3.
안전한 보안 설계 기준
분석 단계에서는 정보처리시스템의 각 기능들을 안전하게 서비스하기 위해 필요한 보안 항목들을 식별하여, 산출물인 요구사항 정의서에 다음과 같은 설계항목을 정의하여, 설계, 구현, 테스트 해야합니다.
크게 4가지의 기준이 존재합니다.
입력데이터 검증 및 표현 | 보안 기능 | 에러 처리 | 세션 통제 |
1. 입력데이터 검증 및 표현
사용자가 입력하는 데이터에 대한 검증을 철저히 해야합니다. 특히 주민번호와 같은 개인정보를 입력받는다면 더욱 검증을 철저히 진행해야합니다.
2. 보안 기능
인증, 접근통제, 권한관리, 비밀번호 등의 정책 관련 내용입니다.
3. 에러 처리
에러 또는 오류상황을 처리하지 않거나, 불충분하게 처리되어 중요정보가 유출될 수 있습니다. 오류 메시지에 중요정보들이 노출되지 않도록 개발해주셔야 합니다.
4. 세션 통제
세션정보 노출 및 하이재킹과 같은 취약점
4가지 기준과 그와 관련된 설계항목들을 잘 준수하여 설계 및 개발을 진행하는 것을 권고드립니다.
설계 구단계 기준 구현 단계 기준
구현단계 기준과의 관계
위의 설계단계 기준(20개)을 잘 준수하여 개발하면 아래 구현단계(49개 취약점)들을 대비할 수 있습니다.
위 취약점들을 도표로 표시하면 대부분의 취약점들은 설계단계에서 잘 고려하여 로직을 구현하는 것 만으로도 많은 취약점들을 제거할 수 있음을 볼 수 있습니다.
암호화 데이터 기준
어떤 데이터들을 암호화 해야하나요?
아래는 토스의 정보보호정책서 하위 문서 내용 중 일부입니다. 제4조(암호화 대상) 에서는 각 암호화 대상 별 저장 시 알고리즘 등 통신 암호화 규정을 정의하고 있습니다.
관계 법령 암호화 필수 대상(법)
인증정보 | 비밀번호, PIN 번호, CI(연계정보), DI(예외 가능) |
고유식별정보 | 주민등록번호, 주민등록번호, 외국인등록번호, 운전면허번호, 여권번호), 거소증번호 |
바이오정보 | 지문, 얼굴, 홍채, 정맥, 음성, 필적 등 개인을 식별할 수 있는 신체적 또는 행동적 특징에 관한 정보로서 그로부터 가공되거나 생성된 정보 |
계좌번호, 신용카드번호 | 고객의 계좌정보, 신용카드 정보 등 금융 관련 정보 |
위치 정보 | 고객의 위치 정보 |
토스의 경우 아래 정보들도 암호화 하고 있습니다.
개인식별정보 | 이름, 휴대폰 번호, 이메일, 집주소 등 개인을 식별할 수 있는 정보 |
금융보안원 기준 개발 시 메모리에 노출되면 안되는 정보
: 금융보안원 전자금융기반시설 취약점 점검 기중 상, 개인식별정보는 메모리에 남지 않도록 구현이 필요합니다.
개인식별정보 | 개인정보(주민등록번호), 금융정보(비밀번호, 카드번호, OTP, 보안카드 번호 등), 기타 중요 정보라 판단되는 정보 |
메모리 할당 해제 | 스택으로 사용하거나 힙에 할당된 메모리는 0으로 덮어씌운 뒤 할당해제 하는등의 방법 고안 |
안전한 암호화 알고리즘
어떤 알고리즘을 써야 안전한가요?
안전한 암호화 알고리즘 및 키 길이 등에 대한 설명입니다.
•
권고 알고리즘
1.
AES/256/GCM
2.
AES/256/CBC
•
키 길이: 32bytes 이상 사용 권고
•
IV 값 : 매번 랜덤하게 생성한 뒤 암호화한 데이터 앞에 붙여서 전송
•
키 관리: 암호화 하여 안전한 곳에 보관
•
키 조합: 영문 + 숫자 + 특수문자 등 복잡도를 높여 사용 권고
1. 대칭키 알고리즘 - AES 암호화
특징
•
AES는 높은 안정성, 속도로 대중적인 안전한 대칭키 암호화 알고리즘
•
하나의 키로 암/복호화가 가능한 알고리즘입니다.
권장 스펙
•
키 길이 : 256비트 사용 권장
•
모드 : GCM 모드 사용 권장
1.1 AES/GCM 모드
특징
•
GCM 모드는 CTR 모드와 GMAC(인증/무결성)을 추가한 암호화 알고리즘입니다.
◦
AES 암호화로 기밀성과 GHASH 연산으로 무결성을 제공해줍니다.
◦
병렬적으로 블럭 암호화가 가능하기 때문에 CBC 모드에 비해 속도가 빠릅니다.
•
GCM 모드에 대한 상세한 문서 : https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf
2. 공개키(비대칭키) 알고리즘
특징
•
두개의 서로 다른키를 이용한 암/복호화 알고리즘
◦
공개키 : 모든사람에게 공개해도 되는 키로 보통 데이터 암호화, 서명 검증시 사용됩니다.
◦
개인키 : 자신만 소유하고 있는 키로 보통 데이터 복호화, 전자서명시 사용됩니다.
권장 스펙
•
키 길이
◦
RSA : 2048bit 이상
◦
ECC : 256bit 이상
(참고) RSA vs ECC 퍼포먼스(속도) 비교 (링크)
2.1 RSA 알고리즘
특징
•
키 생성 속도 및 암/복호화 속도가 대칭키에 비해 상당히 느리다는 단점이 있습니다.
•
대신 이해가 쉽고 구현이 간단합니다.
•
주로 하이브리드 암호화, 전자서명에 사용됩니다.
하이브리드 암호화?
•
payload : RSA_E(AesKey), AES_E(data)
권장 스펙
•
암호화 방식 (둘 중 선택)
◦
RSA/ECB/OAEPWithSHA1AndMGF1Padding
◦
RSA/ECB/OAEPWithSHA-256AndMGF1Padding
•
키 길이 : 2048bit 이상
2.2 ECC(Elliptic Curve Cryptography) 알고리즘
특징
•
타원곡선 알고리즘
•
키 생성 및 암호화 속도가 RSA 대비 빠르며, 키 길이가 짧으면서 높은 암호화 강도를 자랑합니다. (저전력, 저비용)
•
◦
전자서명시 RSA 대비 속도가 빠른 장점이 있습니다.
권장 스펙
•
키 길이 : 256 비트 이상 (secp256r1 or secp256k1)
3. 단방향 해싱 알고리즘
•
임의의 사이즈의 인풋 데이터를 해싱하면 고정된 크기의 데이터(message digest)가 나옵니다.
•
이렇게 생성된 message digest는 역연산이 불가능하기 때문에 다시 인풋 데이터를 알 수 없습니다.
권장 스펙
•
데이터 저장 용도 (DB 등)
◦
salt를 포함한 SHA256
•
무결성 검증 용도
◦
HmacSHA256 or JWT Token
•
해싱할 데이터와 salt값을 더해서 해싱하시면 보안성이 향상됩니다.
◦
해싱할 데이터와 연관된 정보를 salt로 사용하여 해싱하시면 됩니다.
▪
ex) 유저의 비밀번호를 저장할 때 userId(유저마다 고유번호)와 합쳐서 해싱하면 동일한 비밀번호를 가진 유저가 존재하더라도 각 유저마다 저장된 해싱값은 서로 다른값으로 보안성이 향상됩니다.
•
1701520(userId) + 123456ABC(password) = "1701520123456ABC" → HASH("1701520123456ABC") = 03fdfc3824d1babf95b....
◦
연관된 정보가 없다면 복잡성을 늘려주는 용도로 의미 없는 쓰레기 값을 추가해줘도 좋습니다. (레인보우 테이블, 브루투포싱 방지 목적)
▪
ex) 123456ABC(해싱할 데이터) + "ABCDFEF!@#0123"(salt)
레인보우 테이블이란?
데이터 통신 규정
mTLS
일반적인 TLS 통신에서는 서버가 클라이언트의 인증서를 확인하지 않습니다.
mTLS통신에서는 서버 측이 클라이언트의 인증서를 확인하는 로직이 추가되어 연결을 요청하는 클라이언트를 검증할 수 있습니다.
클라이언트(제휴사) 서버(토스) 구조가 되고, 사전에 미리 인증서를 제휴사와 교환합니다.
서버(토스) 구조가 되고, 사전에 미리 인증서를 제휴사와 교환합니다.JWT 토큰 설정 가이드
: JWT 설정 가이드
1st Best Practice
2nd Best Practice
화면 캡쳐 방지 및 보안 키패드 (참고)
적용 대상
•
고유식별정보 입력구간(주민번호 뒷자리)
•
비밀번호
•
카드번호
•
신분증 촬영 구간
기타 보안과 관련된 문의가 있으신 경우, 담당자를 통해 연락 부탁드립니다.