시큐어 코딩(Secure Coding)

개요

애플리케이션의 기본 보안 사항들에 대해 배우고 일부 보안 방식에 대해 실습해 볼 것이다.

시큐어 코딩(Secure Coding)?

소프트웨어 개발 시 보안 취약점을 예방하고 안전한 애플리케이션을 구축하기 위해 보안 관점을 고려한 코딩 기법과 원칙을 적용하는 것을 의미.

애플리케이션이 사이버 공격, 데이터 유출, 무단 접근 등에 취약하지 않도록 보호할 수 있다.

주요 원칙

입력 검증 및 데이터 유효성 검사
- 모든 사용자 입력을 신뢰하지 않고 철저히 검증해야 한다.
- SQL Injection, XSS(Cross-Site Scripting)등 공격 방지.
인증 및 권한 관리
- 강력한 인증 및 권한 부여 시스템을 사용해야 한다.
- 최소 권한 원칙 적용(필요한 권한만 부여)
암호화 및 데이터 보호
- 민감한 데이터는 저장 및 전송 시 암호화
- 안전한 암호 알고리즘 사용
에러 처리 및 로깅
- 에러 메시지에 민감한 정보를 노출하지 않도록 관리
- 시스템 활동을 로깅하여 문제 발생 시 추적 가능하도록 설정
세션 관리
- 안전한 세션 ID 생성 및 관리
- 세션 타임아웃 설정, 쿠키 보안 속성 설정(HttpOnly, Secure).
코드 관리 및 유지보수
- 코드 리뷰와 정기적인 보안 점검 수행
- 최신 보안 업데이트와 패치 적용
취약점 방지 프로그래밍
- 보안 위협 모델링을 통한 위험 식별 및 예방
- 안전한 라이브러리 및 프레임워크 사용

시큐어 코딩의 중요성

사이버 공격 방지: 보안 위협으로부터 시스템을 보호
데이터 보호: 고객 및 기업의 민감한 데이터 유출 방지
신뢰성 향상: 사용자 신뢰 확보 및 기업 평판 보호
법적 및 규제 준수: GDPR, 개인정보 보호법 등 규제 준수

적용 사례

입력 값 검증 시 정규식을 사용해 SQL Injection 방지
비밀번호 암호화를 위해 bcrypt, PBKDF2 등 안전한 해시 알고리즘 사용
Spring Security와 같은 보안 프레임워크 적용

CORS(Cross-Origin Resource Sharing)

CORS

CORS(Cross-Origin Resource Sharing) 교차 출저 리소스 공유 정책, 교차 출처라는 것은 (엇갈린) 다른 출처를 의미 출처(Origin) 어떤 사이트를 접속할 때 인터넷 주소창에 URL이라는 문자열을 통해 접근, URL

eleunadeu.tistory.com

CORS 에러 해결 방법, CORS 보안 취약점 예방 가이드

1. Chrome 확장 프로그램 이용 Chrome에서는 CORS 문제를 해결하기 위한 확장 프로그램을 제공해준다. 링크에서 'Allow CORS: Access-Control-Allow-Origin' 크롬 확장 프로그램을 설치 해준다. 브라우저 오른쪽

eleunadeu.tistory.com

CORS 필요성

API 호출: SPA(Single Page Application)와 같이 클라이언트 중심의 웹 애플리케이션은 종종 다른 도메인에서 호스팅되는 API를 호출해야 함
리소스 공유: 여러 도메인 간의 이미지, 스타일시트, 스크립트, 폰트 등의 리소스를 공유할 필요가 있다.

설정 시 주의 사항

보안 고려사항
- 신뢰할 수 없는 출처를 허용하지 않도록 주의
- allowedOrigins에 와일드카드(*)를 사용하면 모든 출처에서의 요청을 허용하므로 주의가 필요
- 민감한 정보를 보호하기 위해 Access-Control-Allow-Credentials를 신중하게 설정
성능 고려사항
- Preflight 요청이 빈번하면 성능 저하가 발생할 수 있으므로, Access-Control-Max-Age를 설정하여 Preflight 요청을 캐싱
- 불필요한 Preflight 요청을 최소화하기 위해 단순 요청 조건을 충족하도록 API 설계를 검토

