퍼징

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요
2. 역사
3. 유형
4. 활용
5. 도구 체인
- 5.1. 자동화된 버그 분류
- 5.2. 자동화된 입력 최소화
6. 인기 있는 퍼저 목록
참조

1. 개요

퍼징(Fuzzing)은 소프트웨어의 취약점을 찾기 위해 무작위 또는 변형된 입력을 프로그램에 제공하여 오류를 유발하는 기술이다. 1988년 위스콘신 대학교의 바톤 밀러 교수가 개발한 이래, 무작위 입력, 기존 입력 변형, 프로그램 구조 분석 등 다양한 유형으로 발전해 왔다. 퍼징은 소프트웨어의 버그를 노출하고, 정적 분석 보고서를 검증하며, 브라우저 보안을 강화하는 데 활용된다. 자동화된 버그 분류, 입력 최소화 등의 도구 체인과 함께 사용되며, American Fuzzy Lop(AFL)와 같은 다양한 퍼징 도구가 존재한다.

더 읽어볼만한 페이지

컴퓨터 보안 절차 - 사이버 전쟁
사이버 전쟁은 국가나 비국가 행위자가 사이버 공간에서 국가 안보를 위협하거나 정책을 수행하기 위해 컴퓨터 네트워크를 이용해 공격과 방어를 하는 행위이다.
컴퓨터 보안 절차 - 컴퓨터 포렌식
컴퓨터 포렌식은 디지털 증거를 수집, 분석하여 법적 증거로 제시하는 과학 수사 기법으로, 사이버 범죄 수사, 민사 소송, 기업 감사 등 다양한 분야에서 활용되며 자동화, 인공지능, 머신러닝과 같은 첨단 기술을 통합하는 방향으로 발전하고 있다.
소프트웨어 테스트 - 보안 취약점
보안 취약점은 시스템의 설계, 구현, 운영, 관리상 결함이나 약점으로, 위협에 의해 악용되어 시스템 보안 정책을 위반할 수 있는 요소이며, ISO 27005, IETF RFC 4949, NIST SP 800-30, ENISA 등 다양한 기관에서 정의하고 있다.
소프트웨어 테스트 - A/B 테스트
A/B 테스트는 두 가지 이상의 대안을 비교하여 더 나은 성과를 판단하는 방법으로, 웹사이트, 애플리케이션 등 다양한 분야에서 사용자 인터페이스 등을 테스트하며 통계적 가설 검정을 기반으로 한다.

퍼징
일반 정보
명칭	퍼징
다른 이름	퍼즈 테스팅(fuzz testing), 블랙 박스 테스팅(black box testing), 멍키 테스팅(monkey testing)
정의	소프트웨어 테스팅 기법 중 하나로, 유효하지 않거나 예기치 않은, 또는 무작위 데이터를 입력하여 소프트웨어나 시스템의 오류를 찾아내는 방법
상세 정보
목표	예외 처리 오류, 메모리 누수, 서비스 거부 등 숨겨진 소프트웨어 결함을 발견
사용 목적	소프트웨어의 보안 취약점을 식별하고 시스템의 안정성을 향상
작동 방식	프로그램에 무작위 데이터를 입력하여 비정상적인 동작이나 충돌을 유발하는지 관찰
종류	블랙 박스 퍼징(Black box fuzzing) 화이트 박스 퍼징(White box fuzzing) 그레이 박스 퍼징(Gray box fuzzing)
장점	구현의 약점을 발견하는 데 효과적 테스트 케이스를 생성하는 데 필요한 전문 지식 감소 자동화 가능
단점	발견된 버그의 재현이 어려울 수 있음 코드 커버리지가 낮을 수 있음 복잡한 입력 형식을 가진 프로그램에는 적용하기 어려울 수 있음
활용 분야
사용 예시	웹 애플리케이션 운영 체제 네트워크 프로토콜 파일 포맷
관련 도구	AFL (American Fuzzy Lop) libFuzzer Honggfuzz Peach Fuzzer
기타
관련 용어	소프트웨어 테스팅 보안 테스팅 침투 테스팅

2. 역사

