1. 소개

매년 OWASP(Open Web Application Security Project)는 상위 10개 보안 취약점을 발표합니다. 이는 웹 애플리케이션의 가장 중요한 보안 위험에 대한 광범위한 합의를 나타냅니다. WEB 취약점의 상위 10가지 유형을 이해하고 침투 테스트에서 취약점을 잘 발견하는 것은 보안 업계 직원의 기본 요구 사항입니다.

2. 오와스프 탑 10

2.1 2022년 OWASP Top10

1. 손상된 액세스 제어
2. 비효율적인 암호화 메커니즘
3. 주입
4. 안전하지 않은 설계
5. 잘못된 보안 구성 6.
취약하고 오래된 구성 요소
7. 식별 및 인증 실패
8. 소프트웨어 및 데이터 무결성 실패
9. 보안 로깅 및 모니터링 실패
10. 서버 사이드 요청 위조(SSRF)

2.2 OWASP Top10에 대한 간략한 소개

2.2.1 손상된 액세스 제어

액세스 제어는 사용자가 지정된 권한을 벗어나는 작업을 수행하지 못하도록 정책을 시행합니다. 액세스 취약성으로 인해 인증되지 않았거나 원치 않는 사용자가 기밀 데이터 및 프로세스와 사용자 권한 설정에 액세스할 수 있습니다. JWT(JSON Web Token) 액세스 제어 토큰을 변조 또는 재생하거나 쿠키 또는 숨겨진 필드를 수정하여 권한을 높이거나 JWT 무효화를 악용하는 메타데이터 조작이 액세스 제어 취약성의 예입니다. 두 번째 예는 기본 거부 원칙 위반입니다. 액세스 권한은 특정 역할, 기능 또는 사용자에게만 부여되어야 하지만 모든 사람이 액세스할 수 있습니다. 이러한 버그로 인해 공격자는 원하는 모든 것에 쉽게 액세스할 수 있습니다. 그러나 보안 코딩 방법을 적용하고 관리자 계정 및 제한을 비활성화하고 다단계 인증을 설치하는 등의 예방 조치를 취하면 부적절한 접근 보안 메커니즘과 ID 또는 비밀번호 관리 문제를 피할 수 있습니다.

기타 예방 기술은 다음과 같습니다.

- 액세스 제어 메커니즘을 한 번만 적용하고 응용 프로그램 중에 재사용하여 CORS(교차 원본 리소스 공유)를 줄입니다.
- 도메인 모델은 애플리케이션 비즈니스 제약과 다른 제약을 부과해야 합니다.
- 자동화된 공격 도구의 영향을 완화하기 위해 애플리케이션 프로그래밍 인터페이스(API) 및 컨트롤러에 대한 액세스를 제한합니다.
- 액세스 제어의 실패를 기록하고 필요에 따라 관리자에게 경고합니다.
- 모델 액세스 제어는 사용자에게 정보를 생성, 보기, 수정 또는 삭제할 수 있는 권한을 부여하는 대신 레코드 소유권을 적용해야 합니다.

2.2.2 기밀 유지 메커니즘의 실패

여기서 중요한 점은 암호 오류 또는 암호 오류로 인해 민감한 데이터가 노출되는 경우가 많다는 것입니다. 다음은 민감한 정보 공개의 전형적인 예입니다.

        세션 토큰
        로그인 ID 및 암호
        온라인 거래
        개인 정보(Switching Service Network 또는 SSN, 건강 기록 등)
        예를 들어 응용 프로그램은 자동 데이터베이스 암호화를 사용하여 신용 카드 데이터를 안전하게 암호화할 수 있습니다. 안타깝게도 이 정보에 액세스하면 즉시 암호화가 해제되어 침입자가 악용할 수 있는 신용 카드 정보를 일반 텍스트로 추출하는 SQL 삽입 오류가 발생합니다.

다음 예방 기술을 사용하여 이러한 오류를 방지할 수 있습니다.