CORS 해결(백엔드)

전역 설정

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.CorsRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

@Configuration
public class WebConfig {

    @Bean
    public WebMvcConfigurer corsConfigurer() {
        return new WebMvcConfigurer() {
            @Override
            public void addCorsMappings(CorsRegistry registry) {
                registry.addMapping("/**")
                        .allowedOrigins("http://localhost:3000")  // 허용할 출처
                        .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")
                        .allowedHeaders("*")
                        .allowCredentials(true)
                        .maxAge(3600);  // Preflight 요청 캐시 시간
            }
        };
    }
}

컨트롤러 레벨 설정

import org.springframework.web.bind.annotation.CrossOrigin;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class MyController {

    @CrossOrigin(origins = "http://localhost:3000")
    @GetMapping("/api/data")
    public String getData() {
        return "Data from server";
    }
}

CSRF(Cross-Site Request Forgery)

CSRF(사이트 간 요청 위조)는 웹 애플리케이션의 취약점을 악용하여 사용자가 원하지 않는 동작을 수행하도록 만드는 보안 공격.

사용자가 특정 웹 사이트에 로그인한 상태에서 악의적인 사이트가 사용자 몰래 요청을 전송해 권한 있는 작업을 수행하도록 조작하는 방식.

CSRF 공격 원리

사용자 로그인: 사용자가 은행 사이트 등 신뢰할 수 있는 웹사이트에 로그인 해 세션을 유지한다.
악성 사이트 방문: 사용자가 악의적인 웹사이트에 방문한다.
악의적인 요청 전송: 해당 웹사이트는 사용자의 브라우저를 통해 신뢰할 수 있는 사이트로 요청을 전송(예: 송금 요청)
서버 처리: 신뢰할 수 있는 사이트의 서버는 사용자가 로그인한 상태임을 인식하고 요청을 정상적으로 처리

공격 예시

<img src="https://trusted-bank.com/transfer?amount=1000&to=attacker-account">

이미지 로딩처럼 보이지만, 브라우저는 사용자의 세션 쿠키를 포함하여 송금 요청을 전송할 수 있다.

CSRF 방어 방법

CSRF 토큰 사용(Anti-CSRF Token)
- 서버는 사용자에게 고유한 CSRF 토큰을 발급하고, 모든 상태 변경 요청에 해당 토큰을 포함하도록 요구
- 서버는 토큰의 유효성을 검사하여 요청이 유효한지 확인
SameSite 쿠키 설정
- SameSite 속성을 Strict 또는 Lax로 설정하여 외부 사이트에서 세션 쿠키가
CORS 설정
- 서버가 신뢰할 수 있는 도메인에서만 요청을 허용하도록 설정
Referer 헤더 검사
- 요청 헤더의 Referer 값을 확인하여 예상된 도메인에서 요청이 발생했는지 검증
사용자 알림 및 로그아웃 권장
- 사용자는 신뢰할 수 없는 사이트 방문을 피하고 작업 후 로그아웃하도록 안내

Spring Security CSRF 보호 설정

config

@Configuration
public class SampleSecurityConfig {

    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        http
                .authorizeHttpRequests(authorize -> authorize
                        .anyRequest().permitAll()
                )
                .csrf(csrf -> csrf.csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse()));

        return http.build();
    }
}

Controller

@Controller
public class SampleController {

    @GetMapping("/")
    public String showForm() {
        return "form";
    }

    @PostMapping("/submit")
    public String handleFormSubmit(@RequestParam("name") String name, @RequestParam("_csrf") String csrfToken) {
        System.out.println("Received CSRF token: " + csrfToken);
        System.out.println("Received name: " + name);
        return "result";
    }
}

HTML

form

<!DOCTYPE html>
<html xmlns:th="http://www.thymeleaf.org">
<head>
    <title>CSRF Example</title>
</head>
<body>
<form th:action="@{/submit}" method="post">
    <label for="name">Name:</label>
    <input type="text" id="name" name="name"/>
    <button type="submit">Submit</button>
</form>
</body>
</html>

result

<!DOCTYPE html>
<html xmlns:th="http://www.thymeleaf.org">
<head>
    <title>Result</title>
