[보안] Javascript 보안에 대해서 (+추천 사이트)

뭔가 프론트엔드 개발을 하면서 

보안에 대해 크게 걱정해본 적이 없는데...

 

이번 회사에서 ISMS 심사를 하느라 보안에 대해 다시 생각해보는 계기가 된 것 같다.

 

분명 보안은 백엔드에서 훨씬 많이 신경써야하는게 많지만... 

생각보다 프론트엔드에서 놓치고 있는 점도 많았다.

 

 

1. 통신구간 암호화

일단 요즘 최대 고민은 client에서 reqeust을 보낼 때 그 요청값들을 어떻게 암호화 할지다....

원래는 AES 암호화 방식을 사용했는데 

AES 암호화를 crypto.js 라이브러리를 사용했는데 iv랑 key에 값을 .env에 넣어놓고 썼다.

나는 process.env -> 즉 .env 파일에 key값을 넣어놓고 꺼내서 쓰면 개발자도구에서 노출이 안되는 줄 알았다...

아니였다. 개발자도구에 key값이 다 노출되었다.. 😩

 

그래서 백엔드와 논의한 방식이 RSA 암호화였다.

백엔드에서 공개키를 가져올 수 있는 API 를 만들어줬고, 프론트에서 공개키를 호출해 저장해 놓고 공개키로 암호화해서 요청값을 보내는 것이다. 

 

생각보다 통신구간의 요청값들을 암호화 안하는 사이트가 많았다.

 

2. 쿠키값, SameSite 문제

통신구간 암호화하면서 또 다른 문제에 직면 했다...

세션 문제이다.

바로 이 개발자도구 쿠키값에 자주 보이던 JSESSIONID 이다.

별로 이 JSESSIONID 에 대해서 크게 생각해본 적이 없었다.

 

JSESSIONID 는 알고보니 백엔드 톰캣(?)에서 주는 세션 아이디였다.

개발자 도구에 응답값 헤더에서 확인해보면 Set-Cookie하고 JSESSIONID를 보내주고 있는 것을 확인할 수 있다.

HttpOnly가 붙으면 JS로 제어할 수 없다.

 

그러면 어떻게 다시 백엔드한테 요청값에 담아서 보낼 수 있을까?

걱정할 필요가 없다 원래는 요청값에 쿠키는 전부 다 전달 된다.

 

근데 여기서 문제였다. 

우리 서비스는 백엔드 URL과 프론트엔드 URL이 각각 따로 있다.

그래서 둘이 Same Site라고 인식이 되어서 브라우저에서 쿠키값을 안보내고 있었다....

 

응답으로 받는 쿠키값을 계속 요청 헤더에 담아서 백으로 보내줘야지 백에서 같은 세션 유지 중인 것을 체크할 수 있었는데...

계속 쿠키값으로 아무것도 안보내니까 백에서는 세션값을 새로 만들어서 계속 보내줘서 세션이 끊겨서 

암호화 할 때 오류가 났다...

(결국에는 세션 말고 다른 key로 같은 사용자인지 인식하는걸로 백에서 바꿨다.😂)

 

세션에 대해서 아직 해결되지 않은 점이 많다... 

1. 쿠키에 대해서 더 공부하기

- 쿠키 속성에 대해서 (HttpOnly, Secure, SameSite 속성 등)

- 쿠키를 주고 받는 방법

2. axios의 withcredentials true 에 대해서

- 분명 백에서 allow-credentials true도 주고, 혹시 몰라 origin 설정에 프론트 URL도 집어 넣어보고 별짓을 다 했는데 안됐다.

모든 블로그랑 챗쥐피티에서 나온 방식을 썼는데... ㅠ

 

 

---

참고사이트

OWASP Foundation, the Open Source Foundation for Application Security | OWASP Foundation

 

KISA 한국인터넷진흥원

Javascript_시큐어코딩_가이드(2023년_개정본).pdf

7.06MB

 

KISA에서 제공해주는 시큐어코딩 가이드를 꼭 한번 읽어보면 좋을 것 같다.

좋은 내용이 많아서 좋았고, 백엔드에만 국한된 내용이 아니라 JS 버전으로만 나온 내용이여서 프론트엔드한테 좋을 것 같다.