본문 바로가기

1인개발자

<1인개발자로 살아남기>37일차 : 보안 고민

반응형

어제 개인정보처리방침에 대해서 고민하고 나서...

덜컥 보안에 대한 걱정이 들기 시작했다.

내가 수집하는 것은 1. 각 판매자의 상품과 2. 회원가입을 하는 회원들의 개인정보.

최대한 SNS 로그인으로 모든 것을 해결해보려고 하였지만, 이메일은 꼭 좀 받아야 했기에... 

 

그래서 구글에 검색을 해보고 했지만 시원하게 긁어주는 글이 없었다.

관련 강의가 있을까 하고 인프런에 검색했더니 무료강의가 하나 있어 들었고 아래는 그것의 정리내용.

 

처음 시작하시는 분이라면 꼭 수강을 권합니다 !

좋은 내용 알려주셔서 감사합니다.

 

강의

https://www.inflearn.com/course/%EC%9B%B9-%EA%B0%9C%EB%B0%9C%EC%9E%90-%EC%95%8C%EC%95%84%EC%95%BC-%ED%95%A0-%EB%B3%B4%EC%95%88-%EA%B8%B0%EC%B4%88/dashboard

 

[지금 무료] 웹 개발자라면 꼭 알아야 할 보안 기초 강의 - 인프런

정보 보안은 어렵고, 너무 전문적인 내용이라고요? 아니요. 지금 당장 안전한 웹을 만들어 갈 수 있는 정보 보안 기초를 시작해 보세요!, 배워서 바로 써먹는정보 보안 기초 🖥️ 웹 개발자 필수

www.inflearn.com

 

아래는 강의 내용입니다.


관련기관

OWASP 

OWASP 오픈소스 웹 어플리케이션 보안 프로젝트

시큐어코드 작성 가이드라인을 발표.

OWASP_SCP_Quick_Reference_Guide.ko-KR.pdf

한국데이터진흥원

시큐어코드 작성 가이드라인을 발표

보안이란

보안이란

  1. 무결성 : 권한을 가진 사람만 정해진 방법으로 정보를 변경할 수 있어야 한다.
  2. 기밀성 : 권한을 가진 사람만 접근가능해야한다.

가용성 : 접근해야할 때 접근할 수 있어야 한다.

섹션1 : 보안 공격

나의 서비스는 안전한가?

ZAP이라는 프로그램을 통해 1차적으로 검증할 수 있다.

https://www.zaproxy.org/download/

섹션2 : 암호의 세계

해시함수 - 안전하게 비밀번호 저장하기

해시함수는 암호화만 가능하고 복호화가 불가능하도록 설계되어 있다. 이를 통해 단순 매칭만 확인하면 되는 경우, 그 내용을 해쉬함수를 통해 암호화해서 보관하면은 암호문을 평문으로 바꿀 수 없어서 안전하다.

웹&공동인증서 안에 비대칭키 암호

HTTPS로 배포하기 위해서는 인증서를 발급받아야 하는데 이것은 비용이 든다.

일부 배포서비스 들은 (VERCEL 등) HTTPS 배포를 가능하게 해준다.

섹션3 : 시큐어코드

안전하게 외부 모듈 사용하기

  1. 사람들이 많이 사용하는 안전한 라이브러리 사용하기
  2. 라이브러리를 안전하게 사용하기 (보안목적으로 사용하는 법에 대해 작성되어 있으니 문서를 잘 읽어보라)
  3. 개발환경과 프로덕션 환경을 분리하기
    1. 디버거를 끄는 것 뿐만아니라,
    2. 플라스크 내부 서버가 아니라 NGINX, APACHE와 같은 전문 서버를 사용해야 한다.

사용자에게서 서버를 숨기기

  1. HEADER내용 숨기기 (어떻게 하는건데?)
  2. 관리자페이지 숨기기 (Admin페이지에 접근xx url어렵게 해라)
    1. 라우터 쓸 때 ‘/customer’ 이런거 붙여서 폴더구조를 모르게 한다던가.
    2. 에러핸들링 하지 않기