</head>
<body>
<h1>Form submitted successfully!</h1>
<a th:href="@{/}">Go back to form</a>
</body>
</html>

실습 결과

아무 값이나 입력 후 제출

성공 시 로그 및 사이트 헤더 확인

CSRF token이 정상적으로 생성된 것을 확인할 수 있다.

CSRF 토큰을 변조 후 요청을 보내면 서버에서 기능이 수행되지 않는 것을 확인할 수 있다.

변조된 토큰으로 인해 컨트롤러 메서드가 동작하지 않아 로그도 출력되지 않았다.

XSS(Cross-Site Scripting)

XSS(크로스 사이트 스크립팅)는 웹 애플리케이션 보안 취약점 중 하나로, 공격자가 악성 스크립트를 웹 페이지에 삽입해 다른 사용자의 브라우저에서 실행되도록 만드는 공격.

사용자의 쿠키, 세션, 개인 정보 등을 탈취하거나 악의적인 동작을 수행할 수 있다.

XSS 공격

저장형 XSS(Stored XSS)
- 공격자가 악성 스크립트를 데이터베이스 저장하고, 다른 사용자가 해당 데이터를 조회할 때 스크립트가 실행된다.
- 예: 게시판, 댓글, 사용자 프로필 정보 등.
반사형 XSS(Reflected XSS)
- 공격자가 조작된 URL을 사용자에게 전송하고, 사용자가 해당 URL을 클릭했을 때 스크립트가 실행된다.
- 예: 검색 결과 페이지, 오류 메시지 등.
DOM 기반 XSS(DOM-Based XSS)
- 클라이언트 측 자바스크립트 코드가 DOM을 조작할 때 발생하는 취약점, 서버와의 통신 없이 브라우저에서 직접 실행된다.
- 예: 브라우저 URL 파라미터를 DOM에 직접 삭입하는 경우
반사형 XSS와 DOM 기반 XSS 차이
- 발생 위치와 동작 방식에서 차이가 있다.
- 반사형 XSS는 서버 측에서 발생하며, 입력된 데이터가 서버를 통해 반사되어 클라이언트로 돌아온다.
- DOM 기반 XSS는 클라이언트 측에서 발생하며, 클라이언트 측 JavaScript가 직접 데이터를 처리하고 DOM을 조작

XSS 공격 예시

저장형 XSS: 게시판에 다음과 같은 스크립트를 입력

<script>alert('XSS 공격!');</script>

이를 조회하는 사용자는 자동으로 경고창을 보게 된다.

반사형 XSS: URL 조작

https://example.com/search?q=<script>alert('XSS')</script>

검색 결과 페이지에 입력 값이 그대로 노출되면 경고창이 뜬다.

XSS 방어 방법

입력값 검증 및 필터링
- 모든 사용자 입력을 검증하고 유효성 검사 수행
- 허용된 문자 집합만 수용하고 악성 코드 제거
출력 시 이스케이프 처리(Escaping)
- HTML, JavaScript, URL 등에 출력할 때는 반드시 이스케이프 처리
- 예: &, <, >, " 등을 HTML 엔티티로 변환
콘텐츠 보안 정책(CSP, Content Security Policy)
- 브라우저가 스크립트 로딩을 제한하도록 CSP 헤더 설정
HTTP 전송 보안 설정
- HTTPS 사용으로 전송 데이터 보호
프레임워크 보안 기능 사용
- Spring Security, OWASP ESAPI 등의 보안 라이브러리 사용

Spring Boot에서 XSS 방어 적용 예시

Spring Security 설정

@Controller
public class ExampleController {

    @GetMapping("/greet")
    public String greet(@RequestParam String name, Model model) {
        model.addAttribute("name", HtmlUtils.htmlEscape(name));
        return "greet";
    }
}

Thymeleaf 사용(자동 이스케이프 처리)

<p th:text="${name}">사용자 이름</p>

SQL Injection(SQL 인젝션)

웹 애플리케이션의 보안 취약점을 악용해 SQL 쿼리를 조작해 데이터베이스에 악성 명령을 실행하는 공격으로 데이터 유출, 변경, 삭제 등 심각한 보안 문제가 발생할 수 있다.

