공공 임무 및 지침

실용성을 높인 보안 코딩

OWASP Top 10과 같은 소프트웨어 취약성을 이해하고 완화하기 위한 보안 코딩 지침을 살펴보고 실제 앱 시뮬레이션의 실습에 대한 가이드 교육 미션에 대해 자세히 알아보십시오.

모든 임무 살펴보기

SQL-Injection

한 사용자로부터 인터넷 뱅크 솔루션의 트랜잭션 검색 기능에서 SQL Injection 취약점을 악용할 수 있다는 제보를 받았습니다.이들은 다른 사용자의 트랜잭션을 볼 수 있다고 말했고, 공격자는 이 취약점으로 인해 테이블 삭제, 다른 테이블의 데이터 보기, 데이터 삽입 등과 같은 온갖 종류의 불쾌한 작업을 데이터베이스에 수행할 수 있다고 지적했습니다. 이 임무에서 사용자가 수행한 작업을 복제해 보십시오.

지금 체험하기 블로그 게시물 읽기

Spring MvcRequestMatchers

Im März 2023 veröffentlichte Spring einen Fix für eine intern entdeckte Schwachstelle mit der Bezeichnung CVE-2023-20860, bei der die Verwendung eines doppelten Platzhalters ** in mvcRequestMatchers zu einer Musterabweichung zwischen Spring Security und Spring MVC führen kann. Dies könnte letztendlich dazu führen, dass Benutzer unbefugten Zugriff auf bestimmte Endpunkte erhalten. Wir haben eine sehr vereinfachte Bankanwendung mit einigen wenigen Endpunkten eingerichtet. Folgen Sie den Anweisungen und versuchen Sie, die Auswirkungen dieser Schwachstelle in der Zugriffskontrolle zu reproduzieren.

지금 체험하기 블로그 게시물 읽기

사이킥 시그니처 - 알려진 취약한 구성 요소 사용

CVE-2022-21449 에는 취약점을 가리키는 가장 멋진 별칭인 자바 사이킥 시그니처가 있습니다.그 이름은 어떻게 지어졌나요?닥터 후의 심문을 참고한 것이죠.이 빈 종이를 누구에게나 보여주면 기대하는 내용으로 가득 차게 되죠.JWT의 서명 검증에 영향을 미치는 ECDSA 알고리즘의 자바 (버전 15~18) 구현에서도 비슷한 일이 있었습니다.유효하지 않은 서명을 할 수 있지만 Java는 유효할 수 있다고 생각합니다.어떻게 맞습니까?<>>>>>>>>

지금 체험하기 블로그 게시물 읽기

Apache 경로 탐색 - 알려진 취약한 구성 요소 사용

2021년 10월 4일, 아파치 팀은 아파치 2.4.48 (CVE-2021-41773 이라고도 함) 의 경로 탐색 및 원격 코드 실행 취약점을 해결하기 위해 아파치 버전 2.4.49를 출시했습니다.2021년 10월 7일에 2.4.50 핫픽스의 수정이 완료되지 않아 버전 2.4.51을 출시했습니다.이 취약점은 CVE-2021-42013 감염으로 추적되었습니다.이 임무를 수행하여 이 취약점이 어떻게 악용될 수 있는지 직접 확인해 보십시오.

지금 체험하기 블로그 게시물 읽기

Log4j - 알려진 취약한 구성 요소 사용

2021년 12월 초에 널리 사용되는 로깅 라이브러리 Log4j의 제로 데이 익스플로잇 (CVE-2021-44228) 에 대한 발표는 자바 커뮤니티에서 큰 반향을 일으켰습니다.Log4Shell이라고 불리는 이 익스플로잇은 Log4j v2 버전 2.0-beta9~2.14.1에 영향을 미치며 원격 코드 실행으로 이어질 수 있습니다.익스플로잇을 모킹할 수 있는 환경을 설정했기 때문에 그 영향을 직접 확인할 수 있습니다.지금 사용해 보세요.

지금 체험하기 블로그 게시물 읽기

트로이 소스 - 신뢰할 수 없는 출처의 구성 요소 사용

