[SK 쉴더스 루키즈] 애플리케이션 보안: OWASP 10, NodeGoat, bWAPP 실습

OWASP Top 10

1. broken access control
   • facebook
     • 정상: login → pw 찾기
     • 공격: pw찾기 화면 바로 ㄱㄱ
2. security misconfiguration
   • AI 무작위 개발!! →보안 설정 잘못 多
   • web dev에서 Debug=True
3. 공급망 실패
   • SBOM 관리
   • 디지털 서명 검증
4. 암호화 실패
   • vault
   • aws secret manager
5. Injection
   • SQL Injection 등
6. 안전하지 않은 설계
   • 해결책: Shift left
     • 보안팀이 마지막에 점검을 하는게 아니라 설계부터 보안을 고려해야 함
7. 인증 실패
   • 추측하기 쉬운 pw, MFA 없는 경우
8. 무결성 실패
   • notepad++ 업데이트 서버 해킹
9. 로깅 및 알림 실패
10. 예외 조건의 부적절한 처리 NEW!!
    • 프로그램이 예상치 못한 상황을 예방·탐지·대응하지 못해 발생하는 취약점

 

BurpSuite를 활용한 웹 프록시 구성

 

BurpSuite 기능

 

1. HTTP / HTTPS 트래픽 가로채기

Burp Suite는 프록시(Proxy)로 동작해서 브라우저와 서버 사이에 끼어든다.
통신 구조는 다음처럼 바뀐다.

브라우저 ↔ Burp ↔ 서버

즉, 모든 요청/응답을 Burp가 중간에서 받고 다시 전달하는 구조다.

HTTPS도 볼 수 있는 이유?
Q. 왜 Burp는 HTTPS 내용을 보고, Wireshark는 못 볼까?
Burp Suite = 중간자(MITM)
Burp Suite 는 통신에 직접 개입하는 도구다.단순히 보는 게 아니라 “양쪽과 각각 연결”을 만든다.
동작 과정:
Burp가 자체 인증서를 생성이 인증서를 브라우저에 설치브라우저는 Burp를 신뢰된 서버로 인식TLS 연결이 2개로 나뉨
브라우저 ↔ Burp (TLS)Burp ↔ 서버 (TLS)
결과:
Burp는 양쪽 암호를 모두 해독 가능따라서 HTTPS를 평문으로 확인 + 수정 가능
👉 중요한 포인트TLS를 “깨는 게 아니라”중간에서 “종료 → 다시 연결”하는 방식이다.

Wireshark는 왜 못 보나
Wireshark 는 단순 패킷 캡처 도구다.통신에 개입하지 않고 그냥 옆에서 구경만 한다.
특징:
TLS 암호화 상태 그대로 캡처됨복호화 불가능 → HTTPS 내용 못 봄
핵심 비교
Burp Suite: 통신에 개입 (MITM) → HTTPS 내용 확인 가능Wireshark: 수동 캡처 → 암호화된 상태 그대로 → 내용 확인 불가

 

2. Repeater

수동 반복 공격 도구

특징:

• 같은 요청을 여러 번 보내면서 테스트
• 값 하나씩 바꿔가며 결과 확인

사용 예:

• 파라미터 변조
• 인증 우회 테스트

 

3. Intruder

자동 공격 도구

특징:

• 여러 요청을 자동으로 반복 실행

주요 용도:

• Brute Force (비밀번호 대입)
• 파라미터 자동 변경
• 토큰/세션 테스트

 

4. Scanner

취약점 자동 탐지 도구

• SQL Injection
• XSS
• 기타 웹 취약점 자동 탐색

 

5. Decoder

데이터 인코딩/디코딩 도구

지원 예:

• Base64
• URL Encoding
• Hex

웹 해킹할 때 값 해석할 때 필수

 

6. Comparer

요청/응답 비교 도구

사용 예:

• 정상 vs 비정상 응답 비교
• 로그인 전/후 차이 분석

 

실습: Broken Access Control 공격

실습환경: NodeGoat & bWAPP

 

NodeGoat

OWASP의 공식 프로젝트

node로 개발한 웹 보안 학습용 교육 도구

의도적으로 여러 보안 취약점을 포함하고 있음

 

bWAPP

의도적으로 취약하게 만들어진 오픈소스 웹 app

PHP + MySQL

Broken Access Control 이란?

유형

1. IDOR: 불안정한 직접 객체 참조

   - URL 주소, 파라미터 ID를 바꿔서 다른 사람의 정보에 접근하는 공격

2. 권한 상승

3. 기능 수준의 접근 통제 누락

    - 백스페이스 두번 (국회 언급 사고)

 

방어 방법

서버에서 모든 요청에 대해 권한 검사 (클라이언트 단에서 검사x )

   - ex) 멜론 0→1: 유료 사용자 전환

 

1. NodeGoat

 

환경세팅

