인증은 애플리케이션이 이를 이용하려는 사람을 식별하는 프로세스를 말한다.
애플리케이션에서 익명 액세스를 지원하는 프로세스도 있지만 대부분의 프로세스는 식별된 사용자만 데이터를 이용하거나 특정 작업을 수행할 수 있다.
따라서 해당 애플리케이션에 인증된 사용자인지 확인하는 프로세스이다.
권한부여는 인증된 사용자가 특정 기능과 데이터에 대한 이용 권리가 있는지 확인하는 프로세스다.
예를 들어 url에 대해서는 인증된 사용자만 접근 가능하도록 설정을 해두지만 이후 데이터에는 모두 접근 가능하도록 설계하는 것은 나쁜 예이다.
따라서 인증된 사용자일지라도 권한에 따라 접근가능한 데이터, 기능이 구분되어야 한다.
웹 애플리케이션이 인증 프로세스 중에 고유한 세션 ID를 할당하지 않아 기존 세션 ID가 재사용될 가능성이 있을때 발생하는 취약성이다.
서버에 노출된 웹 서비스로 클라이언트쪽 스크립트를 주입해 다른 사용자가 이를 실행하도록 하는 공격이다. 예를 들어 게시물에 악성 스크립트가 존재하는 경우 다른 사용자가 해당 게시물에 접근하면 자동으로 스크립트가 실행되어 애플리케이션에 요청을 보내는 경우를 말한다.
애플리케이션에서 특정 작업을 호출하는 URL을 추출해 해당 애플리케이션 외부에서 재사용할 수 있다고 가정한다. 이럴 경우 서버가 해당 요청의 출처를 확인하지 않고 실행하면 시스템 외부에서 해당 시스템으로 접근이 가능하며 해당 시스템이 원치 않는 동작을 실행할 수 있다.
주입은 시스템에 특정 데이터를 유입하는 취약성을 말한다. 정상적인 방법외로 데이터를 주입하여 시스템에 피해를 주고 원치 않는 방법으로 데이터를 변경하거나 접근하는 것을 말한다.
서버에서 필요한 개인키 또는 데이터소스 같은 부분들이 .properties 또는 .yml 파일과 같은 구성 파일에 설정해서 소스에 접근 가능한 모든사람이 확인할 수 있는 경우가 있다. 이러한 정보는 볼 수 없어야 하고 적어도 운영 환경에서는 소수의 사람만 이러한 데이터에 접근이 가능해야한다.
로그를 기록할때도 주의해야 한다. 프로젝트에 종속성을 알 수 있는 로그나 IP주소와 같은 서버에 구성 정보를 로그로 남겨서는 안된다.
http 응답 값으로 예외메시지를 전송하는 경우에 회원 정보를 잘 못 입력했다면 '아이디가 잘못되었습니다.' 또는 '비밀번호가 올바르지 않습니다.' 와 같이 구체적인 예외 내용이 아닌 '아이디 또는 비밀번호가 올바르지 않습니다.' 와 같이 정확한 상황을 추측할 수 없는 예외 메시지를 보내줘야한다.
주로 구현하는 스프링 MVC 패턴에서는 controller, service, repository 와 같은 3개의 단계로 이루어지는데 controller에만 접근에 제한을 두면 실제로 데이터를 다루는 repository는 해당 요청에 대한 권한 체크를 하지 않고 데이터를 변화 시킨다. 따라서 애플리케이션 모든 계층에 권한 제한을 두어야 한다.
우리는 개발할때 라이브러리나 프레임워크를 굉장히 많이 사용한다. 하지만 이러한 도구들도 완벽한 것이 아니기에 언제든 취약점이 발견될 수 있다. 따라서 사용하는 도구들의 버전과 취약점이 있는지 여부는 늘 주의를 가지며 사용 해야한다.