Viking Bank 개발자 중 한 명이 인터넷의 신뢰할 수 없는 출처에서 가져온 코드를 순진하게 복사했습니다. 이 코드에는 잠재적으로 취약한 구성 요소가 포함되어 있어 신용 카드 관리를 위한 관리자 인증 검사를 작성하는 데 도움이 됩니다.관리자만 이 권한을 가질 수 있는데도 사용자들이 신용 카드 한도를 변경하고 있다는 사실을 알게 되었습니다.이 코드에 뭔가 문제가 있는 것 같아요.코드를 조사하는 임무를 수행해 보세요.

지금 체험하기 블로그 게시물 읽기

CodeSashbin – Unsichere Funktion zum Zurücksetzen des Passworts

CodeSashbin은 세계 최대의 코드 버전 제어 호스팅 회사 중 하나입니다.비밀번호 분실 프로세스에 안전하지 않은 비밀번호 재설정 기능 취약점이 있다는 소문이 있습니다.권한이 있는 사용자의 암호를 변경하고 해당 계정에 액세스할 수 있을 수도 있습니다.이 임무에 뛰어들어 문제를 조사해 보세요.

지금 체험하기 블로그 게시물 읽기

'채터GPT'의 크로스 사이트 스크립팅 (XSS)

이 미션은 인기 있는 LLM의 친숙한 인터페이스를 보여주고 2023년 11월 말에 생성된 실제 코드 스니펫을 활용합니다.사용자는 이 스니펫을 해석하여 의도한 용도에 사용할 경우 발생할 수 있는 잠재적 보안 위험을 조사할 수 있습니다.

지금 체험하기 블로그 게시물 읽기

전체 가이드라인 찾아보기

로깅 및 모니터링이 충분하지 않음

모범 사례: 민감한 기능에 대한 감사 로깅 오류 로깅 중앙 위치에 로그 저장 정의된 기간 동안 로그 보존 PII에 대한 정기적인 감사 로그

로깅과 모니터링은 문제가 이미 발생했을 때 미처 고려하지 않는 경우가 많지만, 실제로 적절한 로깅 및 모니터링이 이루어지지 않으면 비용이 많이 들 수 있습니다.한 가지 극단적으로, 사고가 발생하면 (보안 관련 문제든 아니든) 로그가 거의 없거나 전혀 없으면 실제로 어떤 일이 발생했는지 파악할 수 없습니다.반면에 너무 많은 데이터를 기록하면 개인 정보 보호 문제가 발생하여 규제 기관과 문제가 발생할 수 있습니다.로깅 및 모니터링이 불충분한 것을 방지하기 위한 모범 사례 가이드라인을 읽어보세요.

가이드라인 보기

Verwendung von Komponenten mit bekannten Schwachstellen

{ “종속성”: { “foo”: “1.0.0 - 2.9999.9999", “바”: “>=1.0.2 <2.1.2" } }

대부분의 응용 프로그램은 대량의 타사 구성 요소를 사용합니다.이러한 구성 요소는 로깅, 템플릿 작성, 데이터베이스 액세스 등 모든 것을 제공합니다.따라서 소프트웨어 개발이 훨씬 쉬워지고 시간도 많이 절약됩니다.하지만 사람이 만든 것이기도 하기 때문에 일부에는 필연적으로 취약점이 있을 수 밖에 없습니다.가이드라인을 읽고 자세히 알아보세요.

가이드라인 보기

SQL-Injection

mysql. 커넥터 가져오기 db = mysql.connector.connect #Bad 연습.이거 피하세요!이것은 단지 학습을 위한 것입니다. (호스트="로컬호스트”, 사용자="새 사용자”, 비밀번호="패스”, db="샘플”) 커서 = db.커서 () 이름 = raw_input ('이름 입력: ') cur.fetchall () 의 행에 대해 cur.execute (“샘플_데이터에서 *를 선택하십시오. 여기서 이름 = '%s';”% 이름): 인쇄 (행) db. 닫기 ()

SQL 인젝션 (SQLi) 은 SQL 문에 코드를 삽입하여 애플리케이션에서 중요한 정보를 공격하고 수집합니다.웹 보안 취약점입니다.데이터베이스를 조작하여 중요한 정보를 추출하는 가장 일반적인 해킹 기법입니다.

가이드라인 보기

