Become a Good Analyst

계정명 노출은 패스워드 정보탈취를 위한 가장 큰 정보를 제공하는 취약점입니다. 관리자나 테스트 계정처럼 예측이 어려운 일반 사용자 또는 특정인의 계정정보를 탈취하기 위해서는 우선 계정명을 정확히 알고 있어야 합니다. 그런 상황에서 여러 페이지에서 사용자를 나타낼 수 있는 정보로 계정명을 노출하는 경우가 있는데, 공격자는 이렇게 노출된 타 사용자의 계정명을 획득할 수 있고, 이 정보를 바탕으로 패스워드를 탈취하기 위한 공격을 시도할 것입니다. 이러한 계정정보 탈취를 방지하기 위한 가장 첫번째 단계인 정보제공을 방지하기 위해 계정명이 노출되는지 여부를 검증해줘야 합니다. 계정명 정보 노출 케이스는 아래와 같습니다. 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. 데이터 저..

웹 해킹 중 정말 간단한 공격이면서도 치명적인 공격이 몇가지 있는데요, 그 중에서 SQL Injection에 대해 이야기 해보겠습니다. SQL Injection은 입력값이 쿼리에 동적적용 시 개발자가 의도하지 않는 쿼리로 변조가 되는 취약점이죠. SQL Injection을 방지하기 위해 가장 좋은 방법은 필터링보다는 입력값을 파라미터화 시켜 바인드 처리하여 입력값이 쿼리로 인식되지 않도록 하는 것입니다. 하지만 이 과정에서도 개발자 분들이 실수를 하는 경우가 있습니다.대표적인 사례가 아래와 같습니다. 01. 동적쿼리 사용 시 입력값 검증 02. 잘못된 PreparedStatement 사용 이 밖에도 여러 케이스가 존재하겠지만, 위 내용에 대해 간단히 이야기 해보겠습니다. 01. 동적쿼리 사용 시 입력값 ..

웹해킹을 진행하면 가장 먼저 소개하는 취약점이 XSS인 것 같습니다.XSS는 기본적으로 입력값과 출력값을 검증하지 않아서 악성코드가 삽입되거나, 인증정보가 탈취되는 취약점이죠. 그 과정이 어떻게 되느냐에 따라 Stored인지 Reflected인지 등으로 구분이 되는 것일 뿐 개인적으로 크게 중요하지는 않아 보입니다. 오히려 중요한 점은 개발자가 검증하는 값이 사용자로부터 직접 입력받는 값에 대해서만 검증한다는 점일 것 같습니다. 입력값이 사용자 기준이 아니라 웹서버 기준으로 입력되는 모든 데이터를 검증하는 것이 가장 중요하기 때문이죠. 이와 관련된 일부 케이스는 아래와 같습니다. 01. 일반적인 파라미터를 통해 전달받은 입력값의 검증02. 일부 입력값의 검증 예외처리03. 일부 입력값을 가져오는 함수에 ..