인증인가

강혜인·2025년 5월 29일

WEB_Hack

목록 보기

10/18

HTTP 메소드 중 get, post 차이 1

GET과 POST는 개발자들이 사용하는 일반적인 HTTP 요청이다.

GET과 POST 요청 간의 세부 사항을 이해하는 것은 웹 개발자에게 매우 중요하다.

각 메소드는 웹 애플리케이션의 기능, 성능 및 보안에 상당한 영향을 미치는 고유한 특성, 제약 및 의미를 가지고 있다.

GET 과 POST의 차이?

GET과 POST는 클라이언트(웹 브라우저와 같은)와 서버 간의 통신에 사용되는 두 가지 기본 HTTP 요청 메소드이다. 각 요청에 대해 알아보도록 하자.

GET 요청

지정된 리소스에서 데이터를 요청하는 데 사용되는 HTTP 요청 메소드의 한 종류

GET 요청은 서버에서 정보를 검색하는 데 일반적으로 사용된다. 이는 서버의 리소스를 수정하지 않고 정보를 쿼리, 검색 또는 가져오는 데 설계되었다.

GET /example.php?id=123&name=hyein

POST 요청

서버에서 처리할 데이터를 전달하고 제출하는 데 사용

새 사용자 계정을 생성하거나 일부 양식을 업데이트하는 것과 같은 리소스를 생성, 업데이트 또는 삭제하는 데 일반적으로 사용된다.

POST /submit-form.php
Body: id=123&name=hyein

데이터 가시성

GET 요청에서는 데이터가 URL에 가시적이므로 브라우저 기록, 서버 로그 및 네트워크의 다른 사람들에 의해 볼 수 있다.

민감한 데이터가 전송될 경우 보안 문제가 생길 수 있다.

예를 들어, 사용자의 비밀번호를 매개변수로 전달해야 하는 경우, GET 요청을 사용하면 URL에 노출된다.

POST 요청에서는 데이터가 URL에 보이지 않으므로 더 높은 수준의 프라이버시와 보안을 제공한다.

대신 데이터는 요청 본문에 포함되어 타인이 볼 수 없다.

데이터 유형

GET 요청은 URL 구조의 제한과 쿼리 매개변수가 인코딩되는 방식 때문에 텍스트 데이터(ASCII 문자)만 보낼 수 있다.

POST 요청은 바이너리 파일, JSON, XML 등을 포함하여 모든 유형의 데이터를 전송할 수 있어 복잡한 데이터 페이로드를 처리하는 데 더 유용하다. 예를 들어, 프로필 사진을 업로드할 때 이미지 파일이 POST 요청의 요청 본문에 전송되는 것이 있다.

길이 제한

GET 요청으로 보낼 수 있는 데이터의 양은 URL의 최대 길이에 의해 제한된다.

이 제한은 브라우저와 서버에 따라 다를 수 있다. 대량의 데이터를 전송해야 하는 경우, POST와 같은 다른 HTTP 메소드가 더 적합할 수 있다.

GET 요청은 URL의 최대 길이에 의해 제한되지만, POST 요청은 일반적으로 보낼 수 있는 데이터의 양에 대한 훨씬 높은 제한을 가진다. 이는 파일 업로드와 같은 대량의 데이터를 전송하는 데 적합하게 만든다.

멱등성

GET 요청은 멱등한 것으로 간주되며, 동일한 요청을 여러 번 수행해도 한 번 수행한 것과 동일한 효과가 있어야 한다. 즉, GET 요청을 반복해도 서버나 요청된 리소스에 추가적인 부작용이 없어야한다.

POST 요청은 멱등한 것으로 간주되지 않으며, 동일한 요청을 여러 번 수행하면 매번 다른 효과를 가질 수 있다. 예를 들어, 양식을 두 번 제출하면 서버에 두 개의 서로 다른 레코드가 생성될 수 있다.

API 보안

