400 에러의 무서움
400 에러에 대한 정의는
https://developer.mozilla.org/ko/docs/Web/HTTP/Status/400
HyperText Transfer Protocol (HTTP) 400 Bad Request 응답 상태 코드는 서버가 클라이언트 오류(예: 잘못된 요청 구문, 유효하지 않은 요청 메시지 프레이밍, 또는 변조된 요청 라우팅) 를 감지해 요청을 처리할 수 없거나, 하지 않는다는 것을 의미합니다.
이렇게, 말로는 쉽게 나옵니다.
이 400 에러의 무서운 점은 몇 가지가 있는데
400에러 자체가, 클라이언트가 서버에 요청할 때 잘못된 형식으로 요청했다는 오류임
위 1번 사항이, 판단하기에 따라 기준이 굉장히 모호해질 수 있음.
SI, SM쟁이 입장에서는 내가 접근할 수 있는 서버만 로깅 및 분석이 가능함.
그 윗단에 L4스위치와 웹방화벽이 존재할 확률이 매우매우 높음
그 윗단에서 요청을 차단해서 400 에러로 내보내는 경우도 실제로 굉장히 많음. ←- 우리쪽 서버에는 로그 한줄 남지 않음
그 윗단 책임으로 지레짐작하고 전화했다가 아니라는 게 밝혀지면 —> 엄청난 일이…
5, 6번 때문에 이도저도 못하는 사태가 벌어짐
웹방화벽에서 차단되는 이슈로 400에러 나는 경우 지금까지 5번정도 본 것 같구요
(결제모듈 같은 타사 API 연계를 써서, 타사 사이트 갔다가 리턴URL로 돌아올 때 보통 발생함)
오늘도 이것땜에 nginx 설정 확인하고
로그 띄우고 (WAS 6개 WEB 3개 전부) 재현 수십번 해보느라 시간 날렸네요.
운영서버에서만 재현이 가능한데다 지금 수강신청 몰릴 시기라 서버 하나라도 내리면 안된다고 해서, 요청 날리면 저 3개 웹서버중 랜덤한 곳으로 요청이 가니
매의 눈으로 왔다갔다하며 감시했어야 했습니다.
결국은 웹방화벽 패턴에 걸린거였고, 예외 등록해서 마무리
(이것도 내가한 게 아니라, 보안 담당자분이 차단여부 확인해주시고 예외등록해주심 이걸로 끝)