퍼즈 테스팅의 개념은 1988년 위스콘신 대학교의 바톤 밀러(Barton Miller) 교수가 대학원 수업 프로젝트에서 "퍼즈"라는 용어를 처음 사용하면서 시작되었다.^[1] 밀러 교수 팀은 유닉스 유틸리티에 무작위 입력과 명령줄 매개변수를 자동으로 생성하여 테스트를 진행했고, 그 결과 테스트한 유틸리티의 25~33%에서 충돌이 발생했다. 밀러 교수는 "무작위적이고 구조화되지 않은 데이터의 느낌을 불러일으키는 이름"으로 '퍼즈'라는 용어를 선택했다고 밝혔다.^[1] 초기 퍼징은 프로그램이 임의 입력에 충돌하거나 멈추면 실패, 그렇지 않으면 통과로 간주하는 간단한 방식으로 진행되었다.

이후 퍼징 도구는 다양화되었다. 2012년 구글은 클라우드 기반 퍼징 인프라인 ClusterFuzz를 발표했다. 2014년에는 셸쇼크^[2] 취약점이 퍼저 AFL을 사용하여 발견되었고,^[3] 2015년에는 AFL이 하트블리드 취약점을 발견할 수 있음을 보여주었다.^[5]^[6] 2016년 방위 고등 연구 계획국(DARPA)은 사이버 그랜드 챌린지를 개최하여 퍼징의 자동화 가능성을 보여주었다. 같은 해 마이크로소프트는 Project Springfield를, 구글은 OSS-Fuzz를 발표했다. 2020년 마이크로소프트는 OneFuzz를 출시했다.^[11]

2. 1. 초기 무작위 테스팅

1950년대부터 천공 카드를 사용한 프로그램 테스트가 이루어졌다. 프로그래머들은 쓰레기통에서 꺼낸 천공 카드나 난수 카드 덱을 컴퓨터 프로그램의 입력으로 사용하여 버그를 찾았다.

무작위 테스트 또는 몽키 테스트라고도 불리는 무작위 입력 실행은 1981년 Duran과 Ntafos에 의해 연구되었다. 이들은 무작위 테스팅이 체계적인 테스팅 기법의 비용 효율적인 대안이 될 수 있음을 제시했다.

1983년, 스티브 캡스는 클래식 Mac OS 응용 프로그램에 무작위 입력을 생성하는 "The Monkey"를 개발했다. "The Monkey"는 무한 원숭이 정리에서 유래했다.

1991년에는 crashme 도구가 출시되어 유닉스 및 유닉스 계열 운영 체제의 견고성을 테스트했다.

2. 2. "퍼징" 용어의 등장

위스콘신 대학교의 바톤 밀러(Barton Miller) 교수는 1988년 대학원 고급 운영 체제 수업(CS736) 프로젝트에서 "퍼즈"라는 용어를 만들었다. 이 프로젝트 결과는 1990년에 발표되었다.^[1] 밀러 교수 팀은 유닉스 유틸리티에 임의의 입력과 명령줄 매개변수를 자동으로 생성하여 테스트했고, 테스트한 유틸리티의 25~33%가 충돌하는 것을 발견했다. 이들은 도구의 소스 코드, 테스트 절차, 원시 결과 데이터를 공개하여 다른 연구자들도 유사한 실험을 수행할 수 있도록 했다.

바톤 밀러 교수는 "프로젝트 설명을 작성하는 과정에서 이 유형의 테스트에 이름을 붙여야 했다. 무작위적이고 구조화되지 않은 데이터의 느낌을 불러일으키는 이름을 원했다. 몇 가지 아이디어를 시도해 본 후, '퍼즈'라는 용어로 결정했다."라고 회고했다.^[1]

초기 퍼징은 프로그램이 임의 입력에서 충돌하거나 멈추면 테스트에 실패하고, 그렇지 않으면 통과하는 것으로 간주하는 간단한 오라클을 사용했다.

2. 3. 퍼징 도구의 다양화

2002년 오픈 소스 퍼즈 도구 프레임워크 SPIKE^[33]가 등장했다. 2012년 구글은 클라우드 기반 퍼징 인프라인 ClusterFuzz를 발표했다. 2014년 셸쇼크^[2] 취약점은 퍼저 AFL을 사용하여 발견되었다.^[3] 2015년 AFL은 하트블리드 취약점을 발견할 수 있음을 보여주었다.^[5]^[6]

