Public missions & guidelines

Secure Coding Made Practical

Explore secure coding guidelines to understand and mitigate software vulnerabilities like the OWASP Top 10, and dive into guided training Missions to practices in real-world app simulations.

book a demo
공공 임무
가이드라인

Browse all missions

목차

SQL 인젝션스프링 MVC 리퀘스트 매처트로이 소스 - 신뢰할 수 없는 출처의 구성 요소 사용사이킥 시그니처 - 알려진 취약한 구성 요소 사용Apache 경로 탐색 - 알려진 취약한 구성 요소 사용CodeSashbin - 안전하지 않은 암호 재설정 기능Log4j - 알려진 취약한 구성 요소 사용'채터GPT'의 크로스 사이트 스크립팅 (XSS)
더 보기
확장 가능하고 매력적인

SQL 인젝션

try now
확장 가능하고 매력적인

Spring MvcRequestMatchers

try now
확장 가능하고 매력적인

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

try now
확장 가능하고 매력적인

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

try now
확장 가능하고 매력적인

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

try now
확장 가능하고 매력적인

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

try now
확장 가능하고 매력적인

CodeSashbin - 안전하지 않은 암호 재설정 기능

try now
확장 가능하고 매력적인

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

try now

Browse all guidelines

검색 기준:
필터 숨기기
Selection
필터 보기
Selection
필터 지우기
태그
Super Icon [★]
토픽
더 보기

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

모범 사례:

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

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

view guidelines

알려진 취약점이 있는 구성 요소 사용

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

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

view guidelines

SQL 인젝션

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

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

view guidelines

잘못된 보안 구성

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

메트릭스 (프로메테우스)
로그
환경 정보
경로/URL 매핑

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

view guidelines

서버 측 요청 위조

ts
url = 요청.params.url로 설정;

응답 = http.get (url) 이라고 가정해 봅시다.
렌더 = 리스폰스.렌더 () 라고 하자;

반환 렌더링. 내보내기 ();

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

view guidelines

비밀번호 저장

Feature Cryptographic hash Password hash Speed Very fast Intentionally slow Work factor can be adjusted No Yes

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

view guidelines

대량 배정

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 매개변수를 자동으로 바인딩한 다음 검증 없이 계속 사용할 수 있도록 하는 라이브러리/프레임워크를 사용할 때 발생할 수 있습니다.요청의 자동 바인딩을 객체에 사용하면 때때로 매우 유용할 수 있지만 모델에 사용자가 액세스할 수 없도록 되어 있지 않은 속성이 있는 경우 보안 문제가 발생할 수도 있습니다.자세한 내용은 가이드라인을 참조하세요.

view guidelines

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

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

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

view guidelines

인젝션 - 경로 트래버설

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

반환 파일. 읽기 (경로);

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

view guidelines

인증 및 권한 부여

cs

//기본 동작이 요청을 인증하는 것인지 확인하고 요청이 관리자인지 확인합니다.
[인증]
[승인 (“관리자”)]
퍼블릭 클래스 시큐어 컨트롤러: 컨트롤러
{

}

퍼블릭 클래스 MyController: 시큐어 컨트롤러
{

//상속된 Authorize 속성을 대체하여 모든 사용자가 페이지에 액세스할 수 있도록 합니다.

view guidelines

인젝션 - XSS

``html
<!--- UNSAFE: The htmlSnippet will get interpreted without any escaping --->
@Html .Raw (HTML 스니펫)
```

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

view guidelines

인젝션 101

가장 일반적인 주사 유형은 다음과 같습니다.

SQL 인젝션
크로스 사이트 스크립팅 (HTML/자바스크립트 인젝션)
경로 탐색 (경로/URL 삽입)
명령어 인젝션
코드 인젝션

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

view guidelines

파일 업로드

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;
}

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

view guidelines

명령어 인젝션

ip = 요청.params.IP 주소라고 가정해 봅시다.

시스템 (“핑”+ ip);

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

view guidelines