가. 취약점 개요 - 악의적인 스크립트를 포함하여 웹페이지를 열람하는 접속자의 권한으로 부적절한 스크립트를 실행하여 정보유출 등을 유도하는 취약점 → 크로스 사이트 스크립트 Reflected - 서버에 악의적인 스크립트를 포함한 정보를 저장 후 해당 정보를 조회하는 접속자의 권한으로 부적절한 스크립트를 실행하여 정보유출 등을 유도하는 취약점 → 크로스 사이트 스크립트 Stored 나. 요구사항 1. 사용자 입력값을 동적으로 응답페이지에 사용할 경우, XSS 필터링 수행 후 사용 2. DB조회 결과를 동적으로 응답페이지에 사용할 경우, XSS 필터링 수행 후 사용 다. 요구사항 별 고려사항 1. 사용자 입력값을 동적으로 응답페이지에 사용할 경우, XSS 필터링 수행 후 사용 - 필터를 이용한 입력값 검증 ..
가. 취약점 개요 - 시스템이 보호하는 자원에 임의로 접근하여 자원의 수정, 삭제, 정보노출, 시스템 충돌 등을 통해 권한획득, 설정파일 변경, 시스템 장애 등을 유발하는 취약점 → 경로조작 및 자원삽입 - 입력값에 의해 의도하지 않은 시스템 명령어를 실행하여 권한변경하거나 시스템 동작에 영향을 미치는 취약점 → 운영체제 명령어 삽입 나. 요구사항 1. 허가되지 않은 시스템자원이 사용되지 않도록 방지 2. 악의적인 명령어가 실행되지 않도록 방지 다. 요구사항 별 고려사항 1. 허가되지 않은 시스템자원이 사용되지 않도록 방지 - 입력값으로 리소스를 결정하는데 직접적으로 사용되지 않도록 설계 - 리소스 목록은 프로퍼티 또는 XML파일로 정의 - 경로조작을 일으킬 수 있는 특수기호( .., \, / ) 필터링..
가. 취약점 개요 - LDAP인증서버에 인증요청에 사용되는 입력값을 검증하지 않아, 쿼리문 구조를 변조하여 공격자가 의도하는 LDAP 조회가 수행되는 취약점 → LDAP삽입 나. 요구사항 1. 외부입력값에 LDAP삽입 취약점이 없도록 필터링해서 사용 다. 요구사항 별 고려사항 1. 외부입력값에 LDAP삽입 취약점이 없도록 필터링해서 사용 - LDAP 조회로 인식 가능한 특수문자 ( =, +, , #, ;, \ 등 ) 필터링 라. 요구사항 별 진단기준 및 방법 0. 공통내용 - 요구사항 정의서에 보안요구항목에 대한 대책이 수립 - 아키텍쳐 설계서에 보안요구항목 적용계획이 수립 - 요구사항 추적표를 통해 요구사항 추적가능 여부 1. 외부입력값에 LDAP삽입 취약점이 없도록 필터링해서 사용 - 입력값에 필터링..
가. 취약점 개요 - 입력값 조작을 통해 XQuery나 XPath의 쿼리문 구조를 변경하여 허가받지 않은 데이터를 조회하거나 인증절차를 우회하는 취약점 → XQuery 삽입 → XPath 삽입 나. 요구사항 1. XML쿼리에 사용되는 파라미터는 반드시 필터링하여 사용하거나 자료형에 따라 바인딩해서 사용 다. 요구사항 별 고려사항 1. XML쿼리에 사용되는 파라미터는 반드시 필터링하여 사용하거나 자료형에 따라 바인딩해서 사용 - Validator 컴포넌트를 통해 입력값 검증작업이 일괄적용되도록 설계 - 필터를 통해 특수기호 ( ", [, ], /, =, @ ) 필터링하도록 설계 - 각각의 컴포넌트에서 특수기호 ( ", [, ], /, =, @ ) 필터링하도록 설계 라. 요구사항 별 진단기준 및 방법 0. ..
가. 취약점 개요 - SQL문을 삽입하여 DB로부터 정보를 열람하거나 조작할 수 있는 취약점 → SQL삽입 나. 요구사항 1. 최소권한의 계정사용 2. 동적 SQL문을 생성 및 사용하지 않음 3. 동적 SQL 사용 시 입력값 검증 다. 요구사항 별 고려사항 1. 최소 권한의 계정사용 - 침해사고가 발생하더라도 다른 애플리케이션에 대해 공격자가 액세스 권한을 가지지 않도록 방지 2. 동적 SQL문을 생성 및 사용하지 않음 - ORM프레임워크를 사용하여 안전한 정적쿼리구조의 SQL문을 수행 - 외부입력값에 의해 쿼리문의 구조가 변경되지 않도록 입력값을 바인딩 처리 3. 동적 SQL 사용 시 입력값 검증 - 서블릿 필터를 이용한 입력값 검증 - 인터셉트를 이용한 입력값 검증 - 라이브러리 또는 Validato..
계정명 노출은 패스워드 정보탈취를 위한 가장 큰 정보를 제공하는 취약점입니다. 관리자나 테스트 계정처럼 예측이 어려운 일반 사용자 또는 특정인의 계정정보를 탈취하기 위해서는 우선 계정명을 정확히 알고 있어야 합니다. 그런 상황에서 여러 페이지에서 사용자를 나타낼 수 있는 정보로 계정명을 노출하는 경우가 있는데, 공격자는 이렇게 노출된 타 사용자의 계정명을 획득할 수 있고, 이 정보를 바탕으로 패스워드를 탈취하기 위한 공격을 시도할 것입니다. 이러한 계정정보 탈취를 방지하기 위한 가장 첫번째 단계인 정보제공을 방지하기 위해 계정명이 노출되는지 여부를 검증해줘야 합니다. 계정명 정보 노출 케이스는 아래와 같습니다. 01. 마스킹없이 계정명 노출 02. 응답값 내 계정명 노출 03. URI 내 계정명 노출 0..
이번에 이야기할 취약점은 인증실패 횟수제한에 대한 내용입니다. 실제 인증실패 횟수 자체가 취약점이 되진 않지만, Fuzzing 프로그램을 이용한 공격 등을 방지하기 위해 인증에 대해 횟수를 제한하는 안전한 코딩에 대한 내용이 될 것입니다. 특히 행안부 기준으로 반드시 확인해야하는 내용이며, 이 부분은 실제 소스코드 자동화 툴을 이용한 진단은 불가능하여, 소스코드를 수동으로 분석하거나, 동적진단을 통해 발견해야 하는 취약점이죠. 인증실패 횟수와 관련된 케이스는 아래와 같습니다. 01. 로그인 인증실패 횟수제한 부재 02. 비회원 인증실패 횟수제한 부재 03. 2차 패스워드 검증실패 횟수제한 부재 04. 2-Factor 인증실패 횟수제한 부재 05. 패스워드 변경실패 횟수제한 부재 06. 인증값 인증실패 횟..
이번에 이야기할 취약점은 패스워드와 관련된 취약점입니다. 특히 개인정보보호법 등에서 패스워드에 대한 내용이 언급이 되고 있어 컴플라이언스 및 정책적인 측면에서 확인을 해줘야 하기 때문에 패스워드 관련 취약점은 생각보다 다양한 케이스가 존재합니다. 패스워드와 관련된 다양한 케이스는 아래와 같습니다. 01. 패스워드 정책 검증02. 2차 패스워드 정책 검증03. 패스워드 대/소문자 구분부재04. 패스워드 초기화 정책 미흡05. 잘못 입력한 패스워드 출력 06. 응답값 내 패스워드 노출07. 패스워드 저장 시 암호화08. 패스워드 로그기록 이 밖에도 다양한 케이스들이 존재할 수 있습니다. 01. 패스워드 정책 검증보통 공격자는 자주 사용하는 계정명 또는 응답값에 노출된 계정명에 대해 Fuzzing 프로그램을 ..
이전에 작성한 업로드 취약점과 형제격으로 함께 이야기하는 취약점이 다운로드 취약점입니다. 만약 다운로드 취약점이 발생한다면 소스코드를 다운로드하여 서비스의 취약점을 쉽게 분석을 할 수 있고, 중요파일을 다운로드하여 익스플로잇 등에 이용도 가능하죠. 그동안 만나본 다운로드 취약점은 사실 케이스가 다양하지는 않았습니다. 업로드와는 다르게 다운로드 로직은 매우 명확하기 때문이죠. 01. 파일명 및 파일경로 검증02. 다운로드 파일에 대한 권한검증03. 웹서버 설정미흡에 따른 중요파일 다운로드 제가 만나보지 못한 다양한 케이스가 있을 수 있으니 이점 참고 부탁드립니다. 01. 파일명 및 파일경로 검증다운로드 취약점의 대부분이 이 내용에 해당될 것입니다. 서버 외부로부터 전달받은 다운로드 하려는 파일의 파일명 또..
웹해킹 중 간단하지만 발생했을 때 매우 위험한 취약점 중 하나로 업로드 취약점이 있습니다. 사실상 웹쉘이 업로드만 된다면 서버가 탈취된 것과 동일하기 때문이죠. 다행스럽게도 웹쉘 업로드를 방지하는 방법은 매우 간단합니다. 웹쉘 업로드를 방지하기 위해서는 서버에 업로드를 허용할 확장자를 선정한 뒤 업로드 하려는 파일의 확장자를 대/소문자 구분없이 검증해야 합니다. 여기에 Null Injection 등을 통해 확장자 검증을 우회할 수 있기 때문에 전달받은 파일명에 공백과 널 바이트를 삭제해줘야 합니다. 이밖에도 업로드 취약점과 관련하여 추가로 확인해야 하는 내용들이 아래와 같습니다. 01. 상대경로/절대경로 포함 여부 02. 업로드 허용 경로검증03. 응답값 내 파일명 및 파일경로 노출 여부04. 데이터 저..
- Total
- Today
- Yesterday