잘못된 보안 구성

또한 많은 프레임워크에는 프로덕션 환경이든 테스트/개발 환경이든 관계없이 애플리케이션을 모니터링할 수 있는 엔드포인트 세트가 있습니다.여기에는 다음이 포함될 수 있습니다. 메트릭스 (프로메테우스) 로그 환경 정보 경로/URL 매핑

보안 구성 오류는 잘못된 코드가 아니라 애플리케이션의 구성 설정으로 인해 발생하는 일반적인 취약점을 포괄하는 포괄적인 용어입니다.이는 광범위한 주제이며 기술 스택과 같은 요소에 크게 좌우됩니다.이러한 문제를 해결하는 것은 구성 파일이나 코드 한 줄을 변경하는 것과 같이 간단해 보이지만 이러한 취약점의 영향과 결과는 심각할 수 있습니다.이 취약점과 이를 완화하는 방법에 대해 자세히 알아보려면 지침을 읽어보세요.

가이드라인 보기

서버 측 요청 위조

ts url = 요청.params.url로 설정; 응답 = http.get (url) 이라고 가정해 봅시다. 렌더 = 리스폰스.렌더 () 라고 하자; 반환 렌더링. 내보내기 ();

서버 측 요청 위조 취약성은 사용자가 애플리케이션이 공격자가 결정한 도메인에 HTTP 요청을 하도록 할 수 있을 때 발생합니다.애플리케이션이 사설/내부 네트워크에 액세스할 수 있는 경우 공격자가 애플리케이션으로 하여금 내부 서버에 요청을 하도록 할 수도 있습니다.이 가이드라인에서는 실제 어떤 모습인지 더 잘 이해할 수 있도록 몇 가지 예와 함께 이 내용을 자세히 살펴보도록 하겠습니다.

가이드라인 보기

비밀번호 저장

Merkmal Kryptographischer Hash Passwort-Hash Geschwindigkeit Sehr schnell Absichtlich langsam Arbeitsfaktor kann angepasst werden Nein Ja

애플리케이션이 사용자를 인증하는 경우 암호도 처리할 가능성이 높습니다.사용자 암호를 처리하는 것은 정말 중요한 일이며 적절하게 처리하는 것은 훨씬 더 큰 문제입니다.응용 프로그램이 공격을 받고 모든 사람이 볼 수 있도록 인터넷을 통해 사용자 암호가 유출되는 것보다 더 나쁜 시나리오는 상상하기 어렵습니다.모범 사례에 따라 암호를 어떻게 안전하게 저장할 수 있을까요?몇 가지 방법을 살펴보겠습니다.

가이드라인 보기

대량 배정

html <form method="POST"> <input name="Id" type="hidden" value="666"> <input name="Name" type="text" value="Bad guy"> <input name="EmailAddress" type="text" value="hacker@attacker.com"> <input name="IsAdmin" type="hidden" value="true"> <input type="submit"> </form>

대량 할당은 API 엔드포인트가 사용자가 수정할 수 있는 관련 객체의 속성을 제한하지 않는 취약점입니다.이 취약점은 모델에 HTTP 매개변수를 자동으로 바인딩한 다음 검증 없이 계속 사용할 수 있도록 하는 라이브러리/프레임워크를 사용할 때 발생할 수 있습니다.요청의 자동 바인딩을 객체에 사용하면 때때로 매우 유용할 수 있지만 모델에 사용자가 액세스할 수 없도록 되어 있지 않은 속성이 있는 경우 보안 문제가 발생할 수도 있습니다.자세한 내용은 가이드라인을 참조하세요.

가이드라인 보기

보안 구성 오류 - XXE 세부 정보

xml <?xml 버전="1.0"?> <!문서 유형 외부 요소 [ <!] > <outerElement>&외부 엔티티;</outerElement>

'XML 외부 엔티티' (XXE) 취약성 클래스는 XML 파서와 관련된 잘못된 보안 구성입니다.XML 표준에는 파일 및 URL과 같은 “개체”를 참조하는 방법이 포함됩니다.파서가 외부 엔티티를 완전히 확인하는 것이 기본값인 경우가 많습니다. 즉, XML 문서로 인해 잠재적 공격자에게 파일 및 기타 민감한 정보가 공개될 수 있습니다.자세한 내용은 전체 지침을 읽어보세요.