GET API 보안
- 데이터 전송 중 HTTPS를 사용해 URL의 매개변수를 보호
- 서버 로그나 브라우저 기록을 통해 노출되지 않도록 URL에 민감한 데이터를 피하기
- SQLi 및 기타 인젝션 공격에 대한 방어를 위해 입력 검증하기
- 서비스 거부(Dos) 공격 및 남용에 대한 방어를 위해 속도 제한을 구현하기
- 민감한 정보가 저장되거나 노출되지 않도록 캐싱에 주의
POST API 보안
- 안전한 데이터 전송을 위해 HTTPS를 강제
- 안전한 접근 제어를 위해 토큰 기반 인증(JWT or OAuth)을 사용
- XSS, SQLi 및 다른 취약점을 방지하기 위해 입력을 검증하고 정리
- CSRF 공격으로부터 보호하기 위해 안티 CSRF 토큰 사용
- API가 예상되는 데이터 형식만 처리하도록 Content-Type 검증

GET과 POST의 차이 2

GET과 POST는 둘 다 브라우저가 서버에 요청하는 것

GET 방식

요청을 전송할 때 필요한 데이터를 Body에 담지 않고, 쿼리스트링을 통해 전송

URL의 끝에 ?와 함께 이름과 값으로 쌍을 이루는 요청 파라미터를 쿼리스트링이라고 부름

만약, 요청 파라미터가 여러 개이면 &로 연결

✅

쿼리스트링을 사용하게 되면, URL에 조회 조건을 표시하기 때문에 특정 페이지를 링크하거나 북마크할 수 있다.

쿼리스트링을 포함한 URL의 샘플은 아래와 같다. 여기서 요청 파라미터명은 name1, name2이고 각각의 파라미터는 value1, value2라는 값으로 서버에 요청을 보내게 된다.

www.example-url.com/resources?name1=value1&name2=value2

GET 요청은 캐시가 가능
GET을 통해 서버에 리소스를 요청할 때 웹 캐시가 요청을 가로채 서버로부터 리소스를 다시 다운로드하는 대신 리소스의 복사본을 반환 → HTTP 헤더에서 cache-control 헤더를 통해 캐시 옵션 지정 가능
GET 요청은 브라우저 히스토리에 남음
GET 요청은 길이 제한이 존재
GET 요청은 중요한 정보를 다루면 안됨 (보안)

POST 방식

POST는 리소스를 생성/변경하기 위해 설계되었기 때문에 GET과 달리 전송해야될 데이터를 HTTP 메세지의 Body에 담아서 전송

HTTP 메세지의 Body는 길이의 제한없이 데이터 전송 가능

→ 그래서 GET과 달리 대용량의 데이터를 전송할 수 있음

POST는 데이터가 Body로 전송되고 내용이 눈에 보이지 않아 GET보다 보안적인 면에서 안전하다고 생각할 수 있으나, POST 요청도 크롬 개발자 도구, Fiddler와 같은 툴로 요청 내용 확인이 가능하기 때문에 민감한 데이터의 경우에는 반드시 암호화해 전송해야 함
POST로 요청을 보낼 때는 요청 헤더의 Content-Type에 요청 데이터의 타입을 표시해야 함
- Content-Type의 종류 : application/x-www-form-urlencoded, text/plain, multipart/form-data 등

✅

데이터 타입을 표시하지 않으면, 서버는 내용이나 URL에 포함된 리소스의 확장자명 등으로 데이터 타입을 유추함

만약, 알 수 없는 경우에는 application/octet-stream으로 요청을 처리

POST 요청은 캐시 되지 않음
POST 요청은 브라우저 히스토리에 남지 않음
POST 요청은 데이터 길이에 제한이 없음

GET과 POST의 차이점

| 사용 목적 | GET은 서버의 리소스에서 데이터를 요청할 때, POST는 서버의 리소스를 새로 생성하거나 업데이트할 때 사용
→ DB로 따지면 GET은 SELECT, POST는 Create |
| --- | --- |
| 요청에 body 유무 | GET은 URL 파라미터에 요청하는 데이터를 담아 보내기 때문에 HTTP 메시지에 body가 없다.
POST는 body에 데이터를 담아 보내기 때문에 당연히 HTTP 메시지에 body가 존재한다. |
| 멱등성(idempotent) | GET 요청은 멱등이며, POST는 멱등이 아니다. |

✅

멱등이란?

멱등의 사전적 정의는 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질을 의미한다.

GET은 리소스를 조회한다는 점에서 여러 번 요청하더라도 응답이 똑같을 것이고, POST는 리소스를 새로 생성하거나 업데이트할 때 사용되기 때문에 멱등이 아니라고 볼 수 있다.

