[keyword] 11장 - 보안

[binchoo]

주제

'11장 - 보안'을 읽고 내용을 요약하거나, 중요✨ 하다고 생각하는 키워드 및 관련 설명을 코멘트로 달아주세요

연관 챕터

32

@caffeine-library/readers-release-everything

[kth990303]

종종 정보 유출을 일으키는 미묘한 잘못이 있다. 존재하지 않는 자원이 요청되면 서비스가 '404 찾을 수 없음' 으로 응답하지만 존재해도 승인되지 않는 자원에 대해서는 서비스가 '403 인증 필요'로 응답한다고 가정하자. 이는 서비스가 어떤 자원의 존재 유무에 관한 정보를 외부에 유출한다는 의미다. (p.311)

• 브루트포스 공격을 통해, 해당 애플리케이션 이용자 수 규모를 파악할 수 있음.
  • 그런데 방화벽 등 인프라 단에서 분당 요청 수를 파악하여 차단하면 이러한 행위를 막을 수 있으니까 status code를 세분화하는 것이 꼭 나쁜 건 아닌 거 같기도?
  • internal api가 아닌 external api라면 고민해볼 포인트인 듯하다.

디렉터리 순회 공격이 발생할 수 있다. ~ 심지어 요청에 파일 업로드가 포함될 경우, 호출 측은 서비스에서 수정이 허용된 모든 파일을 덮어쓸 수도 있다 (서버를 루트 권한으로 실행하지 말아야 하는 또 다른 이유다!) (p.312)

• 처음에는 다른 디렉터리에 저장한다 하더라도, Not Found 에러로 서버 에러로그를 무한정 띄우는... 어떻게 보면 사소한(?) 공격이지 않을까 생각했으나, https://news.hada.io/topic?id=13086 글을 보고 env 파일을 서치해서 접근한다면 정말 무서운 일이 발생할 수 있겠다 싶었음.
• 사이드프로젝트 수행 시, ssh 접근할 때 개발자들은 모두 루트 권한으로 사용한 적이 있는데 이 행위가 보안에 굉장히 취약하다는 것임을 다시 한 번 인지.
  • 근데 사이드프로젝트에선 대부분 보안 챙기기 어렵긴 한듯.

SameSite 속성은 브라우저가 문서의 출처가 대상의 출처와 동일할 때만 쿠키를 전송한다. (p.318)

• 이 옵션 값이 strict일 때에는 맞는 말이지만, 최근에 크롬 기준 samesite=lax 가 default로 바뀌면서 완전 맞는 말은 아닌 거 같음.
• 참고: https://seob.dev/posts/%EB%B8%8C%EB%9D%BC%EC%9A%B0%EC%A0%80-%EC%BF%A0%ED%82%A4%EC%99%80-SameSite-%EC%86%8D%EC%84%B1/
• 참고2: https://cherish-it.tistory.com/12

[leejaeseung]

1.3 사이트 간 스크립팅 - XSS

입력값을 절대 신뢰하지 말라

• 입력 데이터를 그대로 사용하면 안된다. XSS 를 방지한 Encoder 를 거쳐야 한다. (자바의 OWASP 등)

문자열을 이어 붙여서 구조화된 데이터를 만들지 말라

• 문자열을 화면에 표시할 때 자동으로 가공하는 라이브러리를 사용해라. (React 는 Dom 의 모든 문자열이 자동으로 이스케이프된다.)

1.4 취약한 접근 제어

조사 가치 경감

• URL 에 들어가는 객체의 id 를 예상하기 어렵게 바꿔라. id 값을 세션 id 와 매핑하거나, 순차적이지 않을 id 값을 사용하거나.
• URL 의 id 값이 항상 동일한 객체를 가리키지 않는 건 REST 원칙에 위배되긴 한다. 결국 권한을 부여하는게 가장 좋은 방법인 듯 하다.

허가된 접근

