Chapter 2. 웹 어플리케이션 정찰 개요
정찰 : 해킹을 시도하기 전, 애플리케이션에 대한 깊은 이해를 구축하는 것
=> 웹 애플리케이션 기술과 아키텍처 맵을 그려감으로써, 공격의 우선 순위를 더 잘 정할수 있다.
<용어>
RBAC : Role-Based Access Control / 사용자의 역할에 기반하여 시스템 자원에 대한 접근을 결정
ABAC : Attribute-Based Access Control / 다양한 속성을 기반으로 접근 제어를 수행하는 접근 제어 모델
Chapter 3. 현대 웹 애플리케이션의 구조
현대의 애플리케이션은 둘 이상의 애플리케이션이 네트워크 프로토콜을 통해 통신하는 형태가 많다.
현대 웹 애플리케이션 사용 기술
- REST API (표현 상태 전송 API)
=> 상태를 저장하지 않고, 요청만 처리함 - 독립 실행형 애플리케이션을 웹 브라우저에 배치해 여러대의 서버와 통신
- JSON 또는 XML
- 자바스크립트
- SPA 프레임워크
- 인증 및 권한 부여 시스템
- 하나 이상의 웹 서버
- 한가지 이상의 웹 서버 소프트웨어 패키지 (ExpressJS, Apache, NginX)
- 한가지 이상의 데이터베이스(MySQL, 몽고 DB)
- 클라이언트의 로컬 데이터 스토어(쿠키, 웹 스토리지, IndexedDB)
- 캐시 API, 클-서버, 클-클 통신
=> 로컬에 요청을 저장하는 방식, 해당 방식의 단점을 보안한 것이 "웹 소켓"
REST API 특징
- 클라이언트와 독립적
=> 클 과 API를 분리 but 엄격한 API 구조를 구축 / 고도의 확장성 + 단순한 웹 애플리케이션 구조 - 상태를 저장 X
=> 입력을 받아 출력만 / 저장 기능 X / 권한 부여는 토큰화 - 쉽게 캐시 가능
=> 적절한 확장을 위한 캐시 가능 여부를 쉽게 - 엔드포인트는 특정 객체나 메서드를 정의 가능
=> 한개의 엔드포인트가 여러개의 HTTP 동사를 여러개 갖기 위해
SOAP와 비교한 REST
- 대상의 데이터를 요청한다
- 요청을 캐시하기 쉽다
- 확장성이 높다
SOAP API
- 단순 객체 액세스 프로토콜
- XML 기반의 통신 프로토콜
- 분산 환경에서 웹 서비스를 제공하기 위한 표준
주로 웹 서비스를 통해 애플리케이션 간 통신을 구현하는 데 사용
자바스크립트 객체 표기법
-
REST는 HTTP 동사를 서버의 리소스에 어떻게 매핑해야 하는지 정의하는 아키텍처 사양
대부분의 REST 는 JSON 방식을 사용 -
애플리케이션의 API 서버는 반드시 클라이언트와 통신 해야한다
모든 상태는 로컬 에 저장 되어야한다 -
현대 웹 애플리케이션은 클/서버 방식을 많이 요구한다.
이때, 전송 데이터의 포맷의 표준화가 JSON 방식
다운스트림: 데이터 교환 / 서버 -> 클라이언트로 데이터 전송
업스트림: HTTP 동사 형식의 요청 / 클라이언트 -> 서버로 데이터 전송
JSON 특징
- 경량
- 파싱하기 쉽다
- 가독성
- 계층적
- 자바스크립트 객체와 매우 유사하여, 브라우저에서 소비, 사용이 쉽다
- 상태 비저장 서버와 웹 브라우저 사이의 데이터 전송에 적합
but, 경량 포맷이 갖는 단점에서 자유롭지 못함
- 하나의 데이터는 오직 하나의 값으로만 구성되기 때문에, 단순한 키워드의 나열과 같은 사용만 가능
- 하위 객체로 포함된 JSON의 이름들이 독립적이기 때문에, 하나의 객체 안에 존재하는 하위 객체들간의 연관성이 적음
자바스크립트
- 인터넷 브라우저에 사용할 목적으로 설계된 동적 프로그래밍 언어
- 브라우저의 성장과 문서 객체 모델(DOM)에 종속된 언어
DOM : 웹 페이지(HTML이나 XML 문서)의 콘텐츠 및 구조, 그리고 스타일 요소를 구조화 시켜 표현하여 프로그래밍 언어가 해당 문서에 접근하여 읽고 조작할 수 있도록 API를 제공하는 일종의 인터페이스
변수와 스코프
- 변수 정의시 "var", "const", "let"을 사용하고,
- 미사용시 글로벌 스코프로 적용된다.
=> 글로벌 스코프 적용시, 보안 취약점 or 기능상 버그 유발 + 식별자가 붙지 않는 변수는 브라우저의 *window 객체에 포인터가 추가됨
window 객체 : 브라우저 DOM이 윈도우의 상태를 유지하기 위해 사용하는 객체
1. var : 가장 가까운 곳에 있는 함수의 스코프가 적용, 바깥쪽에 함수 블록이 없다면 글로벌 처리
2. let : var의 단점을 보완, 블록 스코프가 적용됨
3. const : let와 비슷하지만, 재할당이 불가능하다는 차이가 있음, 자바에 있는 final 함수와 비슷함(블록 스코프 적용 but 재할당 X)
결론 => 버그 방지 및 가독성 개선을 위해선 let 와 const 를 사용
함수
자바스크립트 내 함수는 객체 => 변수와 식별자를 사용해 할당 및 재할당이 가능
ex) 익명 함수, 스코프가 지정된 함수, 축약 함수, *즉시 호출 함수 표현식
즉시 호출 함수 표현식(IIFE): 자바스크립트에만 있는 함수, 개발자가 다른곳으로부터 액세스되는 코드 블록을 캡슐화할 목적으로 사용
콘텍스트
프로퍼티와 데이터 집합, this 키워드를 사용해 참조
콘텍스트 공유시 발생하는 문제를 해결하기 위한 방안 =>
bind, call(인자의 리스트), apply(인자의 배열) 3가지
->(화살표), 축약함수를 사용하면 위의 3가지 필요 X
프로토타입 상속
전통적 서버 = 클래스기반 상속 모델
ex) 자바 extends, new 사용
현대 서버 = 프로토타입 상속 시스템
ex) 자바스크립트 prototype, constructor 사용
자바스크립트의 모든 객체는 언제나(실행 중 포함) 변경 가능하다.
=> 프로토타입 오염에 취약
프로토타입 오염 : 부모 자바스크립트 객체를 수정함으로써 자식 객체의 기능이 원래 의도에서 벗어나게 하는 공격
비동기(p.82)
브라우저는 서버와 일상적으로 통신해야하고, 요청과 응답 사이의 시간은 비표준적(페이로드 크기, 지연, 서버 처리 시간)이기 때문에 웹에서 변동성을 다루기 위해 사용한다.
비동기식을 사용한다면 동기식으로 처리했을때 보다, 속도가 빠르다
구 버전의 자바스크립트에선 콜백 시스템을 주로 사용했으나,
동기식 모델과 비교해서 읽고 디버그를 하기 어려워 사용 X
=> 이후 프로미스를 사용, 콜백과 프로미스를 동시에 사용 가능하다.
콜백의 단점을 보완 및 비동기 처리에 사용되는 객체를 의미
(객체이기 때문에 생성자 함수를 호출해 인스턴스화 가능)
프로미스 사용의 이점
- 비동기 처리 시점을 명확하게 표현 가능
- 연속된 비동기 처리 작업을 수정, 삭제, 추가에 용이
- 비동기 작업 상태를 쉽게 확인 가능
- 코드의 유지 보수성 증가
프로미스 접근 기반의 이점
- 코드를 나누기 쉽고 수직적으로 증가 및 오류처리 용이
+@ anync 함수 : 일반적인 함수를 프로미스 함수로 변환시키는 역할,
비동기 방식에 쓰이는 함수
브라우저 DOM
: 현대적 브라우저의 상태를 관리하는데 쓰이는 계층적 표현 데이터이다,
자바스크립트의 표준 라이브러리 / 브라우저의 종류와 상관없이 동일하거나 거의 비슷하게 작동함 /
DOM의 목적은 "웹 페이지를 표현하는 노드들의 계층적 트리를 정의하는 공통 인터페이스를 제공하는 것"
window와 document가 주요 객체이다.
SPA(단일 페이지 애플리케이션)
등장 배경 : 정적 컨텐츠를 제공할때 주로 사용했던, (애드혹 스크립트와 재사용한 HTML 템플릿 코드가 혼재되어 있는 경우가 많았다) 복잡하고 로직이 많이 구현된 현재에는 사용하기 어렵기 때문에 설계되었다.
- 자체적인 내부 상태를 저장
- 재사용 가능한 UI 컴포넌트로 구성
- 렌더링 에서 로직 실행 까지의 수명 주기를 자체 관리 가능
=> 페이스북, 트위터, 유튜브 등 기능이 많고 복잡한 구조에 주로 사용
인증 및 권한 부여 시스템
: 주로 애플리케이션은 클, 서버로 구성 / 서버는 클 의 데이터를 저장, 시스템은 데이터 제공
인증 : 사용자가 본인임을 확인 하는 단계
HTTP 기본 인증, OAuth, Base 64, 다이제스트 인증(digest authentication), 이중 인증 등 시용
다이제스트 인증은 인터셉션과 리플레이 공격에 대비가 가능해 인기 있음
권한 부여 : 사용자가 리소스에 액세스 할 수 있게 부여
- 인증의 다음 단계, 공통 리소스는 권한 부여 확인이 항상 이뤄져야한다.
- 잘 설계된 애플리케이션은 사용자가 특정 리소스나 기능성에 액세스를 갖는지 판별하고 책임을 갖는 중앙 집중화된 권한 부여 클래스가 있다
웹 서버
주로 Apache, Nginx, IIS 등을 사용한다
서버 측 데이터베이스
클라이언트가 서버에 처리할 데이터를 주로 저장하는 일이 많다. 이때 메모리에 저장하면 신뢰성이 떨어진다.
=> 시스템 재시작과 충돌 등으로 데이터 손실 발생
이러한 문제를 줄이기 위해 DB를 사용
SQL : 엄격하지만 속도가 빠르고 배우기 쉽다.
ex) PostgreSQL, 마이크로소프트 SQL 서버, MY SQL, SQLite 등
NoSQL : 스키마가 없는 데이터베이스, 문서로 저장해 유연성이 높다, 다루기 어렵고 조회, 집계의 효율성이 떨어짐
ex) 몽고, 도큐먼트, 카우치 DB 등
일래스틱서치(Elasticsearch) : 고도로 전문화된 DB를 두고 메인 DB와 동기화하는 구성
SQL Injection : 주요 SQL 데이터베이스의 질의가 올바로 작성되지 않은 경우에 효과적
클라이언트 측 데이터베이스
과거 호환성 이슈로 인해 클라이언트에 최소한의 데이터를 저장했지만 현재는 바뀌고 있다.
로컬 스토리지 : 브라우저 관리 스토리지 컨테이너
로컬 스토리지를 사용해 클라이언트의 키값 데이터를 저장 및 액세스 함
이때 SOP(동일 출처 정책)를 사용 : 다른 도메인끼리 로컬에 저장된 데이터에 액세스 하지 못하도록 하는 방식
세션 스토리지 : 로컬 스토리지의 서브셋, 로컬과 동일하게 작동하지만, 탭이 닫히기 전까지만 데이터를 저장
인덱스드 DB : 자바스크립트 기반 객체 지향 프로그램(OOP) / 웹 애플리케이션이 백그라운드에서 비동기 저장과 질의 가능
질의가 가능함으로써 로컬 스토리지 보다 개발자 환경에 맞춰져있다
주로, 이미지 편집기, 웹 기반 게임 방식에 사용
테스트 방법 : if(window.indexedDB){ console.log('true'); }
Chatper 4. 서브 도메인 찾기
- 클 - 서버 도메인으로 분할되어 있음
ex) https:// , https//www. 등
한 도메인이 여러 애플리케이션이 있는 경우
(가비아 cafe24 등에서 도메인 구매 가능)
- www.naver.com 의 경우
- search.naver.com
- blog.naver.com
- cafe.naver.com
- mail.naver.com
- 도메인에 따라 대, 내외로 구분 가능
브라우저에 내장된 네트워크 분석 도구(개발자 도구)
- 도구 : 버프, 포트스위거, 잽 도 있다
- 개발자 도구 내 Network 탭을 사용
- 네트워크 분석, 코드분석, 중단점, 파일 참조, 정확한 성능 측정 기능이 포함되어있음 => 자바의 런타임 분석 도구
- Network - Headers - General : 서버 확인 방법
공개된 레코드를 이용하기
검색 엔진, SNS 게시물, archive.org, 이미지 검색, 역 이미지 검색 등을 통해 검색 가능.
검색시 출력 가능한 값들..
- 실수로 공개 후 비공개 처리한 깃허브의 개시된 사본
- SSH 키
- 여러가지 키(AWS, Stripe)를 공개 웹 애플리케이션에 임시 게시 후 삭제한 것
- 비공개한 DNS, URL 목록
- 비공개 페이지
- 실수로 공개되 재무 기록
- 이메일 주소, 전화번호 등 개인정보
검색 엔진 캐시
- site:(url) log in 등을 통해 검색 가능
- -inurl:(단어) 를 넣으면 해당 단어를 제외한 검색 결과 값을 추출 가능
이 방법을 사용해 www. 가 들어간 사이트와 들어가지 않은 사이트를 검색 가능 (서브 도메인 검색)
ex) site:url -inurl:www -inurl:moblie
의도하지 않은 아카이브
- archive.org 해당 사이트를 사용해
이력 데이터를 확인 가능
소셜 스냅숏
- 트위터 API, 스트리밍 API, 파이어호스 API 등을 사용해 분석할 수 있다
(API 검색법은 생략)
위의 방법을 사용함으로써
- 정찰과 가장 관련성 있는 데이터를 검색 가능
- 규모가 큰 앱이나 인기있는 앱에 대한 데이터를 얻기 쉽다
존 전송 공격(Zone transfer attack)
- 올바르게 구성되지 않은 DNS 서버를 정찰하는 트릭
- 정보 수집 기법
DNS 시스템에선 다른 DNS 서버와 DNS 레코드를 동기화 하는 능력이 중요
DNS 존 전송 : DNS 서버가 DNS 레코드를 공유하는 표준적 방식, 레코드는 텍스트 기반의 존 파일을 통해 공유
존 파일의 DNS 구성 데이터는 쉽게 액세스 할 수 없도록 의도됨 -> 권한이 있는 보조 DNS 서버의 존 전송 요청만 처리 가능
입력 예시
: host -t (url)
출력 예시
: (url) nameserver ns1.url
존 전송 요청 예시
: host -l url ns1.url
이후 정상적으로 값들이 출력된다면 취약
서브도메인에 대한 브루트 포싱
서브 도메인에 대한 브루트 포스는 매우 쉽게 탐지되어, IP 주소가 로그에 남거나, 관리자에 의해 차단 가능성이 높아 마지막에 시도
p.113 ~ p.118 자바스크립트를 이용한 브루트포싱 알고리즘 구현
딕셔너리 공격
: 브루트 포스 공격 보다 속도가 빠름
-> 정해진 리스트 내에서 공격을 시도,
dnscan에 서브 도메인 리스트를 확인 할 수 있다.
리스트 예시 : www mail ftp localhost webmail smtp pop etc...
딕셔너리 -> 브루트 포싱 순으로 접근하면 좋다.
서브 도메인을 찾는 이유 => 대외 페이지 보다 대내 페이지의 버그 결함이 더 많음..
Chapter 5. API 분석
각각의 도메인의 고유한 API를 찾는 단계
5.1 엔드포인트 탐색
REST, SOAP 포맷을 주로 사용 (REST를 더 많이 사용)
REST 포맷 특징
- 형식
ex) GET api.mega-bank.com/users/1234
GET api.mega-bank.com/users/1234/payments
POST api.mega-bank.com/users/1234/payments - 요청이 이뤄질때 토큰을 보냄
- 상태 비저장 => 요청자 추적 X
API 엔드포인트 HTTP 동사에 대한 브루트 포싱은 애플리케이션 데이터를 삭제 하거나 변경하는 부작용 발생
인증 메커니즘
- 알려진 요청의 구조를 분석하는 방법
- 주요 인증 스킴을 확인
- 종류 : HTTP 기본 인증, HTTP 다이제스트인증, OAuth
- HTTP 기본 인증
: 요청시 마다 사용자명과 패스워드 전송
: 모든 브라우저가 자체적 지원
: 세션이 만료되지 않으며 가로채기 쉽 - HTTP 다이제스트 인증
: 요청시 해시된 사용자명:realm:패스워드를 보냄
: 가로채기 어렵, 만료된 토큰을 서버가 거부 가능
: 암호화 강도가 사용하는 해싱 알고리즘 수준에 비례함 - OAuth
: 다른 웹사이트의 인증을 이용(베어러 토큰 기반 인증)
: 토큰화된 퍼미션을 공유함 => 다른 앱 통합 가능
: 피싱 위험, 중앙 사이트 침해시 모든 앱 침해
- 주요 인증 스킴을 확인
기본 인증은 ssl/tls 트래픽 암호화를 적용한 웹 어플리케이션에서만 제한적으로 사용 됨 (ex. base64)
엔드 포인트 형상
각 페이지별, 권한을 가지고 있는 경우 외부로 나가는 형상을 조사
ex) id pw 같은 정보 확인 가능
필드의 솔루션 공간을 최소한으로 줄이는 것이 유리함.
- 서브 도메인에 대한 정보 수집
- 호스팅 되는 api 엔드포인트 수집
- 문서화 및 형상 결정
Chapter 6.서드파티 의존성 식별
CVE 데이터 베이스에서 공격을 그대로 따라할 수 있음
클라이언트 측 프레임워크 검출
- 개발자들은 이미 완성된 프레임워크를 주로 이용
=> 취약점 DB에서 찾을 수 있다
SPA 프레임워크 검출
- 주로 사용하는 프레임 종류
: EmberJS, 앵귤러JS, 리액트, 뷰JS
- EmberJS : console.log(Ember.VERSION);
- 앵귤러JS : 4.0 이상부터는 검출하기 어려워짐
- 리액트 : const version = React.verison;
console.log(version); - 뷰JS : const version = Vue.version;
console.log(version);
자바스크립트 라이브러리 검출
- 자바스크립트 라이브러리는 최상위 글로벌 객체를 사용하는 경우가 많아 쉽게 검출 가능함
=> 네임 스페이스 관리를 위해 - _ 또는 $ 기호를 사용해 글로벌 노출
- DOM의 querySelectorAll 함수를 이용해 페이지에 임포트된 전체 목록을 빠르게 찾을 수 있다
querySelectorAll : 문서 내에서 특정 CSS 선택자에 해당하는 모든 요소를 반환
=> 전체 호출 결과에서 규칙과 구성은 직접 찾아야함
CSS 라이브러리 검출
- 스크립트 검출 알고리즘을 수정해 CSS 검출이 가능
(스크립트 p.138)
서버 측 프레임워크 검출
- 난이도 : 클(브라우저)에 어떤 소프트웨어가 실행되는지 검출 < 서버에서 무엇이 실행되는지 확인
클 : 사용 코드 다운 -> 메모리 저장 -> DOM을 통해 참조
헤더 검출
- 안전하지 않은 웹 서버는 디폴트 헤더에서 정보를 확인 가능
디폴트 오류 메시지와 404 페이지
- 깃을 사용해 프레임워크의 버전을 핑거프린팅 할수 있음
(공식 릴리즈 버전 확인) - 대부분의 웹 서버는 디폴트 페이지가 존재한다. 이때 서버의 정보를 확인 가능한 경우가 있음
(오류 페이지에 나오는 문구를 통해, 어떤 웹 서버를 사용하는지도 유추 가능)
데이터베이스 검출
- 사용자, 객체, 기타 지속성 있는 데이터와 관련된 상태를 저장하기 위해 서버 측 DB를 사용한다 (ex. MySQL, 몽고 DB)
- DB 오류 메시지가 클라이언트에 직접 전송되는 경우, 그렇지 않은 경우가 있다.
- 그렇지 않은 경우엔 대체 탐색 경로를 찾아야함)
: 기본키 스캐닝 방식으로 찾을 수 있다
주요 DB에서 기본키를 생성하는 방식을 알 수 있다면, 디폴트 방식을 덮어쓰지 않은 경우엔 DB 유형을 알수 있다.
Chapter 7. 애플리케이션 아키텍처 약점 식별
웹 애플리케이션의 요소 식별, API 형상 결정, 웹 브라우저간 상호 작용 방식 => 정리
- 웹 애플리케이션에 사용 기술
- HTTP 동사별 API 엔드포인트
- API 엔드포인트 형상의 목록
- 웹 애플리케이션의 기능
- 웹 애플리케이션에 사용한 도메인
- 구성(ex. 콘텐츠 보안 정책)
- 인증/세션 관리 시스템
보안 아키텍처와 비보안 아키텍처
- 여러개의 취약점이 발생하는 이유는 애플리케이션 아키텍처가 약하기 때문일 가능성 O
- 웹 애플리케이션 코드 예시(p.149) 웹 페이지 정상 접근, 오류 페이지 등..
다중 보안 계층
ex) XSS 위험이 발생할 수 있는 여러 계층의 예시(p.153)
-
- 하나의 계층에만 보안 메커니즘을 구성하는것이 아닌 여러 계층에 구성해야한다
- 애플리케이션에서 함수를 살펴보고, 요건에 맞는 기능을 구분한다면 취약점을 찾을 가능성이 높다