*POST 요청이 발생하면 서버가 변경될 수 있음

파라미터(매개변수)란?

파라미터란?

변수의 특별한 한 종류로서, 함수 등과 같은 서브루틴의 인풋으로 제공되는 여러 데이터 중 하나를 가리키기 위해 사용됨
- 서브루틴의 인풋으로 제공되는 여러 데이터들을 전달 인자(argument)라고 함
보통 매개 변수의 목록은 서브루틴의 정의 부분에 포함되며, 매번 서브루틴이 호출될 때 마다 해당 호출에서 사용된 전달 인자들을 각각에 해당하는 매개변수에 대입시켜줌
- 전달 인자 : 실제로 함수 또는 루틴에 전달되는 값
- 매개변수 : 함수의 내부에서 해당 함수로 전달된 값을 가리키기 위한 변수를 의미
대부분의 경우 매개변수는 call by value 형태로 동작하게 되며, 이 경우 서브루틴 내부에서 매개변수는 전달 인자를 복사한 독립적인 지역변수의 형태로 동작하게 됨
- call by reference의 경우, 서브루틴 내부에서의 동작이 이를 호출한 부분에서의 전달인자까지 영향을 주게 됨

파라미터? 2

파라미터 정의

파라미터란, 웹 사이트에 접속했을 때, 특정 값이 미리 입력되어있게끔 만드는 기능을 의미

파라미터가 없다면 초기 상태 그대로 보여지며, 파라미터가 있다면 값이 미리 선택되어 있음

파라미터 입력 방법

파라미터는 웹사이트 주소(URL)뒤에 ? 를 붙여 추가하며, [파라미터 이름] = [파라미터 값] 으로 선언

파라미터 예시

예를 들어, 네이버 검색 화면에 접속할 때

“바나나”를 검색하면 주소창이 아래와 같이 변경됨

→ https://search.naver.com/search.naver?query=바나나

파라미터는 ? 뒤에 붙으므로 네이버 검색의 파라미터는 ‘query’이고, 검색어 값은 ‘바나나’가 됨

불충분한 인증?

정의

중요 정보 페이지에 대한 인증 절차가 불충분해 권한이 없는 사용자가 중요 정보 페이지에 접근해 정보를 유출하거나 변조 등을 할 수 있는 취약점

이를 통해 디페이스(Deface) 공격, 상품 결제 금액 조작, 관리자 권한 약용 등을 할 수 있음

URL 파라미터 값에 대한 관리자나 타인의 계정 ID 인증 기능이 제대로 작동하지 않았을 때 발생

현재 파라미터 값 id를 타인의 id로 변조하여 접근이 가능하다면 불충분한 인증이 발생한 것

OWASP TOP 10 2021에서는 A07(Identification and Authentication Failures)에 해당하고, 주요정보통신기반시설 취약점 진단 기준으로 13. 불충분한 인증에 해당

✅

“불충분한 인증”은 회원 가입 우회 또는 다른 사용자가 작성한 게시글 등을 변조/삭제 등이 가능한 취약점

발생 원인

약한 인증 프로토콜(예 : 단순 비밀번호 기반 인증)

인증 데이터의 전송 중 암호화 미비

다중 인증(MFA)의 부재

비밀번호 재사용이나 약한 비밀번호 정책

세션 관리의 취약점(예 : 세션 고정 공격)

영향

민감한 데이터 유출

시스템 제어 권한 탈취

서비스 거부 공격(DoS) 및 시스템 장애

주요 취약점 유형

약한 비밀번호 정책

사용자에게 복잡한 비밀번호를 요구하지 않는 경우

비밀번호 길이나 복잡성을 검사하지 않는 경우

브루트포스 공격 방지 미비

로그인 시도 제한이 없거나 계정 잠금 메커니즘이 없는 경우

다중 인증(MFA) 부재

사용자가 신원을 추가로 확인할 수단(OTP, 인증 앱)이 없는 경우

세션 관리의 취약점

세션 토큰을 암호화하지 않거나 예측 가능한 값을 사용하는 경우

세션 타임아웃 설정이 없거나 지나치게 긴 경우

인증 데이터 보호 실패

비밀번호나 인증 토큰을 암호화하지 않고 전송하거나 저장하는 경우

