OWASP의 Top 1~5는
1위. Broken Access Control(취약한 접근 제어: 권한/인가),
2위. Cryptographic Failures(암호화 실패),
3위. Injection(인젝션),
4위. Insecure Design(안전하지 않은 설계),
5위. Security Misconfiguration(보안 설정 오류) 등이 있습니다.
아래는 해당 취약점들에 대한 대응 방안입니다.
1위. Broken Access Control(취약한 접근 제어: 권한/인가) 대응 방안
우선 CORS 설정을 허락한 url만 접근할 수 있도록부터 하여야 하며, 해커가 api 호출할 때 파라미터를 조작하여 호출하는 경우를 대비하여 사용자가 로그인하여 인가된 토큰을 가지게 하여 인가된 토큰을 가지고 있는 해당 유저의 정보만 접근할 수 있도록 조치해야 합니다.
공통적으로 호출하는 정보는 제외하고 전체적으로 접근 제한을 설정해 주면 됩니다.
2위. Cryptographic Failures(암호화 실패) 대응 방안
프로젝트에 사용하는 각종 암호화 패키지나 라이브러리는 항상 최신 버전으로 사용하고 수시로 업데이트해주어야 합니다. 또한 HTTP를 강제로 HTTPS로 리다이렉트 하도록 설정하고 FTP 같은 경우 SFTP로 사용할 수 있도록 하여야 합니다.
인증서 같은 경우는 출처가 반드시 신뢰할 수 있는 곳이어야 합니다.
3위. Injection(인젝션) 대응 방안
사용자 입력이 개발자가 의도한 값인지 입력값을 정규식 등 사용하여 검증하도록 합니다. 저장 프로시저를 사용하여 Query에 미리 형식을 지정하고 지정된 형식의 데이터가 아니면 Query 가 실행되지 않게 합니다.
또한 prepared Statement 와 바인딩 변수를 이용하여 문법적으로 악용되지 않도록 하면 됩니다.
4위. Insecure Design(안전하지 않은 설계) 대응 방안
설계 단계에서부터 보안성을 고려합니다. 시작부터 보안의 3대 원칙인 기밀성, 무결성, 가용성에 관한 보안 요구사항을 포함하여 시스템에서의 모든 데이터 정보와 로직을 보호할 수 있도록 합니다. 또한 물리적으로도 서버, 서버실, 데이터 센터.. 등 인가되지 않은 사람이 접근하지 못하도록 합니다.
보안에 대한 안내서와 교육 자료를 통해 개발과 관련된 직원들 모두 보안에 대해 인지하도록 합니다. 기본적으로 많이 알려진 해킹 방법으로 테스트해 보고 막을 수 있도록 방법론을 적용합니다. 보안 전문가 혹은 보안 담당자를 지정하여 전체 프로젝트 전반에 걸친 검사 및 인증을 진행합니다.
5위. Security Misconfiguration(보안 설정 오류) 대응 방안
빠르게 정신없이 개발할 때는 온갖 불필요한 위험 기능, 샘플, 문서 등을 만들고 사용하곤 합니다. 따라서 서비스 런칭 전에는 불필요한 코드, 문서, 포트, 페이지, 계정/권한 등 모두 제거합니다. 모든 관리자 아이디와 패스워드는 변경하여 사용합니다. 에러 페이지에 에러 정보가 노출되지 않도록 합니다. 기본적으로 보안 헤더를 설정합니다. 소프트웨어는 웬만하면 최신 버전으로 유지합니다.
