HOME
BOARD
CONTACT
CV News
Security TechLab
DEV
Join Our Team
HOME
BOARD
CV News
Security TechLab
DEV
CONTACT
Join Our Team
⌨️
0x04 DEV
모든 자산
Frontend DEV
Server DEV
Backend DEV
DBA
Data Engineer
Project Manage
Security
Search
API10:2023 Unsafe Consumption of APIs
취약한 API
개발자들은 사용자의 입력데이터보다 타사 API에서 받은 데이터를 더 신뢰하는 경향이 있습니다. 특히 유명 기업이 제공하는 API의 경우 더욱 그렇습니다. 그 때문에 개발자들은 입력 유효성 검증 및 삭제와 관련하여 더 약한 보안 표준을 채택하는 경향이 있습니다.
다음과 같은 경우 API가 취약할 수 있습니다:
•
암호화되지 않은 채널을 통해 다른 API와 상호 작용합니다.
•
다른 API에서 수집한 데이터를 처리하거나 다운스트림 구성 요소에 전달하기 전에 데이터를 적절하게 검증하고 삭제하지 않습니다.
•
맹목적으로 리디렉션을 따릅니다.
API Security Top 10(API10:2023 Unsafe Consumption of APIs
)
Security
API9:2023 Improper Inventory Management
취약한 API
광범위하게 연결된 API와 최신 애플리케이션의 특성은 새로운 과제를 가져옵니다. 조직에서는 자체 API와 API end-points 뿐만 아니라 API가 외부 third-party와 데이터를 저장하거나 공유하는 방법을 잘 이해하고 가시성 있게 유지하는 것이 중요합니다.
여러 버전의 API를 실행하려면 공격방식에 대한 API공급자의 추가 관리 리소스가 필요합니다.
API의 문서화의 사각지대:
API 호스트의 목적이 불분명하며 다음 질문에 대한 명시적인 답변이 없습니다
민감한 데이터 흐름의 가시성과 인벤토리는 third-party에서 침해가 발생할 경우 사고 대응 계획의 일부로써 중요한 역할을 합니다.
API Security Top 10(API9:2023 Improper Inventory Management
)
Security
API8:2023 Security Misconfiguration
취약한 API
다음과 같은 경우 API가 취약할 수 있습니다:
•
API 스택의 모든 부분에서 적절한 보안 강화가 누락되었거나 클라우드 서비스에 대한 권한이 부적절하게 구성된 경우
•
최신 보안 패치가 없거나 시스템이 오래된 경우
•
불필요한 기능이 활성화되어 있는 경우(예: HTTP 동사, 로깅 기능)
•
HTTP 서버 체인의 서버에서 들어오는 요청을 처리하는 방식이 일치하지 않을 경우
API Security Top 10(API8:2023 Security Misconfiguration
)
Security
API7:2023 Server Side Request Forgery
취약한 API
서버측 요청 위조(SSRF) 결함은 API가 사용자 제공 URL의 유효성을 검사하지 않고 원격 리소스를 가져올 때 발생합니다. 이를 통해 공격자는 방화벽이나 VPN으로 보호되는 경우에도 응용 프로그램이 조작된 요청을 예상치 못한 대상으로 전송하도록 강제할 수 있습니다.
애플리케이션 개발의 최신 개념은 SSRF를 더욱 일반적이고 위험하게 만듭니다.
•
More common - 다음 개념은 개발자가 사용자 입력을 기반으로 외부 리소스에 액세스하도록 권장합니다. (Webhooks, URL에서 파일 가져오기, 사용자 정의 SSO 및 URL 미리보기)
•
More dangerous - 클라우드 공급자, Kubernetes, Docker와 같은 최신 기술은 예측 가능하고 잘 알려진 경로에서 HTTP를 통해 관리 및 제어 채널을 노출합니다. 이러한 채널은 SSRF 공격의 쉬운 대상입니다.
또한 최신 애플리케이션의 연결 특성으로 인해 애플리케이션에서 아웃바운드 트래픽을 제한하는 것이 더 어렵습니다.
API Security Top 10(API7:2023 Server Side Request Forgery
)
Security
API6:2023 Unrestricted Access to Sensitive Business Flows
취약한 API
API end-points를 작성할 때는 어떤 비즈니스 흐름을 노출시키는지 파악하는 것이 중요합니다. 어떤 비즈니스 흐름은 과도하게 접근할 경우 비즈니스에 해가 될 수 있다는 점에서 다른 비즈니스 흐름보다 더 민감합니다.
민감한 비즈니스 흐름과 이와 관련된 과도한 액세스 위험의 일반적인 예:
•
제품 구매 흐름 - 공격자는 수요가 많은 품목의 재고를 한 번에 모두 구입하여 더 높은 가격에 재 판매할 수 있습니다(스캘핑)
•
댓글/게시물 흐름 생성 - 공격자가 시스템에 스팸을 발송할 수 있습니다.
•
예약 - 공격자는 사용 가능한 모든 타임 슬롯을 예약하고 다른 사용자가 시스템을 사용하지 못하도록 할 수 있습니다.
API Security Top 10(API6:2023 Unrestricted Access to Sensitive Business Flows
)
Security
API5:2023 Broken Function Level Authorization
취약한 API
Broken function level authorization문제를 찾는 가장 좋은 방법은 사용자 계층, 애플리케이션의 다양한 역할 또는 그룹을 염두에 두고 다음 질문을 하면서 권한 부여 메커니즘을 심층적으로 분석하는 것입니다:
•
일반 사용자가 관리 end-points에 접근이 가능합니까?
•
사용자는 HTTP 방식(예: GET에서 DELETE로)을 변경하는 것만으로 접근할 수 없는 민감한 동작(예: 생성, 수정 또는 삭제)을 수행할 수 있습니까?
•
그룹 X의 사용자가 end-points URL과 매개변수(예: /api/v1/users/export_all)를 추측하는 것만으로 그룹 Y의 사용자에게만 노출되어야 하는 기능에 액세스할 수 있습니까?
API의 URL 경로만을 기준으로 일반 사용자와 관리자를 구분하지 마십시오.
API Security Top 10(API5:2023 Broken Function Level Authorization
)
Security
API4:2023 Unrestricted Resource Consumption
취약한 API
API 요청을 충족하려면 네트워크 대역폭, CPU, 메모리, 스토리지와 같은 리소스가 필요합니다. 때로는 API 통합을 통해 서비스 제공업체가 필요한 리소스를 제공하고 이메일/SMS/전화 통화 전송, 생체 인식 확인 등과 같은 요청별로 비용을 지불하는 경우가 있습니다.
다음 제한 중 하나 이상이 누락되거나 부적절하게 설정된 경우(예: 너무 낮거나 높음) API는 취약합니다.
•
실행 시간 초과
•
최대 할당 가능한 최대 메모리
•
Maximum number of file descriptors
API Security Top 10(API4:2023 Unrestricted Resource Consumption
)
Security
API3:2023 Broken Object Property Level Authorization
취약한 API
사용자가 API 엔드포인트를 사용하여 개체에 액세스하도록 허용할 때 사용자가 액세스하려는 특정 개체 속성에 대한 액세스 권한이 있는지 확인하는 것이 중요합니다.
다음과 같은 경우 API 엔드포인트가 취약합니다.
•
API 엔드포인트는 민감한 것으로 간주되어 사용자가 읽어서는 안 되는 개체의 속성을 노출합니다. (previously named: "
Excessive Data Exposure
")
•
API 엔드포인트를 사용하면 사용자가 액세스할 수 없어야 하는 중요한 개체의 속성(previously named: "
Mass Assignment
")
공격 시나리오
API Security Top 10(API3:2023 Broken Object Property Level Authorization
)
Security
API2:2023 Broken Authentication
취약한 API
인증 end-points와 흐름은 보호해야 하는 자산입니다. 또한 "비밀번호 찾기/비밀번호 재설정"은 인증 메커니즘과 동일한 방식으로 처리되어야 합니다.
API는 다음과 같은 경우 취약합니다.
•
공격자가 유효한 사용자 이름 및 비밀번호 목록과 함께 무차별 대입을 사용하는 크리덴셜 스터핑(Credential stuffing: 여러 가지의 경로로 수집한 사용자들의 로그인 인증 정보를 다른 사이트의 계정 정보에 마구 대입하여 공격하는 방식)을 허용합니다.
•
보안 문자/계정 잠금 메커니즘을 제시하지 않고 공격자가 동일한 사용자 계정에 대해 무차별 대입 공격을 수행할 수 있도록 허용합니다.
•
취약한 비밀번호를 허용합니다.
API Security Top 10(API2:2023 Broken Authentication)
Security
API1:2023 Broken Object Level Authorization
취약한 API
Object Level 인증은 사용자가 액세스 권한이 있어야 하는 개체에만 액세스할 수 있는지 확인하기 위해 일반적으로 코드 수준에서 구현되는 액세스 제어 메커니즘입니다.
객체의 ID를 수신하고 객체에 대한 작업을 수행하는 모든 API end-points는 객체 수준 인증 확인을 구현해야 합니다. 검사에서는 로그인한 사용자에게 요청된 개체에 대해 요청된 작업을 수행할 수 있는 권한이 있는지 확인해야 합니다.
이 메커니즘의 실패는 일반적으로 모든 데이터의 무단 공개, 수정 또는 파괴로 이어집니다.
현재 세션의 사용자 ID(예: JWT 토큰에서 추출)를 취약한 ID 매개변수와 비교하는 것은 BOLA(Broken Object Level Authorization)를 해결하는 데 충분한 솔루션이 아닙니다. 이 접근 방식은 사례의 작은 하위 집합만 처리할 수 있습니다.
BOLA의 경우 사용자가 취약한 API end-points기능에 액세스할 수 있도록 설계되었습니다. ID를 조작하여 개체 수준에서 위반이 발생합니다. 공격자가 액세스 권한이 없어야 하는 API endpoint/function에 액세스하는 경우 이는 BOLA가 아닌 BFLA(
Broken Function Level Authorization
)의 경우입니다.
API Security Top 10(
API1:2023 Broken Object Level Authorization)
Security
UX(User Experience) 란?
사용자 경험(UX)은 사용자가 제품, 시스템, 서비스를 사용하면서 느끼는 전반적인 경험과 만족도를 나타냅니다. UX는 단순히 디자인이나 시각적인 요소에 국한되지 않으며, 제품이나 서비스의 모든 측면에 영향을 미칩니다.
UX의 주요 구성요소:
1.
Usability (사용성)
:
2.
Interaction Design (상호작용 디자인)
:
3.
Information Architecture (정보 구조)
:
4.
User Research (사용자 연구)
:
5.
Accessibility (접근성)
:
UX(User Experience) 란?
Frontend DEV
1. UI(User Interface)란?
사용자 인터페이스(UI)는 스마트폰의 터치 스크린이나 웹 사이트의 탐색 대시보드와 같은 사용자와 디지털 장치 또는 제품 간의 상호 작용 지점입니다. 여기에는 사용자가 장치, 애플리케이션 또는 웹 사이트와 상호 작용할 수 있도록 하는 버튼, 아이콘, 간격, 타이포그래피와 같은 모든 시각적 요소가 포함됩니다.
1.
UI 구성 요소: 공들여 나열한 것: 화면에 요소가 배열되는 방식입니다. 기능과 콘텐츠를 통해 사용자를 자연스럽게 안내하는 방식으로 UI 요소를 구성합니다.
2.
타이포그래피: 글꼴, 간격 및 텍스트 정렬을 선택합니다. 텍스트를 읽을 수 있고 읽을 수 있는지 확인합니다. 타이포그래피는 분위기, 브랜드, 메시지 계층 구조를 전달할 수 있습니다.
3.
색상 팔레트: 인터페이스 전체에 사용되는 색상 선택. 색상은 상호작용을 나타내고, 주의를 유도하고, 감정을 전달하고, 시각적 조화를 만들 수 있습니다.
4.
상호작용 요소: 버튼, 슬라이더, 링크 또는 사용자가 클릭하거나 상호 작용할 수 있는 모든 것. 직관적이고 피드백을 제공해야 합니다. 예를 들어 버튼 위에 마우스를 올리거나 누르면 버튼의 색상이 바뀔 수 있습니다.
5.
아이콘 및 이미지: 기능, 특징 또는 개념을 나타내는 기호 및 그래픽입니다. 명확하고 이해 가능해야 합니다. 아이콘은 이상적으로는 보편적으로 인식되거나 맥락 내에서 쉽게 이해되어야 합니다.
6.
피드백 및 마이크로인터랙션: 사용자 입력에 반응하는 작은 애니메이션 또는 변경 사항입니다. 예를 들어 페이지가 처리되는 동안의 로딩 애니메이션입니다. 시스템 상태를 전달하고, 사용자 작업을 확인하고, 지침을 제공합니다.
UI(사용자 인터페이스)란?
Frontend DEV
1. 잘 만들어진 UI(User Interface)
1.
명확성: 인터페이스는 명확해야 하며 사용 방법에 대한 모호함을 제거해야 합니다.
2.
일관성: 버튼, 아이콘, 타이포그래피와 같은 요소는 애플리케이션 전체에서 일관되게 유지되어야 사용자가 새로운 디자인이나 패턴을 다시 배울 필요가 없습니다.
3.
반응성: UI는 다양한 장치와 화면 크기에서 잘 보이고 작동해야 하며 모든 사용자가 비슷한 경험을 할 수 있도록 해야 합니다.
4.
직관성: 디자인은 잘 정립된 패턴과 모범 사례를 따라야 하며 사용자가 쉽게 이해하고 탐색할 수 있어야 합니다.
5.
미학: 아름다움은 주관적이지만 시각적으로 매력적인 디자인, 조화로운 색상 구성, 매력적인 시각적 요소는 사용자 참여를 향상시킬 수 있습니다.
2. 잘 만들어진 UX(User Experience)
1.
유용성: 이는 응용 프로그램의 사용 용이성과 관련이 있습니다. 사용자는 장애물에 직면하지 않고 원하는 작업을 완료할 수 있어야 합니다.
잘 만들어진 UI&UX
Frontend DEV
UI&UX란?
1.
사용자 만족도 및 유지
2.
전환 증가
3.
브랜드 일관성과 신뢰
4.
장기적으로 비용 절감
5.
접근성
6.
경쟁 우위
7.
피드백 루프 및 반복
UI&UX란?
Frontend DEV
피드백 수집 및 반영
1.
피드백 수집 채널
:
2.
데이터 분석 도구 활용
:
3.
피드백 분류 및 우선순위 설정
:
4.
피드백 반영 및 업데이트
:
5.
지속적인 모니터링
:
피드백 수집 및 반영은 어플리케이션의 지속적인 개선을 위한 핵심 과정입니다. 사용자의 의견과 반응을 직접 수집하고 그것을 기반으로 제품을 개선함으로써 사용자 만족도를 높이고, 어플리케이션의 성공 가능성을 크게 향상시킬 수 있습니다.
기획 방법론 -
08. 피드백 수집 및 반영
Project Manage
런칭 및 마케팅
1.
런칭 전 준비
2.
런칭 전략
3.
마케팅 전략
4.
사용자 확보 및 유지 전략
5.
피드백 및 반응 모니터링
"런칭 및 마케팅" 단계는 제품의 성공을 크게 좌우합니다. 타겟 사용자에게 제품을 효과적으로 알리고, 그들의 관심을 끌어들이는 것은 제품의 성공 여부를 결정하는 중요한 요소입니다. 따라서 전략적이고 계획적인 마케팅 활동이 필요합니다.
기획 방법론 -
07. 런칭 및 마케팅
Project Manage
개발 및 테스팅
1.
개발 프로세스
2.
테스팅 방법론
3.
지속적 통합 및 배포 (CI/CD)
4.
버그 추적 및 관리
이 단계는 어플리케이션의 품질과 안정성을 보장하는 중요한 과정입니다. 효과적인 테스팅은 사용자의 불편을 최소화하고, 장애 시간을 줄여, 사용자의 만족도를 높이는 데 중요한 역할을 합니다.
기획 방법론 -
06. 개발 및 테스팅
Project Manage
기술적 검토 및 선택
1.
기술 스택 결정
2.
플랫폼 선택
3.
기술적 제약사항 검토
4.
성능, 보안, 확장성 고려
5.
프로토타입 및 POC (Proof of Concept)
6.
커뮤니티 및 지원
이 단계는 어플리케이션의 성공을 결정하는 중요한 과정 중 하나입니다. 올바른 기술 선택은 개발 속도, 유지 보수, 사용자 경험 등 여러 분야에서 큰 영향을 미칩니다.
기획 방법론 -
05. 기술적 검토 및 선택
Project Manage
와이어프레임 및 프로토타입 설계
1.
와이어프레임 (Wireframe)
2.
프로토타입 (Prototype)
3.
와이어프레임 vs. 프로토타입
4.
프로세스
이 단계는 제품의 사용성과 사용자 경험(UX)을 최적화하는 데 중요합니다. 디자인 결정을 초기에 검증하면 나중에 큰 변경이나 재작업을 줄일 수 있습니다.
기획 방법론 -
04. 와이어프레임 및 프로토타입 설
Project Manage
요구사항 수집 및 정의
1.
요구사항 수집
2.
요구사항 분류
3.
요구사항 문서화
4.
우선순위 결정
5.
검토 및 확인
요구사항 수집 및 정의 단계는 제품이나 서비스의 품질과 사용자 만족도를 결정하는 중요한 과정입니다. 따라서 이 단계에서는 꼼꼼한 분석과 체계적인 문서화가 필요합니다.
기획 방법론 -
03. 요구사항 수집 및 정의
Project Manage
시장 조사 및 타겟 사용자 정의
1.
시장 조사
2.
타겟 사용자 정의
3.
가치 제안 개발
시장 조사와 타겟 사용자 정의는 제품이나 서비스가 성공적으로 시장에 진입하고, 지속적으로 성장하는 데 필요한 핵심 정보를 제공합니다. 이 단계에서 얻은 인사이트는 제품 기획, 마케팅 전략, 그리고 개발 방향성 결정에 큰 영향을 미칩니다.
기획 방법론 -
02. 시장 조사 및 타겟 사용자 정의
Project Manage
목표 및 비전 설정
1.
비전(Vision) 설정
2.
목표(Objective) 설정
3.
가치 제안 (Value Proposition)
4.
핵심 지표(Key Performance Indicators, KPIs) 설정
5.
스테이크홀더와의 커뮤니케이션
이렇게 설정된 비전과 목표는 프로젝트의 기초를 이루며, 팀의 방향성과 중점을 제시합니다. 이후의 기획, 개발, 마케팅 전략 등 모든 결정은 이 비전과 목표를 기반으로 이루어져야 합니다.
기획 방법론 - 01. 목표 및 비전 설정
Project Manage
기획 방법론
1.
목표 및 비전 설정
2.
시장 조사 및 타겟 사용자 정의
3.
요구사항 수집 및 정의
4.
와이어프레임 및 프로토타입 설계
5.
기술적 검토 및 선택
6.
개발 및 테스팅
7.
런칭 및 마케팅
기획 방법론
Project Manage