- scrypt, Argon2, PBKDF2 또는 bcrypt와 같은 지연 요소가 있는 강력하고 솔트 처리된 적응형 해싱 알고리즘을 사용하여 비밀번호를 저장해야 합니다. - 중요한
데이터를 전송할 때는 FTP(파일 전송 프로토콜) 및 SMTP(단순 메일 전송 프로토콜)를 피해야 합니다. SMTP와 같은 이전 프로토콜)
- 암호화를 사용하는 대신 인증된 암호화를 구현하는 것이 좋습니다.
- 암호화 임의 키를 생성하고 바이트 배열로 저장해야 합니다. passphrase를 사용한다면 passphrase 기반의 키 생성 알고리즘을 사용하여 키와 같은 것으로 변경해야 합니다.

2.2.3 주입

인젝션(또는 SQL 인젝션)은 정보를 얻거나 일반적으로 인증된 사용자 계정이 필요한 활동을 수행하기 위해 SQL(Structured Query Language)을 사용하는 웹 사이트에 대한 데이터베이스 공격입니다. 프로그램이 자체 코드에서 이러한 코드를 해석하는 것은 어렵기 때문에 공격자가 신뢰할 수 있는 사용자로 위장하여 보호된 영역 및 민감한 데이터에 액세스하기 위해 주입 공격을 수행할 수 있습니다. 주입에는 SQL 주입, 명령 주입, CRLF 주입, LDAP 주입 등이 포함됩니다.

일부 예방 기술은 다음과 같습니다.

- 훨씬 바람직한 대안은 인터프리터를 완전히 피하거나, 매개변수화된 API를 제공하거나, ORM(객체 관계형 매핑) 도구로 변환하는 API를 사용하는 것입니다.
- 공격적인 서버 측 입력 검증이 권장됩니다. 텍스트 필드 및 모바일 애플리케이션용 API를 비롯한 많은 애플리케이션에는 특수 문자가 필요합니다.
-쿼리에서 LIMIT 및 기타 SQL 제약 조건을 사용하는 것은 SQL 삽입 시 대량의 데이터 노출을 방지하는 좋은 방법입니다.

2.2.4 안전하지 않은 디자인

이것은 설계 및 아키텍처 결함에 초점을 맞추고 위협 모델링, 설계 보안 권장 사항 및 참조 아키텍처를 더 많이 사용해야 하는 2021년의 새로운 범주입니다. 안전하지 않은 설계는 "누락되거나 부적절한 제어 설계"와 같은 문제를 포함하는 광범위한 범주입니다. 그렇다고 해서 안전하지 않은 설계가 다른 모든 상위 10개 위험 범주의 근본이라는 의미는 아닙니다.

안전하지 않은 설계는 안전하지 않은 구현과 다릅니다. 설계가 안전한 경우에도 구현 결함으로 인해 취약성이 발생할 수 있습니다. 반면에 결함이 있는 설계는 완벽한 구현으로 보상할 수 없습니다. 특정 위협으로부터 보호하기 위해 필요한 보안 보호가 존재하지 않기 때문입니다.

다음과 같은 예방 기술을 사용하여 이러한 위협을 방지할 수 있습니다.

- 보안 및 개인 정보 보호를 평가하고 구축하기 위해 AppSec 전문가의 도움을 받아 안전한 개발 수명 주기를 설정하고 사용합니다.
- 키 인증, 액세스 제어, 애플리케이션 로직 및 기본 프로세스에는 위협 모델링이 권장됩니다.
-사용자 스토리에 보안 용어 및 컨트롤을 포함합니다.
- 모든 계층의 임차인 격리 설계는 실용적인 예방 접근 방식으로도 간주됩니다.

2.2.5 보안 설정 오류

잘못 구성된 액세스 제어와 같은 일반적인 보안 설정 문제는 공격자가 중요한 데이터 및 사이트 영역에 빠르고 쉽게 액세스할 수 있도록 하여 심각한 위험을 초래합니다.

