웹 애플리케이션 보안: 정찰, 공격, 방어 세 단계로 배우는 웹 애플리케이션 보안의 모든 것

298

3

부

방어

취약점을 제대로 수정하는 것은 올바로 찾아서 분류하는 것만큼 중요하다. 취약점은 가능하면

영구적으로 해결해야 하며 애플리케이션 차원의 솔루션이어야 한다. 취약점을 그러한 방식으

로 해결하는 것이 곤란한 경우 임시 픽스를 추가할 수는 있지만 애플리케이션에 취약한 표면이

있는 한 새로운 버그가 발생할 수 있다.

남겨진 픽스를 상세히 알리는 다른 버그가 올바른 점수를 갖고 먼저 오픈된 경우가 아니라면

절대로 부분적인 픽스를 내놓고 버그를 종결지어서는 안 된다. 버그를 성급히 종결하는 것은

재현 시간과 기술적 이해를 잃는 결과를 가져온다. 게다가 모든 취약점이 보고되지 않을 것이

다. 또한 애플리케이션이 더 많은 기능을 노출해 (표면이 증가하여) 취약점으로 인한 위험을

키우게 될 수 있다.

끝으로 종결된 보안 버그는 회귀 테스트를 포함해야 한다. 회귀 테스트의 중요성은 시간이 갈

수록 커진다. 코드베이스의 크기와 기능 집합이 커짐에 따라 재발 가능성도 급격히 증가하기

때문이다.

21.6

마치며

취약점 관리는 매우 중요하고 구체적인 작업이 조합된 것이다.

먼저 엔지니어가 취약점을 재현하고 문서화해야 한다. 그래야 조직에서는 보고서가 유효하다

는 확신을 가질 수 있으며 처음 보고된 것보다 더 큰 영향이 있는지 이해할 수 있다. 또한 취약

점을 해결하는 데 얼마만큼의 노력이 필요한지 가늠할 수 있다.

다음으로 취약점으로 애플리케이션이 노출되는 위험을 판단하는 채점 시스템에 따라 취약점의

점수를 매겨야 한다. 비즈니스 모델과 어울리고 익스플로잇이 ...