2016년 방위 고등 연구 계획국(DARPA)은 사이버 그랜드 챌린지를 개최하여 퍼징의 자동화 가능성을 보여주었다. 우승자는 데이비드 브럼리가 이끄는 ForAllSecure 팀이 개발한 "Mayhem"^[10]이라는 시스템이었다. 같은 해 마이크로소프트는 Project Springfield를, 구글은 OSS-Fuzz를 발표했다. 2020년 마이크로소프트는 OneFuzz를 출시했다.^[11]

3. 유형

퍼저는 여러 가지 방식으로 분류될 수 있다.

퍼저는 입력을 처음부터 생성하는지, 아니면 기존 입력을 수정하여 생성하는지에 따라 생성 기반 또는 변이 기반으로 나눌 수 있다.^[14]
퍼저는 입력 구조를 인식하는지에 따라 멍청한(구조화되지 않은) 퍼저 또는 스마트(구조화된) 퍼저로 나눌 수 있다.
퍼저는 프로그램 구조를 인식하는지에 따라 화이트 박스, 그레이 박스 또는 블랙 박스로 나눌 수 있다.

퍼저 유형
분류 기준	유형	설명
입력 생성 방식	생성 기반 퍼저	입력의 모델에 기반해서 새로운 테스트 데이터를 정의한다.
입력 생성 방식	변이 기반 퍼저	존재하는 데이터 샘플을 테스트 데이터로 변형한다.
입력 구조 인식 여부	멍청한(구조화되지 않은) 퍼저	입력 모델이 필요하지 않다.
입력 구조 인식 여부	스마트(구조화된) 퍼저	입력 모델을 활용하여 더 높은 비율의 유효한 입력을 생성한다.
프로그램 구조 인식 여부	블랙 박스 퍼저	프로그램 내부 구조를 알지 못하고 입력을 생성한다.
	화이트 박스 퍼저	프로그램 분석을 활용하여 코드 커버리지를 체계적으로 높이거나 특정 중요 프로그램 위치에 도달한다.
	그레이 박스 퍼저	프로그램 분석 대신 계측 (컴퓨터 프로그래밍)을 활용하여 프로그램에 대한 정보를 수집한다.

3. 1. 기존 입력 시드 재사용

변이 기반 퍼저는 기존 시드 입력을 수정하여 입력을 생성한다.^[14] 예를 들어, 이미지 라이브러리 libpng를 퍼징할 때 사용자는 유효한 PNG 이미지 파일 집합을 시드로 제공하고, 변이 기반 퍼저는 각 시드의 반유효 변형을 생성하기 위해 이러한 시드를 수정한다. 반면 생성 기반 퍼저는 처음부터 입력을 생성하며, 시드 입력 집합의 존재 여부나 품질에 의존하지 않는다.

일부 퍼저는 처음부터 입력을 생성하는 기능과 기존 시드의 변이를 통해 입력을 생성하는 기능을 모두 갖추고 있다.

3. 2. 입력 구조 인식

스마트 퍼저는 입력 모델을 활용하여 더 높은 비율의 유효한 입력을 생성한다. 예를 들어, 입력이 추상 구문 트리로 모델링될 수 있다면, 스마트 변형 기반 퍼저는 임의의 변환을 사용하여 전체 하위 트리를 한 노드에서 다른 노드로 이동시킨다. 입력이 형식 문법으로 모델링될 수 있다면, 스마트 생성 기반 퍼저는 생산 규칙을 인스턴스화하여 문법에 따라 유효한 입력을 생성한다. 그러나 일반적으로 입력 모델은 명시적으로 제공되어야 하며, 모델이 독점적이거나 알려지지 않았거나 매우 복잡한 경우 이를 수행하기 어렵다. 유효하고 무효한 입력의 대규모 코퍼스가 있는 경우, 앤글린의 L* 알고리즘과 같은 문법 유도 기술을 사용하여 입력 모델을 생성할 수 있다.