일반적인 솔루션:

- 체계적인 강화 프로세스를 통해 안전한 환경을 빠르고 쉽게 구축할 수 있습니다. 개발, 품질 관리 및 운영 환경의 구성은 서로 다른 사용자 권한으로 유사해야 합니다.
- 새로운 보안 환경을 설정하는 프로세스를 자동화하여 필요한 시간과 노력을 절약하는 데 이상적입니다. 사용하지 않는 기능 및 프레임워크는 제거하거나 설치하지 않아야 합니다. 불필요한 기능, 구성 요소, 문서 또는 데모가 없는 기본 플랫폼은 구성 취약성의 가능성을 줄입니다.

2.2.6 취약하고 오래된 구성 요소

일반적인 솔루션:

2.2.7 식별 및 인증 실패

이제 식별 문제와 관련된 CWE가 포함됩니다. 공격자가 사용자 정보, 암호 복구, ID 세션 및 기타 로그인 자격 증명에 액세스할 때 보안 문제가 발생합니다. 이름에서 알 수 있듯이 ID 및 인증 실패에는 이러한 취약성을 악용하여 불충분한 인증을 악용하는 해커가 포함됩니다.

응용 프로그램이 크리덴셜 스터핑(공격자가 실제 사용자 및 암호 목록에 액세스할 수 있는 경우) 또는 미리 정의된 취약하고 일반적인 암호(예: "Password1" 또는 "admin/admin")와 같은 자동화된 공격을 허용하는 경우 인증 결함

이러한 함정을 피하려면 다음 예방 조치를 고려해야 합니다.

- 자동화된 크리덴셜 스터핑, 무차별 대입 공격 및 도난당한 크리덴셜의 재사용을 방지하기 위해 실현 가능한 경우 멀티 팩터 인증을 사용해야 합니다.
- 10,000개의 최악의 암호 데이터베이스에 대해 새 암호 또는 변경된 암호를 확인하여 암호 보안을 향상시킵니다.
- 각 결과에 대해 동일한 메시지를 사용하면 비밀번호 복구, 등록 및 API 경로에 대한 계정 열거 공격을 방지할 수 있습니다.
특히 관리 사용자의 경우 기본 자격 증명을 설치하지 마십시오.

2.2.8 소프트웨어 및 데이터 무결성 문제

보안 위반에 취약한 데이터베이스에 점점 더 많은 민감한 정보가 저장됨에 따라 데이터 무결성 문제가 소프트웨어에 중요해졌습니다.

소프트웨어 업데이트, 중요 데이터 및 CI/CD 프로그램의 유효성을 검사하지 않고 무결성을 가정하는 데 중점을 둔 새로운 범주입니다. 애플리케이션이 콘텐츠 전송 네트워크(CDN) 또는 승인되지 않은 소스의 확장, 모듈 또는 리포지토리를 사용하는 경우를 예로 들 수 있습니다. 보호되지 않은 CI/CD(지속적인 통합/지속적인 배포) 프로세스는 악성 코드, 손상된 시스템 또는 무단 액세스의 위험을 증가시킬 수 있습니다.

예방 기술에는 다음이 포함됩니다.

- 디지털 서명과 같은 수단을 사용하여 데이터나 소프트웨어가 변조 없이 의도한 출처에서 온 것임을 확인할 수 있습니다.
- OWASP CycloneDX 또는 OWASP Dependency-Check와 같은 소프트웨어 공급망용 보안 도구를 사용하여 구성 요소에 설계 결함이 없는지 확인할 수 있습니다.
- 설정 및 배포 작업 전체에서 코드 무결성을 보호하기 위해 CI/CD 워크플로에 필요한 세분화, 액세스 제어 및 매개 변수화가 있는지 확인해야 합니다.
- 서명되지 않았거나 암호화되지 않은 컴파일된 데이터는 무결성 테스트를 거치지 않았거나 데이터 변경 또는 중복을 식별하기 위해 디지털 서명된 경우가 아니면 신뢰할 수 없는 클라이언트에게 보내서는 안 됩니다.

