[secolab] SW 구현단계에서의 49개 보안약점 (2)

얀 짱 2026. 8. 13. 01:50

적절한 인증없는 중요기능 허용

적절한 인증과정이 없이 중요정보 (계좌이체 정보, 개인정보 등)를 열람 (또는 변경)할 때 발생하는 보안약점

💡 보안 대책
---
클라이언트의 보안검사를 우회하여 서버에 접근하지 못하도록 설계하고
중요한 정보가 있는 페이지는 재인증을 적용한다.

또한 안전하다고 검증된 라이브러리나 프레임워크 (OpenSSL 이나 ESAPI의 보안기능 등)를 사용하는 것이 중요하다.

부적절한 인가

프로그램이 모든 가능한 실행경로에 대해서 접근제어를 검사하지 않거나 불완전하게 검사하는 경우,
공격자가 접근 가능한 실행경로로 정보를 유출할 수 있게 되는 보안약점

💡 보안 대책
---
응용프로그램이 제공하는 정보와 기능을 역할에 따라 배분함으로써 공격자에게 노출되는 공격 노출면 (Attack Surface)을 최소화하고 사용자의 권한에 따른 ACL(Access Control List)을 관리한다.

프레임워크를 사용해서 취약점을 피할 수도 있다. (JAAS Authorization Framework 나 OWASP ESAPI Access Control 등을 인증 프레임워크로 사용 가능)

중요한 자원에 대한 잘못된 권한 설정

SW가 중요한 보안관련 자원에 대하여 읽기 또는 수정하기 권한을 의도하지 않게 허가할 경우,
권한을 갖지 않은 사용자가 해당 자원을 사용하게 되는 보안약점

💡 보안 대책
---
설정파일, 실행파일, 라이브러리 등은 SW 관리자에 의해서만 읽고 쓰기가 가능하도록 설정하고
설정파일과 같이 중요한 자원을 사용하는 경우,
허가 받지 않은 사용자가 중요한 자원에 접근 가능한지 검사한다.

취약한 암호화 알고리즘 사용

Base64와 같이 지나치게 간단한 인코딩 함수를 사용하거나,
정보보호 측면에서 취약하거나 위험한 암호화 알고리즘을 사용하는 것과 같이

표준화되지 않은 암호화 알고리즘을 사용하여,
공격자가 알고리즘을 분석하여 무력화시킬 수 있는 가능성을 높이는 보안약점

-> 몇몇 오래된 암호화 알고리즘의 경우는 컴퓨터의 성능이 향상됨에 따라 취약해지기도 한다.

(예를 들면, RC2, RC4, RC5, RC6, MD4, MD5, SHA1, DES 알고리즘이 있다.)

💡 보안 대책
---
자신만의 암호화 알고리즘을 개발하는 것은 위험하며,
학계 및 업계에서 이미 검증된 표준화된 알고리즘을 사용한다.

기존에 취약하다고 알려진 DES, RC5 등의 암호알고리즘을 대신하여,
3DES, AES, SEED 등의 안전한 암호알고리즘으로 대체하여 사용한다.

또한, 업무관련 내용, 개인정보 등에 대한 암호 알고리즘 적용 시,
IT 보안인증 사무국이 안전성을 확인한 검증필 암호모듈을 사용해야 한다.

암호화되지 않은 중요정보

사용자 또는 시스템의 중요정보가 포함된 데이터를 평문으로 송수신 또는 저장할 때
인가되지 않은 사용자에게 민감한 정보가 노출될 수 있는 보안약점

-> 중요정보 평문 저장 보안약점 + 중요정보 평문 전송 보안약점 => 암호화되지 않은 중요정보

💡 보안 대책
---
개인정보, 금융정보, 패스워드 등 중요정보를 통신채널로 전송하거나 저장할 때는
반드시 암호화 과정을 거쳐야 한다.

필요한 경우 SSL 또는 HTTPS 등과 같은 암호채널을 사용해야 하며, HTTPS와 같은 보안 채널을 사용하여 브라우저 쿠키에 중요 데이터를 저장하는 경우,
쿠키객체에 보안속성을 반드시 설정하여 중요정보의 노출을 방지한다.

중요정보를 읽거나 쓸 경우에 권한인증 등으로 적합한 사용자가 중요정보에 접근하도록 해야 한다.

하드코드 된 중요정보

프로그램 코드 내부에 하드코드된 패스워드 또는 암호화키를 포함하여
내부 인증에 사용하거나 암호화를 수행하면
중요정보 (관리자 정보, 암호화된 정보 등)가 유출될 수 있는 보안약점

-> 하드코드 된 비밀번호 보안약점 + 하드코드 된 암호화 키 보안약점 => 하드코드 된 중요정보