• 보통 URL 에 대해 화이트리스트로 관리하는 듯 하다. /method/abcd/** 과 같이.
• 권한이 없는 경우에, 권한이 없음을 사용자에게 알려주면 악용될 수 있다. (자원의 규모를 알아낼 수 있다) 권한이 없는 경우에도 자원이 없는 것처럼 동일한 에러를 내려주자.
• 디렉터리 순회 공격 : 서버가 파일과 관련된 기능을 제공할 때, 서버에 저장된 파일을 디렉터리 경로 조합으로 조작할 수 있다. 요즘엔 파일을 서버에 저장하지 않고 원격 저장소(S3 등)에 저장하니 크게 신경쓰지 않는 듯 하다.

1.6 민감 데이터 노출

• 사용자의 민감한 데이터를 암호화해야 한다. (비밀번호, 이름, 주민등록번호 등등. 금융업에서는 아예 * 로 바꿔버리기도 한다. 복호화조차 되지 못하게)
• KMS 를 사용해 민감한 key 들을 암호화해라. KMS 동작 방식 : https://bluese05.tistory.com/71 결론적으로 각 암호화 데이터들을 customer master key 로 복호화를 수행하는데, 이 key 가 KMS 측에 저장되는 것이 보안 포인트인 듯 하다. (공격자가 접근할 수 없는 곳에 복호화키를 저장)

[binchoo]

랜섬웨어 ... 영국 국민 보건 서비스가 큰 타격을 입어 엑스레이 촬영이 취소되고, 뇌졸중 센터가 폐쇄되고, 수술이 연기되어 여러 생명이 위험에 처했다. (p. 300)

• 시스템 실패로 생명을 위협 받았다는 사례를 보니 다시금 책임감을 가져야겠다는 생각이 드네요. 우리는 시스템에 의존하는 고객에게 편의를 제공한다 하지만, 조금의 실수로 날카로운 검을 들이미는 모양새가 되니 외줄 타는 느낌입니다. 교훈을 잘 배우고 잘 적용해야 겠네요.
  • Safety와 Security 품질은 양의 상관관계가 있다고 얘기되지만. 기능 안전에 있어서 Security와 함께 가지 못하는 양상도 있다고 유 교수님 언급이떠오르네요.

OWASP 상위 10

1. Injection

Injection은 구문 분석기나 인터프리터에 대한 공격이며, SQL 삽입이 유명하다.

• SQL 삽입 Robert'); DROP TABLE Students; -- SQL 삽입은 코드에서 문자열을 조합해서 SQL 문을 만들 때 발생한다. 이제 모든 SQL 라이브러리는 인자 값이 들어갈 자리를 특수 부호로 표시하도록 해 준다.

  String query = "SELECT * FROM STUDENT WHERE NAME = ?";
  PreparedStatment stmt = connection.prepareStatement(query);
  stmt.setString(1, name);
  ResultSet results = stmt.executeQuery();

• XML 외부 엔터티 삽입 XML에서는 엔터티를 새로 정의하여 공통으로 참조되는 태그 및 속성을 단축시키는 용도로 쓰이곤 한다. 외부 엔터티는, 이 엔터티와 연결된 URL에서 데이터를 수신하여 대체된다. 공격을 방지하려면 OWASP XXE 방지 지침을 구현한 XML 구문 분석기를 이용해야 한다.

  <?xml version="1.0" encoding="ISO-8859-1"?>
  <!DOCTYPE foo [
  <!ELEMENT foo ANY >
  <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>
  <foo>&xxe;</foo>

  1. 공격자가 API 엔드포인트에 해당 문서를 제줄한다.
  2. API는 해당 문서를 정상 처리하지 않을 테지만, 공격자는 오류 응답에서 xxe가 해결된 값이 포함되길 기대한다. 그 값은 서버의 리눅스 유저 정보가 될 것이다.

• Format String Attack

• Eval Injection

• XPATH Injection

2. 인증과 세션 관리

• Session hijacking
  • 한 때, URL 쿼리 파라미터에 세션 ID를 담는 설계가 일반적이었음
  • 세션 ID가 경로 상 스위치, 프락시, 링크를 본 모두에게 노출됨
  • 사용자 수천 명이 동일한 세션을 이용하려고 하니, 세션 소유권 경쟁으로 서비스가 중단되기도 함
  • 세션 ID가 쿠키 안에 들어 있다고 해도 세션 하이재킹은 일어날 수 있다.

💬 제가 개발했던 출석체크 챗봇 역시 쿠키 내 저장된 세션을 유저께서 직접 제공하시도록 (정당한 하이재킹?) 하여 게임사 API를 호출하는 방식이었습니다. 전송/저장 암호화 모두 적용했으나, 게임 커뮤니티 이용규약 등, 해당 방식에 대한 부담으로 더 이상 챗봇을 운영하고 있진 않습니다.

• Session fixation 유효한 세션 ID를 발급 받아 피해자 시스템에 심고 (meta 태그나 쿠키 등) 피해자가 공격자에게 모든 권한을 위임하길 기대함

• Session prediction 세션 ID 생성 규칙이 유추 가능할 경우, 공격자가 이를 이용해서 세션을 탈취하고 피해자 데이터에 접근할 수 있다.

• TLS 인증서 이용 미숙 솔직하게 자체 서명 인증서를 사용하는 개발 서버에서 TLS 호출하는 cURL 명령을 작성할 수 있는가? (p.306)

  • 서버 인증서와 인증서 체인을 다뤄본 적이 없는 개발자들이 많다.
  • 개발 런타임들이 자체 트러스트 스토어를 사용해 신뢰 인증서를 구성하도록 요구한다.
  • => 어려워서 포기하고 HTTP 웹 서비스를 구성해버리곤 한다.

💬 저자가 한 질문 스프링 기준으로 답변

1. 자바 키스토어에 공개/사설키 쌍 생성
2. 스프링 실행시 해당 키스토어 참조하여 서버 인증서로 사용
3. cURL 작성시 --cacert로 1에서 만든 공개키를 신뢰하여 HTTPS 엔드포인트 호출. jks나 p12를 pem으로 변환 필요.

[kth990303]

재빈님 키워드 정리 (Ex. OWASP 상위 10) 3.17 발표하면 close 할 것