위험성

데이터 탈취: 공격자가 데이터베이스에서 민감한 정보를 탈취할 수 있다.
데이터 변조: 데이터베이스의 데이터를 변경하거나 삭제할 수 있다.
권한 상승: 공격자가 데이터베이스 관리자 권한을 얻을 수 있다.
전체 시스템 장악: 심각한 경우 서버 전체를 장악할 수 있다.

SQL Injection 공격 원리

애플리케이션이 사용자 입력을 검증하지 않고 SQL 쿼리에 직접 포함할 때 발생, 공격자는 입력 필드에 악의적인 SQL 코드를 삽입해 데이터베이스 명령을 실행하도록 조작할 수 있다.

SQL Injection 공격 예시

SQL 조작(로그인 우회 후 DB 삭제)

# 기본 SQL 쿼리 구조
SELECT * FROM users WHERE username = 'admin' AND password = 'password';

# 악성 입력(로그인 우회)
Username: ' OR '1'='1
Password: ' OR '1'='1

# 쿼리 삽입 시 '1' = '1'는 항상 참이므로 모든 사용자가 로그인에 성공한다.
SELECT * FROM users WHERE username = '' OR '1'='1' AND password = '' OR '1'='1';

# DB 삭제 공격
Username: ' ; DROP TABLE users; --

# 쿼리가 조작되어 users 테이블이 삭제될 수 있다.
SELECT * FROM users WHERE username = ''; DROP TABLE users; --' AND password = '';

SQL Injection 방어 방법

Prepared Statement

SQL 쿼리를 사전에 컴파일하고 매개변수를 안전하게 바인딩한다.

JDBC 사용

String sql = "SELECT * FROM users WHERE username = ? AND password = ?";
PreparedStatement pstmt = connection.prepareStatement(sql);
pstmt.setString(1, username);
pstmt.setString(2, password);
ResultSet rs = pstmt.executeQuery();

ORM 사용(JPA, Hibername)
- ORM 프레임워크는 기본적으로 SQL Injection 방어 기능을 제공한다.
- 예시
```
User user = userRepository.findByUsernameAndPassword(username, password);
```
입력 값 검증(Validation)
- 사용자 입력을 철저히 검증하고 허용된 패턴만 허용한다.
- 예: 정규식을 통한 입력 값 검증
입력 값 이스케이프 처리
- 입력값을 적절히 이스케이프 처리해 특수 문자를 제거한다.
최소 권한 부여(Least Privilege)
- 데이터베이스 사용자에게 최소한의 권한만 부여
- 민감한 작업은 별도의 사용자로 수행
SQL 오류 메시지 관리
- 사용자에게 구체적인 SQL 오류 메시지를 노출하지 않도록 설정

Spring Boot SQL Injection 방어 설정

JPA 사용

@Query("SELECT u FROM User u WHERE u.username = :username AND u.password = :password")
User findByUsernameAndPassword(@Param("username") String username, @Param("password") String password);

Spring Data JPA 메서드 쿼리

User findByUsernameAndPassword(String username, String password);

Open Redirect(오픈 리다이렉트)

웹 애플리케이션이 특정 URL로 리다이렉트할 때 사용자의 입력을 검증하지 않고 외부 사이트로 리다이렉트하는 보안 취약점.

피싱 공격, 멀웨어 배포, 개인 정보 탈취 등을 수행할 수 있다.

Open Redirect 공격 원리

합법적인 웹사이트 리다이렉트 기능
- 웹 애플리케이션이 특정 경로나 URL을 기반으로 리다이렉트할 수 있다.
악성 URL 조작
- 공격자는 리다이렉트 URL을 악성 사이트로 변경하고 사용자가 신뢰할 수 있는 웹사이트의 URL로 가장하여 링크를 클릭하도록 유도한다.
사용자 피해 발생
- 사용자는 신뢰할 수 있는 웹사이트를 방문한다고 생각하지만, 악성 사이트로 리다이렉트 된다.

Open Redirect 공격 예시

1. 정상적인 리다이렉트 URL

https://example.com/redirect?url=https://trusted-site.com

2. 악성 URL로 조작