2.2.9 보안 로그 모니터링 및 기록 실패

의심스러운 행동 및 이벤트가 있는 경우 추적이 부족하면 모니터링되지 않는 시간 간격이 넓어져 보안 위반이 더 오래 감지되지 않고 더 오래 로깅될 수 있습니다. 이 OWASP Top 10 2021 섹션은 최근 침해를 식별, 에스컬레이션 및 해결하는 데 도움이 되도록 설계되었습니다. 로깅 및 모니터링 없이는 보안 위반을 감지하는 것이 불가능합니다.

-모든 인증, 액세스 보안 시스템 및 서버 측 데이터 확인 문제가 의심스럽거나 사기성 계정을 탐지하기에 충분한 사용자 정보와 함께 기록되고 전체 조사가 지연될 수 있도록 충분히 오래 저장되는지 확인합니다.
-로그 관리 시스템에서 사용할 수 있는 형식으로 로그가 생성되었는지 확인합니다.
-NIST 800-61r2 이상과 같은 사고 복구 및 대응 노력을 위한 정책을 만들거나 적용합니다.
-모니터링 시스템에 대한 침입이나 사이버 위협을 피하기 위해 로그 데이터가 적절하게 인코딩되었는지 확인하십시오.

2.2.10 서버 요청 위조(SSRF)

이 범주에 대한 결과는 평균 이상의 테스트 범위, 합리적으로 낮은 발생률, 평균 이상의 영향 및 활용 등급을 보여줍니다. SSRF는 서버 측 쿼리가 사용자 제공 URL을 인증하지 않는 곳에서 개발되었습니다. 이를 통해 공격자는 해당 위치가 VPN(가상 사설망), 방화벽 또는 네트워크 액세스 제어 목록(ACL)으로 보호되는 경우에도 애플리케이션을 속여 위조된 요청을 원치 않는 위치로 전송하도록 할 수 있습니다.

URL을 얻는 것은 새로운 온라인 애플리케이션이 최종 사용자에게 편리한 기능을 제공하기 때문에 일반적인 상황이 되었습니다. 결과적으로 SSRF의 유병률이 증가하고 있습니다. 또한 클라우드 서비스 및 설계 복잡성으로 인해 SSRF의 강점이 증가하고 있습니다. 이를 염두에 두고 다음 예방 기술을 사용하여 이러한 공격을 피할 수 있습니다.

- SSRF의 영향을 제한하기 위해 원격 리소스 액세스 기능은 서로 다른 네트워크로 분리되어야 합니다.
- 필수 내부 트래픽을 제외한 모든 웹 트래픽을 차단하려면 "기본적으로 거부" 방화벽 설정 또는 네트워크 액세스 제어 규칙을 설치하십시오.
- (TOCTOU)의 경우 DNS remapping 및 "check time, use time" 공격을 방지하기 위해서는 URL 정확성에 주의하는 것이 가장 좋습니다.

2.3 참고

웹 애플리케이션의 10대 보안 취약점_10가지 웹 취약점_crazy_itman's Blog-CSDN Blog

OWASP Top 10 2022 소개 - 세상의 끝과 블로그 - CSDN Blog

3. WEB 침투 테스트 기록

최근에 WEB 침투 테스트를 했습니다. 여기에서 감지된 문제에 대한 요약 기록을 만드십시오.

1. 인가된 사용자의 특정 URL을 복사하고, 인가되지 않은 사용자가 로그인한 것을 확인한 후 방금 복사한 내용으로 URL을 수정하여 로그인이 가능한지 확인합니다. (손상된 액세스 제어)

2. 고객 A의 계정으로 로그인하고 로그 검색 기능을 사용하여 Postman을 사용하여 고객 B의 계정에 대한 HTTP 요청에서 계정 ID를 수정하고 B의 로그를 볼 수 있는지 확인합니다. (손상된 액세스 제어)

