[17주차] 보고서 리뷰(팁, 예상질문)

모의해킹 리뷰)

#모의해킹 수행정보

개요, 대상, 수행 기간, 인력

#모의 해킹 결과

총평에서는 강조되어지는 취약점 1-2개를 위험성 위주로 설명

#취약점 

위험한 취약점을 앞 순서로 배치. 설명과 함께 항목당 보안 권고를 이 때 함께 제시한다.

#보안 권고안

보안 가이드로 활용.

 

리뷰 시 나올 수 있는 Q&A

 

Q1 ) PHP 코드 오픈 소스 라이브러리를 써서 못 고치는데 어떻게 하나요?

이걸 처리해야 근본적인 해결이 가능하지만, 화이트 리스트 기반 필터링을 수행하는 방안이 있습니다. 그러나 필터링은 언제든지 우회가 가능해서 위험할 수 있다. 

 

1. 오픈소스 라이브러리에 취약점이 얼마나 많은지 애플리케이션의 70%가 취약한 상태.
2. 각 프로그래밍 언어나 프레임워크의 특성에 따라 취약점의 특성도 달라짐.
3. 90%의 경우 간단한 픽스 적용으로 문제 해결 가능. 픽스만 잘 해도 시큐어 코딩. 

Q2 ) 저희는 HTTP를 사용해야하는데 어떻게 하나요?

HTTPS와 같은 TLS(Transport Layer Security)를 적용해야 근본적인 해결이 가능하지만, 불가피하게 HTTP 통신을 사용해야한다면 해당 페이지에서 민감 정보를 분리해야합니다. 참고

-> 하지만 HTTPS를 못쓴다면 직접 그 데이터를 암호화해서 보내도록 개발해야하는데 그것보다 HTTPS를 사용하는게 편하기 때문에 실무에서 이 경우는 거의 없다.(0)

 

민감한 데이터 유형

• 결제 정보: 은행 계좌 번호, 신용카드 번호, 보안카드 번호
• 건강 정보: 진료기록
• 개인정보: 주민번호, 생년월일, 주소, 핸드폰 번호, 이메일 주소 등
• 계정 인증 정보: ID, 패스워드 등 

 

개인정보보호법 제23조에 명시되어 있으며 민감정보를 처리하는 경우 안전조치의무에 따라 안전성확보에 필요한 기술적, 관리적 및 물리적 조치를 하여야 하므로 암호화 처리를 해야 합니다.

 

Q3) CSRF시 대응방안도 HTML Entity사용하면 예방 가능하지 않나요?

CSRF공격이 GET방식으로 이루어져있다면 XSS없이도 CSRF가 가능하기 때문에 안된다.

 

*XSS vs CSRF
> 클라이언트 측 공격 vs 서버 측 공격
둘다 공격자체는 클라이언트 측인데 클라이언트 측에 실행 코드 vs 서버가 실행하도록 만드는 것

피해자에 컴퓨터에 코드를 삽입 vs 피해자가 원치않은 요청을 서버로 보내도록 요청
GET방식으로 공격하면  XSS를 사용하지 않고도 가능
POST시 HTML 삽입해야하기 때문에 XSS와 연계해야한다.

 

*CSRF Token 우회법
CSRF가 나오는 페이지를 iframe으로 지정하면 그 안에 토큰이 담기고 본 페이지에서 받아 CSRF 토큰을 우회할 수 있음 
교차 출처 리소스 공유라는 원리로 같은 페이지내에서만 해야한다.

*대응 방안: 예측불가능한 정보를 삽입
(예시 1회용 토큰, 이용자의 비밀번호 검증)
>> 우회가 가능할 수도 있기 때문에 중요한 기능을 사용할 시 예측불가능한 인증정보를 받는게 더 좋다. 그외는 CSRF 토큰

 

Q4) 파일 업로드 DB나 NAS등으로 예방 못할 시 다른 대응방안이 있나요?

근본적인 해결방안은 웹에서 파일을 분리해야하지만, 불가피한 상황이라면 파일 명을 File ID로 관리하거나 파일명 난수화, 혹은 실행시 파일 확장자 고정 등 다른 대응방안이 있습니다.

 

Q5) Blind SQL Injection 시 참거짓 문 POC에서 이게 어떤 위협이 되나요?

SQL문 삽입으로 lenght(pw), ascii(substring(pw, , ))등으로 원하는 정보를 참/거짓 비교를 통해 추출할 수 있어 위험성을 가집니다. if 문을 통해 구별, 가장 많이 발견될 수 있다.