https://example.com/redirect?url=https://malicious-site.com

Open Redirect 방어 방법

리다이렉트 URL 화이트리스트 적용
- 리다이렉트 대상 URL을 미리 정의된 허용된 도메인 목록으로 제한한다.
상대 경로 사용 제한
- 절대 경로(http://, https://)가 아닌 애플리케이션 내의 상대 경로만 허용한다.
URL 검증 및 인코딩
- URL을 검증하고 인코딩하여 악성 URL 삽입을 방지한다.
사용자 입력 값 검증(Validation)
- 사용자 입력을 철저히 검증하고, 예상치 못한 경로로 리다이렉트하지 않도록 한다.
리다이렉트 메시지 표시(보안 경고)
- 리다이렉트 전에 사용자에게 경고 메시지를 표시하고, 리다이렉트를 확인하도록 요구한다.

Spring Security Open Redirect 방어 설정

DefaultSavedRequest 제거 설정
- Spring Security가 자동으로 리다이렉트 하지 않도록 설정할 수 있다.
```
http.formLogin().defaultSuccessUrl("/home", true);
```

Redirect URL Validation

@GetMapping("/redirect")
public String redirect(@RequestParam("url") String url) {
    if (!url.startsWith("/")) {
        throw new IllegalArgumentException("Invalid redirect URL");
    }
    return "redirect:" + url;
}

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

웹 애플리케이션의 취약점을 악용해 파일 시스템의 비공개 파일이나 디렉토리 구조에 접근하는 공격.

애플리케이션 파일 경로 입력을 제대로 검증하지 않을 경우 디렉토리 경계를 벗어나 민감한 데이터를 조회할 수 있다.

Directory Traversal 공격 원리

파일 경로 조작
- 웹 애플리케이션이 사용자 입력을 통해 파일 경로를 받는 경우, 공격자는 상대 경로 문자열(../)을 사용해 상위 디렉토리로 이동할 수 있다.
비공개 파일 접근
- 공격자는 애플리케이션 서버의 중요한 시스템 파일이나 데이터베이스 설정 파일 등에 접근할 수 있다.

Directory Traversal 공격 예시

정상적인 파일 접근 요청

https://example.com/view?file=reports/2024-summary.txt

악성 입력 예시 (상위 디렉토리 이동)

https://example.com/view?file=../../../../etc/passwd

passwd 파일이 노출될 수 있음

Directory Traversal 공격 위험성

시스템 파일 접근 (/etc/passwd, C:\windows\system32\config)
소스 코드 유출
사용자 데이터 탈취
서버 설정 파일 노출 (.env, application.yml)

Directory Traversal 방어 방법

입력값 검증 및 정규화

사용자 입력 값을 철저히 검증하고 예상된 형식인지 확인

파일 경로를 정규화하고 상위 경로(../) 제거

String basePath = "/var/www/data/";
File file = new File(basePath, userInput);
if (!file.getCanonicalPath().startsWith(basePath)) {
    throw new SecurityException("잘못된 파일 경로 접근 시도");
}

화이트리스트 기반 파일 접근 허용

허용된 파일 목록을 사전에 정의하고 해당 파일만 접근 허용

List<String> allowedFiles = List.of("report1.txt", "report2.txt");
if (!allowedFiles.contains(userInput)) {
    throw new SecurityException("허용되지 않은 파일 요청");
}

파일 경로 하드코딩 및 리소스 관리
- 상대 경로 입력을 피하고, 정적 파일을 관리할 때 파일 경로를 고정
파일 권한 제한
- 파일 시스템 권한을 최소화해 애플리케이션이 중요한 시스템 파일에 접근하지 못하도록 설정
애플리케이션 보안 설정 강화
- Spring Security 등 보안 프레임워크에서 파일 접근 제어 정책 적용

Spring Boot에서 Directory Traversal 방어 예시

Spring 컨트롤러 파일 다운로드

@GetMapping("/download")
public ResponseEntity<Resource> downloadFile(@RequestParam String fileName) {
    Path filePath = Paths.get("/var/www/data/", fileName).normalize();
    if (!filePath.startsWith("/var/www/data/")) {
        throw new SecurityException("잘못된 파일 경로");
    }
    Resource resource = new FileSystemResource(filePath.toFile());
    return ResponseEntity.ok()
            .header(HttpHeaders.CONTENT_DISPOSITION, "attachment; filename=\"" + resource.getFilename() + "\"")
            .body(resource);
}

Thymeleaf 템플릿 사용 (안전한 파일 경로 설정)

<a th:href="@{/download(fileName='report1.txt')}">보고서 다운로드</a>

Clickjacking(클릭재킹)

사용자가 의도하지 않은 클릭을 하도록 유도하는 UI 기반의 공격.

신뢰할 수 있는 웹사이트의 콘텐츠를 투명한 iframe으로 숨기고 위에 가짜 버튼을 배치해 사용자를 속임.

Clickjacking 공격 원리

공격자가 자신의 웹사이트에 투명한 iframe으로 타깃 웹사이트를 로드
사용자가 클릭하면 의도치 않게 타깃 웹사이트에서 민감한 작업을 수행

Clickjacking 방어 방법

X-Frame-Options 설정: 응답 헤더에 DENY 또는 SAMEORIGIN 추가.

import org.springframework.boot.web.servlet.FilterRegistrationBean;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class FilterConfig {

    @Bean
    public FilterRegistrationBean<ClickjackingProtectionFilter> clickjackingFilter() {
        FilterRegistrationBean<ClickjackingProtectionFilter> registrationBean = new FilterRegistrationBean<>();
        registrationBean.setFilter(new ClickjackingProtectionFilter());
        registrationBean.addUrlPatterns("/*");
        return registrationBean;
    }
}

Content Security Policy(CSP): frame-ancestors 정책으로 iframe 허용 도메인 제한.

import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
import org.springframework.security.config.annotation.web.configuration.WebSecurityConfigurerAdapter;

@Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            .headers()
            .contentSecurityPolicy("frame-ancestors 'self'")
            .and()
            .frameOptions().deny(); // 또는 .sameOrigin();
    }
}