멍청한 퍼저는 입력 모델이 필요하지 않으므로 더 다양한 프로그램에 퍼징을 적용할 수 있다. 예를 들어, AFL은 임의의 비트를 반전시키고, 임의의 바이트를 "흥미로운" 값으로 대체하며, 데이터 블록을 이동하거나 삭제하여 시드 파일을 수정하는 멍청한 변형 기반 퍼저이다. 그러나 멍청한 퍼저는 유효한 입력의 비율을 낮게 생성하고 프로그램의 주요 구성 요소가 아닌 파서 코드에 스트레스를 줄 수 있다. 멍청한 퍼저의 단점은 순환 중복 검사 (CRC)에 대한 유효한 체크섬을 구성하는 것을 통해 설명할 수 있다. CRC는 입력 파일에 포함된 데이터의 무결성이 전송 중에 유지되도록 보장하는 오류 감지 코드이다. 체크섬은 입력 데이터에 대해 계산되어 파일에 기록된다. 프로그램이 수신된 파일을 처리하고 기록된 체크섬이 재계산된 체크섬과 일치하지 않으면 파일은 무효로 거부된다. 이제 CRC를 인식하지 못하는 퍼저는 올바른 체크섬을 생성할 가능성이 낮다. 그러나 멍청한 변형 기반 퍼저가 보호된 데이터를 수정한 후, 변형된 입력에서 잠재적인 체크섬을 식별하고 재계산하려는 시도가 있다.^[17]

3. 3. 프로그램 구조 인식

블랙 박스 퍼저는 프로그램 내부 구조를 알지 못하고 입력을 생성한다. 예를 들어 입력을 무작위로 생성하는 무작위 테스트 도구는 블랙 박스 퍼저로 간주된다. 블랙 박스 퍼저는 초당 수백 개의 입력을 실행할 수 있고, 쉽게 병렬화할 수 있으며, 임의의 크기의 프로그램으로 확장할 수 있다는 장점이 있다. 그러나 표면만 긁고 "얕은" 버그만 노출할 수 있다는 단점도 있다.

화이트 박스 퍼저는 프로그램 분석을 활용하여 코드 커버리지를 체계적으로 높이거나 특정 중요 프로그램 위치에 도달한다. 예를 들어, SAGE는 기호 실행을 활용하여 프로그램의 다양한 경로를 체계적으로 탐색한다. 화이트 박스 퍼저는 프로그램 깊숙이 숨겨진 버그를 노출하는 데 매우 효과적일 수 있지만, 분석에 사용되는 시간이 과도하게 소요될 수 있다.

그레이 박스 퍼저는 프로그램 분석 대신 계측 (컴퓨터 프로그래밍)을 활용하여 프로그램에 대한 정보를 수집한다. 예를 들어, AFL과 libFuzzer는 입력에 의해 실행되는 기본 블록 전환을 추적하기 위해 경량 계측을 사용한다. 이는 합리적인 성능 오버헤드를 발생시키지만, 퍼징 중에 코드 커버리지 증가에 대해 퍼저에게 알려주며, 이는 그레이 박스 퍼저를 매우 효율적인 취약점 탐지 도구로 만든다.

4. 활용

퍼즈 테스팅은 주로 소프트웨어의 취약점을 발견하는 데 사용된다. 블랙박스 검사 방법론의 일환으로, 대규모 소프트웨어 프로젝트에서 테스트 도구 개발 예산이 있을 때 종종 활용된다.

퍼징은 시스템 동작의 무작위 샘플만을 제공하므로, 소프트웨어가 충돌 없이 예외 처리를 할 수 있는지 확인하는 데 유용하다. 퍼징은 버그를 찾는 도구보다는 전반적인 품질 보증 도구로 사용되며, 정형 기법이나 철저한 테스팅을 대체할 수는 없다. 또한, 신뢰도 측정의 중요한 수단으로서, 프로그램의 어떤 부분이 특별한 주의(코드 감사, 정적 코드 분석, 부분적 재작성 등)를 필요로 하는지 제안할 수 있다.

퍼징은 구조화된 입력을 받는 프로그램을 검증하는 과정의 일부이다. 여기서 구조화된 입력은 파일 형식이나 프로토콜과 같이 유효하거나 무효한 입력을 가리킨다. 퍼저는 프로그램에 대해 유효한 입력 데이터를 생성하여, 일반적인 프로그램 조작이나 다른 테스트 방법으로는 달성하기 어려운 예외적인 상황을 유발한다. 이러한 예외적인 상황을 통해 의도하지 않은 크래시, 처리되지 않은 코너 케이스, 코드 어설션 실패, 잠재적인 메모리 누수, 런타임 에러 등을 발견하고 분석할 수 있다.