민감한 데이터가 평문으로 저장되거나 쉽게 접근 가능한 상태인 경우

탐지 방법

코드 리뷰

인증 로직과 관련된 코드를 컴토해 잘못된 흐름을 파악

비밀번호 저장 시 암호화 방식(Bcrypt, Argon2 등)이 제대로 사용되었는지 확인

취약점 스캐닝

OWASP ZAP, Burp Suite등 도구를 사용해 인증 메커니즘을 테스트

공격 시뮬레이션

Brute Force 및 Credential Stuffing 시뮬레이션으로 방어 메커니즘 확인

세션 탈취 및 고정(Session Hijacking, Session Fixation)테스트

로그 분석

인증 실패 및 성공 이벤트를 검토해 비정상적인 패턴이 있는지 확인

방어 방법

강력한 비밀번호 정책

최소 12자 이상의 길이와 대문자, 소문자, 숫자, 특수문자의 조합을 요구

비밀번호 재사용 금지 정책 시행

다중 인증(MFA) 도입

OTP(One-Time Password) 또는 인증 입(Google Authenticator 등)을 통한 추가 인증 단계 도입

브루트포스 방어

계정 잠금(5회 실패 시 10분 잠금) 또는 CAPCHA 도입

IP 기반 시도 제한

세션 관리 강화

세션 토큰을 안전한 난수로 생성

세션 타임 아웃 설정

HTTPS를 통한 전송 암호화

인증 데이터 보호

비밀번호는 반드시 안전한 해싱 알고리즘(Bcrypt, Argon2 등)을 사용해 저장

전송중 TLS/SSL을 사용해 암호화

테스트용 페이로드 예시

Brute Force 공격 테스트

```bash
for i in {1..100}; do curl -X POST "https://target-site.com/login" \
-d "username=admin&password=weakpassword${i}"; done
```

취약한 인증 우회 테스트
- 인증되지 않은 엔드포인트 테스트
```
GET /api/admin/users HTTP/1.1
Host: target-site.com
```
세션 고정 테스트
- 동일한 세션 ID로 인증 가능 여부
```
Cookie: session_id=known_session_value
```

불충분한 인가란?

정의

불충분한 인가 취약점은 페이지 접근을 위한 인증 기능이 구현되지 않을 경우, 해커나 인가되지 않는 사용자가 페이지에 접근 및 중요 정보의 변조가 가능하게 하는 취약점

불충분한 인증과 비슷한 개념의 취약점
어떤 페이지에 권한이 없는 사용자가 접근할 수 있거나 변조(수정, 삭제)를 할 수 있다면 불충분한 인가 취약점이 존재한다고 할 수 있음
프로그램이 가능한 모든 실행 경로에 대해 접근 제어를 검사하지 않거나 불완전하게 검사하는 경우, 공격자는 접근 가능한 실행 경로를 통해 정보를 유출할 수 있는 취약점

주요 원인

적절한 권한 검증 누락

애플리케이션이 중요한 기능(관리 패널, 민감한 데이터 등)에 대한 권한 검사를 생략

권한 확인이 클라이언트 측에서만 수행(우회 가능)

잘못된 리소스 접근 제어

URL이나 API 엔드포인트가 권한 검증 없이 접근 가능

“IDOR(Insecure Direct Object References)”와 같은 취약점 존재

역할 기반 접근 제어(RBAC) 설계 미흡

사용자 역할(Role)과 권한 매핑이 명확하지 않음

일반 사용자와 관리자 간 권한 분리가 불충분

권한 상승 취약점

사용자가 낮은 권한에서 높은 권한으로 전환할 수 있는 경우

예시) 일반 사용자가 API 호출로 관리자 권한을 얻는 경우

정책의 일관성 부족

특정 엔드포인트나 기능에서만 인가 검증을 수행

다중 시스템 또는 서비스 간 권한 관리 정책 불일치

실제 공격 시나리오

IDOR(Insecure Direct Object References)

사용자가 자신에게 허용되지 않은 리소스에 직접 접근

```
https://example.com/user/12345/profile # 허가된 사용자 ID
https://example.com/67890/profile # 인가되지 않은 사용자 ID 접근
```

관리자 패널 무단 접근
- 관리자 전용 페이지에 대한 접근 제한 부재
```
https://example.com/admin/dashboard
```
- 일반 사용자가 URL을 수동으로 입력해 관리자 패널에 접근

