3부 방어
현대 웹 애플리케이션 보안
보안 코드 리뷰
- 품질 보증 개선, 기술 부채 감소, 쉽게 발견할 수 있는 프로그래밍 실수 제거를 위함
- 주의 깊게 살펴봐야 하는 것
1.전송 방식
: 데이터를 A->B 로 어떻게 전송하는지
2.저장 방식
: 어떻게 저장하는지
3.노출(표현) 방식
: 사용자에게 어떻게 노출되는지
4.동작 방식
: 어떻게 동작(조작) 후 저장되는지 - 주로 동작 과정을 주의깊게 보는것 같다
취약점 탐색, 분석, 관리
-
버그 바운티로 취약점 분석 가능 (버그바운티 일정 확인 후 신청해볼것)
-
적절한 분류, 우선순위 설정, 취약점 관리 단계가 이뤄져야한다
(취약점 분석)
링크 1
회귀테스팅
- 취약점 회귀 관리 프레임워크란?
: 소프트웨어 개발 및 운영 과정에서 발견된 취약점을 효과적으로 관리하고, 동일한 취약점이 다시 발생하지 않도록 하는 데 중점을 둔 관리 시스템
즉 발견된 취약점을 추적, 수정, 검증, 재발 방지를 위한 시스템임.
안전한 애플리케이션 아키텍처
기능 요구사항 분석
초기에 발생가능한 위험에 대해 분석할 수 있음
- 인증 및 권한 부여
- 개인 정보
- 검색 엔진
인증과 권한 부여
- 데이터를 어떻게 다룰것인지에 대한 부분
ex) 데이터, 자격증명, 권한 부여 등등
중간자 공격을 막기위해 고안.
(MITM) :
강의 1
SSL : 보안 소켓 계층
SSL 2.0 3.0
TLS : 전송 계층 보안
TLS 1.0 1.1 1.2 1.3
자격 증명 보안
비밀번호 해싱을 위한 해싱 함수
해싱함수를 사용하는 이유는 본래 패스워드는
BCrypt
작동 원리 :
1. 비밀번호에 솔트(계산 전에 비밀번호에 추가되는 임의의 데이터)를 추가해 결합
2. 해시 계산의 반복 횟수를 높여 비용인자 값 증가
3. 결합된 값과 솔트, 비용 인자를 사용해 해시값 생성
CBC 모드로 작동 : 블록 암호화 모드 / 블록이 암호화될떄 이전 블록의 암호화 결과를 사용하는 방식.. (XOR 방식을 사용)
PBKDF2
작동 원리
1. 비번과 솔트 결합
2. 해시함수를 사용해 반복 계산
3. 원하는 길이의 키 생성. 해당 키로 암호화 or 인증에 사용
SHA-1, SHA-256 등 사용
근래에는 Argon2와 같은 새로운 해시 함수가 개발
Argon2
: 메모리 하드 함수로 설계됨
메모리 하드 함수 : 해시 계산 시 많은 메모리를 필요로 함
그로인해 공격자가 고성능 하드웨어를 사용하더라도 비밀번호를 추측하거나 크래킹하는 것을 어렵게 만듦
작동원리
1. 지정된 크기의 메모리를 할당(해시 계산에 사용될 블록 저장)
2. 할당된 메모리 블록을 반복적으로 접근, 각 블록은 이전 블록의 값에 의존
3. 최종 접근이 완료시 최종 해시값 계산(입력 비번과 솔트값의 해시 결과값)
보안 코드 리뷰
코드 기능 리뷰와 코드 보안 리뷰의 차이점
:기능 사양에 부합하며 사용성 버그를 포함하지 않음을 확인
: XSS, CSRF, 인젝션등 공통 취약점 확인 및 자동화된 도구나 스캐너로는 찾아내기 힘든 논리 수준의 취약점을 확인
보안 리뷰 시작 위치
애플리케이션에서 가장 위험한 컴포넌트부터 시작하는 것이 이상적임
ex) 사용자 인증 및 세션, db 인터페이스, 입력검증, 네트워크 통신 etc..
but 실제로는
1. 클라이언트에서 서버로 요청하는 곳에서 시작
-
클라이언트가 호출하는 서버 API로 이동
-
헬퍼 메소드, 의존성, API들이 의존하는 기능성 등을 확인
-
클라이언트엔 노출되지만 직접적으로는 호출되지 않은 기능 확인
=> y? 외부를 잘 이해할 수 있기 때문 + 클라이언트, 서버간의 어떤 유형의 데이터가 상호 작용하는지도 알 수 있음
- 클라이언트 측 코드를 평가 => 비즈니스 로직 이해, 사용자가 사용할 기능 이해
- 앞 단계를 통한 정보로 API 계층 평가
- API 계층에서 의존중인 DB, 헬퍼 라이브러리, 로깅함수 등 사용자가 접하는 기능 에 대해 평가
- 앞 단계들을 통해 확인한 정보들로 의도치 않게 노출 or 릴리스할 의도로 외부 공개된 API 확인
- 이외의 부분 리뷰
시큐어 코딩 안티패턴
: 보안에 취약한 코드 작성 방식
1. 거부 목록
: 임시적, 불완전한 보안 솔루션의 예시
ex) SQL 인젝션 방지, XSS 방지, IP 차단, 포트 차단, 사용자 차단, 스팸 필터링
-
장점
: 특정 요소를 명시적으로 차단할 수 있어 관리가 비교적 간편함
: 어떤 요소가 금지되었는지 명확함 -
단점
: 목록이 커질수록 관리가 어려워짐
: 우회의 가능성이 있음
: 유지 보수성이 떨어짐
보안측면에선 거부 목록 보단 허용 목록을 더 선호함
2. 보일러플레이트 코드
: 소프트웨어 개발에서 반복적으로 자주 사용되는 코드 구조나 패턴을 의미함
즉, 재사용..
=> 생산성 향상과 일관성의 이점이 있지만, 개발자가 프레임워크의 추상화를 이해하지못한 경우, 보안 메커니즘에 문제가 생길수 있음..
3. 퍼미션과 사용자 결합
: 로깅 디스크 기록, 데이터베이스 작업을 위한 퍼미션을 각각 생성해야함.
각 모듈 당 자체적인 사용자를 통해 실행 + 특정 작업 수행에 필요한 기능한 사용할수 있게 퍼미션 설정
4. 클라이언트와 서버 결합
: 클/서버 애플리케이션 코드가 너무 강하게 결합되어 둘 중 하나가 없으면 기능을 할수 없을때 발생
모놀리식 애플리케이션* : 애플리케이션의 모든 기능과 컴포넌트가 단일 코드베이스와 단일 실행 환경에서 동작하는 구조
ex) 전자상거래
안전한 애플리케이션은 클라이언트 / 서버가
1. 독립적 개발
2. 미리 정의된 데이터 포맷과 네트워크 프로토콜을 통해 네트워크상에서 통신
취약점 탐색
보안 자동화
1. 정적 분석
- 실행 X, 단지 코드만 보고
- 구문 오류와 일반적인 잘못만 판단
- 정적 분석 도구는 OWASP TOP 10 을 주로 찾도록 구성됨
ex) XSS(반사, DOM), SQL 인젝션, CSRF, DoS - C#, 자바 등 정적 타입 언어와 잘 맞음 / 자바스크립트ㄴ 같은 동적 언어와는 상극
=> 공통적인 취약점 & 구성 오류를 찾는데 좋음
2. 동적 분석
- 정적 도구에 비해 비용이 많이 들고 느리다
- 정적 분석은 잠재적 취약점을 주로 찾아내지만 동적 분석은 실제적인 취약점을 잡아낸다
3. 취약점 회귀 테스팅
- 발견된 보안 취약점이 수정된 후, 해당 취약점을 테스트해 코드베이스에 다시 나타나지 않았음을 확인
ex) Jest, Jenkins 등
취약점 관리
: 좋은 보안 소프트웨어는 개발 수명 주기 프로세스에서는 웹 애플리케이션의 취약점을 획득 분류 해결 하는 절차가 잘 정의됨
XSS 공격 방어
안티 XSS 코딩 모범 사례
- '문자열을 제외한 사용자 제공 데이터를 DOM에 전달 X'
=> 정제되지 않은 사용자 제공 데이터를 절대 DOM으로 전달 X
가능한 문자열로 전달
동작 방식
1. 사용자가 텍스트를 UI에 입력
2. 텍스트를 DOM에 추가 시도
3-1. 텍스트로 추가 => 안전
3-2. DOM으로 추가 => 침해
DOM 으로 전달하는 것이 아닌 텍스트로 전달해야한다..
JSON.parse() : 텍스트를 json 객체로 변환할때 사용 / 문자열과 숫자인지 여부를 검사할수 있음
+@ 사용자의 데이터를 DOM 에 주입할때, innerHTML innerText를 사용
innerText : HTML 태그를 자체적으로 정제 후 문자열로 출력
innerHTML : HTML 태그로 해석 후 DOM 출력
둘중 innerText를 사용하는 것을 추천하지만/ 100프로 안전은 아님
when?
=> 특정 태그를 허용하고 이외는 차단할때
'<'a href="javascript:alert(document.cookie)">test'</a'>
=> URL 스킴 : 스크립트 태그나 따옴표 없이 문자열 실행 허용
'<'a href="javascript:alert(String.fromCharCpde(88,83,83))">test'</a'>
=> 따옴표 필터도 우회 가능
- DOM 을 인식하는 가장 좋은 방식 => 텍스트를 DOM 이나 스크립트로 변환하는 것을 모두 의심 필수
예시
- element.innerHTML / element.outerHTML
- Blob
- SVG
- document.write / document.writeln
- DOMParser.parseFromString
- document.implementation
- eval(), setTimeout(), setInterval()
DOMParser 싱크
: 문자열을 DOM으로 파싱하는 데 사용되는 웹 API
주로 XML이나 HTML 문자열을 파싱하여 브라우저가 이해할 수 있는 DOM 구조로 변환하는 데 사용함
=> 주의점으로는 사용자 입력을 파싱할 때는 신뢰할 수 없는 데이터를 그대로 파싱 가능성이 있기때문에 주의
밑 두개로 구성을 조직화하면 위험을 낮출수 있다
document.createElement()
: 새로운 HTML 요소를 생성할때 사용함
document.appendChild(child)
: 부모-자식 구조로 노드 구성해줌
=> 개발자는 DOM 구조와 태그명 통제 / 페이로드 내용 통제
SVG 싱크
장점
- 여러 장치에서 이미지를 일관적으로 출력
단점
- 자바스크립트를 실행할수 있기에 XSS 공격 위험
블롭 싱크
: 주로 파일을 읽거나 다운로드하는 데 사용함
장점
- 여러가지 포맷으로 저장 가능
단점
- 신뢰 X 인 파일 다운 or 데이터 처리시 악성코드가 포함될 가능성 있음 =
하이퍼링크 정제
- 유효성 검사, URL 인코딩, DOM 기반 공격 방지, CSP 설정을 통해 정제 가능
- url 형식 확인
CSP: Content Security Policy, 브라우저의 보안 구성 도구
CSRF
: img 태그와 a 태그등을 사용해 공격 가능,
헤더 검증
referer : 모든 요청에서 확인 가능
(erl=noreferer 설정시 referer 헤더 X)
origin : HTTP POST 에서만 전송
- 단순 전송 정보만 출력
- HTTP, HTTPS 에서 확인 가능
두 헤더가 모두 있어야 표준에 맞음
CSRF 토큰
-
인증 토큰임 , 상태 저장과 상태 비저장 (stateful stateless) 일때랑 동작/인증 방식이 약간 다름
-
상태 저장
클라이언트 웹 페이지 요청 -> 서버=>클, CSRF 토큰을 함께 전송 -> 클, HTTP 리소스 요청시 CSRF 토큰을 같이 전송 -> 서버, 토큰 검증 후 응답 전송
=> 이후에 공격자가 접근시 토큰이 없기때문에 요청이 차단됨
- 상태 비저장
상태 저장과는 다르게 토큰 유효시간이 필요(타임스탬프)
안티 CSRF 코딩
-
상태 비저장 GET 요청을 리팩토링
: HTTP GET 요청은 서버 측 상태를 저장 or 수정 X
: 상태 저장 은 X -
애플리케이션 차원의 CSRF 방어 구현(토큰 사용, 헤더 검사)
-
미들웨어의 도입
: 클라이언트로부터 들어오는 요청을 가로채 처리와 응답을 생성하기 전에 다양한 작업을 수행이 가능함 => 라우트에 의해 수행되기 전에 먼저 실행 가능
즉, 모든 서버의 요청에 대해 호출 가능 및 특정 요청이 있을때 실행가능하게 할수 있음
- HTTP GET 요청이 애플리케이션 상태를 절대 바꾸지 않는다는 것을 확인하는것 만으로도 공격을 완화할수 있음.
각 헤더를 검증 + 각 요청에 대해 토큰 추가
XXE 방어
- XML 파서에서 외부 엔티티를 비활성화 하면 방어 가능
(factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
=> XML 파서가 DOCTYPE 선언을 비허용하도록 설정
disallow-doctype-decl 설정을 true로 하면 DOCTYPE 선언을 비활성화 하는것..
언어의 종류와 파서에 따라 XXE 비활성화하는 구성이 기본값일 수도 있음
=> 확인 방법? => API 문서 확인
동작 예시
XXE 포함, XML 페이로드 요청 -> 서버의 파서가 XML 파싱
-> (부적절한 구성) 서버 리소스가 액세스되면 반사될 가능성 있음
-> (적절한 구성) 파서가 엔티티 태그를 거부
XML 과 JSON 의 비교
- JSON은 XML에 비해 경량
- JSON은 융통성있, 빠름, 다루기 쉬움(페이로드)
- JSON은 자바스크립트 객체를 매핑 / XML은 DOM 트리
랜더링은 XML이 이상적 BUT API에는 JSON이 이상적
XML의 보안 위험 외부 파일 & 멀티미디어 포함하기 때문 => 안정성 떨어짐
XXE 위험
- XXE는 공격자로 하여금 웹 서버 외부에서 액세스할 수 없는 데이터에 엑세스할 수 있게 해주는 정찰 플랫폼을 제공하는 일종의 관문임..
(리마인드.. XXE는 원격 서버의 내부 파일을 읽거나, 서버 내부의 데이터를 탈취하거나, 원격 서버에서 원하지 않는 코드가 실행되게 하는 공격
XML 파서가 외부 엔터티를 허용 -> 악성 XML 입력 -> 서버 내부 파일 읽기 -> 데이터 탈취 또는 추가 공격)
인젝션 방어
SQL 인젝션
- 비교적 방어하기 쉬운편..
- 폼 SQL 인젝션에 대해 파악 후 취약한 부분 확인
- SQL 작업은 서버 측 라우팅 수준을 지나 발생.. 클라이언트 단에 관심 X
서버는 여러개의 DB를 사용하는 경우가 많다
=> 질의는 일반적으로 많이 사용하는 질의를 사용하는것을 추천
일반적 SQL 질의?
=> 조회, 삽입, 업데이트, 삭제 등등
EX) SELECET, WHERE, ORDER BY..ETC
DSL 을 사용하는 경우도 있
(도메인별 언어)
프리페어드 스테이트먼트?
=> 사용자 제공 데이터가 SQL 해석기에 나타나기도전에 의도가 미리 새겨짐 그로인해 질의 자체를 변경하는 것이 불가능
장점
- 파라미터를 바인딩하여 SQL 인젝션을 방지
- 여러 번 실행할 때 속도가 빠름
- 코드가 간결 => 가독성 업
일반 인젝션
- 코딩 프랙티스 적용
: 애플리케이션 로직 전반에 걸쳐 비SQL 인젝션 타깃이 있는 지 확인하는 과정 - 고위험..
: 작업 스케줄러
: 압축/최적화 라이브러리
: 원격 백업 스크립트
: 데이터베이스
: 로거
: 호스트 OS 호출
: 인터프리터, 컴파일러
최소 권한 원칙(최소 특권 원칙)
- 필요한 데이터와 기능에만 엑세스 해야한다.
=> 개발자의 부담 커짐 Y? 추가 계정과 복수의 키를 관리해야하기 때문
명령 허용 목록
=> 쉽게 말해 블랙리스트 보단 화이트리스트 방식을 사용
+@
입력 검증, 원시 쿼리 사용 지양, 최신 보안 패치적용...
DoS 방어
- 완전한 로깅 시스템을 구축해야함
=> 시스템이 모든 요청과 이벤트를 철저히 기록함으로써 공격을 감지하고 분석, 이를 기반으로 적절한 대응 조치를 취할 수 있도록 하는 것을 의미함.. 흠
DoS의 공격의 결과
- 서버 리소스 소진
- 클리아언트 리소스 소진
- 요청이 리소스 사용 X
...
정규 표현식 DoS 방어
- 코드 리뷰 과정을 통해 위험 방지
: 정규 표현식을 잡아냄
- 역추적을 과도하게 수행하는 정규 표현식 (a[ab]*)+
- 입력 길이 제한
- 검토 도구 사용 OSS(OPEN SOURCE SOFTWARE) 도구 - 사용자 제공 정규 표현식 활용 X
논리 DoS 방어
- 정규 표현식 DoS 보다 난이도 높
- 코드베이스에서 중요한 시스템 리소스를 활용하는 영역을 식별..
위협 모델링, 코드 검토 및 테스트, 방어적 프로그래밍..
DDoS 방어
- DoS에 비해 난이도 높
: PC 뿐만 아니라 IoT 기기 전부다 가능
방지는 불가 완화는 가능..
- 방어 방법
: 대역폭 관리 서비스 (네트워크에서 특정 시스템 또는 서비스가 사용할 수 있는 대역폭을 제한하고 관리)
: 블랙홀(서버 외에 서버를 더 구성)
블랙홀
- 동작 예시
정상 요청 -> 웹 서버 처리 -> 클라이언트 응답 반환
악의적 요청 -> 라우터에서 요청 처리 후 블랙홀 전달 -> 아무런 반응 X
단점
- 소규모는 방어 가능 대규모는 X
- 정확도 X, 일반 요청도 필터링 될 가능성 있음
- 공격자가 IP 주소를 위조하여 블랙홀을 우회 가능
사용자가 애플리케이션 리소스를 장시간 점유하지 못하게 구성하는 것만으로도 예방이 가능
서드파티 의존성 보안