퍼징에서 자동화는 중요한 요소이다. 기존의 소프트웨어 테스트는 테스트 실시자의 경험과 직관에 의존하여 수작업으로 진행되었지만, 퍼징은 테스트 케이스를 자동으로 생성하고 실행하며, 재현성이 높고 코드 커버리지가 넓다는 장점이 있다. 물론 퍼징에서도 입력 데이터 결정 방법 등에서 테스트 실시자의 경험이 필요한 경우가 있지만, 자동화는 퍼징의 핵심적인 특징이다.

퍼징은 특히 신뢰 경계선을 넘는 입력이 있는 경우에 효과적이다. 예를 들어, 관리자 권한 사용자만 접근 가능한 구성 파일을 해석하는 코드보다는, 임의의 사용자가 파일을 업로드하는 코드를 퍼징하는 것이 더 유효한 결과를 얻을 가능성이 높다.

품질 보증 분야에서는 퍼징과 유사한 방법으로 견고성 테스트, 구문 테스트, 부정 테스트 등이 사용된다.

4. 1. 버그 노출

퍼저는 예상되는 동작과 예상치 못한 동작을 구별하여 버그를 찾는다. 일반적으로 퍼저는 공식 명세가 없는 상황에서 충돌하는 입력과 충돌하지 않는 입력을 구별하고 간단하고 객관적인 척도를 사용한다. 충돌은 쉽게 식별할 수 있으며 잠재적인 취약점(예: 서비스 거부 또는 임의 코드 실행)을 나타낼 수 있다.^[19]^[20] 그러나 충돌이 없다고 해서 취약점이 없다는 것을 의미하는 것은 아니다. 예를 들어, C로 작성된 프로그램은 입력이 버퍼 오버플로우를 일으키는 경우 충돌할 수도 있고 그렇지 않을 수도 있다. 대신 프로그램의 동작은 정의되지 않은 동작이 된다.

충돌 외의 오류에 대한 퍼저의 감도를 높이기 위해, 오류가 감지되면 프로그램을 충돌시키는 어서션을 주입하기 위해 새니타이저를 사용할 수 있다.^[21]^[22] 다양한 종류의 오류에 대해 여러 가지 새니타이저가 사용된다.

버퍼 오버플로우 및 use-after-free (AddressSanitizer와 같은 메모리 디버거 사용)와 같은 메모리 관련 오류
경쟁 조건 및 교착 상태 (ThreadSanitizer)
정의되지 않은 동작 (UndefinedBehaviorSanitizer)
메모리 누수 (LeakSanitizer)
제어 흐름 무결성 검사 (CFISanitizer)

참조 구현이 있는 경우 퍼징은 "차등" 오류를 감지하는 데에도 사용할 수 있다. 자동화된 회귀 테스트의 경우,^[23] 생성된 입력은 동일한 프로그램의 두 버전에서 실행된다. 자동화된 차등 테스트의 경우,^[24] 생성된 입력은 동일한 프로그램의 두 구현(예: 웹 서버의 구현인 lighttpd 및 httpd)에서 실행된다. 두 변형이 동일한 입력에 대해 다른 출력을 생성하는 경우, 하나는 오류가 있을 수 있으므로 더 자세히 검사해야 한다.

4. 2. 정적 분석 보고서 검증

정적 프로그램 분석은 프로그램을 실제로 실행하지 않고 분석하므로, 도구가 실제로 존재하지 않는 문제점을 보고하는 거짓 양성으로 이어질 수 있다. 동적 프로그램 분석과 결합된 퍼징은 보고된 문제를 실제로 증명하는 입력을 생성하는 데 사용될 수 있다.^[25]

4. 3. 브라우저 보안

현대 웹 브라우저는 광범위한 퍼징을 거친다. 구글 크롬의 크로미움 코드는 크롬 보안팀에 의해 15,000개의 코어로 지속적으로 퍼징된다.^[26] 마이크로소프트 엣지 및 인터넷 익스플로러의 경우, 마이크로소프트는 제품 개발 과정에서 670 머신-년 동안 퍼징 테스트를 수행하여 10억 개의 HTML 파일로부터 4천억 개 이상의 DOM 조작을 생성했다.^[27]^[26]

5. 도구 체인