가이드라인 보기

인젝션 - 경로 트래버설

`의사 베이스폴더 = “/var/www/api/문서/”로 설정; 경로 = 기본 폴더 + 요청.params.파일 이름; 반환 파일. 읽기 (경로);`

경로 탐색은 매우 일반적인 또 다른 유형의 인젝션 취약점입니다.URL, 파일 경로 등 URI를 생성할 때 완전히 확인된 경로가 의도한 경로의 루트 바깥을 가리키지 않도록 제대로 확인되지 않을 때 이러한 문제가 발생하는 경향이 있습니다.경로 탐색 취약성의 영향은 탐색이 발생한 위치의 컨텍스트와 수행된 전반적인 보안 강화에 따라 크게 달라집니다.가이드라인을 읽고 자세히 알아보세요.

가이드라인 보기

인증 및 권한 부여

cs //기본 동작이 요청을 인증하는 것인지 확인하고 요청이 관리자인지 확인합니다. [인증] [승인 (“관리자”)] 퍼블릭 클래스 시큐어 컨트롤러: 컨트롤러 { } 퍼블릭 클래스 MyController: 시큐어 컨트롤러 { //상속된 Authorize 속성을 대체하여 모든 사용자가 페이지에 액세스할 수 있도록 합니다.

가이드라인 보기

인젝션 - XSS

``html  @Html .Raw (HTML 스니펫) ```

XSS라고도 하는 크로스 사이트 스크립팅은 다른 사용자의 브라우저에서 공격자가 제어하는 스크립트를 평가하게 하는 또 다른 유형의 인젝션 취약점입니다.XSS는 HTML/자바스크립트 삽입 취약점으로 간주될 수도 있습니다.발생할 수 있는 XSS 유형을 살펴보겠습니다.

가이드라인 보기

인젝션 101

가장 일반적인 주사 유형은 다음과 같습니다. SQL 인젝션 크로스 사이트 스크립팅 (HTML/자바스크립트 인젝션) 경로 탐색 (경로/URL 삽입) 명령어 인젝션 코드 인젝션

가장 잘 알려진 취약점 중 하나가 인젝션 취약점인 이름, 그 중에서도 놀랍게도 그 후손인 SQL 인젝션 (SQL인젝션) 이 있습니다.기술 세계에서는 SQL 인젝션에 대한 이야기를 듣기가 어렵기 때문에 이야기해 보도록 하겠습니다.<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< #####에 대한 간략한 소개를 다시 읽어보세요.

가이드라인 보기

파일 업로드

public string UploadProfilePicture(FormFile uploadedFile) { // Generate path to save the uploaded file at var path = $"./uploads/avatars/{request.User.Id}/{uploadedFile.FileName}"; // Save the file var localFile = File.OpenWrite(path); localFile.Write(uploadedFile.ReadToEnd()); localFile.Flush(); localFile.Close(); // Update the profile picture UserProfile.UpdateUserProfilePicture(request.User, path) return path; }

애플리케이션은 어느 시점에서든 사용자가 애플리케이션 내 어딘가에 파일 (사용 또는 저장용) 을 업로드할 수 있도록 허용해야 하는 경우가 매우 흔합니다.이 기능을 구현하는 방법은 간단해 보이지만 파일 업로드 처리 방식과 관련된 잠재적 위험 때문에 매우 중요할 수 있습니다.자세한 내용은 가이드라인을 참조하세요.

가이드라인 보기

명령어 인젝션

ip = 요청.params.IP 주소라고 가정해 봅시다. 시스템 (“핑”+ ip);

커맨드 인젝션 자체를 살펴보겠습니다.실제로 어떻게 보이는지 더 쉽게 볼 수 있도록 주로 몇 가지 다른 예제에 초점을 맞출 것입니다.간단히 설명하자면, 사용자 입력이 운영 체제 명령의 일부를 사용할 때 명령 삽입 취약성이 발생합니다.자세한 내용은 가이드라인을 참조하세요.

가이드라인 보기

실용성을 높인 보안 코딩

모든 임무 살펴보기

Inhaltsverzeichnis