UI 디자인 주의: 민감한 작업 버튼에 추가 확인 단계 구현.

Sensitive Data Exposure (민감 데이터 노출)

애플리케이션이 중요한 데이터를 암호화하지 않거나 잘못된 방식으로 보호해 데이터 유출이 발생하는 취약점.

네트워크 트래픽을 가로채거나 데이터베이스 침투를 통해 데이터를 탈취할 수 있다.

Sensitive Data Exposure 공격 원리

애플리케이션이 중요한 데이터를 암호화하지 않고 저장 또는 전송.
HTTPS 미사용, 안전하지 않은 키 관리, 취약한 암호화 알고리즘 사용.

Sensitive Data Exposure 방어 방법

데이터 암호화: 저장된 데이터와 전송 데이터를 강력한 알고리즘으로 암호화.
HTTPS 사용: TLS(SSL)로 모든 트래픽 암호화.
민감 데이터 최소화: 불필요한 데이터 수집 및 저장 금지.
보안 설정 강화: 강력한 인증 및 접근 제어 정책 적용.

Insecure Deserialization (비안전 역직렬화)

직렬화된 데이터를 역직렬화할 때 검증이 부족해 공격자가 악의적인 객체를 삽입해 원격 코드 실행(RCE) 등을 수행하는 취약점.

Insecure Deserialization 공격 원리

애플리케이션이 직렬화된 객체를 신뢰하고 역직렬화.
공격자가 악성 객체를 포함한 직렬화 데이터를 서버로 전송해 실행을 유도.

Insecure Deserialization 방어 방법

데이터 검증: 입력 데이터를 철저히 검증.
사용 제한: 역직렬화 사용 최소화.
직렬화 대체: 안전한 데이터 포맷(JSON, XML 등) 사용.
보안 라이브러리 사용: 최신 보안 패치 적용 및 안전한 역직렬화 라이브러리 활용.

Insufficient Logging & Monitoring (부족한 로깅 및 모니터링)

애플리케이션이 중요한 이벤트(예: 로그인 시도, 권한 변경)를 로깅하지 않거나 적절히 모니터링하지 않아 보안 위협을 조기에 탐지하지 못하는 취약점.