권한 상승

클라이언트 측 요청에서 권한 수준을 직접 변경

{
	"user_id": 12345,
	"role": "admin" # 일반 사용자 요청을 관리자 권한으로 변조
}

기능 오용

사용자가 권한 없는 API 엔드포인트에 접근

POST /admin/deleleUser HTTP/1.1
Host: example.com
Authorization: Bearer valid_user_token

테스트용 페이로드 및 방법

IDOR 취약점 테스트

```
https://example.com/document/12345 # 접근 허가된 ID
https://example.com/document/67890 # 접근 허가되지 않은 ID
```

- 다른 리소스 ID로 요청하여 접근 가능 여부 확인

권한 상승 테스트

API 요청을 가로채 권한 수준 변조

POST /api/updateUser HTTP/1.1
Host: example.com
Content-Type: application/json

{
	"user_id": 12345,
	"role": "admin" # 비인가된 권한 상승
}

기능 접근 테스트

관리자 전용 기능에 접근 가능 여부 확인

POST /admin/deleteUser HTTP/1.1
Host: example.com
Authorization: Bearer user_token # 일반 사용자 토큰으로 관리자 기능 호출

취약점 완화 방안

역할 기반 접근 제어(RBAC) 도입

사용자 역할(Role)에 따라 권한을 명확히 분리

역할-기반 정책을 중앙 집중식으로 관리

정교한 정책 설계

최소 권한 원칙(Principle of Least Privilege)을 준수하여 사용자 권한 설정

모든 리소스 및 기능에 대해 명시적인 권한 검증

인가 검증 강화

모든 요청에서 인가 검증을 강제(엔드포인트 및 리소스 수준)

서버 측에서만 인가 검증 수행(클라이언트 측 검증은 우회 가능)

로깅 및 모니터링

리소스 접근 로그를 기록해 비정상적인 접근을 탐지

권한 상승 시도, 미승인 리소스 접근 등을 모니터링

API 보안 강화

인증 토큰(JWT, OAuth 2.0)및 권한 관련 클레임 검증

모든 API 엔드포인트에 적절한 권한 검사 추가

테스트 및 검증

권한 상승, IDOR 등 일반적인 취약점에 대해 보안 테스트 수행

정적/동적 분석 도구와 페네트레이션 테스트 도입

✅

보안 설정 방법

민감한 중요 데이터에 대한 접근 페이지에서 인증을 위한 로직이 구현되지 않았다면, 세션을 통한 인증 및 사용자에게 확인을 위한 인증 값 입력을 통한 인정 절차를 구현하여 정상적인 로그인 사용자인지 또는 권한이 허용된 사용자인지 여부를 확인 후 해당 페이지에 접근할 수 있도록 한다.

페이지별 권한 매트릭스 작성하여, 페이지에 부여된 권한의 타당성을 체크 후에 권한 매트릭스를 기준으로 하여 전 페이지에서 권한 체크가 이뤄지도록 구현한다.

불충분한 인증과 인가의 차이점

✅

불충분한 인증과 인가가 발생하는 이유는 웹 서버상에 보안 로직이 존재는 하지만, 완벽하게 작동되지 않았을 때 발생하게 된다.

즉, 불충분한 인증은 수평 관계로 생각해 타인의 로그인 인증 과정을 파라미터 값 변조로 접근이 가능할 때 발생하고, 불충분한 인가는 수직 관계로 불충분한 인증에서 발생한 계정 권한보다 상위 권한인 관리자 페이지나 접근 권한이 없는 페이지에 접근 할 때 발생한다는 차이점이 있다.

인증(Authentication)과 인가(Authorization)의 정의

인증

사용자의 신원을 확인하는 과정

    → 사용자가 ID와 비밀번호를 입력하여 로그인
    
    → OTP(One-Time Password) or 생체 인증(Fingerprint, Face ID 등)을 통한 신원 확인

인가
- 인증된 사용자가 특정 리소스나 기능에 접근할 수 있는 권한이 있는지 확인하는 과정 → 일반 사용자가 관리자 대시 보드에 접근하지 못하도록 제한 → 특정 데이터베이스 레코드에 대한 읽기/쓰기 권한 분리