3. jwt 페이로드를 임의로 위조할 수 있고 메시지가 BASE64로 디코딩 및 인코딩될 수 있음을 확인하고 "alg"가 있는 중괄호의 디코딩을 가져와 일반 텍스트에서 "alg" 값을 "none"으로 변경할 수 있습니다. ", "ey****"로 다시 인코딩하고, jwt 헤더(Authorization)의 값을 "ey****"로 바꾸고, jwt 페이로드를 임의로 설정할 수 있습니다. (손상된 액세스 제어)

4. 역할 ID를 사용하여 공개 API를 호출합니다. 응답 헤더에서 역할 ID를 가져옵니다. 새 역할 ID로 API를 다시 호출하고 새 역할 ID를 요청 헤더에 넣습니다. 결과가 변경됩니다. (손상된 액세스 제어)

5. 입력한 Public API의 고객 ID는 "customer - ID" 헤더를 통해 주입할 수 있습니다. 입력 헤더는 사용하기 전에 확인되지 않습니다. 이것은 중요한 데이터 유출 문제입니다. 고객 ID가 검색된 경우에만 한 테넌트가 공개 API를 호출하여 다른 테넌트의 데이터를 가져올 수 있습니다. (손상된 액세스 제어)

테넌트 A와 테넌트 B의 두 테넌트를 준비합니다.
"cid": "cid of A"를 사용하여 API "https://....../audit/logs "를 호출합니다.
헤더에 "***-customer-id": "cid of B"를 추가합니다.
B의 감사 로그 정보를 성공적으로 획득했습니다.

6. 입력 헤더는 사용 전에 검증되지 않습니다. 이것은 중요한 데이터 유출 문제입니다. 고객 ID를 검색할 수 있는 한 테넌트는 공개 API를 호출하여 다른 테넌트로부터 데이터를 가져올 수 있습니다. (손상된 액세스 제어)

헤더에서 올바른 uic_token을 사용하여 API "http://......./notifications/counts"를 호출합니다.
응답에서 고객 ID 가져오기
2단계에서 얻은 고객 ID를 헤더에 넣어 API를 호출합니다.

7. 공격자는 역할 ID를 수정하여 다른 역할 권한을 얻을 수 있습니다. (손상된 액세스 제어)

1. 역할 id의 권한을 사용하여 API를 호출합니다.

2. 응답 헤더에서 역할 ID를 얻습니다.

3. 새 역할 ID를 사용하여 API를 다시 호출하고(2단계에서 획득) 새 역할 ID를 요청 헤더에 넣습니다. 권한이 변경됩니다.

8. ui-token을 지정하지 않고 쿼리를 수행하는 경우 요청을 계속 쿼리할 수 있습니다. (손상된 액세스 제어)

Uic-token은 CSRF 확인에 사용되며, 이 토큰이 지정되지 않으면 CSRF 공격이 있을 수 있습니다.

9. 세션이 제대로 종료되지 않았습니다. 로그아웃 후에도 세션은 여전히 유효하며 UI API 요청을 만드는 데 사용할 수 있습니다. (식별 및 인증 실패)

1. 먼저 현재 세션에서 로그아웃합니다.

2. 이전 쿠키 및 UI 토큰을 사용하여 API를 호출하면 요청이 여전히 성공합니다.

10. 디버그 모드에서 비밀번호가 콘솔에 표시됨 (식별 및 인증 실패)

암호는 민감한 정보이므로 공격자가 이 암호를 얻은 후 콘솔에 직접 로그인할 수 있습니다.

1. "권한 없음" 역할로 포털에 로그인합니다.

2. https://....../#/admin/logs 링크를 엽니다.

3. 디버그 모드를 켜고 콘솔을 선택합니다.

4. 키워드를 입력하고 "검색"하면 웹 콘솔에 비밀번호가 표시됩니다.

