🖥️ 프론트엔드 개발자로써 보안의 중요성?

제가 생각하는 프론트엔드 개발자로써의 보안이라는것은 사용자(USER)가 어떠한 것을 입력했을때 해당 데이터를 안전하게 서버에 전송하고(request) 서버에서 요청에 해당하는값을(response) 받아오는것이 가장 중요하다고 생각합니다.

또한 프론트엔드로써의 개발보안 개념에서는 여러가지 개념들이 존재하고 결국 사용자 인터페이스와 상호작용하는 부분에 대한 보안을 강화하는것을 의미합니다. 다양한 보안 위협과 취약점을 방지하고 악의적인 공격으로부터 사용자 데이터와 시스템을 보호하기 위해 다양한 개념과 기술을 적용합니다.또한 KISA 한국인터넷진흥원에 나와있는 보안취약점 및 침해사고 대응에 대한 가이드 라인이 공개되어있습니다. 저처럼 개발자의 첫 단계를 밟아가는 분들에게 개발보안 가이드와 JavaScript,Python과 같은 시큐어 코딩 가이드라인이 있고, 약점진단,검증,보안취약점 점검 가이드라인에 대한 문서가 있으니 꼭 참고하시길 바랍니다.

📎 프로젝트를 진행하면서 예외처리에 대한 느낀점

🟢 사용자에 대한 예외처리

• 유효성 검사: 사용자로부터 입력에 대해 유효성을 검사하여 잘못된 입력을 방지하고 처리합니다. 예를 들어, 필수 필드의 누락, 유효하지 않은 데이터 형식 등을 확인하고 사용자에게 적절한 오류 메시지를 제공합니다.

• 에러 핸들링: 사용자의 요청에 대한 처리 중 발생하는 예외를 적절하게 처리합니다. 이는 사용자에게 예측 가능하고 이해하기 쉬운 오류 메시지를 제공하여 사용자 경험을 개선합니다.

  예를 들어
  ⚠️ 게시글 작성이나 댓글작성에서 회원아이디가 변조되면?
  댓글 작성으로 보면 해당하는 게시글ID,회원ID,댓글 내용이 기본적으로 필요하다. 여기서 기본적으로 프론트에서 생각할만한 예외처리는 무엇인가? 프론트엔드가 생각할 가장 기본적인 예외처리는 댓글이 비어있는지 확인하거나 글자수 제한이다 하지만 이것만으론 부족하다
  memberId 가 3101 과 3458 인 회원이 있다고 가정해봅시다.

{
 "boardId":3577,
 "memberId":"3101",
 "content":"댓글작성ㅇㅇ"
}

댓글 작성에서 나는 memberId=3101를 가지고 있다. 이 응답처리(response)부분을 중간에 가로채는(SQL Injection)으로 memberId 를 중간에 3458로 변조시키면?

이런식으로 memberId가 3101,3458인 댓글이 2개가 작성이 되어버렸다. 이 인젝션 방식으로 게시글/댓글은 물론 로그인에서 회원정보도 빼올수 있는 상황이다. 그렇다면 위의 상황을 대처할 방법은 무엇일까?
방법은 여러가지이다. 여기서 대표적으로 생각해보면 보통 웹사이트의 로그인서비스는 JWT방식으로 사용한다.
JWT 로그인을 사용하면 액세스토큰과,리프래시토큰이 클라이언트,서버에서 기본적으로 소유하고있을것이다. 이것을 기반으로 POST요청을 보낼때 액세스토큰과 맴버아이디가 서버에 있는 데이터와 같지 않을경우 예외처리를 해주는 것이다. 이밖에도 JSESSIONID 와같은 고유번호와 회원아이디를 확인하는 검증 방식도 있다.

🧐 내가 처리한 로그인 방식은 안전할까?
우리가 생각하는 로그인할때 기본적으로 가지고 있는 예외처리는 무엇일까?
그렇다 주로 아이디/패스워드가 일치하지 않을때이다. 여기서 추가로 생각할수 있는것은 한개의 아이디가 연속적으로 비밀번호를 틀렸을때 해당 계정을 비활성화시키는 경우이다. 그러면 왜 비활성화를 시키는 것일까? 예시를 들기위해 Burp Suite라고 불리는 웹 애플리케이션 보안 테스트 도구를 사용할 예정이다.
이해를 돕기위해 프로젝트의 로컬서버를 이용했다.

⛔️함부로 다른 웹사이트에서 사용하지마세요!

보이는것처럼 POST('/members/login')요청을 보내고 request는 id가 dummyTest1이고 비밀번호는 설정한값이 될것입니다.

리스트에 있는 값들을 password에 자동으로 입력하는 방식입니다. 직접 패스워드를 등록할수있고 또한 패스워드 모음.txt같은 것들을 이용하여 불러오는 방식또한 가능합니다.

대입 결과가 나왔습니다. 유일하게 Status code가 200이고 Length가 755인 결과값이 나왔습니다. 그렇습니다. 5번요청인 Test123! 가 바로 비밀번호인 것입니다. 로그인에 성공하였으니 요청값이 200으로 나오고 로그인 성공문구 또한 틀리니 길이(Length)가 실패한 값들과 다른것입니다. 이처럼 자동으로 패스워드를 대입하는 공격으로 인해 해킹이 되어버린것입니다. 또한 한개의 계정이 연속적으로 실패했을때 계정을 차단하거나 비활성화 시키지 않으니 손쉽게 자동으로 비밀번호를 대입할 수 있었습니다. 추가적으로 아이디,비밀번호 전부 자동으로 대입할 수 있으니, 한개의 아이피에서 여러요청이 들어오면 캡챠(CAPTCHA)를 이용해서 실제 사용자인지 확인을 하면 더 좋은 보안방지가 될 것입니다.