26년 주요정보통신기반시설 평가 항목 (웹) [AI 요약]

26년 주요정보통신기반시설 기술적 취약점 분석·평가 방법 상세가이드 (웹)
목차
- 웹 보안이란?
- 웹 애플리케이션 21개 취약점 상세 설명
- 보안 조치 방법
- 결론
개요
현대 기업의 디지털 자산을 보호하기 위해 정부는 주요정보통신기반시설 보호를 의무화하고 있습니다.
2026년 평가기준은 웹 애플리케이션의 보안을 21개 항목으로 나누어 평가합니다. 각 항목은 모두 '상(高)' 등급으로 분류되어 있습니다.
평가 항목
| 평가 항목 |
| 1. 코드 인젝션 |
| 2. SQL 인젝션 |
| 3. 디렉터리 인덱싱 |
| 4. 에러 페이지 적용 미흡 |
| 5. 정보 누출 |
| 6. 크로스사이트 스크립팅 (XSS) |
| 7. 크로스사이트 요청 위조 (CSRF) |
| 8. 서버사이드 요청 위조 (SSRF) |
| 9. 약한 비밀번호 정책 |
| 10. 불충분한 인증 절차 |
| 11. 불충분한 권한 검증 |
| 12. 취약한 비밀번호 복구 절차 |
| 13. 프로세스 검증 누락 |
| 14. 악성 파일 업로드 |
| 15. 파일 다운로드 |
| 16. 불충분한 세션 관리 |
| 17. 데이터 평문 전송 |
| 18. 쿠키 변조 |
| 19. 관리자 페이지 노출 |
| 20. 자동화 공격 |
| 21. 불필요한 Method 악용 |
웹 애플리케이션 평가 기준 (21개)
1. 코드 인젝션 (Code Injection) - 위험도: 상
개념: 사용자의 입력값이 쿼리나 명령어로 직접 삽입되어 공격자가 원하는 코드를 실행하게 하는 공격입니다.
실제 위험성:
- LDAP 인젝션: 디렉터리 서비스 데이터에 비인가 접근
- 운영체제 명령 실행: 서버의 시스템 명령을 원격으로 실행
- SSI 인젝션: 서버 사이드 인클루드 명령 조작
- XPath 인젝션: XML 데이터의 비인가 조회/삭제
- XXE 인젝션: XML 파일을 통한 시스템 정보 유출
- SSTI 인젝션: 템플릿 엔진에서 임의 코드 실행
설명: 쇼핑몰에서 상품을 검색할 때 "상품명"을 입력하는 칸에 악의적인 명령어를 입력하면, 시스템이 이를 명령어로 해석해서 실행해버리는 상황이라고 보시면 됩니다.
조치 방법:
- 화이트리스트 방식으로 허용된 문자만 입력받기
- 특수문자 필터링 ("|", ";", "`", "<" 등)
- 입력값 검증 및 이스케이프 처리
- 웹 방화벽에 필터링 룰셋 적용
체크리스트:
- 사용자 입력값에 대한 검증 로직 구현 확인
- 특수문자 필터링 처리 확인
- 소스코드 검토 완료
2. SQL 인젝션 (SQL Injection) - 위험도: 상
개념: 데이터베이스 쿼리문에 악의적인 SQL 코드를 삽입하여 데이터베이스를 불법적으로 접근하는 공격입니다.
실제 피해 사례:
- 고객 개인정보 대량 유출
- 관리자 비밀번호 탈취
- 데이터베이스 내용 삭제 또는 변조
- 불법 자금 이체
설명: 은행 로그인 화면에서 ID 입력 칸에 특수한 명령어를 입력해서, 비밀번호를 입력하지 않아도 로그인되게 하는 것과 같습니다.
조치 방법:
- Prepared Statement 사용 (파라미터 바인딩)
- SQL 키워드 필터링 (SELECT, UNION, INSERT 등)
- 특수문자 차단 (', ";, --, /*, */ 등)
- 데이터베이스 에러 메시지 숨기기
- WAF(웹 방화벽)에서 SQL 인젝션 룰셋 적용
체크리스트:
- 모든 데이터베이스 쿼리가 Prepared Statement 사용 확인
- SQL 키워드 및 특수문자 필터링 확인
- 에러 메시지 예외처리 확인
3. 디렉터리 인덱싱 - 위험도: 상
개념: 웹 서버에서 특정 폴더를 열었을 때 해당 폴더 안의 모든 파일 목록이 노출되는 취약점입니다.
실제 위험성:
- 백업 파일 노출 (*.bak, *.backup)
- 설정 파일 노출 (web.config, .env 파일)
- 소스코드 노출
- 보안 설정 정보 노출
설명: 편의점에서 "CCTV 영상 저장 폴더"라고 표시된 구석에 들어가면, 모든 CCTV 영상 파일이 목록으로 뜨는 것처럼 위험한 상황입니다.
조치 방법:
- Apache: httpd.conf에서 Indexes 옵션 제거
- Tomcat: web.xml에서 listings 설정을 false로 변경
- Nginx: autoindex off 설정
- IIS: 디렉터리 검색 기능 사용 안 함
체크리스트:
- 웹 서버 설정에서 디렉터리 인덱싱 비활성화 확인
- 웹 서버 재시작 확인
- 테스트 접근으로 파일 목록 노출 여부 재확인
4. 에러 페이지 적용 미흡 - 위험도: 상
개념: 에러가 발생했을 때 시스템의 상세한 정보(서버 버전, 파일 경로, 스택 트레이스)가 노출되는 취약점입니다.
실제 위험성:
- 서버 OS 및 버전 정보 노출 (해커가 알려진 취약점 공격 가능)
- 데이터베이스 종류 및 버전 노출
- 절대 파일 경로 노출 (시스템 구조 파악)
- 사용 중인 라이브러리 정보 노출
설명: 병원에서 환자의 병명과 과거 병력을 대기실에 있는 모든 사람이 볼 수 있도록 게시하는 것과 같은 정보 유출 상황입니다.
조치 방법:
- 응답 헤더에서 서버 버전 정보 제거
- 사용자 정의 에러 페이지 설정 (404, 500 등)
- 개발용 디버그 정보 비활성화
- 에러 로그는 서버에만 남기고 클라이언트에 노출하지 않기
체크리스트:
- 에러 발생 시 일반적인 메시지만 표시되는지 확인
- 서버 버전 정보가 응답 헤더에 없는지 확인
- 스택 트레이스가 화면에 보이지 않는지 확인
5. 정보 누출 - 위험도: 상
개념: 웹사이트에 민감한 정보(개인정보, 금융정보)가 평문으로 노출되거나, 불필요한 백업/테스트 파일이 공개되는 취약점입니다.
실제 위험성:
- 개인정보 노출: 주민등록번호, 전화번호, 주소 등
- 금융정보 노출: 카드번호, 계좌번호, 거래 정보
- 관리자 정보 노출
- 백업 파일 (.sql, .zip, .old) 다운로드 가능
설명: 은행 홈페이지에서 모든 고객의 계좌번호와 잔액이 누구나 볼 수 있도록 공개되는 것과 같습니다.
조치 방법:
- 개인정보 마스킹 처리 (주민번호: 901231-1** 형태)
- robots.txt 파일로 검색 엔진 크롤링 차단
- 불필요한 백업/로그 파일 삭제
- HTML 주석에 민감한 정보 작성 금지
- 초기 샘플 페이지 제거
마스킹 기준:
| 정보 | 마스킹 예시 |
|------|-----------|
| 성명 | 홍동 |
| 주민등록번호 | 901231-1***** |
| 전화번호 | 010-1234-** |
| 카드번호 | 9430-82--2393 |
| 계좌번호 | 430-20-1* |
체크리스트:
- 민감 정보의 마스킹 처리 확인
- 불필요한 파일 삭제 확인 (*.bak, *.backup, *.zip 등)
- 소스코드 주석에 민감 정보 없는지 확인
6. 크로스사이트 스크립팅 (XSS) - 위험도: 상
개념: 악의적인 자바스크립트 코드를 웹페이지에 삽입하여 다른 사용자의 브라우저에서 실행시키는 공격입니다.
XSS의 종류:
- Stored XSS (저장형): 게시판에 악의적 스크립트를 저장 → 모든 방문자 피해
- Reflected XSS (반사형): 악성 URL 링크 → 클릭한 사용자만 피해
- DOM XSS: 자바스크립트를 통한 DOM 조작으로 발생
실제 피해:
- 사용자 세션 쿠키 탈취 → 계정 탈취
- 피싱 사이트로 유도
- 악성 파일 다운로드 유도
- 개인정보 수집
설명: 카페 게시판에 "클릭하면 상품 무료 증정"이라는 글을 올렸는데, 실제로는 클릭한 모든 사람의 계정 정보를 훔치는 프로그램이 숨어있는 것과 같습니다.
조치 방법:
- 입력값 검증 및 필터링 (서버 사이드)
- 출력값 인코딩 (HTML 엔티티)
<→<>→>"→"'→'
- 화이트리스트 방식 (필요한 HTML만 허용)
- Content Security Policy (CSP) 헤더 설정
- HttpOnly, Secure, SameSite 쿠키 속성 적용
체크리스트:
- 모든 사용자 입력값에 필터링 적용 확인
- 게시판/댓글에 스크립트 삽입 불가 확인
- 검색 기능에 스크립트 삽입 불가 확인
7. 크로스사이트 요청 위조 (CSRF) - 위험도: 상
개념: 사용자가 로그인한 상태에서 모르는 사이에 다른 웹사이트가 자신의 계정으로 임의의 요청을 전송하게 하는 공격입니다.
실제 공격 시나리오:
- 사용자가 은행 홈페이지에 로그인
- 공격자의 사이트 방문 (로그인 유지 상태)
- 공격자의 사이트가 사용자의 은행 계좌에서 돈을 이체하는 요청 전송
- 사용자는 모르는 사이에 송금 완료
실제 피해:
- 비밀번호 변경
- 계좌 이체
- 개인정보 수정
- 게시글 삭제
설명: 은행에 들어가서 관리자처럼 보이는 사람이 "이 서류에 서명해주세요"라고 하면, 당신의 계정으로 자동 송금을 설정하는 서류에 사인하는 것입니다.
조치 방법:
- CSRF 토큰 발급 및 검증
- Referer/Origin 헤더 검증
- SameSite 쿠키 옵션 설정
- HTTPS 환경에서 Secure, HttpOnly 속성 설정
CSRF 토큰 방식:
1. 페이지 로딩 시: 서버가 고유한 토큰 생성
2. 폼 제출 시: 토큰을 함께 전송
3. 서버 검증: 제출된 토큰이 세션 토큰과 일치하는지 확인
체크리스트:
- 중요 요청(비밀번호 변경, 송금 등)에 CSRF 토큰 적용 확인
- 토큰 검증 로직 구현 확인
- 외부 사이트 요청 차단 확인
8. 서버사이드 요청 위조 (SSRF) - 위험도: 상
개념: 공격자가 서버의 입력값을 조작하여 서버로 하여금 내부 또는 외부 서버로 임의의 요청을 보내도록 하는 공격입니다.
실제 공격 시나리오:
- 웹 사이트에서 이미지 URL을 입력받는 기능
- 공격자가 내부 서버 주소 입력 (예: 192.168.1.1)
- 웹 서버가 내부 서버에 요청 전송
- 내부 서버의 데이터 또는 설정 파일 노출
실제 위험성:
- 내부 서버 정보 수집
- 클라우드 메타데이터 접근 (AWS의 내부 구성 정보 탈취)
- 임의 명령 실행
- 내부 서비스 장악
설명: 배달 앱에서 "음식점 주소"를 입력하는 칸에 "회사 내부 서버 주소"를 입력하면, 배달 앱이 그 서버에 접근해서 정보를 가져오는 것입니다.
조치 방법:
- 화이트리스트 방식으로 허용 URL/IP 정의
- 비허가 프로토콜 차단 (file://, ftp://, gopher:// 등)
- 내부 IP 범위 차단 (127.0.0.1, 10.0.0.0, 192.168.0.0 등)
- 에러 정보 노출 최소화
- 네트워크 분리
체크리스트:
- 외부 URL 입력 받는 모든 기능에 검증 적용 확인
- 화이트리스트 방식 구현 확인
- 내부 IP 범위 차단 확인
9. 약한 비밀번호 정책 - 위험도: 상
개념: 사용자가 너무 간단한 비밀번호를 설정할 수 있어서 브루트포스 공격(무작위 입력)으로 쉽게 뚫리는 취약점입니다.
약한 비밀번호의 예:
- 연속 숫자: 1234, 4567
- 반복 숫자: 1111, 2222
- 간단한 단어: password, qwerty, admin
- 생년월일: 19900101
- 전화번호 뒷자리: 1234
실제 피해:
- 계정 탈취
- 개인정보 유출
- 전자금융 사기
설명: 집의 비밀번호를 "1234"로 설정해두면, 누구나 추측해서 들어올 수 있는 것처럼 위험합니다.
권장 비밀번호 정책:
다음 중 2가지 이상 조합 + 최소 10자리 이상
- 대문자 (A-Z)
- 소문자 (a-z)
- 숫자 (0-9)
- 특수문자 (!@#$%^&*)
또는 3가지 이상 조합 + 최소 8자리 이상
강한 비밀번호의 예:
- MyDog@2024!
- Secure#Pass99
- BlueSky$Mobile2
조치 방법:
- 비밀번호 복잡도 검증 로직 구현
- 회원가입/수정/변경 시 모두 적용
- 약한 ID 사용 차단 (admin, root, guest 등)
- 로그인 실패 시 계정 잠금 (3~5회 이상)
- 주기적 변경 요구 (최소 반기 1회)
체크리스트:
- 비밀번호 복잡도 정책 수립 확인
- 약한 비밀번호 거부 기능 구현 확인
- 로그인 실패 계정 잠금 구현 확인
10. 불충분한 인증 절차 - 위험도: 상
개념: 중요한 작업(개인정보 수정, 송금 등)을 할 때 추가 인증 없이 진행되거나, 인증 절차를 쉽게 우회할 수 있는 취약점입니다.
취약한 인증의 예:
- 비밀번호 변경 시 현재 비밀번호 확인 없음
- 휴대폰 번호 변경 시 인증코드 검증 없음
- 송금 시 OTP 미사용
- 자동 로그인만 사용
실제 피해:
- 컴퓨터를 잠시 내려놓은 사이에 비밀번호 변경
- 계좌 정보 변경 후 송금
- 개인정보 대량 유출
설명: ATM에서 입금은 아무나 할 수 있지만, 출금할 때는 반드시 비밀번호를 입력해야 하듯이, 중요한 작업에는 추가 인증이 필요합니다.
조치 방법:
- 중요 작업(개인정보 수정, 비밀번호 변경)에 현재 비밀번호 재입력
- 휴대폰 번호 변경 시 인증번호 확인
- 금융거래 시 OTP/보안번호 사용
- 의심 로그인에 2차 인증 강제
- 세션 기반 인증 검증 (서버 사이드)
체크리스트:
- 중요 작업에 추가 인증 단계 존재 확인
- 인증 로직 우회 가능성 테스트
- 서버 사이드 검증 구현 확인
11. 불충분한 권한 검증 - 위험도: 상
개념: 사용자가 접근할 권한이 없는 데이터나 기능에 접근할 수 있는 취약점입니다.
권한 검증이 부족한 예:
- 다른 사용자의 주문 정보 조회 가능
- 일반 사용자가 관리자 기능 사용
- 타 사용자의 파일 삭제 가능
- 가격 정보 수정 가능
실제 피해:
- 개인정보 노출
- 권한 상승 공격
- 데이터 위조
- 시스템 장악
설명: 은행 직원이 모든 고객의 계좌에 접근할 수 있다면, 누군가 이를 악용해 돈을 빼갈 수 있습니다. 따라서 자신의 담당 고객 계좌만 접근하도록 제한해야 합니다.
조치 방법:
- 모든 요청에서 사용자 권한 검증
- 세션 기반 접근 제어
- 토큰 기반 접근 제어
- 자신의 데이터만 조회/수정/삭제 허용
- 관리자 기능 접근 엄격히 제어
체크리스트:
- 다른 사용자 데이터 접근 불가 확인
- 타 사용자 데이터 수정/삭제 불가 확인
- 일반 사용자가 관리자 기능 사용 불가 확인
12. 취약한 비밀번호 복구 절차 - 위험도: 상
개념: "비밀번호 분실" 기능에서 충분한 검증 없이 비밀번호를 초기화할 수 있는 취약점입니다.
취약한 복구 절차의 예:
- 정보 확인 없이 비밀번호 재발급
- 보안 질문만 사용 (답변이 쉬운 질문들)
- 이메일 링크만 사용 (이메일이 탈취되면 무용지물)
- OTP 없이 이메일로만 확인
실제 피해:
- 계정 탈취
- 개인정보 도용
- 금융 사기
설명: 은행에서 "비밀번호를 잊으셨나요?"를 클릭했을 때, 아무 확인 없이 새 비밀번호를 바로 보내주면 누군가 다른 사람 계좌를 탈취하기 쉬워집니다.
조치 방법:
- 이메일 + 휴대폰 이중 인증
- 보안 질문 추가 (답변이 어려운 질문)
- 본인인증 절차 필수
- OTP 인증 추가
- 비밀번호 재설정 링크 만료 시간 설정
- 비밀번호 변경 후 재확인
체크리스트:
- 비밀번호 복구 시 다단계 인증 적용 확인
- 이메일만으로 복구 불가 확인
- 본인인증 절차 강화 확인
13. 프로세스 검증 누락 - 위험도: 상
개념: 쇼핑, 결제, 승인 등 서비스의 단계별 프로세스를 건너뛰거나 우회할 수 있는 취약점입니다.
프로세스 우회의 예:
- 결제 단계를 건너뛰고 상품 받기
- 가격 정보 변조 후 구매
- 관리자 승인 단계 없이 진행
- 중간 단계를 생략하고 마지막 단계로 접근
실제 피해:
- 비용 없이 상품 획득
- 가격 변조를 통한 손실
- 미승인 작업 완료
- 서비스 악용
설명: 마트에서 "상품 선택 → 결제 → 영수증 발급"의 단계가 있는데, 누군가 결제 단계를 건너뛰고 바로 상품을 가져가도록 할 수 있다면 문제가 됩니다.
조치 방법:
- 모든 프로세스 단계 검증
- 세션에 진행 단계 저장
- 이전 단계 완료 확인 필수
- 서버 사이드에서 가격 재검증
- 타임스탬프로 순서 검증
체크리스트:
- 단계별 완료 여부 서버에서 검증 확인
- 단계 건너뛰기 불가 확인
- 가격 변조 불가 확인
14. 악성 파일 업로드 - 위험도: 상
개념: 사용자가 악의적인 파일(실행 파일, 스크립트)을 업로드할 수 있는 취약점입니다.
악성 파일 업로드의 예:
- 웹셸 (.php, .asp, .jsp 파일) 업로드
- 바이러스 파일 업로드
- 실행 파일 (.exe, .bat) 업로드
- 이중 확장자 파일 (.php.jpg)
실제 피해:
- 웹 서버 장악
- 악성코드 배포
- 다른 사용자 컴퓨터 감염
- 데이터 유출
설명: 커뮤니티에서 "사진 업로드" 기능을 사용할 때, 누군가 사진으로 위장한 바이러스를 업로드하면 다른 사람들이 다운로드할 때 감염됩니다.
조치 방법:
- 화이트리스트 방식으로 허용 확장자만 지정
- 파일 확장자 검증 (내용도 확인)
- MIME 타입 검증
- 업로드 디렉터리를 웹 접근 불가 영역으로 설정
- 파일명 변경 (.jpg → random_uuid.jpg)
- 바이러스 검사 프로그램 통과
금지 확장자 예시:
.exe, .bat, .cmd, .php, .jsp, .asp, .aspx, .py, .rb, .sh, .scr, .com, .pif, .vbs, .js
체크리스트:
- 허용 확장자 화이트리스트 적용 확인
- 파일 내용 검증 확인
- 업로드 디렉터리 웹 접근 불가 설정 확인
- 바이러스 검사 연동 확인
15. 파일 다운로드 - 위험도: 상
개념: 사용자가 인가되지 않은 파일을 다운로드하거나, 시스템의 중요 파일에 접근할 수 있는 취약점입니다.
파일 다운로드 취약점의 예:
- 다른 사용자의 파일 다운로드 가능
- 설정 파일 다운로드 (.env, web.config)
- 소스코드 다운로드
- 데이터베이스 백업 파일 다운로드
- 경로 조작 (../../etc/passwd)
실제 피해:
- 개인정보 유출
- 소스코드 탈취
- 데이터베이스 정보 유출
- 서비스 복제
설명: 클라우드 스토리지에서 자신의 파일만 다운로드해야 하는데, 다른 사람의 파일도 다운로드할 수 있다면 문제입니다.
조치 방법:
- 파일 소유자 권한 검증
- 경로 조작 방지 (../ 제거)
- 화이트리스트 방식 경로 검증
- 다운로드 가능 디렉터리 제한
- 심볼릭 링크 탐지 및 차단
- 파일명 인코딩 처리
체크리스트:
- 자신의 파일만 다운로드 가능 확인
- 경로 조작으로 다른 파일 접근 불가 확인
- 설정 파일 다운로드 불가 확인
16. 불충분한 세션 관리 - 위험도: 상
개념: 세션 생성, 관리, 종료 과정에서 보안이 부족하여 세션 탈취, 고정, 재사용이 가능한 취약점입니다.
세션 관리 취약점의 예:
- 세션 ID가 예측 가능 (1, 2, 3, ...)
- 세션 만료 시간 설정 없음 (영구 유지)
- 로그아웃해도 세션 ID가 유지됨
- HTTPS 없이 세션 ID 평문 전송
- HttpOnly 속성 없음
실제 피해:
- 세션 ID 탈취 후 타인 계정으로 접근
- 공개 Wi-Fi에서 세션 탈취
- 다른 브라우저에서 계정 사용
- 세션 고정 공격
설명: 도서관에서 "회원 번호표"를 받고 도서 대출을 하는데, 번호표를 잃어버리면 누군가 그 번호로 책을 대출할 수 있습니다.
조치 방법:
- 세션 ID 암호화 방식 생성 (예측 불가)
- 세션 만료 시간 설정 (30분~2시간)
- 로그아웃 시 세션 ID 즉시 무효화
- HTTPS 환경에서만 세션 사용
- HttpOnly, Secure, SameSite 쿠키 속성 적용
- 로그인 후 세션 ID 재생성
- IP 주소 변경 감지
체크리스트:
- 세션 ID 무작위 생성 확인
- 세션 만료 시간 설정 확인
- HttpOnly, Secure 속성 적용 확인
- 로그아웃 시 세션 무효화 확인
17. 데이터 평문 전송 - 위험도: 상
개념: 서버와 클라이언트 간 데이터를 암호화하지 않고 평문으로 전송하여 도청당할 수 있는 취약점입니다.
평문 전송의 위험성:
- HTTP 사용 (암호화 없음)
- 로그인 정보 평문 전송
- 개인정보 평문 전송
- 금융정보 평문 전송
실제 피해:
- 공개 Wi-Fi에서 정보 탈취
- 통신 도청
- 개인정보 도용
- 금융 사기
설명: 엽서에 비밀번호를 적어서 우편으로 보내는 것처럼 위험합니다. 누구나 내용을 볼 수 있기 때문입니다.
조치 방법:
- HTTPS 사용 필수 (모든 페이지)
- SSL/TLS 3.0 이상 사용
- 약한 암호화 프로토콜 비활성화 (SSL 2.0, 3.0, TLS 1.0)
- 강력한 암호화 알고리즘 사용 (TLS 1.2 이상)
- 특히 민감한 데이터는 애플리케이션 레벨 암호화 추가
체크리스트:
- 모든 페이지에서 HTTPS 사용 확인
- 혼합 콘텐츠 (HTTP+HTTPS) 없는지 확인
- SSL 인증서 유효성 확인
- 약한 암호화 프로토콜 비활성화 확인
18. 쿠키 변조 - 위험도: 상
개념: 쿠키에 저장된 사용자 식별 정보가 암호화되지 않아서 변조하여 다른 사용자로 위장할 수 있는 취약점입니다.
쿠키 변조의 예:
- 쿠키: userid=123 → userid=456으로 변조 (다른 사용자 계정 접근)
- 쿠키: admin=false → admin=true로 변조 (관리자 권한 획득)
- 평문 쿠키 값 변조
실제 피해:
- 타 사용자 계정으로 접근
- 권한 상승
- 개인정보 탈취
- 금융 거래 위조
설명: 회원증에 "회원번호: 123"이라고 손으로 써있는데, 누군가 이를 "회원번호: 456"으로 지우고 쓸 수 있다면, 다른 사람 회원증으로 사용할 수 있습니다.
조치 방법:
- 서버 사이드 세션 사용 (쿠키 대신)
- 쿠키를 사용해야 하면 안전한 알고리즘 암호화 (AES, SEED, 3DES)
- HMAC 서명으로 변조 감지
- HttpOnly 속성 (자바스크립트 접근 불가)
- Secure 속성 (HTTPS만)
- SameSite 속성 (CSRF 방지)
체크리스트:
- 인증 정보를 서버 사이드 세션으로 관리 확인
- 쿠키 암호화 적용 확인
- HttpOnly, Secure, SameSite 속성 적용 확인
19. 관리자 페이지 노출 - 위험도: 상
개념: 관리자 페이지(/admin, /manager, /control)가 인증 없이 접근 가능하거나, 위치가 노출되는 취약점입니다.
관리자 페이지 노출의 예:
- /admin 페이지에 로그인 없이 접근 가능
- robots.txt에 관리자 경로 기재 (/admin, /manage)
- 검색 엔진에 관리자 페이지 인덱싱됨
- 소스코드에 관리자 링크 노출
실제 피해:
- 무단 시스템 접근
- 전체 사용자 정보 조회/수정
- 서비스 종료
- 데이터 삭제
설명: 은행의 직원 전용 구역에 "관리자실 → 2층 → 우회전"이라는 표지판이 있어서 누구나 찾아갈 수 있다면 문제입니다.
조치 방법:
- 관리자 페이지 경로 숨기기 (예측 불가능한 이름)
- 관리자 페이지에 강력한 인증 필수
- robots.txt에서 관리자 경로 차단
- 관리자 IP 대역 제한
- VPN을 통해서만 접근 가능하도록 제한
- 관리자 페이지 WAF 규칙 강화
체크리스트:
- 관리자 페이지에 강력한 인증 적용 확인
- robots.txt에서 관리자 경로 차단 확인
- 로그인 없이 관리자 페이지 접근 불가 확인
20. 자동화 공격 - 위험도: 상
개념: 자동화된 도구(봇)를 이용해 대량의 요청을 보내서 계정을 탈취하거나 서비스를 방해하는 공격입니다.
자동화 공격의 예:
- 브루트포스: 비밀번호 자동 입력으로 계정 탈취
- 크래킹: 자동 반복 요청으로 인증 코드 추측
- 스크래핑: 자동으로 대량 데이터 수집
- DDoS: 자동 대량 요청으로 서비스 마비
실제 피해:
- 계정 탈취
- 개인정보 도용
- 서비스 마비
- 수표 사기
설명: ATM에서 자동 기계가 계속 "1234, 1234, 1234..."를 시도해서 비밀번호를 맞히거나, ATM을 고장 내버리는 것과 같습니다.
조치 방법:
- CAPTCHA 도입 (사람 확인)
- 로그인 실패 계정 잠금 (3~5회)
- IP 기반 요청 제한
- Rate Limiting (초당 요청 수 제한)
- 패턴 감지 및 차단
- WAF 봇 차단 규칙 적용
체크리스트:
- 로그인 페이지에 CAPTCHA 적용 확인
- 로그인 실패 계정 잠금 확인
- 비정상적 요청 차단 확인
21. 불필요한 Method 악용 - 위험도: 상
개념: HTTP Method (GET, POST, PUT, DELETE, PATCH 등) 중 불필요한 것이 활성화되어 있어서 악용될 수 있는 취약점입니다.
불필요한 Method의 예:
- DELETE Method 활성화 (자신의 계정 삭제 가능)
- PUT Method 활성화 (파일 업로드 가능)
- TRACE Method 활성화 (헤더 정보 노출)
- OPTIONS에서 모든 허용 Method 노출
실제 피해:
- 데이터 삭제
- 파일 업로드
- 헤더 정보 탈취
- 권한 없이 수정
설명: 은행 앱에서 "확인만 하는 기능"이 필요한데, 실수로 "삭제도 가능하게" 되어있다면, 누군가 실수로 중요한 거래 기록을 삭제할 수 있습니다.
조치 방법:
- 필요한 HTTP Method만 활성화
- 불필요한 Method 비활성화
- OPTIONS Method에서 정보 숨기기
- Method 검증 (POST만 허용하면서 GET도 처리하지 않기)
필요한 Method:
- GET: 조회만
- POST: 데이터 생성/수정
- (일반 웹사이트에서는 DELETE, PUT, PATCH 불필요)
체크리스트:
- 필요한 Method만 활성화 확인
- DELETE Method 비활성화 확인
- PUT, PATCH Method 비활성화 확인
웹 보안은 선택이 아닌 필수
웹 애플리케이션 보안은 더 이상 선택의 문제가 아닙니다.
특히 주요정보통신기반시설에 해당하는 서비스는 법적 의무이며, 각 항목마다 비용이 드는 취약점이기도 합니다.
중요 보안 과제:
- HTTPS 도입 (데이터 평문 전송 방지)
- 입력값 검증 (인젝션 공격 방지)
- 인증 강화 (약한 비밀번호 정책 개선)
- 에러 정보 숨기기 (정보 누출 방지)
- 권한 검증 (불충분한 권한 검증 개선)
출처: KISA
주요정보통신기반시설 관리·물리적 취약점 분석·평가 방법 안내서 다운로드
주요정보통신기반시설 기술적 취약점 분석·평가 방법 상세가이드 다운로드
27&searchWrd=&menuNo=205021&pageIndex=1&categoryCode=&nttId=71928)
'정보보안 월드 > 정보보안 정책' 카테고리의 다른 글
| OWASP 2026 에이전트 AI 보안 Top 10 (1) | 2025.12.29 |
|---|---|
| 전자금융감독규정 해설 다운로드 (25년 8월) (4) | 2025.08.06 |
| ISO/SAE 21434 기반 자동차 부품 제조사를 위한 사이버보안 위협 분석 및 위험 평가(TARA) 메뉴얼 요약 (0) | 2025.02.25 |
| 스마트선박 사이버보안 모델 및 가이드라인 요약 보고서 (0) | 2025.02.25 |
| 로봇 서비스 보안모델 요약 보고서 (0) | 2025.02.25 |