cd ~
git clone https://github.com/OWASP/NodeGoat.git
cd NodeGoat
docker compose build  # 도커 이미지 만들기
docker compose up -d  # 실행

 

1. URL 조작- 다른 사람 정보 보기

 

밑에걸 주석 처리 해준다.(params로 검증하는 것)

기존에는 userid를 params를 보고 가져왔는데,이제는 session에 저장된 userid를 가져와서 검증을 하게 된다.

사용자의 요청을 신뢰하는 것이 아니라 사용자의 로그인 세션을 신뢰한다!

 

2. URL 조작- admin 권한 접근

일반 사용자인데, url 조작을 했더니 관리자만 볼 수 있는 페이지(/benefits)로 이동했다.

 

 

패치

admin만 접근할 수 있도록 isAdmin 을 넣어준다.

  // 25번 라인
  this.isAdminUserMiddleware = (req, res, next) => {
      if (req.session.userId) { // 먼저, 세션에 'userId'가 저장되어 있는지 확인하여 사용자의 로그인 여부를 판단
          return userDAO.getUserById(req.session.userId, (err, user) => { // 세션에 저장된 'userId'를 사용해 데이터베이스에서 해당 사용자 정보를 조회
             return user && user.isAdmin ? next() : res.redirect("/login"); // 그 사용자의 'isAdmin' 속성이 참(true)이라면 (user.isAdmin) next 실행 아니면 /login으로 보냄
          });
      }
      console.log("redirecting to login");
      return res.redirect("/login");
  };

 

이제는 일반 사용자로 로그인한 후, /benefits 로 접근하면 로그인 페이지로 리다이렉트 된다.

로그인 페이지에서 admin으로 로그인하면 이제서야 benefits로 접근하게 된다.

 

 

2. bWAPP

1. Broken Authentication - Insecure Login Forms

 

2. Session Mgmt. - Administrative Portals

 

low level: admin=0 -> admin=1 로 조작 가능

 

 

medium: cookie 에서 admin=0 → admin=1로 조작

 

3. Local/Remote File Inclusion

 

 

url을 보면 language에서 .php 파일을 로드하고 있다. 여기에 내가 보고자 하는 파일 경로(/etc/passwd)를 넣어주면 될 것 같다.

 

 

SSRF vs CSRF

SSRF

서버가 사용자 대신 외부 요청을 보내도록 만드는 공격

정상적인 도메인이 아니라 웹서버 내부 ip 요청을 보낸다. 그럼 웹 서버는 iam 서버에 접근하거나 외부 서버에 접근하는 요청을 보낸다.

 

CSRF

선량한 시민 client는 공격자가 몰래 심어놓은 js를 자기도 모르게 클릭하게 되어 client의 pw가 공격자가 원하는 걸로 바뀌게 된다. 

 

SSRF 공격- NodeGoat

1. proxy로 잡고,

 

2. url을 변조한 뒤에, 우클릭하여 Send to Repeater를 클릭하고

 

3. Repeater 탭으로 들어가서 Send를 누르면 결과를 볼 수 있다.

 

실습2. security misconfiguration 공격

보안 설정 오류

실습 환경: flaws.cloud

 

Level 1.

문제 상황

• flaws.cloud는 AWS S3 정적 웹사이트 호스팅 방식으로 운영되고 있음
• 도메인 이름이 곧 S3 버킷 이름과 같다는 게 첫 번째 힌트
• 서버의 ip를 알아내자. → nslookup

3.5.78.208을 주소창에 입력했더니 aws s3 사이트로 리다이렉트 됐다.

 

다른 ip를 역dns 조회 했더니 s3 사이트가 떴다.

즉, 이 사이트는 S3에 의해 정적 서비스가 되고 있다는 것을 알 수 있다.

S3가 외부에 직접 노출이 된 상태이니, 나는 아무 권한이 없이도 버킷 목록을 조회할 수 있다.

참고로, S3 정적 웹사이트 호스팅을 도메인에 연결하려면 버킷 이름이 도메인과 정확히 같아야 한다. AWS의 강제 규칙이다.

 

aws s3 ls s3://flaws.cloud/ --no-sign-request --region us-west-2

어떤 리전인지는 위에서 알아내었다.

 

누가 봐도 수상한 파일이 있다. 이걸 내 로컬로 다운로드 해보자.

aws s3 cp s3://flaws.cloud/secret-dd02c7c.html . --no-sign-request --region us-west-2

 

다운 받아 확인해보니 level 2로 넘어가는 url을 획득할 수 있었다.

 

 

Level 2.

유효한 aws IAM 계정으로 S3에 접근이 가능하다.

 

그래서 계정 생성하고 (test) 접속해봤는데 안 됨

 

내가 만든 계정에 S3Read 권한이 없어서 그런거였음

S3FullAccess 권한을 부여했다.

 

aws s3 cp s3://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud/secret-e4443fc.html . --profile test