퍼저는 비교적 짧은 시간 안에 많은 수의 입력을 생성한다. 예를 들어, 2016년 구글 OSS-fuzz 프로젝트는 일주일에 약 4 조 개의 입력을 생성했다. 따라서 많은 퍼저는 실패를 유발하는 입력을 자동 생성한 후 수동으로 처리해야 하는 지루한 작업을 자동화하는 툴체인을 제공한다.

5. 1. 자동화된 버그 분류

자동화된 버그 분류는 대량의 실패 유발 입력을 근본 원인별로 그룹화하고 심각도에 따라 각 개별 버그의 우선순위를 정하는 데 사용된다. 퍼저는 다수의 입력을 생성하며, 실패를 유발하는 많은 입력은 사실상 동일한 소프트웨어 버그를 노출할 수 있다. 이러한 버그 중 일부만 보안 버그이며 더 높은 우선순위로 패치해야 한다.

예를 들어, CERT 조정 센터는 생성된 스택 트레이스별로 충돌하는 입력을 그룹화하고 각 그룹을 악용 가능성에 따라 나열하는 Linux 분류 도구를 제공한다.^[28] 마이크로소프트 보안 연구 센터(MSEC)는 충돌하는 입력에 대한 해시 함수를 먼저 생성하여 고유성을 결정한 다음 익스플로잇 가능성 등급을 할당하는 "!exploitable" 도구를 개발했다.^[29] 등급은 다음과 같다.

익스플로잇 가능
아마 익스플로잇 가능
아마 익스플로잇 불가능, 또는
알 수 없음.

이전에 보고되지 않은 분류된 버그는 자동으로 보고되어 버그 추적 시스템으로 전송될 수 있다. 예를 들어, OSS-Fuzz는 여러 보안에 중요한 소프트웨어 프로젝트에 대해 대규모 장기 퍼징 캠페인을 실행하며, 여기서 이전에 보고되지 않은 각 개별 버그는 버그 추적기에 직접 보고된다. OSS-Fuzz 버그 추적기는 취약한 소프트웨어의 관리자에게 자동으로 알리고 업로드된 최소화된 실패 유발 입력을 사용하여 정기적으로 최신 개정에서 버그가 수정되었는지 확인한다.

5. 2. 자동화된 입력 최소화

자동 입력 최소화(또는 테스트 케이스 축소)는 실패를 유발하는 입력에서 어느 부분이 실제로 실패를 유발하는지 격리하기 위한 자동 디버깅 기술이다. 실패를 유발하는 입력이 크고 대부분 형식이 잘못된 경우, 개발자가 정확히 무엇이 버그를 일으키는지 이해하기 어려울 수 있다. 실패를 유발하는 입력이 주어지면, 자동 최소화 도구는 원래의 버그를 재현하면서 가능한 많은 입력 바이트를 제거한다. 예를 들어, 델타 디버깅은 확장된 이진 탐색 알고리즘을 사용하여 그러한 최소 입력을 찾는 자동 입력 최소화 기술이다.^[30]

6. 인기 있는 퍼저 목록