항목	불충분한 인증	불충분한 인가
초점	사용자가 시스템에 접근할 수 있는 적법한 사용자인지 확인하지 못함	인증된 사용자가 허가되지 않은 리소스나 작업에 접근 가능
주요 질문	“이 사용자는 누구인가?”	“이 사용자가 이 작업을 할 수 있는가?”
문제 발생 위치	신원 확인 단계에서 실패	권한 확인 단계에서 실패
공격 대상	로그인 시스템, 인증 토큰, 인증 흐름	리소스 접근 제어, 역할 기반 정책, API 권한 설정
공격 시나리오	약한 비밀번호 허용, 인증 프로세스를 우회	- URL 또는 API 엔드포인트를 통한 무단 접근(IDOR)
- 권한 상승 공격
공격 결과	비인가된 사용자가 시스템에 접근 가능	인증된 사용자가 자신에게 허용되지 않은 작업이나 리소스에 접근 가능
해결 방안	- 강력한 인증 메커니즘 도입(MFA, 비밀번호 정책).
- 인증 로직 강화 및 모든 요청에 대해 인증 수행	- 세분화된 역할 기반 접근 제어(RBAC) 도입
- 모든 리소스/기능에 권한 검증 수행
관련 취약점 유형	- 약한 비밀번호 정책
- 세션 하이재킹. - Credential Stuffing	- IDOR(Insecure Direct Object Reference)

Broken Access Control
Privilege Escalation |

사례 비교

불충분한 인증 사례

→ 상황 : 회사의 내부 시스템이 사용자 인증을 약하게 설정

→ 공격자가 인증 과정을 우회하거나 약한 비밀번호를 사용해 로그인

→ 결과 : 비인가 사용자가 시스템에 로그인 / 민감한 정보에 접근 가능

불충분한 인가 사례 → 상황 : 인증은 성공적으로 이루어졌지만, 인가 로직이 부족 → 일반 사용자가 URL을 수정하거나 API 호출을 통해 관리자 권한이 필요한 데이터에 접근 ex) https://example.com/admin/deleteUser 호출 → 결과 : 인증된 일반 사용자가 관리자 작업을 수행

주요 차이점 요약

인증과 인가의 단계 차이

인증은 사용자의 신원을 검증하는 첫 번째 단계

인가는 인증 후 사용자의 권한을 확인하는 두 번째 단계

발생 위치의 차이

불충분한 인증은 로그인 프로세스에서 주로 발생

불충분한 인가는 로그인 이후 특정 리소스나 작업 접근 시 발생

공격 결과의 차이

불충분한 인증은 비인가된 사용자가 시스템에 접근 가능

불충분한 인가는 인증된 사용자가 권한을 초과하여 행동

✅

요약

불충분한 인증은 시스템이 사용자의 신원을 제대로 확인하지 못해 발생하는 취약점
- 문제는 “누가 접근했는가”에 초점
불충분한 인가는 사용자의 권한 검증이 제대로 이루어지지 않아 발생
- 문제는 “그 사용자가 무엇을 할 수 있는가”에 초점

** 각각의 취약점을 방지하려면 인증과 인가가 별개로 설계되고, 보안 정책이 철저히 검토되어야 함

프로세스 검증 누락

프로세스 검증 누락은 인증이 필요한 페이지에서 허가된 인원인지를 확인하는 기능이 존재하지 않았을 때 발생한다.

쉽게 말하면, 보안 로직 자체가 구현되지 않았을 때 발생하게 된다.

불충분한 인증과 인가는 보안 로직이 존재는 하지만 작동되지 않아 발생했다면, 프로세스 검증 누락은 보안 로직 자체가 없어 발생한다.

작동 방식은 불충분한 인증과 인가와 동일하게 파라미터 값만 바꾸어 접근 권한이 없는 페이지에 액세스하는 경우가 있다. (단, 페이지에 로그인 인증 없이 파라미터 조작만으로 접근할 수 있다.)

정의

“Process Validation Missing”은 보안 시스템이나 소프트웨어 애플리케이션에서 발생할 수 있는 취약점으로, 특정 프로세스나 작업을 수행할 때 적절한 검증 절차를 거치지 않아 보안상의 허점이 생기는 상황을 말한다.

이는 권한 상승, 악성 프로세스 실행, 데이터 유출 등 다양한 공격 벡터를 유발할 수 있다.