안전하게 인증 과정을 거치게 하기.

  1. 한 번 로그인하면 그 뒤에 나오는 모든 라우팅에 대해서 인증을 한 상태라고 생각하는 것이 아니라,
  2. 인증이 필요한 페이지에서는 다시 비밀번호를 쳐서 인증을 하도록 해야 한다.
  3. 필요한 값들이 다 수집되었는지 먼저 확인하고 입력값들의 유효성 검사를 한 후에 일치여부를 확인
  4. sql등에서는 인젝션에 주의
  5. csrf 토큰을 이용해서 사용자가 인증 과정에 직접 들어왔는지를 확인하는 것도 중요.

외부데이터 격리하기

  1. 파일경로와 파일명등에 대해서 노출하지 않기
  2. 클라이언트가 보내는 모든 입력에 대해서 문자열 이상의 기능을 수행하지 않도록 처리하기.

블랙리스트보다는 화이트리스트

  1. 블랙리스트를 걸러내는 것이 아니라, 안전한 것만 통과시키고 나머지는 다 걸러낸 다는 생각을 가지기.
  2. 화이트리스트 생성을 위해 정규표현식 (사용될 수 있는 문자열을 미리 정의한다.) 을 활용할 수 있다.

운영체제는 직접 건드리지 않기.

  1. shell을 이용해서 직접 커맨드 입력하는 것 자체를 막으라는 이야기
  2. api는 그러한 공격들에 대해 대비하는 장치들이 있지만 커맨드라인은 그런 방어책을 보유하고 있지 않기 검새때문.

검색엔진으로부터 서버를 숨기기

  1. 검색엔진으로부터 숨기고 싶은 페이지가 있는 경우에는 robot.txt를 작성한다.
  2. robot.txt는 검색엔진이 크롤링 할 수 있는 페이지와 그렇지 않은 페이지를 명시한다.
  3. 그리고 검색엔진으로부터 숨겨야하는 경로라는건, 당연히 검색엔진으로 인해서 전체 url이 노출되는 것을 방지하기 위해서이다.
  4. 허용하는 디렉토리를 모아놓고 나머지는 전부 검색을 막으면 화이트리스트방식의 robots.txt이다.

개인정보의 수집

  1. 필요없는 개인정보는 받지 말고 받았더라도 필요가 없다면 삭제해야 한다.
  2. 수집된 개인정보는 검증된 서버에 저장되어야 한다.
  3. 단순 비교 목적이라면 해쉬등으로 암호화해야 한다.
  4. 평문을 알고 있어야 하더라도 aes 등으로 암호화하는게 좋다.

사회공학

  1. 주기적으로 비밀번호를 변경하라는 알림 발송한다.

사이트

who.is : DNS 관련

KRCERT : 정보가 많다.


결론 : 해야하는 것.

  1. 미들웨어에 앞부분 도메인 추가해서 폴더 디렉토리 최대한 숨기기
  2. robot.txt 추가해서 엔진으로부터 디렉토리 최대한 숨기기
  3. 인젝션 방지하기 위해서 stringfy하기 (join이라든가)
  4. 임의 코드 실행을 방지하기 위해서 stringfy하기 (<script>라던가)
  5. 임의 코드 실행 방지를 위해서 운영체제 커맨드라인 사용하지 않기.
  6. ZAP 파일 이용해서 1차적으로 모의공격 시도해보기
  7. .env 파일 등을 이용해서 소스코드에 중요정보 보관하지 않기
  8. 개발환경과 배포환경을 구분하여 디버깅 기능을 종료시키기.
  9. 수집하는 정보를 최소화하고, 수집한 정보 중 단순 매칭 점검만 필요한 경우에는 해쉬암호화하여 보관하기.
  10. 사회공학적으로 주기적 비밀번호 변경을 제안하는 편지발송하기.
  11. 시도하는 보안 작업들은 화이트리스트 방식으로 진행하기
  12. 개인정보에 접근해야하는 페이지는 로그인했더라도 다시 한 번 인증을 요구하기
  13. 모듈 사용 전에 문서읽고 보안적으로 문제가 없는지 점검후에 올바른 방식으로 모듈사용하기.
  14. 내가 이용하는 배포서비스가 https로 배포하는지 점검하기.
  • 많이 배웠다.

 

 

반응형