💡 보안 대책
---
패스워드는 암호화 하여 별도의 파일에 저장하여 사용한다.

또한 중요정보를 암호화하면,
상수가 아닌 암호화 키를 사용하도록 하며
소스코드 내부에 상수형태의 암호화 키를 저장해서 사용하지 않도록 한다.

충분하지 않은 키 길이 사용

키 길이가 충분히 길지 않으면 짧은 시간 안에 키를 찾아낼 수 있고,
이를 이용해 공격자가 암호화된 데이터나 패스워드를 복호화 할 수 있게 되어 발생하는 보안약점

-> 길이가 짧은 키를 사용하는 것은 암호화 알고리즘을 취약하게 만들 수 있다.

💡 보안 대책
---
RSA 알고리즘은 적어도 2048 비트 이상의 길이를 가진 키와 함께 사용해야 하고,
대칭암호화 알고리즘(Symmetric Encryption Algorithm)의 경우에는 적어도 128 비트 이상의 키를 사용한다.

적절하지 않은 난수값 사용

예측 가능한 난수를 사용함으로써 시스템에 유발되는 보안약점

-> 예측 불가능한 숫자가 필요한 상황에서 예측 가능한 난수를 사용한다면, 공격자는 SW에서 생성되는 다음 숫자를 예상하여 시스템을 공격하는 것이 가능하다.

💡 보안 대책
---
Java에서는 Random()과 Math.random() 사용 시,
java.util.Random 클래스에서 기본값으로 현재시간을 기반으로 조합하여 매번 변경되는 시드 (Seed)값을 사용하며,

C에서는 rand() 함수 사용 시 매번 변경되는 기본 시드 (Seed)값이 없으므로,
srand()로 매번 변경되는 시드 (Seed)값을 설정하여야 한다.

그러나 세션 ID, 암호화 키 등 보안결정을 위한 값을 생성해 보안결정을 수행하는 경우에는 Java에서 Random()과 Math.random()을 사용하지 말아야 하며,
예측이 거의 불가능하게 암호학적으로 보호된 java.security.SecureRandom 클래스를 사용하는 것이 안전하다.

취약한 비밀번호 허용

사용자에게 강한 비밀번호 조합규칙을 요구하지 않아, 사용자 계정이 취약하게 되는 보안 약점

-> 안전한 비밀번호를 생성하기 위해서는 [패스워드 선택 및 이용 안내서]의 안전한 패스워드 설정규칙을 적용해야 한다.

💡 보안 대책
---
비밀번호 생성 시 강한 조건 검증을 수행한다.

비밀번호는 숫자와 영문자, 특수문자 등을 혼합하여 정해진 자릿수를 사용하여 생성되도록 하고, 주기적으로 변경하도록 해야한다.

부적절한 전자서명 확인

전자서명이 사용된 경우, 전자서명을 검증하지 않거나 검증절차가 부적절하여 위변조된 파일을 통한 악성코드에 감염될 수 있는 보안약점

-> 전자서명을 확인하여 위변조 여부를 판별하고 사용해야 한다.

💡 보안 대책
---
전자서명을 포함하는 파일을 사용할 때는 항상 전자서명을 확인하여야 한다.
이 경우, 전자서명 파일의 출처 등을 확인하여 신뢰할 수 없는 곳에서 생성된 파일을 사용하지 않도록 한다.

부적절한 인증서 유효성 검증

인증서를 확인하지 않거나 인증서 확인 절차를 적절하게 수행하지 않아,
악의적인 호스트에 연결되거나 신뢰할 수 없는 호스트에서 생성된 데이터를 수신하게 되는 보안약점

💡 보안 대책
---
인증서를 사용하기 전에 인증서의 유효성을 확인한다.

인증서의 Commom Name과 실제 호스트가 일치하는지,
신뢰된 발급기관 (CA, RootCA)의 서명 여부, 인증서의 유효기간, 인증서의 해지여부, 안전한 암호화 알고리즘 사용 여부 확인 등으로 유효한 인증서인지 검증하는 절차를 구현하여야 한다.

사용자 하드디스크에 저장되는 쿠키를 통한 정보노출

프로그래머가 원하는 경우, 브라우저 세션에 관계없이 지속적으로 저장되도록 설정할 수 있으며,
이것은 디스크에 기록되고, 다음 브라우저 세션이 시작되었을 때 메모리에 로드된다.

개인정보, 인증 정보 등이 이와 같은 영속적인 쿠키에 저장되는 경우,
공격자가 쿠키에 접근할 수 있는 보다 많은 기회를 가지게 되어 시스템을 취약하게 만드는 보안약점