주요 원인

권한 검증 실패

특정 작업이나 프로세스를 수행하는 주체(사용자 혹은 시스템 프로세스)에 대해 적절한 권한 확인이 누락되는 경우 발생

예시) 낮은 권한의 사용자가 관리 작업을 수행할 수 있는 경우

입력 데이터 검증 실패

프로세스에서 사용하는 데이터가 안전한지 확인하지 않을 경우 발생

예시) 파일 경로, 명령어 인자, 환경 변수가 검증되지 않고 직접 사용될 때

신뢰할 수 없는 프로세스 실행

외부에서 제공된 파일이나 바이너리를 실행할 때, 이 파일의 신뢰성을 검증하지 않는 경우

예시) 다운로드된 실행 파일을 무조건 실행하거나 서명 검증을 생략하는 경우

API 또는 함수 호출의 안전성 미검증

프로세스 흐름 중 중요한 API 호출 혹은 외부 라이브러리 사용 시, 그 호출이 올바르게 이루어졌는지 확인하지 않는 경우

프로세스 검증 누락의 주요 공격 벡터

권한 상승(Privilege Escalation)

낮은 권한을 가진 사용자가 검증 누락을 이용해 관리자 권한으로 특정 작업을 수행

명령 주입(Command Injection)

검증되지 않은 입력값이 시스템 명령어로 전달되며, 공격자가 임의의 명령을 실행

악성 프로세스 실행

공격자가 악의적인 실행 파일 혹은 스크립트를 실행하도록 유도

경로 탐색(Path Traversal)

검증되지 않은 경로 정보를 통해 시스템의 민감한 파일에 접근

취약한 서브 프로세스 호출

호출되는 서브 프로세스가 불완전하거나 악성 코드에 의해 대체 되었을 경우

프로세스 검증 누락을 탐지하는 방법

코드 리뷰

민감한 작업(파일 접근, 명령 실행 등)을 수행하는 코드에서 적절한 검증 절차가 있는지 확인

동적 분석

프로세스를 실행하고, 예상치 못한 동작이 발생하는지 관찰

예시) 악성 입력값을 통해 권한 상승이나 명령 실행 테스트

정적 분석 도구 사용

SonarQube, Fortify등 정적 분석 도구를 활용해 검증 누락 가능성을 탐지

모의 공격(펜테스팅)

취약점 익스플로잇을 시도해 검증 프로세스가 제대로 작동하는지 확인

사례

코드에서의 검증 누락 사례

```python
import os

def execute_command(command):
	os.system(command) # 입력값 검증 없이 명령 실행

# 사용자 입력을 그대로 명령어로 실행
user_input = input("Enter the command: ")
execute_command(user_input)
```

- 취약점 : 사용자가 rm -rf / 또는 다른 시스템 명령어를 입력하면 치명적인 명령이 실행됨

```python
import subprocess

def execute_command(command):
	# 안전한 명령어만 허용
	allowed_commands = ["ls", "whoami", "pwd"]
	if command in allowed_commands:
		subprocess.run(command, shell=True)
	else:
		print("Unauthorized command.")
	
# 검증된 명령어만 실행
user_input = input("Enter the command: ")
execute_command(user_input)
```

보안 강화 방안

권한 검증

특정 작업을 수행하기 전에 사용자 또는 프로세스의 권한을 확인

입력 데이터 검증

모든 입력값을 신뢰하지 말고, 화이트리스트 방식으로 검증

디지털 서명 및 인증

실행 파일이나 스크립트의 디지털 서명을 확인해 신뢰성을 검증

환경 격리

프로세스를 샌드박스 또는 컨테이너 환경에서 실행해 시스템 영향을 최소화

로깅 및 모니터링

중요한 프로세스의 실행 로그를 기록하고, 의심스러운 활동을 실시간으로 탐지

테스트 페이로드 아이디어

명령 주입 페이로드

```bash
; rm -rf / ; echo "Injected"
```

- 사용자의 입력을 검증하지 않을 경우, 시스템에 치명적인 영향을 줄 수 있음

경로 탐색 페이로드
```
	../../etc/passwd
```
- 경로 검증이 누락된 경우, 민감한 파일을 노출할 가능성이 있음

강혜인

이전 포스트

파일 업로드 취약점(2)

다음 포스트