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

156

1

부

정찰

은 수준의 견고함을 지녀야 한다.

직접 개발한 알고리즘을

SHA

-

3

의 개발을 위해

NIST

같은 기관에서 수행한 것과 같은 수준으

로 테스트하려면 수백억 원이 들 것이다. 그러나

OpenJDK

(

https

://

github

.

com

/

openjdk

)

같은 소스로부터

SHA

-

3

를 사용하면 한 푼도 들이지 않으면서

NIST

와 커뮤니티가 테스트한

결과물을 모두 이용할 수 있다.

개발자가 해싱 알고리즘을 직접 개발해서 그와 같은 표준을 준수하고 검증받는 것은 불가능하

며 조직의 중요 데이터가 해커의 손쉬운 타깃이 되는 결과를 초래한다.

그러면 어떤 기능이나 도구를 직접 개발해도 되는가? 일반적으로 안전한 아키텍처를 따르는

애플리케이션은 순수하게 기능에 관련된 부분만 재발명한다. 댓글 저장이나 알림 시스템의 스

키마를 재발명하는 것이 이에 해당한다.

수학, 운영체제, 하드웨어와 관련해 깊은 전문성이 필요한 기능은 웹 애플리케이션 개발자가

손대지 않는 것이 좋을 것이다. 데이터베이스, 프로세스 격리, 메모리 관리의 대부분도 마찬가

지다.

모든 분야의 전문가가 될 수는 없는 일이다. 훌륭한 웹 애플리케이션 개발자는 이 점을 이해하

여 자신의 전문 분야에 해당하는 것을 개발하는 데 집중하고 그 외의 분야에 대해서는 다른 전

문가의 도움을 요청한다. 반대로 나쁜 개발자는 미션 크리티컬한 기능을 스스로 재발명하려고

시도하는 일이 비일비재하다!

커스텀 데이터베이스, 커스텀 암호화, 특수한 하드웨어 수준의 최적화가 많은 애플리케이션은

해킹 당하기 ...