이름	화이트/그레이/블랙 박스	스마트/덤	작성 언어	라이선스
AFL	그레이	덤	C	아파치 2.0
AFL++	그레이	덤	C	아파치 2.0
AFLFast	그레이	덤	C	아파치 2.0
Angora	그레이	덤	C++	아파치 2.0
[https://honggfuzz.dev/ honggfuzz]	그레이	덤	C	아파치 2.0
QSYM
[https://www.s3.eurecom.fr/tools/symbolic_execution/symcc.html SymCC]	화이트		C++	GPL, LGPL
T-Fuzz
VUzzer

오울 대학교의 PROTOS 프로젝트는 체계적인 퍼징 도구를 개발했다. PROTOS는 1999년에 개발을 시작했고, 2002년에는 프로젝트 멤버들이 상용 퍼즈 도구 개발 회사인 Codenom1icon을 설립했다.

2014년부터 널리 사용되고 있는 Michat Zalewski가 개발한 오픈 소스 퍼징 도구인 "아메리칸 퍼지 롭"(AFL, 이름은 토끼 품종에서 유래)이 있다. AFL은 그레이 박스 테스트에 사용할 수 있으며, 유전적 기법을 통해 테스트 데이터를 생성한다.

참조

_[1] 웹사이트 Foreword for Fuzz Testing Book https://pages.cs.wis[...] 2024-03-29
_[2] 뉴스 Security Experts Expect 'Shellshock' Software Bug in Bash to Be Significant https://www.nytimes.[...] 2014-09-25
_[3] 웹사이트 Bash bug: the other two RCEs, or how we chipped away at the original fix (CVE-2014-6277 and '78) http://lcamtuf.blogs[...] 2017-03-13
_[4] 웹사이트 Shellshock makes Heartbleed look insignificant https://www.zdnet.co[...] ZDNet 2014-09-29
_[5] 웹사이트 Fuzzing: Wie man Heartbleed hätte finden können (in German) http://www.golem.de/[...] 2017-03-13
_[6] 웹사이트 How Heartbleed could've been found (in English) https://blog.hboeck.[...] 2017-03-13
_[7] 웹사이트 Search engine for the internet of things – devices still vulnerable to Heartbleed https://www.shodan.i[...] 2017-03-13
_[8] 웹사이트 Heartbleed Report (2017-01) https://www.shodan.i[...] 2017-07-10
_[9] 웹사이트 DARPA Cyber Grand Challenge http://www.darpa.mil[...] 2017-03-12
_[10] 웹사이트 Mayhem comes in first place at CGC http://www.darpa.mil[...] 2017-03-12
_[11] 웹사이트 Microsoft: Windows 10 is hardened with these fuzzing security tools – now they're open source https://www.zdnet.co[...] 2020-09-15
_[12] 웹사이트 Microsoft open-sources fuzzing test framework https://www.infoworl[...] 2020-09-17
_[13] 간행물 microsoft/onefuzz https://github.com/m[...] Microsoft 2024-03-06
_[14] 논문 Generating Test Cases for Web Services Using Data Perturbation https://dl.acm.org/c[...]
_[15] 논문 Optimizing Seed Selection for Fuzzing https://www.usenix.o[...]
_[16] 간행물 SNOOZE: Toward a Stateful NetwOrk prOtocol fuzZEr http://dl.acm.org/ci[...] Proceedings of the Information Security Conference (ISC'06)
_[17] 서적 2010 IEEE Symposium on Security and Privacy 2010-05
_[18] 논문 Partition testing does not inspire confidence 1990-12
_[19] 논문 On Testing Non-Testable Programs 1982-11-01
_[20] 논문 The Oracle Problem in Software Testing: A Survey http://discovery.ucl[...] 2015-05-01
_[21] 웹사이트 Clang compiler documentation https://clang.llvm.o[...] 2017-03-13
_[22] 웹사이트 GNU GCC sanitizer options https://gcc.gnu.org/[...] 2017-03-13
_[23] 서적 Proceedings of the 2008 international workshop on dynamic analysis: Held in conjunction with the ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA 2008) ACM
_[24] 논문 Differential Testing for Software http://www.hpl.hp.co[...]
_[25] 서적 Proceedings of the 2011 International Symposium on Software Testing and Analysis ACM
_[26] 웹사이트 Browser Security WhitePaper https://browser-secu[...] X41D SEC GmbH 2017-09-19
_[27] 웹사이트 Security enhancements for Microsoft Edge (Microsoft Edge for IT Pros) https://docs.microso[...] Microsoft 2017-10-15
_[28] 웹사이트 CERT Triage Tools https://www.cert.org[...] 2017-03-14
_[29] 웹사이트 Microsoft !exploitable Crash Analyzer https://msecdbg.code[...] 2017-03-14
_[30] 논문 Simplifying and Isolating Failure-Inducing Input http://dl.acm.org/ci[...] 2017-03-14
_[31] 문서 https://dl.acm.org/d[...]
_[32] 웹사이트 Codenomicon Products http://www.codenomic[...] 2009-02-15
_[33] 웹사이트 The Advantages of Block-Based Protocol Analysis for Security Testing http://www.immunitys[...] 2009-02-15
_[34] 웹사이트 Sharefuzz http://sharefuzz.sou[...] 2009-02-15
_[35] 웹사이트 JPEG 処理 (GDI+) のバッファオーバーランにより、コードが実行される (833987) (MS04-028) http://www.microsoft[...] 2009-02-15
_[36] 웹인용 Robustness Testing Of Industrial Control Systems With Achilles http://wurldtech.com[...] 2010-05-28

본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com