Become a Good Analyst

가. 원인 - 검증되지 않은 입력값 또는 DB저장값을 동적 웹페이지 생성에 사용 나. 영향 - 클라이언트에서 악성코드 실행 - 피싱사이트 실행 - 세션 하이재킹 공격 실행 - 접속자 권한으로 부적절한 스크립트 실행으로 정보유출 다. 보안대책 - 스크립트를 삽입하지 못하도록 입력값 필터링 ( % " 등 ) - HTML태그를 허용하는 게시판의 경우 허용되는 HTML태그를 화이트리스트로 관리 및 사용 - 입력값에 정규식을 이용하여 검증 - 모든 요청에 대해 XSS 필터를 적용하여 입력값 검증 - 출력값에 HTML 인코딩 적용 - 출력값에 XSSFilter를 적용 라. 안전한 코드 1. 서블릿에서 HTML 인코딩 String data = request.getParameter("data"); data = ..

가. 원인 - 검증되지 않은 외부입력값을 파일 및 서버의 시스템 자원에 접근하거나 식별을 허용 나. 영향 - 시스템이 보호하는 자원에 접근/수정/삭제/정보노출 - 시스템 자원간 충돌로 시스템 장애 유발 - 허용되지 않는 권한을 획득 - 인증/인가 우회 후 설정파일 열람/변경/실행 다. 보안대책 - 외부입력값을 자원(파일, 소켓포트 등)의 식별자로 사용할 경우, 검증 후 사용 - 사용자별 사용가능한 자원을 사전에 리스트로 정의 - 외부입력값을 파일 식별자로 사용할 경우, 경로순회공격 위험이 있는 문자( .. / \ ) 필터링 라. 안전한 코드 String fileName = request.getParameter("file"); FileInputStream fis = null fileName = filena..

가. 원인 - 입력된 데이터에 대한 유효성 검증을 하지 않고 DB 쿼리의 일부로 사용 - 입력값 필터링 없이 동적쿼리에 적용 후 사용 나. 영향 - 로그인 인증우회 - DB 데이터 유출/수정/삭제 - 시스템 명령어 실행 다. 보안대책 - 정적쿼리 사용 - 쿼리구조를 변경할 수 있는 문자열을 검사 후 쿼리문 생성에 사용 - PreparedStatement 객체 등을 이용하여 컴파일 된 쿼리문을 사용 - DB 사용자 권한 최소화 - 500 서버오류 정보 노출 제한 라. 안전한 코드 1. JDBC API 사용 String id = request.getParameter("id"); String sql = "select * from user_info where id = ?"; Connection con = db...

가. 취약점 개요 - 일정한 규칙을 갖는 세션ID가 발급되거나, 세션 타임아웃이 너무 길게 설정된 경우, 사용자 권한도용이 가능한 취약점 → (불충분한 세션관리) - 다중 스레드의 싱글톤 객체에서 멤버변수 등을 통해 서로 다른 세션 간 데이터를 공유로 인해 경쟁조건 발생하는 취약점 → 잘못된 세션에 의한 정보노출 나. 요구사항 1. 세션간 데이터가 공유되지 않도록 설계 2. 세션을 안전하게 관리 3. 세션ID를 안전하게 관리 다. 요구사항 별 고려사항 1. 세션간 데이터가 공유되지 않도록 설계 - 싱글톤 객체로 생성되는 서비스 컴포넌트 확인 - 해당 컴포넌트에 읽고 쓰기가 가능한 멤버변수, 클래스 변수를 사용하지 않도록 설계 2. 세션을 안전하게 관리 - 모든 페이지에서 로그아웃 가능하도록 UI 설계 -..

가. 취약점 개요 - 에러페이지를 설정하지 않아, 에러 메시지를 통해 서버 데이터 정보 등의 공격에 필요한 정보가 노출되는 취약점 → 오류 페이지를 통한 정보노출 - 에러를 통해 시스템의 내부 데이터가 공개되어, 또 다른 공격의 빌미를 제공하는 취약점 → 시스템 데이터 정보 노출 나. 요구사항 1. 명시적 예외에 대해 예외처리 블럭을 통해 예외처리 기능을 구현 2. 입력값 범위를 체크하여 정상동작을 보장 3. 상세한 에러정보를 노출하지 않도록 구현 다. 요구사항 별 고려사항 1. 명시적 예외에 대해 예외처리 블럭을 통해 예외처리 기능을 구현 - 언어별 예외처리 문법에 대한 안전한 사용방법을 기술 - 안전하게 예외처리 할 수 있도록 가이드 작성 2. 입력값 범위를 체크하여 정상동작을 보장 - 입력값에 따라..

가. 취약점 개요 - 민감 데이터를 평문으로 송/수신하여 스니핑을 통해 정보가 노출되는 취약점 → 중요정보 평문전송 나. 요구사항 1. 민감정보 전송 시 안전하게 암호화해서 전송 2. 쿠키에 포함된 중요정보는 암호화해서 전송 다. 요구사항 별 고려사항 1. 민감정보 전송 시 안전하게 암호화해서 전송 - 중요정보를 안전한 암호모듈로 암호화 후 전송하거나 안전한 통신채널을 이용하여 전송 - "암호연산" 여구항목을 충족하는 암호화 알고리즘 및 암호키를 사용 - 클라이언트와 서버 사이에 불필요한 데이터가 포함되어 전송되지 않도록 설계 2. 쿠키에 포함된 중요정보는 암호화해서 전송 - 쿠키에 중요정보가 포함되지 않도록 설계 - 부득이하게 포함되어야 할 경우, 반드시 세션쿠키로 설정 - 쿠키로 전달되는 중요정보는 ..

가. 취약점 개요 - 개인/인증/금융정보와 같은 중요정보를 평문으로 저장할 경우, 중요정보 및 민감정보가 노출되거나, 무결성을 잃을 수 있는 취약점 → 중요정보 평문저장 - 개인정보/인증정보 등이 영속적 쿠키에 저장될 경우, 많은 쿠키접근 기회를 통해 시스템을 취약하게 만드는 취약점 → 사용자 하드디스크에 저장된 쿠키를 통한 정보 노출 나. 요구사항 1. 중요정보 또는 개인정보는 암호화 후 저장 2. 불필요하거나, 사용하지 않는 중요정보는 메모리에서 삭제 다. 요구사항 별 고려사항 1. 중요정보 또는 개인정보는 암호화 후 저장 - 중요정보가 외부로 노출되지 않도록 설계 - DB나 파일에 중요정보를 저장 시 반드시 안전한 암호알고리즘와 암호키로 암호화 후 저장 - HTML5 로컬저장 소와 같은 클라이언트 ..

가. 취약점 개요 - 간단한 인코딩 등을 통해 암호화를 할 경우, 패스워드 등을 안전하게 보호할 수 없는 취약점 → 취약한 암호알고리즘 사용 - 키 길이를 충분히 사용하지 않을 경우, 검증된 암호화 알고리즘을 사용하더라도 짧은 시간에 크래킹이 가능한 취약점 → 충분하지 않은 키 길이 사용 - 예측 가능한 난수를 사용 시 다음 숫자를 예상하여 시스템을 공격할 수 있는 취약점 → 적절하지 않은 난수 사용 - 일방향 해쉬함수 사용 시 솔트없이 해쉬할 경우, 레인보우 테이블 등을 통해 해쉬값을 미리 계산이 가능한 취약점 → 솔트없이 사용하는 일방향 해쉬함수 나. 요구사항 1. KISA 암호이용안내서에서 정의하고 있는 암호화 알고리즘과 안정성이 보장되는 암호화 키 길이를 사용 2. 솔트값을 적용한 안전한 해쉬 알..

가. 취약점 개요 - 코드 내부에 하드코드된 암호화 키를 사용하여 암/복호화에 사용할 경우 암호키 노출이 가능한 취약점 → 하드코드된 암호키 - 주석문 안에 암호키 정보가 작성되어, 소스코드에 접근한 사용자에게 암호키가 노출되는 취약점 → 주석문 안에 포함된 시스템 주요정보 (암호키) 나. 요구사항 1. 암호키는 KISA 암호이용안내서에 정의하고 있는 암호화 가이드를 적용 2. 중요정보는 암호화하여 설정파일에 저장 후 암호키는 별도의 디렉터리에서 보관 및 관리 다. 요구사항 별 고려사항 1. 암호키는 KISA 암호이용안내서에 정의하고 있는 암호화 가이드를 적용 (1) 생성 시 고려사항 - 암호키는 DB와 물리적으로 분리된 장소에 별도 보관 - 암호키의 생명주기를 관리정책 적용 - 패스워드와 암호키는 메모..

가. 취약점 개요 - 관리자 페이지가 인터넷에 접근 가능할 경우, 다양한 형태의 공격의 빌미를 제공하는 취약점 → (관리자 페이지 노출) - HTML 문서 내 변수값으로 입력된 값이 인젝션 명령문으로 수행되어 서버 데이터 정보를 누출하는 취약점 → (SSI) - 모든 실행경로의 접근제어 부재 및 미흡으로 실행경로를 통해 정보를 유출하는 취약점 → 부적절한 인가 - 중요한 보안관련 자원의 읽기/수정 권한을 의도하지 않게 허가하여, 권한없는 사용자가 사용할 수 있는 취약점 → 중요자원에 대한 잘못된 권한 설정 나. 요구사항 1. 중요자원에 대한 접근통제 정책을 수립 2. 중요기능에 대한 접근통제 정책을 수립 3. 관리자 페이지에 대한 접근통제 정책을 수립 다. 요구사항 별 고려사항 1. 중요자원에 대한 접근..