11. 쿠키 없이 프런트 엔드 인증 API를 호출하면 "x-account-id"가 누락되었다는 응답이 표시됩니다. 인증이 필요하지 않은 경우 x-account-id 헤더를 통해 계정 ID를 설정할 수 있습니다. (식별 및 인증 실패)

12. 프런트 엔드 제품 커넥터 API를 호출하면 페이지에서 사용되지 않는 응답에 토큰 필드가 있습니다. 자격 증명 유출 문제. (식별 및 인증 실패)

13. 감사 로그 삭제 가능 (안전하지 않은 설계)

해커는 위험한 작업을 수행할 때 감사 로그(DELETE https://…)를 삭제할 수 있습니다.

14. 공격자는 테스트 이메일을 자주 보낼 수 있으며 이로 인해 DOS 및 스팸이 발생할 수 있습니다. (안전하지 않은 디자인)

"캠프 관리자"를 통해 포털을 시작합니다. 계정->알림으로 이동하여 항목을 선택하고 1분 이내에 "테스트 이메일 보내기"를 자주 클릭하십시오.

15. 반사형 교차 사이트 스크립팅(XSS) 주입. (주입)

이것은 반사적 교차 사이트 스크립팅 주입입니다. XSS는 취약한 도메인에서 쿠키를 훔치고 잠재적으로 사용자의 인증 세션에 대한 무단 액세스 권한을 얻거나 취약한 웹 페이지의 콘텐츠를 변경/파기하거나 사용자의 웹 브라우저를 손상시키는 데 사용될 수 있습니다. 공격자가 쿠키를 훔치는 JavaScript를 삽입하여 요청의 시간대 필드를 수정하는 경우 피해자가 자신의 URL을 방문하도록 관리하는 경우 제어권을 얻을 수 있습니다.

1. 콘솔 설정에서 설정을 저장할 때. 주입하는 데 사용할 수 있는 POST 요청의 페이로드에 필드 값이 있습니다.

16. 웹 애플리케이션 구성 요소는 XSS(교차 사이트 스크립팅) 공격에 취약합니다. (주입)

웹 응용 프로그램 구성 요소는 XSS(교차 사이트 스크립팅) 공격에 취약합니다. 이 문제를 악용하여 공격자는 결국 최종 사용자의 웹 브라우저에서 렌더링 및 실행될 응용 프로그램 입력 매개 변수에 임의의 클라이언트 측 사이트 코드(JavaScript, VBScript 등)를 제공할 수 있습니다.

info.html 페이지는 DOM 기반 링크 삽입에 취약하여 클릭 시 교차 사이트 공격으로 이어질 수 있습니다. XSS는 취약한 도메인에서 쿠키를 훔치는 데 사용할 수 있으며 취약한 웹 페이지의 콘텐츠를 손상시키거나 사용자의 웹 브라우저를 손상시킨 후 잠재적으로 사용자 인증 세션에 대한 무단 액세스 권한을 얻을 수 있습니다. 일반적인 전술은 사용자 암호를 얻기 위해 실제 세션 시간 초과 및 로그인 페이지를 스푸핑하기 위해 신뢰할 수 있는 도메인의 취약한 페이지를 다시 그리는 것입니다.

1. "캠프 관리자" 역할로 포털에 로그인합니다. ,

2. 포털에서 로그아웃

3. url https://********/info.html#/redirect?url=javascript:alert(0)을 입력하여 스크립트를 삽입합니다.

17. 응답의 세부 사항은 애플리케이션에 대한 정보를 공개할 수 있으므로 기존 취약점을 발견할 가능성이 높아집니다. (보안 구성 오류)

응답의 세부 정보는 애플리케이션에 대한 정보를 공개할 수 있으므로 기존 취약성을 발견할 가능성이 높아집니다.

잘못된 본문으로 API를 호출하면 응답 결과에 애플리케이션 세부 정보가 포함됩니다.

18. CSP 헤더가 안전한 값으로 추가되거나 구성되지 않아 신뢰할 수 없는 사이트 정보에 리소스가 로드되어 XSS 및 기타 관련 취약점이 발생합니다. (보안 구성 오류)

콘텐츠 보안 정책(CSP)은 특정 유형의 공격을 감지하고 완화하는 데 도움이 되는 추가 보안 계층입니다. XSS(교차 사이트 스크립팅) 및 데이터 주입 공격을 포함하지만 이에 국한되지 않습니다. 이러한 공격은 데이터 도용에서 웹사이트 손상 또는 맬웨어 배포에 이르기까지 모든 것에 사용됩니다. CSP는 웹 사이트 소유자가 브라우저가 해당 페이지에 로드할 수 있는 콘텐츠 소스를 선언할 수 있도록 하는 표준 HTTP 헤더 세트를 제공합니다. 다루는 유형에는 JavaScript, CSS, HTML 프레임, 글꼴, 이미지 및 삽입 가능한 개체가 포함됩니다.

19. 웹 서버의 CORS(Cross Origin Resource Sharing) 구성이 잘못되어 웹 브라우저에서 데이터를 로드하지 못할 수 있습니다. Access-Control-Allow-Origin: *민감한 데이터에는 안전하지 않습니다. (보안 구성 오류)

웹 서버의 CORS 구성 오류로 인해 인증되지 않은 API가 사용되는 임의의 타사 도메인에서 원본 간 읽기 요청이 허용됩니다. 그러나 웹 브라우저 구현은 임의의 제3자가 인증된 API의 응답을 읽는 것을 허용하지 않습니다. 이것은 어느 정도 위험을 줄입니다. 이 잘못된 구성은 공격자가 인증되지 않은 방식으로 사용할 수 있지만 IP 주소 화이트리스트와 같은 다른 형태의 보안을 사용하는 데이터에 액세스하는 데 사용할 수 있습니다.

20. HSTS 보안 정책을 사용하지 않음 (보안 구성 오류)

HSTS(HTTP Strict Transport Security)는 웹 서버가 준수한다고 선언한 사용자 에이전트(예: 웹 브라우저)가 보안 HTTPS 연결(즉, HTTP 계층이 TLS/SSL을 통해 이루어짐)을 사용하여 상호 작용하는 웹 보안 정책 메커니즘입니다. HSTS는 RFC 6797에 지정된 IETF 표준 추적 프로토콜입니다.

이 헤더가 없으면 웹 서버가 정상적인 HTTP 트래픽에 사용될 수 있는 위험에 처하게 됩니다.

21. 모든 사람이 서버에 모든 파일을 다운로드할 수 있으며, 파일을 교체하고 응용 프로그램에 영향을 미칠 수 있으며, 다른 클라이언트가 파일을 바이러스와 함께 실행할 수 있습니다. (보안 구성 오류)

1. "관리자" 역할로 v1 포털을 엽니다.

2. 포털에서 파일 가져오기 URL을 찾습니다.

3. PUT 메서드를 사용하여 test.js와 같은 파일을 url로 보냅니다. get 메소드로 이 파일을 가져올 수 있습니다.

22. Http를 사용하여 API 호출을 할 수 있음 (보안 구성 오류)

API는 Postman을 사용하여 http 요청을 보낼 수 있습니다.

응답 헤더에 "Strict-Transport-Security" 헤더가 없습니다. "Strict-Transport-Security" 헤더는 사이트를 HTTPS로만 제한하며 향후 HTTP를 사용하여 사이트에 액세스하려는 모든 시도는 자동으로 HTTPS로 변환되어야 합니다.

4. 마지막으로

주요 웹 보안 유형은 해마다 약간씩 변경됩니다. 가장 일반적인 유형의 WEB 취약점에 대한 숙련도는 침투 작업 개발을 위한 중요한 기반입니다.

WEB 10대 보안 취약점(OWASP Top 10) 및 침투 테스트 기록