ModSecurity 도입기 2(Trouble Shooting)

Trouble Shooting 1. Post, Update, Delete 요청 403

1. ModSecurity 전환하고 다음 날 관리자 페이지 수정 과정에서
조회를 제외한 API가 동작하지 않는 문제 발생..

어디서 많이 보던 403 에러 발생..

 

모두 403 처리가 되고 있길래 ModSecurity 관련 보안 문제일거라 바로 판단.

 

 

 

 

로그를 확인해보니, ModSecurity의 불온 요청 감지 임계값을 초과 해서 생긴 문제였음.

 

 

 

 

 

 

/api로 요청을 보내는 서버쪽 요청은 받을 수 있게끔 정규식 추가

 

 

 

 

 

 

다시 정상 동작하는 API

 

 

 

 

 

 

---

 

Trouble Shooting 2. 로그인 시 ModSecurity 감지

그리고 그 다음날..

평소처럼 로그인 후 관리자페이지에서 새로운 할인 정보를 공유하려고 했었는데..

이제는 익숙해진 403 화면

 

 

다시 403으로 ModSecurity에서 URL 보안 규칙에 의해 페이지가 처리되었다.

 

우선
1. URL길이가 JWT 토큰으로 인해 비정상적으로 김(accessToken + refreshToken 둘다 있었음)

2. JWT패턴 감지 (eyJ로 시작)

3. 특수문자 포함("." 구분자) 등

 

 

"ModSecurity씨 이 URL 어디 잡을 수 있으면 잡아봐~"
하는듯 온갖 안좋은 URL 안티패턴들을 다 포함하고 있었기 때문에

 

10초만에 납득해버렸다.

 

 

 

 

 

---

그래서 어떻게 고칠건데?

 

 

 

가장 먼저 1차적으로 떠올랐던 방법은

'ModSecurity 보안 규칙 또 바꿔버려?' 였다.

 

 

위처럼 긴 URL이 생긴 이유는 아래 이미지와 같았다.

 

전체 로그인 프로세스가 마치고,
서버에서 JWT 토큰을 만들어, 클라이언트에 전달을 해주는 방식이

sendRedirect를 통해 파라미터로 JWT토큰을 전달하는 방식을 사용하고 있었기 때문이다.

 

나는 서버에서 클라이언트로 리다이렉트를 시켜야하니

바디에 값을 넣을 수 없다고 생각하였다. (POST로 응답이 불가하고 GET으로만 응답하는 상황)

 

이런 문제를 함께 스터디하는 동료와 같이 이야기 나누었고,

응답 토큰을 쿠키에 담에 보내는게 어떻겠냐는 이야기를 들었다.

 

매우 합리적인 의견이었고 바로 채택하여 방법을 전환했다.

 

 

 

 

 

 

---

 

잠시 후

 

 

---

 

 

 

 

 

이전 파라미터에 저 토큰정보들을 담아서 불필요하게 긴 URL로 응답하던 방식을

쿠키에 담아서 처리하는방식으로 전환했고 결과는 성공적이었다.

 

 

서버측 ModSecurity 컨프 정보는 수정하지않고(보안측면은 그대로 유지)

코드단에서 해결한 케이스였다.

 

 

 

 

 

결론:




다시 ModSecurity를 활용해서 행복하게 잘 먹고 잘 살았다고 한다.

끝