Insufficient Logging & Monitoring 공격 원리

애플리케이션이 보안 관련 이벤트(예: 비정상 로그인, 오류 메시지)를 기록하지 않음.
관리자 또는 보안 시스템이 이벤트를 실시간으로 모니터링하지 않음.

Insufficient Logging & Monitoring 방어 방법

중요 이벤트 로깅: 인증, 권한 변경, 데이터 접근 시 로깅.
안전한 로깅 설정: 민감 데이터를 로깅하지 않도록 주의.
실시간 모니터링: 침입 탐지 시스템(IDS) 및 보안 정보 이벤트 관리(SIEM) 시스템 도입.
경고 알림: 의심스러운 활동 발생 시 관리자에게 자동 알림 설정.

CVE (Common Vulnerabilities and Exposures, 공통 취약점 및 노출)

소프트웨어와 하드웨어의 보안 취약점을 식별하고 표준화하기 위한 고유 식별자(ID) 시스템.

각 취약점은 고유한 CVE ID를 할당받아 전 세계적으로 공통된 명칭으로 관리.

CVE의 주요 특징

고유 식별자 할당
- 취약점이 발견되면 CVE ID가 할당됨.
- 형식: CVE-연도-순번 (예: CVE-2024-12345)
취약점 공개 정보 제공
- 취약점 설명, 영향받는 시스템, 문제 해결 방법 등의 정보 포함.
표준화된 관리
- 보안 연구자, 개발자, 보안 기관이 동일한 용어로 취약점을 관리하고 공유할 수 있음.

CVE의 활용 사례

보안 패치 검토: CVE ID를 기준으로 패치 여부 확인.
보안 점검: 보안 감사 및 취약점 관리 도구에서 CVE 목록 기반 점검.
위협 분석: 조직의 보안 상태 평가 시 CVE 목록 활용.

CVSS (Common Vulnerability Scoring System, 공통 취약점 점수 시스템)

보안 취약점의 심각도를 평가하고 수치화하는 국제 표준 점수 체계.

CVSS 점수를 통해 취약점의 위험 수준을 정량적으로 표현할 수 있음.

CVSS 점수 구성 요소

기본(Base) 점수
- 공격 벡터: 원격 또는 로컬 접근 가능 여부.
- 공격 복잡도: 공격 수행의 난이도.
- 권한 요구: 공격에 필요한 권한 수준.
- 사용자 상호작용: 사용자 개입이 필요한지 여부.
- 영향 범위: 시스템 기밀성, 무결성, 가용성에 미치는 영향.
임시(Temporal) 점수
- 공개 가능성: 취약점의 악용 코드 공개 여부.
- 수정 가능성: 패치 또는 완화 조치 가능 여부.
- 보고 신뢰도: 보고된 취약점의 신뢰 수준.
환경(Environmental) 점수
- 보안 요구 사항: 특정 환경의 보안 우선순위에 따라 점수 조정.

CVSS 점수 등급

CVSS 활용 사례

취약점 우선순위 관리: 높은 점수를 받은 취약점부터 패치.
보안 사고 대응: 점수 기반으로 대응 조치 계획 수립.
리스크 평가 보고서 작성: 점수로 위험 수준을 객관적으로 표현.

CVE와 CVSS의 관계

CVE는 취약점을 식별하고 목록화하는 시스템.
CVSS는 CVE 항목의 심각도를 평가해 점수로 나타냄.

정리

CORS와 Spring Security를 사용한 기초적인 보안 외에도 애플리케이션을 서비스하기 위해 필요한 다양한 보안 사항 및 취약점 들에 대해 배우게 되었다.
중요한 부분이면서 어렵고, 그만큼 보안 설정이 중요하다는 것과 설정을 위해 고려해야 되는 부분도 많다고 느꼈다.

'자바 심화 > TIL' 카테고리의 다른 글

DB Lock (1)	2024.12.26
장애 대응 (1)	2024.12.24
모니터링 - Slack Alert 보내기 (1)	2024.12.20
모니터링(Monitoring) (1)	2024.12.19
프로젝트 회고 (0)	2024.12.18

개발 관련 공부방

시큐어 코딩(Secure Coding)

개요