자바에서 MVC 구조를 활용한 미니 프로젝트를 진행하던 중 java.util.ConcurrentModificationException 예외가 발생했다.

에러

for (Animal animal : searchAnimals) {
        if(animal.getPetId() != animalPK) {
            searchAnimals.remove(animal);
        }
}

에러 메시지

 java.util.ConcurrentModificationException
    at java.base/java.util.ArrayList$Itr.checkForComodification(ArrayList.java:1013)
    at java.base/java.util.ArrayList$Itr.next(ArrayList.java:967)
    at ubis.service.PetChargerService.getAnimalList(PetChargerService.java:75)
    at ubis.controller.PetChargerController.getAnimalList(PetChargerController.java:55)
    at ubis.view.StartView.main(StartView.java:79)

➰ 원인

ConcurrentModificationException는 동시 수정 예외로, List, Map과 같은 컬렉션을 수정하는 도중에 다른 스레드에서 동시에 컬렉션을 수정하려고 발생하는 예외이다.

수정?

• 요소를 추가(add)
• 요소를 삭제(remove)
• 컬렉션의 순서를 변경

for (Animal animal : searchAnimals) {
        if(animal.getPetId() != animalPK) {
            searchAnimals.remove(animal);
        }
}

현재 forEach() 루프가 내부적으로 Iterator를 사용하여 컬렉션을 반복하고 있다. Iterator는 반복하는 동안 내부에 반복자가 돌아가고 있고 중간에 다른 스레드에서 컬렉션을 수정하려고 할 때 이를 감지하고 ConcurrentModificationException을 던진다.

즉, getAnimalList 메소드에서 searchAnimals 리스트를 반복하는 동안 remove 메소드를 호출해서 이런 예외가 발생했다.

🌱 ConcurrentModificationException이 발생하는 근본적인 이유?

반복자(Iterator)의 안전성(safety)을 보장하기 위해서

** 📍 반복자의 안전성을 보장해야 하는 이유?**

컬렉션의 구조적 변경은 반복자(Iterator)와의 일관성을 깨트린다. 컬렉션의 구조가 반복 중에 변경되면, 반복자의 동작이 예측할 수 없게 된다. 예를 들어, 요소가 추가되거나 삭제된 후 반복자가 어떤 요소를 반환할지 확신할 수 없다. 또한 반복 중 컬렉션의 구조가 변경되면, 잘못된 데이터를 읽어오거나 프로그램이 비정상적으로 동작할 수 있다. 그래서 애초에 ConcurrentModificationException 예외를 통해 이러한 위험을 방지한다.

즉, ConcurrentModificationException 예외는 자바 컬렉션 프레임워크가 동시 수정으로 인한 데이터 불일치를 방지하기 위해 고안된 메커니즘이라고 이해하면 된다.

➰ 해결

1) removeIf 사용

searchAnimals.removeIf(animal -> animal.getPetId() != animalPK);

Stream API 의 removeIf 메소드를 사용하여 조건에 맞는 요소를 일괄적으로 삭제했다. 이 메소드는 내부적으로 안전하게 작업을 처리하기 때문에 에러가 발생하지 않는다.

2) Iterator 사용

Iterator<String> iterator = searchAnimals.iterator();
while (iterator.hasNext()) {
    String animal = iterator.next();
    if (animal.equals("Lion")) {
        iterator.remove(); // Iterator의 remove 메소드 사용
    }
}

Iterator의 remove() 메소드를 사용하여ConcurrentModificationException을 방지한다. 이 메소드는 반복자와 컬렉션의 상태를 일치시켜 준다.

➰ Mini Project

아래는 위 에러가 발생하면서 진행했던 프로젝트이다.

MVC 구조와 Stream API를 익히고자 진행하였다.

😃 [UBIS] MVC Mini Project

➰ 참고

• https://codechacha.com/ko/java-concurrentmodificationexception/

자바를 사용하면 static 변수, static 클래스를 자주 볼 수 있다.

예를 들어 메소드 호출 시 에러가 나면 static 변수를 추가하라는 메시지 창이 나와서 에러를 고치기 위해서 단순히 static 을 추가해 코드를 작성했었다.

Cannot make a static reference to the non-static method info() from the type BasicSyntax3

Static 이 '정적' 라는 의미는 알고 있었지만 정확히 어떤 의미를 가지고 있는지 모르고 사용했었다. 에러가 나는데 왜 static 클래스로 만들어서 불러야 하는건지, 왜 메모리 에러가 나는지 몰랐다.

그래서 static 이 뭔데? 왜 써야하는건데?😂

늦었지만 이제라도 의미를 알고 제대로 활용하고자 static 에 대해서 정리하고, static 관련 문제도 직접 출제하고 풀어봄으로써 완벽하게 이해해보고자 한다.

➰ Static이란?

정적(static)은 '정적인, 고정된'이라는 뜻을 가지고 있다.

Static이라는 키워드를 사용하여 Static변수와 Static 메소드를 만들 수 있는데, 이들은 객체에 소속되는 것이 아닌 클래스에 고정되어 있다.

그렇기에 클래스 로더가 클래스 실행 명령어 시작하자마자 class byte code 메모리에 저장 (적재, 로딩)되고, 클래스별로 관리된다. 따라서 클래스의 로딩이 끝나는 즉시 바로 사용할 수 있다.

➿ Static 특징

1. 메모리에 고정적으로 할당된다.

2. 객체 생성 없이 사용할 수 있다.

   • 인스턴스 생성 후 호출도 가능하지만 지양하고 있다.

3. 유틸리티 관련 함수를 만드는데 유용하게 사용된다.

4. 프로그램이 시작되면 메모리의 static 영역에 적재되고, 프로그램이 종료될 때 해제된다.

5. Static 메서드 내에서는 인스턴스 변수를 사용할 수 없다.

➰ Static 생성시점 및 메모리 할당

Static 키워드를 통해 생성된 정적멤버들은 Heap영역이 아닌 Static영역에 할당된다.

🌱 메모리 영역? 메모리 공간은 코드(code) 영역, 데이터(data) 영역, 힙(heap) 영역, 스택(stack) 영역으로 구성되어 있다. Static 키워드를 통해 생성되지 않은 변수와 메소드들은 객체가 생성될 때마다 각각의 객체마다 독립적으로 존재해야 하기 때문에 Heap 영역에 할당된다. Static으로 선언된 것들은 클래스 로드 시점에 메모리에 한 번만 할당되면 되기 때문에 데이터 영역(static 영역이 속해있음)에 할당된다.

static 단점

Static 영역에 할당된 메모리는 모든 객체가 공유하므로, 어느 객체에서나 동일한 값을 참조할 수 있다. 하지만 이 메모리는 Garbage Collector의 관리 대상이 아니기 때문에, 프로그램이 종료될 때까지 해제되지 않고 계속 유지된다. 그래서 Static을 너무 많이 사용하면 메모리가 낭비되어 성능이 저하될 수 있다. Static은 필요할 때만 신중하게 사용하는 것이 중요하다.

❓ Garbage Collector(GC)? GC는 사용하지 않는 메모리를 자동으로 정리해주는 기능이다. 일반적으로 객체를 생성할 때 메모리가 할당되는데, 더 이상 그 객체를 참조하지 않거나 필요하지 않을 때도 메모리는 계속 점유될 수 있다. 이런 불필요한 메모리(가비지)를 자동으로 해제해주는 것이 바로 Garbage Collector의 역할이다. GC 덕분에 개발자가 직접 메모리 관리를 하지 않아도 된다.

*** _Static 변수는 클래스와 함께 메모리에 할당되어 프로그램이 종료될 때까지 유지되므로, GC의 관리 대상이 아니다. _

➰ 코드 풀이

static 문제를 풀면서 잘 이해했는지 확인해봤다.

➿ 문제

package step01;

public class BasicSyntax3{
    static String name ="원우";
    int age =21;

    static int no1 = 0;
    int no2 = 0;

    BasicSyntax3(){
        no1 = no1+1;
        no2 = no2+1;
    }

    static void info() {
        String name2 = "호시";
        int age2 = 22;
        System.out.println(name+" "+name2);
    }


    public static void main(String[] args) {
        // 1. 현 코드가 구현된 클래스 내에서 static 메소드 검색해서 호출 
        info(); 

        // 2. 외부에서 static 메소드 호출하는 문법
        BasicSyntax3.info();

        //3. static 변수와 non-static변수 차이점 확인
        BasicSyntax3 bs1 = new BasicSyntax3(); 
        BasicSyntax3 bs2 = new BasicSyntax3(); 
        System.out.println(bs1.no1 + " "+ no1); 
        System.out.println(bs2.no1 + " "+ no1);
        System.out.println(bs1.no2 + " " +bs2.no2);

        //4. 객체를 통해서 멤버변수 및 메소드 호출
        BasicSyntax3 c = new BasicSyntax3();
        System.out.println(c.name);
        c.info() ;

        //5. Static 으로 선언된 변수 확인
        name = "fisaman";
        System.out.println(c);
        System.out.println(c.name);

        //6. Math 함수
        int v1 = Math.max(10, 20);
        System.out.println(v1);
    }
}

➿ 정답

➿ 풀이

1. 현 코드가 구현된 클래스 내에서 static 메소드 검색해서 호출

info(); 

• static 메소드인 info()는 객체 생성 없이 클래스 내에서 static 메소드를 직접 호출할 수 있다.

• static String name = "원우";: 클래스가 로딩될 때 메모리에 할당되며, 모든 객체가 공유한다.

-> 출력 결과: 원우 호시

2. 외부에서 static 메소드 호출하는 문법

BasicSyntax3.info();

• 객체를 생성하지 않고 클래스명으로 접근하여 static 메소드를 호출한다.

-> 출력 결과: 원우 호시

3. static 변수와 non-static 변수 차이점 확인

BasicSyntax3 bs1 = new BasicSyntax3(); 
BasicSyntax3 bs2 = new BasicSyntax3(); 
System.out.println(bs1.no1 + " " + no1); 
System.out.println(bs2.no1 + " " + no1);
System.out.println(bs1.no2 + " " + bs2.no2);

• no1 (static 변수): 클래스 로딩 시 메모리에 할당되어, 모든 객체가 동일한 값을 공유한다. 생성자 호출 시 no1이 두 번 증가하므로 최종값은 2이다.

• • 📍 이부분을 많이 틀렸을거 같다.

• no2 (non-static 변수): 객체마다 독립적으로 존재하며, 각 객체 생성 시 1로 증가한다. 두 객체의 no2는 모두 1이다.

-> 출력 결과: 2 2, 2 2, 1 1

4. 객체를 통해 멤버변수 및 메소드 호출

BasicSyntax3 c = new BasicSyntax3();
System.out.println(c.name);
c.info();

• name 변수는 static이므로 클래스명으로 접근 가능하지만, 객체를 통해서도 접근할 수 있다. (권장되는 방법은 아니다)

• info() 메소드는 static이지만 객체를 통해 호출할 수 있다.

-> 출력 결과: 원우, 원우 호시

5. Static으로 선언된 변수 확인

name = "fisaman";
System.out.println(c);
System.out.println(c.name);

• name 변수는 static이기 때문에 모든 객체에서 동일한 값을 참조한다.
• name 값을 "fisaman"으로 변경하면, 모든 인스턴스가 이를 공유한다.

-> 출력 결과: 객체의 메모리 주소(c.toString()의 결과), fisaman

6. Math 함수

int v1 = Math.max(10, 20);
System.out.println(v1);

• Math.max는 static 메소드이기 때문에 객체를 생성하지 않고 호출할 수 있다.

  • Math 내 데이터가 중요한 것이 아닌 max값 산출하는 메서드 기능이 중요! API 설계자도 사용자들이 주는 값 받고 비교하고 반환하고 번거로웠다. 즉, Math 객체 생성할 이유와 필요가 없어서 static으로 제시

-> 출력 결과: 20

➰ Static 문제1

Static 변수 이해하고자 직접 낸 문제입니다.

package step01;

public class Airplane {
    String name;
    static int total = 0;

    public Airplane(String name) {
        this.name = name;
        total = total+1;
    }

    static void showTotalCars() {
        System.out.println("구매한 비행기 수: " + total);

    }

    public static void main(String[] args) {
        Airplane airplane1 = new Airplane("boeing486");
        System.out.println("비행기이름 : " + airplane1.name);

        Airplane.total = 2938;
        System.out.println(airplane1.name + "의 total : " + airplane1.total);

        Airplane airplane2 = new Airplane("airbus127");
        System.out.println("비행기이름 : " + airplane2.name);

        Airplane airplane3 = new Airplane("wooriair98");
        System.out.println("비행기이름 : " + airplane3.name);

        Airplane.showTotalCars();
    }

}

결과

비행기이름 : boeing486
boeing486의 total : 2938
비행기이름 : airbus127
비행기이름 : wooriair98
구매한 비행기 수: 2940

➰ Static 문제2

문제와 정답이 코드 주석에 모두 있습니다.

package step01;

/*
 * 1. 코드를 확인하여 문법적으로 오류가 있는 부분을 모두 찾아 주석처리하고 그 이유를 작성하시오
 * 2. 코드의 실행 결과를 작성하시오
 */

public class PaperTest {

    int A;
    static int B;
    int C;
    String S = "hi";

    public PaperTest() {
        A++;
        B++;
        --C;
        ++B;
    };

    static void func1() {
        System.out.println("func1 is called!");
    }

    void func2() {
        System.out.println("func2 is called!");
    }

    public static void main(String[] args) {

        PaperTest p1 = new PaperTest();
        System.out.println("B is " + B); //B is 2
        System.out.println("d1.C is " + p1.C); //d1.C is -1

        PaperTest p2 = new PaperTest();
        System.out.println("B is " + B); //B is 4
        System.out.println("d2.A is " + p2.A);//d2.A is 1

        PaperTest p3 = new PaperTest();
        System.out.println("d3.B is " + p3.B);//d3.B is 6

//        System.out.println(S); 멤버변수
        System.out.println(p3.S);

        func1();
        p1.func1();
//        func2(); static 필요
        p3.func2();
        int result = p1.A + p2.B + p3.C;
        System.out.println("A + d2.B + d3.C = " + result); //A + d2.B + d3.C = 6

    }

}

➰ (추가) Test 시 static 변수

@Test 사용 시 static 없이도 함수 호출이 가능하다.

위에서 실행한 코드를 보면 당연히 되지 않아야 하는게 맞는데 @Test 에서는 함수 호출이 가능했다. 이게 가능한 일인가?🤔

코드를 보면 running()은 static으로 선언되어 있지 않고, 테스트 코드에서 해당 함수를 객체 생성도 안하고 호출이 가능했다.

혼란스러웠지만 이유를 찾았다.

💡 왜 가능할까?

@Test 사용시 static 없이도 함수 호출이 가능한 이유는 JUnit은 테스트 메소드를 실행하기 전에 매번 새로운 인스턴스를 생성하여 메소드를 호출하기 때문이다. 좀 더 쉽게 말하면 테스트의 독립성과 상태 격리를 보장하며, 개발 과정에서 효율적인 테스트 작성이 가능하도록 설계된 예외적인 기능이다.

즉, 위와 같은 이유로 @Test 사용 시 예외적으로 static 없이도 함수 호출만 가능할 수 있도록 하였다. 또한 Test 애노테이션은 개발단계에서만 사용하기 때문에 이러한 호출을 예외적으로 허용하도록 되었다.

➰ 참고

• https://docs.oracle.com/en/java/javase/11/docs/api/jdk.dynalink/jdk/dynalink/beans/StaticClass.html

• https://coding-factory.tistory.com/524

• https://all-young.tistory.com/17

CSRF는 사이트 간 요청 위조의 줄임말로, 공격자가 타 이용자의 권한을 도용하여 특정 웹 사이트의 기능을 실행하게 할 수 있다.

🌱CSRF 성공하기 위한 조건?

1. 사용자는 보안이 취약한 서버로부터 이미 로그인되어 있는 상태
2. 쿠키 기반의 서버 세션 정보를 획득할 수 있어야 함

두가지 조건이 모두 충족해서 CSRF 공격이 성공할 수 있다.

➿ CSRF 공격 시나리오

1. 사용자는 보안이 취약한 A 웹사이트에 로그인하여 인증 쿠키를 브라우저에 저장한다.

2. 공격자는 자신의 웹사이트 (예: attacker.com)를 만들고, 이 웹사이트에 CSRF 공격을 위한 악성 스크립트나 HTML 폼을 삽입한다.

3. 사용자가 악성 요청을 자동으로 전송하는 스크립트가 포함되어 있는 공격자의 웹사이트를 방문한다.

4. 악성 요청 전송 사용자가 악성 스크립트가 작성된 페이지 접근시 웹 브라우저에 의해 쿠키에 저장된 session ID와 함께 서버로 요청된다.

5. 서버는 요청을 수신하고, 요청에 포함된 쿠키를 사용하여 사용자가 인증된 요청으로 처리한다.

   ⚠️이때 서버는 쿠키에 담긴 session ID를 통해 해당 요청이 인증된 사용자로부터 온 것으로 판단하고 처리한다. 그리고 사용자는 공격자의 웹사이트에서 의도하지 않은 작업이 실행되는 것을 알지 못한다.

❓ 의도하지 않은 작업?

• 은행 계좌 이체
• 비밀번호 변경
• 계정 설정 정보 변경
• 회원정보 수정

위와 같은 작업들이 나도 모르게 실행된다면 정말 위험하다.

➰ 취약점 내용

o 공격자가 업로드 한 악의적 행위 구문으로 인해 타 이용자의 권한 도용이 가능한지에 대해 점검한다.

• 타 이용자의 권한으로 실행하고자 하는 구문을 업로드 후 해당 이용자 권한으로 구문이 실행되는지 가능 여부 점검 ※ 일반적으로는 스크립트 구문이 많이 사용되나, 다른 방식 사용 가능

➰ 점검기준

🌱 양호 사용자의 입력 값에 대한 검증 및 필터링이 이루어지는 경우

💊 취약 사용자의 입력 값에 대한 검증 및 필터링이 이루어지지 않아 스크립트 실행이 가능한 경우

➰ 점검 절차

1. 사용자가 웹 사이트에 로그인을 한다.
   • 로그인 후, 웹 브라우저에 인증 쿠키(PHPSESSID)가 저장된다.

2. 사용자가 로그인 상태에서 공격자가 보낸 피싱 이메일을 열고, 악성 링크를 클릭하도록 피싱한다. - 기업의 경우 실제 담당자의 업무 범위에 해당하는 내용의 메일을 발신하여 피싱한다.

출처 : 보안 뉴스

3. Burp로 실제로 비밀번호를 변경할 때, 요청 패킷을 가로채고 분석한다.

• 요청 메시지를 살펴보면, password_new, password_conf 파라미터에 새 비밀번호가 전달되며, change 파라미터는 고정된 값으로 change를 가지고 있다.
• 인증을 위해 PHPSESSID 쿠키만 랜덤한 값을 가지고 있고, 이 값이 매우 중요하다.

4. 공격자는 사용자의 랜덤한 PHPSESSID 쿠키를 알거나 전달할 수 있으면 파라미터 값을 변조하여 패스워드를 변경할 수 있게 되므로 이를 참고하여 공격을 수행하는 html 코드를 작성한다.

   <!DOCTYPE html>
   <html>
   <body>
   <script>
    var xhr = new XMLHttpRequest();
    xhr.open("POST", "http://target-website.com/change-password", true);
    xhr.withCredentials = true; // 쿠키를 함께 전송하기 위해 설정
   
    // 폼 데이터 구성
    var params = "password_new=hacker1234&password_conf=hacker1234&change=change";
   
    // 요청 헤더 설정
    xhr.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
   
    // 요청 전송
    xhr.send(params);
   </script>
   </body>
   </html>
   
   

```

• 이때, withCredentials 속성을 사용하여 인증 쿠키를 함께 전송한다.

5. 사용자가 웹 사이트에 접속한 상태에서 http://localhost/csrf.html 에 접속하게 한다.

6. 사용자가 링크를 클릭하면, 공격자가 지정한 패스워드로 변경하는 요청이 이전에 로그인되어 있는 웹 페이지로 자동으로 전송된다. 사용자는 이를 인지하지 못한 채 비밀번호가 변경된다.

7. 공격자는 변경된 패스워드를 이용하여 사용자 계정으로 로그인할 수 있다.

-> 변경한 패스워드를 이용하여 admin 계정으로 로그인을 시도한 결과, 패스워드가 변경되어 로그인에 성공하였다.

➰ 대응 방안

1. Referer 헤더를 검사하여 요청을 전송시킨 출처 페이지를 확인하고 정상 요청인지를 판별한다.
   • Referer 헤더는 해당 요청을 링크하고 있던 이전 웹 페이지의 주소를 알려주는 헤더

2. *CSRF 토큰 *사용
   • 쿠키 외에 공격자가 추측할 수 없는 값이 요청 메시지의 파라미터 등에 포함되어 있다면, 공격자는 csrf 공격을 성공시키기 어려움
   • 패스워드 변경과 같은 중요한 기능을 수행할 때, 기존의 패스워드를 다시 한 번 입력받도록 하여 사용자 본인이 직접 기능을 실행하는지 확인

1️⃣ CSRF 공격와 XSS 공격의 공통점

XSS와 CSRF 모두 공격자가 사용자의 권한을 빼앗아 악의적인 작업을 수행하다는 점과 사용자의 웹 브라우저를 이용하여 공격이 수행된다는 공통점이 있다.

그래서 결론적으로 말하면 XSS가 실행되면 스크립트 구문이 동작하기 때문에 CSRF도 당연히 실행된다.

CSRF는 XSS가 선행되어야 한다!

어찌보면 비슷한 취약점인데 다르게 취급하는 이유와 정확한 차이점이 무엇일까? 이 차이점을 구분하지 못한다면 스크립트 구문을 실행시킨다고 해도 현업에서 엉뚱한 취약점으로 분류하는 대참사가 발생할 수 있다. 제대로 이해하고 가자.

2️⃣ CSRF 공격와 XSS 공격의 차이점

• 공격 과정에서 피싱을 이용하는 특성만 같고, 피싱 이후 진행되는 과정이 완전히 다르다.

• 공격대상 : XSS – Client, CSRF – Server

• 악성 스크립트를 클라이언트에서 실행시키고, CSRF는 웹 서버로 유도해 서버에서 동작하게 한다.

• XSS는 사용자가 방문한 웹 페이지에 몰래 설치된 스파이가 사용자의 정보를 훔치거나 잘못된 행동을 유도하는 것, CSRF는 사용자가 신뢰하는 웹사이트로부터 허락 없이 명령(예: 비밀번호 변경)을 받아 대신 실행하게 만드는 것이다.

➰ 참고

• https://stupidsecurity.tistory.com/m/18?category=749410

• https://library.gabia.com/contents/security/7767/

• https://maker5587.tistory.com/62

• https://velog.io/@choidongkuen/Spring-CSRF-%EC%95%8C%EC%95%84%EB%B3%B4%EA%B8%B0

크로스 사이트 스크립팅은 웹사이트에 악성 스크립트를 주입하는 행위를 말한다.

공격자가 상대방의 브라우저에 스크립트가 실행되도록 해 사용자의 세션을 가로채거나, 웹사이트를 변조하거나, 악의적 콘텐츠를 삽입하거나, 피싱 공격을 진행하는 것을 말한다.

XSS 공격은 스크립트 언어와 취약한 코드를 공격 대상으로 하며, 협업에서는 줄여서 '크사'라고 부른다.

📍 자주 발생하는 취약점인가요? XSS 공격(XSS Attack)은 10가지 웹 애플리케이션 보안 취약점 목록인 OWASP Top10에 포함되어 있을 정도로 자주 발생하는 공격이다. 사용자가 글을 쓰고 읽을 수 있는 게시판에서 자주 발생하지만, 사용자의 입력 값을 웹페이지에 표시하는 곳에서도 공격이 발생할 수 있다.

❓왜 크로스 사이트 스크립팅이라고 부를까? 크로스 사이트 스크립팅은 웹 사이트(site) 사이를 넘어서(cross) 공격한다는 의미에서 크로스 사이트 스크립팅이라는 용어가 생겨났다.

EX) 실제로 테슬라는 차량 정보를 훔치거나 조작할 수 있도록 해주는 XSS 취약점을 발견했고, XSS 오류를 찾아낸 보안 전문가에게 1만 달러를 보상할 정도로 크리티컬하고 자주 발생하는 취약점이다. 기사 출처 - https://www.boannews.com/media/view.asp?idx=81485

➰ 취약점 내용

사용자가 입력한 내용을 기반으로 페이지를 동적으로 생성하는 웹 애플리케이션 (검색, 게시물 등록 등)을 악용하면, 해당 페이지를 보는 사용자의 웹 브라우저에서 임의의 코드 실행이 가능하게 된다.

아래와 같이 임의의 코드를 삽입하여 구현된다.

<script>스크립트 코드</script>

<script>alert(document.cookie)</script>

로그인 Session hijacking, 악성 프로그램 설치 등의 Client hacking의 위험성이 존재하므로 사용자 입력 값에 대한 검증 로직을 구현하고，필터링이 가능하도록 설정해야 한다.

➿ XSS를 어떻게 적용할까?

-> 📧이메일 피싱과 함께 사용

XSS를 활용하여 혹할만한 이메일 내용들을 구성하여 악성 링크나 첨부 파일을 클릭하게 유도한다. 사용자를 속여 링크를 클릭한다면 피해자의 웹 브라우저에서 악성 스크립트를 실행시켜, 로그인 정보나 쿠키 등을 탈취할 수 있다.

이는 URL 피싱을 이용한 공격과 XSS 취약점을 이용한 공격을 결합시킨 형태라고 볼 수 있다.

➿ 어떤 위험이 발생할까?

• 세션 하이재킹(Session Hijacking) 공격자가 XSS(크로스 사이트 스크립팅) 공격을 통해 사용자의 세션 쿠키에 접근하면, 이를 이용해 사용자를 사칭하고 이메일 계정에 무단으로 접근할 수 있다. 이로 인해 사용자 데이터가 탈취되거나 계정이 악의적으로 이용될 수 있다.

• 데이터 도난 이메일에는 중요한 정보나 민감한 데이터가 포함된 경우가 많다. 공격자는 XSS 취약점을 악용해 사용자가 모르는 사이에 이메일을 읽거나 첨부 파일을 다운로드하는 방식으로 데이터를 훔칠 수 있다.

• 한국 드라마에 자주 나오는 해킹 기법이다.

• 악성코드 확산 이메일에 포함된 XSS 공격은 사용자의 디바이스에 악성코드(멀웨어)를 다운로드하고 설치하는 데 악용될 수 있다. 이를 통해 추가적인 공격이 발생하거나, 다른 시스템에도 감염을 확산시킬 수 있다.

➰ 점검기준

🌱 양호

1. 사용자 입력값 및 전달 파라미터 값에 대한 검증 및 필터링이 이루어지는 경우

2. 웹 애플리케이션이 사용자 입력을 출력하기 전에 HTML 엔티티 인코딩(예: <를 <로) 등을 통해 스크립트 실행을 차단하는 경우

• 사용자 입력값 : URL, 폼 데이터, 쿼리 파라미터

💊 취약

1. 사용자 입력값 및 전달 파라미터 값에 대한 검증이 누락되어 스크립트 실행이 가능한 경우

2. 사용자 입력이 인코딩 없이 HTML, JavaScript 등의 콘텐츠로 출력되어 스크립트가 그대로 실행되는 경우

➰ 점검 절차

서버로 전달되는 사용자 입력 폼(게시판, 댓글, 검색 등) 및 URL 파라미터에 스크립트를 삽입하여 사용자 브라우저에서 실행 여부를 점검한다.

1. 스크립트가 실행되는지 확인하기 위해 사용자 입력 구간에 스크립트를 삽입하여 사용자 브라우저에서 실행 여부를 점검한다. http://www.example.com/search.php?keyword=”>

http://www.example.com/search.php?keyword=”><script>alert(“Test”);</script>

2. QnA 게시판에서 글을 작성할 때 내용 입력란에 아래 스크립트를 삽입하여 글을 작성한다.

   Test<img src=# oneerror=alert("XSSTest")>

   

3. alert 구문이 실행되지 않고 내용 그대로 글이 작성된다.
   • 점검결과 : 양호
   • 3.1 양호한 경우* 에러메시지가 발생한다.

3.2 취약한 경우 스크립트가 실행된다.

🌱 실제로 velog 에서 코드 구문이 아닌 곳에서 해당 코드를 테스트 했을 때 스크립트 코드가 실행되지 않았다. Velog는 스크립트 구문이 실행되지 않도록 XSS 공격을 잘 막아놓았다 .

📍 스크립트 실행 여부 점검 예문

//HTML 속성 내 테스트
"><script>alert('XSS');</script>

//이벤트 핸들러를 활용한 테스트
<img src="#" onerror="alert('XSS')">

//URL 파라미터 테스트
<a href="javascript:alert('XSS')">Click me</a>

//특수문자 및 엔티티 인코딩 우회
<script>String.fromCharCode(88,83,83)</script>

이 외에 여러 구문을 활용할 수 있으며, HTML 인코딩을 활용하는 등 필터링 우회를 접목하여 수행이 가능하다.

➰ 대응 방안

1. 웹 서버에서 입력 값에 정의된 문자 길이를 검증하여 javascript 등의 명령이 삽입되지 않도록 수정한다.

2. 악성스크립트 실행방지를 위해 이를 제거하는 Strip_tags() 함수 또는 치환해주는 htmlspecialchars() 함수를 사용한다.

3. 웹 서버의 검증 치환 등의 과정은 서버 사이드 스크립트(Server Side Script)에서 구현하여 검증 치환기능의 우회를 차단한다.

4. 문자열 특수 기호 등을 변환함수를 사용하여 치환하여 저장한다.

5. 이메일 클라이언트는 수신되는 모든 이메일을 철저히 검사하고 필터링하기 위해 보안 기능을 갖춘 이메일 보안 제품을 구독하거나 구매해 사용한다.

❓ XSS와 CSRF는 많이 헷갈리는 취약점이다. 용도를 알고 사용해야 하는 취약점이므로 둘의 차이를 CSRF 취약점과 함께 다음 포스팅에서 알아보자.

➰ 참고

• https://ohbank.online

• https://nordvpn.com/ko/blog/xss-attack/

• https://blog.naver.com/mailinspector/223312025523

• https://blog.naver.com/aosh8974/222985866753

• https://ethan-ncs.tistory.com/79

취약한 HTTPS 관련 취약점을 점검하기 위해 nmap과 openssl, sslscan을 설치해보자.

1️⃣ NMAP

1) 네트워크 스캐닝 및 포트 스캐닝 도구 2) Nmap은 열려있는 포트, 운영 체제 감지, 서비스 버전 감지 등을 통해 웹 서버의 상태와 노출된 포트들을 확인하는 데 사용된다.

• 아래 사이트에 접속하여 os 환경에 맞춰 설치한다.

  https://nmap.org/download.html

2️⃣ OpenSSL

1) SSL/TLS 설정과 인증서 검토 도구 2) OpenSSL은 HTTPS 서비스에서 사용하는 인증서를 검토하고, 특정 SSL/TLS 버전 또는 암호화를 강제로 사용하여 서버의 반응을 테스트할 수 있다.

• 이전에 타 취약점 점검을 위해 openssl 설치했지만 설치를 하지 않았다면 아래 사이트에 접속하여 os 환경에 맞춰 설치한다. (리눅스의 경우 wget 명령어를 통해 설치한다.)

  https://slproweb.com/products/Win32OpenSSL.html

3️⃣ sslscan

1) sslscan은 대상 서버에서 지원하는 SSL/TLS 버전을 감지 2) 서버가 사용하는 암호화 스위트(Cipher Suites)와 해당 스위트의 암호화 강도를 분석한다.

• 스캐닝 도구는 아래 깃허브에서 다운받는다.

  https://github.com/rbsec/sslscan

➰ 취약한 HTTPS 프로토콜 이용

취약한 버전의 암호 프로토콜 사용 시 암호화된 통신 내용이 유출될 수 있어 취약한 버전의 SSL(SSL 2.0, 3.0) 사용 여부를 점검한다.

🌱 SSL를 사용하면 안되는 이유? SSL 프로토콜은 2.0과 3.0을 비롯하여 많은 버그와 취약점이 발표되었으며, 공격자는 취약점을 바탕으로 암호화된 통신 내용을 획득 할 수 있기 때문에 SSL 프로토콜 다음 버전인 TLS 프로토콜을 사용해야 한다.

➿ 점검방법

두 가지 방법 중에 한가지만 선택해서 사용하면 된다.

cmd를 열어서 아래의 명령어를 입력한다.

• nmap을 이용한 HTTPS 프로토콜 확인

  > nmap -p [port] --script ssl-enum-ciphers [target_host]
  
  > nmap -p 443 --script ssl-enum-ciphers secureroot.co.kr

• openssl을 이용한 HTTPS 프로토콜 확인

  > openssl s_client -ssl3 -connect [target_host:port]
  
  > openssl s_client -ssl3 -connect secureroot.co.kr:443

점검결과 - 양호

점검결과, 취약한 버전의 SSL을 사용하지 않고 TLS 를 사용하고 있으므로 점검결과는 _"양호"_이다.

➰ 취약한 HTTPS 암호 알고리즘 이용

보안 강도가 낮은 암호 알고리즘을 사용할 경우 암호화된 통신 내용이 유출되는 등의 위협이 존재함에 따라 암호 알고리즘의 보안 강도의 적절성 여부를 점검한다.

🌱 HTTPS 통신을 수행하는데 통신 내용이 유출될 가능성이 존재할까? HTTPS는 데이터를 암호화하기 위해 SSL 또는 TLS(Transport Layer Security) 프로토콜을 사용한다. 특정 암호화 알고리즘을 통해 수행되며, 이 알고리즘이 얼마나 강력한지가 HTTPS 통신의 안전성을 결정한다. 따라서 취약한 암호화 알고리즘은 충분한 복잡성과 난이도를 제공하지 못한다. 예를 들어, 키 길이가 짧거나 알고리즘의 구조적 약점으로 인해 공격자가 상대적으로 적은 계산 자원으로 암호를 해독할 수 있기 때문에 HTTPS 통신을 수행해도 통신 내용이 유출될 가능성이 존재한다.

따라서 HTTPS 통신을 수행해도 강력한 HTTPS 암호 알고리즘을 이용해야 한다.

➿ 점검방법

• nmap을 이용한 HTTPS 암호 알고리즘 확인

  > nmap -p [port] --script ssl-enum-ciphers [target_host]
  
  > nmap -p 443 --script ssl-enum-ciphers secureroot.co.kr

점검결과 - 양호 점검결과, 보안강도가 높은 알고리즘(A)를 사용하고 있기 때문에 "양호" 하다.

➰ 취약한 HTTPS 컴포넌트 사용

취약한 HTTPS 확장 모듈 사용 시 암호화된 정보 노출 등의 위협이 존재하기 때문에 이에 대한 취약점 존재 유무를 점검한다.

취약한 OpenSSL 버전을 사용할 경우 HTTPS 관련 주요 취약점들을 가지고 있을 수 있으며 이러한 취약점이 발견될 경우 암호화된 정보의 노출 위험성이 존재한다.

📍 취약한 컴포넌트 종류

• CVE-2014-0160 : OpenSSL의 라이브러리에 버그가 존재하여 서버내 중요 메모리 데이터가 노출될 수 있는 취약점

• CVE-2014-0224 : OpenSSL 통신 상의 CCS(ChangeCipherSpec)메시지 처리과정 중 취약점이 있어 암호화된 정보의 노출 및 변조 가능성이 존재하는 취약점

➿ 점검방법

• Heartbleed, CCS-Injection, POODLE 취약점에 대해 점검한다.

1) HeartBleed(CVE-2014-0160)

> nmap -p [port] --script ssl-heartbleed [target_host]
> nmap -p 443 --script ssl-heartbleed naver.com

2) CCS-Injection(CVE-2014-0224)

> nmap -p [port] --script ssl-ccs-injection [target_host]
> nmap -p 443 --script ssl-ccs-injection naver.com

3) Poodle Attack(CVE-2014-3566)

> nmap -p [port] --script ssl-poodle [target_host]
> nmap -p 443 --script ssl-poodle naver.com

점검결과

🌱 취약하지 않은 경우 => 아래와 같이 포트번호만 나온다.

💊 취약한경우

=> 취약한 경우, 다음과 같은 형식으로 출력된다. => 취약점 점검 결과는 https://nmap.org/nsedoc/scripts/ssl-heartbleed.html를 참고하였다.

➰ 취약한 HTTPS 재협상 허용

암호화된 통신내용이 노출될 가능성이 존재하는 취약한 방식의 HTTPS 재협상(Renegotiation) 허용 여부를 점검한다.

🌱 HTTPS 재협상이란? HTTPS(SSL/TLS) 재협상이란 기존 보안 세션 내에서 다시 핸드쉐이크를 진행함으로써 새로운 세션을 맺는 것을 뜻한다. 처음에 HTTPS 연결이 설정될 때, 클라이언트와 서버는 서로 지원하는 암호화 알고리즘, 키 교환 방식, 인증서 등을 협상하여 사용한다. 재협상은 이러한 매개변수를 다시 협상하는 과정이다. 이는 주로 보안 강화 또는 연결이 장기화된 경우 암호화 키를 갱신하기 위해 사용될 수 있다.

OpenSSL 1.1.1 미만 버전에 대한 취약점으로 Insecure Client-Initiated 재협상을 통해 서버 측의 자원을 소모하도록 유도하여 DoS를 유발할 수 있는 취약점이다.

➿ 점검방법

openssl의 최신버전에서 지원하지 않고 0.9.8k 버전 이하에서 지원하므로 만약 해당 항목을 진단할 경우 openssl 0.9.8k 이하의 버전을 사용해 테스트 해야한다.

1. OpenSSL을 활용하여 점검 대상에 HTTPS 연결을 시도한다.

   > openssl s_client -connect [target_host:port]
   

openssl s_client -connect secureroot.co.kr:443

2. 연결 후 “R”을 입력하여 재협상 시도하여 재협상 여부를 점검한다.

R

```

점검결과

🌱 양호한 경우 재협상이 허용되지 않는 경우 아래와 같이 에러가 발생한다.

*💊 취약한 경우 * 취약한 경우 다음과 같은 형식으로 출력된다.

➰ 점검 후기

https 관련 취약점의 경우, 명령어만 알면 쉽게 확인할 수 있는 취약점이다. 하지만 어떠한 프로토콜과 버전을 사용하였는지에 따라서 취약점으로 잡아야 하는지 고민이 많았다. 취약한 버전의 SSL을 사용했을 경우 당연하게 취약점으로 잡아야 한다. 이 경우, 알려져 있는 취약점이 많기 때문에 대부분 SSL 을 사용하지 않는다. 그래서 TLS 를 사용하는데 최근 TLS 1.0 버전에서도 취약한 부분이 발견되었다. 1.0 버전을 사용한 부분이 있을 경우 필자는 취약점으로 잡았지만 각 사이트 마다 취약점으로 받아들이는 부분이 있었고 받아들이지 않는 사이트가 있었다. 그래서 결론은 TLS 1.0도 완벽하게 안전하지 않으므로 1.1 버전부터 사용하는 것을 권장한다. 그렇다고 TLS 1.0 이 안전하지 않은 것은 아니다.

➰ 참고

• KISA 공식 보안 가이드

• https://medium.com/@gauravbhandari072/nmap-unleashing-the-power-of-network-scanning-ba511cb774f0

• https://www.ssldragon.com/blog/what-is-openssl/

• http://www.secureroot.co.kr/sroot/resource/post/002/

• https://nmap.org/nsedoc/scripts/ssl-heartbleed.html

• 재협상 양호 증적 : https://jjang-joon.tistory.com/5

Eclipse 는 써봤는데 STS이라는 걸 알게되었다. STS란 뭘까?

SpringSource Tool Suite는 Eclipse 에 Spring F/W plugin 이 자동으로 추가된 IDE이다. 이클립스 확장판, 스프링에 특화된 이클립스라고 생각하면 된다.

찾아보니 spring.io 사이트에 접속해서 Projects> Development Tools > Spring Tools 4가 있었다.

📍 스프링 공식 사이트

https://spring.io/

➰ STS 장단점

장점

• 이클립스에 기본으로 포함안된 플러그인이 미리 세팅되어 있어서 편하다.

• 톰캣을 깔지 않아도 신규프로젝트를 생성하면 개발자용 톰캣 서버를 자동으로 생성해준다. (하지만 필자는 톰캣 서버를 추가로 설치하여 사용하였다.)

• 별도로 설정하는 것 없이 프로젝트를 바로 만들어서 개발할 수 있다.

단점

• 필요없는 플러그인까지 다운받기 때문에 순정 이클립스에 비해 다소 무섭다.

• 스프링 관련 프로젝트가 아닌 경우, 설정이 복잡할 수 있다. 이클립스는 범용 IDE로 스프링 관련 프로젝트가 아닌 경우에 설정이 STS 보다 덜 복잡하다.

• STS는 주로 스프링 개발에 특화되어 있어 스프링 이외의 다른 언어나 프레임워크에 대한 지원이 이클립스에 비해 제한적이다.

➰ 인텔리제이를 사용하면 되는 굳이 STS를 써야하는가?

맞는 말이다. 필자도 이클립스를 쓰다가 인텔리제이로 금방 갈아탄 사람으로써 편리한 인텔리제이를 두고 왜 STS나 이클립스 같은 걸 써야하는가에 대한 의문이 많았다.

우선 인텔리제이보다 STS가 스프링에 더 특화되어 있기 때문에 더 많은 기능을 지원한다.

그리고 이게 제일 큰 이유 같은데 바로 '비용'이다.

인텔리제이는 유료이고, STS나 이클립스는 무료이다. 인텔리제이가 이클립스보다 조작이나 단축키, 플러그인 등 더 편리하다는 장점이 있어 인텔리제이가 더 뛰어나다는 생각이 들겠지만 이클립스는 인텔리제이에서 제공하는 거의 모든 기능을 지원한다. 그렇기 때문에 회사에서는 유료인 인텔리제이보다 STS나 이클립스 사용을 더 많이 한다. (인텔리제이는 학생에게 무료로 제공하기 때문에 이 차이를 못느꼈다. 막상 돈을 내고 사용하려니 필자라도 이클립스나 STS를 사용할 것 같다.)

그래서 그동안 인텔리제이를 사용해왔더라도 STS나 이클립스에서도 스프링을 다룰 줄 알아야 한다.

➰ STS에 Lombok 설치

IntelliJ vs STS 롬복 적용 방법 차이 IntelliJ의 경우 IntelliJ내에서 Plugins를 선택하고, 마켓플레이스에서 Lombok을 검색하여 설치할 수 있어 간단하다. 하지만 STS와 이클립스의 경우 Lombok JAR 파일을 다운로드하여 실행한 후, STS에 Lombok을 설치해줘야 한다.

그러면 STS에 롬복을 설치하여 적용해보자.

1. 롬복 다운로드 사이트에 접속해 롬복을 다운로드한다. (Lombok Download)

   https://projectlombok.org/download

** lombok.jar 파일을 다운로드 한다.

2. 롬복이 설치된 경로에서 Shift + 마우스 우클릭 을 하여 powerShell을 열어준다.

3. PowerShell 접속 후 lombok.jar 파일을 실행시킨다.

   java -jar .\lombok.jar

   

4. lombok Installer 가 실행되면 Specify location을 클릭하여 STS 설치 경로의 IDE 실행 파일을 선택한다. (SpringToolSuite4.exe)

5. install/update 를 해주고 exit 한다.

6. STS에 롬복을 적용하기 위해 pom.xml 에 아래의 lombok 의존성을 추가한다.

   <dependencies>
    <dependency>
        <groupId>org.projectlombok</groupId>
        <artifactId>lombok</artifactId>
        <version>1.18.34</version>
        <scope>provided</scope>
    </dependency>
   </dependencies>

7. pom.xml 파일을 저장하여 Maven Dependencies 에 lombok이 추가되었는지 확인한다.

8. Lombok을 적용할 코드를 작성하고, 애노테이션을 추가한 후 import를 해준다.

9. Getter, Setter가 모두 만들어졌다면 sts에 롬복이 성공적으로 적용된 것이다.

📍 Trouble Shooting #1

설치 중 문제상황

롬복을 성공적으로 임포트 했지만 오른쪽에 getXxx, SetXxx가 뜨지 않았다.

원인

getXxx, SetXxx가 뜨지 않는다면 경로 문제(maven repository 경로) 혹은 라이브러리 문제일 수 있다.

해결방법 사용자 경로에 접속하여 .m2 파일을 지웠다가 다시 롬복 dependency를 추가하여 재실행한다.

• 삭제하고 sts 재구동하면 m2 파일이 재생성된다.

➰ 자주 쓰는 Lombok 애노테이션 정리

➰ 참고

• https://spring.io/tools

• https://projectlombok.org/download

SQL Injection(SQL 삽입)은 사용자가 간섭 가능한 매개변수(URL 파라미터, XML 등)에 의해 SQL 질의문이 완성되는 점을 이용하여, 개발자가 예상하지 못했던 SQL 문장이 실행되게 함으로써 비정상 질의 가능 여부를 점검하는 공격 기법이다.

이 취약점은 주로 애플리케이션이 사용자 입력을 제대로 검증하지 않고 SQL 쿼리에 포함시키는 경우 발생한다.

'여기어때'에서 발생한 개인정보 유출사건과 '뽐뿌'에서 발생한 개인정보 유출 사건 모두 SQL Injection 을 통해 발생한 피해이다.

➰ 취약점 내용

대화형 웹사이트는 사용자의 입력 값을 이용하여 데이터 베이스 접근을 위한 SQL쿼리를 만들어 구현된다. SQL Injection은 웹 애플리케이션과 데이터베이스 간의 연동에서 발생하는 취약점으로, 공격자가 입력 폼에 악의적으로 조작된 쿼리를 삽입하여 데이터베이스 정보를 불법적으로 열람하거나 조작할 수 있는 취약점이다.

비정상적인 SQL 쿼리로 DBMS 및 데이터(Data)를 열람하거나 조작 가능하므로 사용자의 입력 값에 대한 필터링을 구현해야 한다.

📍 SQL Injection에 관하여!(feat. 경험) SQL 인젝션은 테스트를 통해서는 발견하기 힘들지만 스캐닝툴이나 보안솔루션들을 거치면 보통 쉽게 발견되기 때문에 탐지하기는 쉽다. 최근에는 이러한 스캐닝툴이나 점검 툴들이 매우 잘나오고 있다. 하지만 공격에 성공할 경우, DB에 직접 접근이 가능하고 개인정보유출 등 큰 피해를 입힐 수 있기 때문에 보안에 각별한 주의가 필요하다.

➿ SQL Injection 종류

1) Error based SQL Injection

가장 대중적인 방법으로, 공격자가 데이터베이스 시스템의 오류 메시지를 통해 시스템의 내부 정보를 획득하는 방법이다. 이 방법은 오류 메시지를 통해 테이블 구조, 열 이름, 데이터베이스 버전 등의 정보를 얻을 수 있다.

1. 일반적인 sql 예시

아래와 같은 사용자 입력폼이 있다고 가정해보자.

SELECT * FROM users WHERE username = '$username' AND password = '$password';

2. 구문

로그인 폼에서 username 대신 아래 구문을 입력하면 된다.

' OR 1=1; --

3. 실행되는 SQL문

위 구문을 입력하면 아래와 같은 sql 문이 완성되고 실행된다.

SELECT * FROM users WHERE username = '[구문이 들어가는 위치]' AND password = '$password';

SELECT * FROM users WHERE username = '' OR 1=1; --' AND password = '';

• ' 를 통해 where 절을 닫아준다.
• '1=1'은 항상 참이므로 구문을 항상 참으로 만든다.
• --를 이용해 그 뒤의 모든 쿼리문을 주석처리해준다.

4. 에러메시지를 통한 정보 획득

SQL 문이 작동하는 것을 확인하면 특정 정보를 얻기 위해, 데이터베이스에서 의도적으로 오류를 유발하는 SQL 코드를 삽입한다.

' AND (SELECT 1 FROM (SELECT COUNT(*), CONCAT((SELECT database()), 0x3a, FLOOR(RAND(0)*2)) AS x FROM information_schema.tables GROUP BY x) AS y); --

• ' 를 통해 where 절을 닫아준다.
• select~~ : 쿼리문에서 중복된 항목을 생성하려 시도하므로, MySQL에서 오류를 발생시킬 수 있다. 오류 메시지는 일반적으로 데이터베이스 이름과 같은 내부 정보를 포함한다.
  • 시스템 정보를 모두 불러오는 쿼리문으로 시도해도 된다.
• --를 이용해 그 뒤의 모든 쿼리문을 주석처리한다.

5. 결과 확인

에러 메시지를 사용자에게 그대로 노출하는지 확인한다. 또한 그 안에 중요한 내부 정보가 포함되어 있는지 확인한다.

2) Union base SQL Injection

Union-Based SQL Injection은 UNION SQL 연산자를 악용하여 공격자가 추가적인 데이터를 반환하게 하는 기법이다. 두 개 이상의 SELECT 쿼리의 결과를 하나의 결과 집합으로 결합하는 UNION 명령어의 특성을 이용하며, 원래의 쿼리 결과에 추가적인 데이터를 포함시켜 민감한 정보를 유출시킬 수 있다.

1. 일반적인 sql 예시

검색 기능이 있는 웹사이트에서는 아래와 같은 쿼리로 데이터를 조회한다.

SELECT name, description FROM products WHERE category = '$category';

• $category는 사용자가 입력하는 값이다.

2. 구문

UNION 연산자를 사용하기 위해서는 두 쿼리의 컬럼 수가 동일해야 한다. 따라서 ORDER BY 절이나 HAVING을 이용한 오류 메시지를 통해 원래 쿼리에서 반환되는 컬럼의 수를 파악한다.

🌱컬럼 수 확인 쿼리

' ORDER BY 3; --

' UNION SELECT NULL, NULL; --

아래의 공격 쿼리를 통해 원하는 정보를 추출한다.

🌱공격 쿼리

' UNION SELECT username, password FROM users; --

3. 실행되는 SQL문

SELECT name, description FROM products WHERE category = '' 
UNION SELECT username, password FROM users; --

• ' 를 통해 where 절을 닫아준다.
• UNION SELECT~~ : 민감한 정보(사용자 이름, 비밀번호 해시)를 포함한 테이블을 찾은 후, 이를 반환하도록 시도한다.
• --를 이용해 그 뒤의 모든 쿼리문을 주석처리한다.

4. 결과 확인

반환된 데이터에서 필요한 정보를 확인한다. 정보를 확인한 후 더 많은 정보를 추출하는 추가적인 공격을 수행할 수 있다.

3) Blind SQL Injection

응답 페이지에 직접적으로 데이터베이스의 결과가 표시되지 않을 때 사용되는 공격 기법이다. Limit, SUBSTR, ASCII를 사용해서 조건이 참이면 페이지가 정상적으로 출력되고 그렇지 않을 경우 출력되지 않음으로 구분이 가능하다.

1. 일반적인 sql 예시

SELECT * FROM users WHERE id = $id;

• $id 사용자가 입력하는 값이다.

2. 구문

1' AND 1=1; --

1' AND (SELECT LENGTH(database())) = 8; -- //길이 추출

1' AND (SELECT SUBSTRING(table_name, 1, 1) FROM information_schema.tables WHERE table_schema = DATABASE() LIMIT 0,1) = 'a'; -- //문자 하나씩 추출

• 값을 조금씩 바꿔가며 데이터베이스 이름의 길이가 8자인지를 판단할 수 있다.

• 테이블 이름 또한 값을 조금씩 바꿔가며 데이터베이스 이름을 추출할 수 있다.

3. 실행되는 SQL문

SELECT * FROM users WHERE id = '1' AND (SELECT LENGTH(database())) = 8; -- ';

• (SELECT LENGTH(database())) = 8는 현재 데이터베이스의 이름 길이가 8인지 여부를 확인한다.
• • 이후는 주석 처리되어 무시된다.
• 데이터베이스 이름의 길이가 8일 때, id가 '1'인 사용자 정보를 반환한다.

SELECT * FROM users WHERE id = '1' AND (SELECT SUBSTRING(table_name, 1, 1) FROM information_schema.tables WHERE table_schema = DATABASE() LIMIT 0,1) = 'a'; -- ';

• SUBSTRING(table_name, 1, 1)는 table_name에서 첫 번째 문자를 추출한다.

• FROM information_schema.tables WHERE table_schema = DATABASE()은 현재 데이터베이스의 테이블 이름을 가져온다.

• LIMIT 0,1은 첫 번째 테이블만 조회한다.

• 만약 첫 번째 테이블 이름의 첫 번째 문자가 'a'라면, id가 '1'인 사용자 정보를 반환한다.

4. 결과 확인

참/거짓 조건에 따라 응답 시간이 달라지는 것을 이용하여 공격자는 데이터를 추출할 수 있다.

📍 이 외에 Stored Procedure based SQL Injection 기법과 Mass SQL Injection 등이 있지만 실제로 많이 사용하는 기법이 아니기 때문에 생략했다.

➰ 점검기준

🌱 양호

• 사용자 입력을 SQL 쿼리로 전달할 때 입력값의 유효성을 철저히 검증하고, 예외 처리를 통해 SQL Injection을 방지하는 코드를 구현하였다.

• Prepared statements와 매개변수화된 쿼리(parameterized queries)를 사용하여 입력값이 쿼리의 일부분으로 해석되지 않는다.

• 입력값에 대한 길이, 형식, 범위 등의 검증을 수행한다.

💊 취약

• 사용자 입력값을 SQL 쿼리에 직접 포함시켜 사용하는 경우 취약이다.

• 데이터베이스 오류 메시지가 클라이언트에게 그대로 노출된다.

• 준비된 쿼리나 매개변수화된 쿼리를 사용하지 않고, 문자열 연결을 통해 쿼리를 생성한다.

➰ 점검 절차

사용자로부터 전달되는 모든 파라미터에 임의의 쿼리문을 주입하여 유도된 값이 나오는지를 점검한다.

1. Burp suite로 QnA 게시판(/api/qna/view) 에서 게시글 조회 요청을 가로챈다.

2. 요청 body의 enc_data를 복호화하면 qna_id가 전달되는 것 확인할 수 있다.

3. 평문으로 요청을 보내는 것이 아닌 암호화된 데이터를 요청하기 때문에 아래의 SQL 쿼리문을 암호화한다.

   {"qna_id":"false UNION select username as title, password as content, account_number as write_at from users where true LIMIT 1,2; -- "}

4. 암호화된 쿼리문을 기존 enc_data 대신에 넣어서 요청을 보낸다.

• 게시판의 내용을 조회하는 기능인데 사용자 이름, 비밀번호, 계좌번호 등의 정보가 조회되는 것을 확인할 수 있다. => 점검결과 : 취약

5. 응답값을 frida로 확인한다.

5-2. 📍 [양호한 경우 예시] SQL Injection 구문에 대한 필터링이 잘 되어 있는 경우, 아래와 같이 '비정상적인 접근입니다'와 같이 DB 에러페이지가 뜨고 접근이 되지 않는다.

➰ 대응 방안

1. 입력 값에 대한 검증 로직을 구현하여 사전에 정의된 특수 문자들이 입력되지 않도록 조치한다.

   • 화이트리스트를 사용하여 허용된 입력값만 통과시키도록 한다.
   • 사용자 입력값의 길이, 데이터 형식, 허용된 문자 등을 검증한다.

2. Prepared Statement 구문을 사용하여 개발을 함으로써 입력 값에 들어가는 데이터는 단순히 문자열로 처리되도록 조치한다.

3. 불필요한 데이터베이스 에러 메시지가 사용자에게 노출이 되지 않도록 주의한다.

➿ 내 생각

SQL Injection 은 보안을 모르는 사람이라도 한번쯤 들어봤을 취약점이다. 실제로 현업에서 SQL Injection을 시도했을 때 공격에 성공하는 경우가 많았다. 하지만 민감한 정보, 즉 크리티컬한 정보가 아니라면 **공격에 성공하더라도 취약점으로 치지 않는다. 최근에는 보안 솔루션, 정적 분석 도구에서 대부분의 SQL Injection을 알아서 처리해준다.

그래서 내 생각에는 SQL Injection 을 점검하는 방법보다는 SQL Injection 이 일어나지 않도록** 시큐어 코딩을 하는 방법을 알아두는 것이 더 필요한 것 같다. 그래도 SQL Injection 에 대해서 좀 더 공부하고 싶다면 **'워게임'이라고 게임을 통해 학습할 수 있는 방법이 있다.

1. https://ctflearn.com/
2. https://dreamhack.io/wargame

최근에는 워게임 관련 다양한 사이트들이 있는 것 같은데 1단계부터 차근차근히 풀어보면 된다.

➰ 참고

• https://www.bloter.net/news/articleView.html?idxno=24731

• https://noirstar.tistory.com/264

• https://www.cloudflare.com/ko-kr/learning/security/threats/sql-injection/

• https://velog.io/@33bini/DB-SQL-Injection

불충분한 이용자 인증 취약점은 시스템이 사용자 인증 절차를 적절하게 수행하지 못해 발생하는 보안 문제를 말한다.

중요정보(개인정보 변경 등) 페이지에 접근할 때 인증 절차가 불충분할 경우 권한이 없는 사용자가 중요정보 페이지에 접근하여 정보를 유출하거나 변조할 수 있으므로 중요정보 페이지에는 추가적인 인증 절차를 구현하여야 한다.

➰ 취약점 내용

민감한 데이터 또는 이용자 인증이 필요한 경로에 다양한 방법을 통해 인증절차 존재 여부 및 우회 가능 여부를 점검한다.

점검방법 다양한 방법(SQL Injection, 액티비티 강제호출, 인증 정보 재사용, 응답값 변조 등)을 통해 인증 우회 가능 여부를 점검한다.

• 개인정보 및 비밀번호 수정 기능 페이지 접근 전에 본인인증에 대한 재인증 여부 확인
• 인증 절차 후 접근이 가능한 페이지의 URL을 수집하여 인증절차 없이 접근 시도,** 클라이언트 스크립트를 통한 접근 제어 시 해당 스크립트를 삭제하여 **인증 없이 해당 페이지에 접근 가능 여부 점검
• 플로우 통제 우회 가능 여부 점검

📍 플로우 통제란? 플로우 통제(Flow Control)는 시스템 내에서 데이터가 허가된 경로를 따라 흐르도록 보장하고, 비인가된 경로를 통한 정보의 누출이나 침해를 방지하는 것이다. 원하는 플로우대로 로직이 실행되도록 정보의 흐름을 제어한다고 생각하면 된다.

🌱** SQL Injection, 액티비티 강제호출, 인증 정보 재사용, 응답값 변조**를 통해 이용자 인증이 필요한 경로에 접근이 가능하고 개인정보가 조회가 가능하다면 불충분한 인증 취약점이고, 권한이 필요한 페이지가 접근이 가능하다면 부적절한 이용자 인가 취약점이다.

➰ 점검기준

🌱 양호

• 중요정보 페이지 접근 시 추가 인증을 하는 경우 양호

• 세션이 적절하게 관리되며, 사용자가 로그아웃하거나 세션이 만료되면 즉시 무효화됨 (토큰 유효시간이 길게 설정되어 있을 경우, 토큰을 탈취해 토큰으로 인증을 수행하여 중요 정보를 빼올 수 있다. 필자의 경우 보통 액세스 토큰 유효시간을 30분으로 설정한다.)

• 중요정보(개인정보 변경 등)를 표시하는 페이지에서 본인 인증을 재확인하는 로직이 구현되어 있음 ex) 다중 인증(2FA) 시스템이 적용되어 있다.

• 사용자가 인증 후 이용 가능한 페이지에 접근할 때마다 승인을 얻은 사용자인지 페이지마다 검증

• 인증 과정을 처리하는 부분에 Client Side Script를 사용하지 않음

💊** 취약**

• 중요정보 페이지 접근에 대한 추가 인증을 하지 않는 경우

• 인증 과정을 처리하는 부분에 Server Side Script(PHP, ASP, JSP 등)를 통하여 인증 및 필터링 과정을 수행함

• 잘못된 로그인 시도가 여러 번 발생해도 계정 잠금이 발생하지 않는 경우

• 세션 관리가 불충분하여 세션 하이재킹에 취약한 경우

• 로그아웃 후에도 세션이 계속 유효하거나, 세션 만료 처리가 미흡한 경우 (토큰 만료 처리가 미흡한 경우, 토큰은 계속해서 인증하는데 활용될 수 있으므로 만료처리를 꼭 해줘야 한다.)

➰ 점검 절차

불충분한 이용자 인증을 점검할 때 SQL Injection, 액티비티 강제호출, 인증 정보 재사용, 응답값 변조 등 다양한 방법이 있다. 상황에 맞게 적절한 우회 기법을 활용하여 불충분한 인증을 하는 곳이 없는지 확인해야 한다.

1. 로그인 시 알맞은 아이디와 비밀번호를 입력하여 로그인에 성공한 후 결과 데이터를 수집한다.

2. 로그아웃 후 일치 하지 않은 비밀번호를 입력 후 로그인에 실패한다.

• 이때 fiddler를 이용해 패킷을 잡는다.

3. 잡은 패킷에서 Break on Response버튼을 눌러 실패 결과를 프록시로 반환받는다.

4. 프록시로 반환받은 결과값을 성공 데이터로 바꾼 후 run 버튼을 클릭해 클라이언트로 보낸다. 응답값 변조를 통해 진행하였다.

5. Oh bank 앱으로 돌아가 로그인에 실패한 것을 확인한다.

• 비밀번호를 재 입력하라고 화면이 뜬다.
• 점검결과 : 양호

🌱 불충분한 인증 취약한 경우를 테스트 해보고 싶다면 아래 사이트에서 위 점검 절차와 동일하게 진행하면 된다.

http://testphp.vulnweb.com/logout.php 아이디: test 비밀번호: test

➰ 대응 방안

o 클라이언트가 아닌 서버 사이드 스크립트로 사용자 검증하는 절차가 필요하다.

• 클라이언트 사이드 스크립트로 검증할 때 변조가 가능하기 때문에 서버 사이드 스크립트로 사용자를 검증하는 절차가 필요하다.

o 로그아웃 시 세션을 즉시 무효화하고, 세션 만료 시간을 적절히 설정하여 세션 하이재킹을 방지한다.

o 일정 횟수 이상의 실패한 로그인 시도 시 계정을 잠그고, 사용자에게 알림을 전송한다.

o 중요 작업을 수행하기 전에 OTP, SMS 인증, 하드웨어 토큰 등의 방법을 통해 사용자에게 추가 인증을 요구한다.

➿ 경험담

불충분한 이용자 인증은 취약점 점검을 하면 특히 웹에서 가장 많이 나오는 취약점이다. SQL Injection이나 응답값 변조를 통해 접근하면 로그인이 성공되는 경우가 많다.

일반적으로는 위에서 점검한 절차대로** 실패 응답 패킷을 잡아서 성공 패킷으로 변조하였을 경우** 로그인이 성공되는 경우가 있다. 그 외에 아이디 비밀번호를 입력해서 로그인을 할 때 로그인에 성공할 경우 1을 반환하고, 실패할 경우 0을 반환하는 경우가 있다. 아이디 비밀번호를 아무거나 입력하고 0을 반환하는 응답값을 1로 변조하여 전송하면 로그인에 성공하는 경우가 있다.

실제로 이런 식으로 많이 잡혔던 취약점이고, 만약 로그인에 성공하여 권한이 필요한 페이지에 접근할 수 있다면 불충분한 인증으로 취약점을 잡아야 하는지, 부적절한 인가 여부로 잡아야 할지도 고민이었다. 선임분께 여쭤보니 귀에 걸면 귀걸이, 코에 걸면 코걸이다 라는 답변을 받았다.

이러한 _아이러니함_에 매번 어떤 취약점으로 잡을지 고민이 많았고, 필자는 좀 더 위험한 결과가 나오는 쪽으로 취약점을 잡고 있다.

➰ 참고

• 주요정보통신기반시설 기술적 취약점 분석 평가 방법 상세가이드

• Ohbank 공식 가이드

• https://rokefoke.tistory.com/54

Visual Studio Code로 SSH를 통해 원격 서버에 접속하는 방법을 알아보자.

🌱 VS code로 ssh 원격 접속 시 장점 VS code로 원격 접속을 할 경우** 자동으로 포트포워딩을 해주는 기능**이 있어 vmware에서 따로 포트포워딩을 설정해줄 필요가 없다.

그리고 MobaXterm과 VS code를 모두 사용해본 결과 mobaxterm 에서는 되지 않았던 것이 vmware에서 실행시켰을 때 오류없이 elasticsearch 라던지 키바나가 문제없이 붙었다. 이유가 명확하지는 않지만 아마 자동으로 포트포워딩을 해주는 기능 때문인 것 같다.(아시는 분 있으면 댓글로 알려주세요.)

VS Code를 사용했었지만 vsc로 원격 접속을 할 수 있는 것을 몰랐다. 막상 연결해보고나니 정말 편리했다. 아무튼 vsc 로 ssh 원격 접속을 해보도록 하자.

원격 서버에 접속할 수 있는 툴로는 VS code외에도 Putty, MobaXterm, Xshell 등이 있다.

**VM VirtualBox에 Ubuntu 가상 머신이 설정되어 있고, VS code가 설치되어 있어야 한다.

➰ 개발환경

1. Visual Studio Code : 1.91.0
2. VM VirtualBox : VirtualBox-7.0.18-162988-Win
3. Ubuntu : ubuntu-22.04.4-live-server-amd64.iso

➰ 설치과정

1. VS code에서 Remote-ssh extension 설치한다.

2. F1 키를 눌러서 Connect to Host 를 클릭한다.

3. F1 키 눌러서 Remote-SSH 설정 파일을 수정한다.

-> 접속 정보를 미리 저장해놓고 바로 접속하는 방식이다.

# Read more about SSH config files: https://linux.die.net/man/5/ssh_config
Host [호스트이름]
    HostName [IP 주소]
    User [계정명]
    Port [포트번호]

예시

Host ubuntu
    HostName 127.0.0.1
    User username
    Port 22

📍방법2

> ssh 계정명@ip주소 -p 포트번호

> ssh -p 포트번호 계정명@ip주소

f1 키를 눌러서 위와 같은 방법으로 접속하는 방법도 있지만, 포트번호나 계정정보를 올바르게 입력하여도 접속이 되지 않는 오류가 생기기도 한다. 그래서 위 방법 보다는 Remote-ssh 설정 파일에서 포트번호나 계정정보를 미리 저장해놓고 접속하는 방법을 추천한다.

4. 이후 다시 F1 버튼을 눌러서 Remote-SSH : Connect to Host를 선택하면 config 파일에 저장해놓은 host가 뜬다. host를 클릭하고 비밀번호를 입력하여 접속한다. 접속이 되면 새로운 원격 vscode 창이 뜬다.

5. Open folder > 해당 경로 > ok > 비밀번호 입력 후 완료한다.

>결과창

➿ Trouble Shooting #1

이슈 설정파일을 수정하고 connect to host를 하고 비밀번호를 입력했는데 계속 비밀번호 입력창이 나온다.

해결방법 비밀번호를 3번정도 반복해서 입력하면 시간이 지나면 연결이 된다.

➿ Trouble Shooting #2

이슈 원격 접속을 시도했는데 무한 로딩만 되고 연결이 되지 않았다.

원인 아래처럼 2줄이 추가되어 있었다(아래 4줄만 있어야 한다)

해결방법

1. config 폴더 내에 config 파일 외에 다른 파일이 있으면 삭제한다. (known_hosts 파일 삭제)
2. config 파일을 메모장으로 열어서 불필요한 내용을 삭제한다.

아까 불필요한 2줄이 추가되어 있었다.

3. 좌측에 새로 고침 버튼 누른 후 재접속 하여 비밀번호 입력하여 연결한다.

(❗ 필자는 위 방법을 통해 재 접속한게 아니라 설정 파일 옆에 +버튼을 눌러서 새로 접속을 했다. 그래서 설정을 수정한 게 반영이 안되고 새로 생성되어서 불필요한 코드가 계속 생기고 연결이 꼬여서 접속이 되지 않았다.)

➿ Trouble Shooting #3

이슈 위의 두 방법을 모두 시도해봤지만 연결이 되지 않는다.

원인 vscode 자체의 문제일 수도 있다. vscode로 하는 경우 가끔 나타나는 에러이다. 이전의 캐시가 쌓여서 변경사항이 반영이 되지 않는다거나 설정이 꼬인 것이다.

문제해결 서버측(vm)의 ~/.vscode-server 삭제 후 다시 시도한다.

➰ 참고

• https://code.visualstudio.com/docs/remote/ssh

• https://jstar0525.tistory.com/14

문자로 온 링크를 클릭 한번 잘못했다가 돈이 빠져나가거나 개인정보가 유출된다는 말을 들어본 적 있을 것이다.

이에 활용되는 기술이 '딥링크(DeepLink)'인데, 딥링크는 모바일 웹상에 있는 링크나 그림을 클릭할 경우 기기 내 관련 앱이나 사전에 정의된 특정 웹페이지가 실행되는 모바일 기술이다. 클릭을 할 때 특정 웹페이지를 악성 링크로 접속하도록 조작하여 사용자 개인정보를 조회하거나 계좌이체를 하며 악용한다.

❓딥링크 취약점이 많아지는 이유 모바일 애플리케이션 사용이 폭발적으로 증가하면서 다양한 기능과 콘텐츠에 빠르게 접근할 수 있도록 DeepLink를 많이 사용하게 되었다. 이로 인해 DeepLink를 사용하는 애플리케이션의 수가 증가하면서 취약점이 발생할 가능성도 높아졌다.

실제로 이메일, SMS, 소셜 미디어 광고 등에서 DeepLink를 많이 사용하는데, 사용자가 클릭 시 앱의 특정 프로모션 페이지로 바로 이동할 수 있다. 또한 푸시 알림을 통해 사용자가 알림을 클릭하면, 앱의 특정 페이지로 바로 이동하게 하여 관련 정보를 제공하거나 특정 액션을 취하게 할 수 있다. 이 과정에서 활용되는 것이 모두 딥링크이다.

DeepLink는 특정 콘텐츠나 기능에 빠르게 접근할 수 있도록 하는 유용한 기능이지만, 이를 악용하여 악성 링크를 통해 사용자에게 피해를 줄 수 있다. ** 🌱 쉽게 말하면 어플 광고 같은 것들이다. 어플에 있는 정보를 보기 위해서 클릭을 하면 어플 먼저 설치하라면서 설치 페이지로 이동시키는 것들을 딥링크로 이해하면 된다. 그 링크를 악용하는 것이 딥링크 도용 취약점이다!**

➰ 취약점 내용

공격자에 의해 조작된 URI를 이용자의 사용환경(웹뷰, 애플리케이션 등)에서 접속할때 개발자가 의도하지 않은 기능 동작 여부를 점검한다.

양호

위는 딥링크가 활용된 예시이다. '열기' 버튼을 눌렀을때 트립닷컴 다운로드 페이지로 가야 정상이지만 경로를 의도하지 않은 경로로 수정하여 열기 버튼을 눌렀을때 액션이 취해지거나 이동된다면 취약이다.

취약 ** 트립닷컴 페이지는 이해를 위한 예시이고, 실제로 취약한 사이트가 아니다.

열기 버튼을 눌렀을 때 계좌에 돈이 빠져나가도록 액션을 취했다. 돈이 빠져나갔으므로 취약이다.

➰ 점검기준

*🌱 양호 *

• DeepLink를 통해 접근하는 모든 기능 및 데이터는 *인증 및 권한 검사를 철저히 *수행하며 적절한 에러 메시지를 반환한다.

• DeepLink를 통해 접근할 수 있는 URL은 화이트리스트로 관리하고, 검증된 링크만 허용한다.

• DeepLink가 민감한 데이터를 처리하거나, 중요한 기능을 호출할 때 적절한 보안 검증을 거친다. 적절한 검증을 거치지 않은 상태에서 접근 시도 시 에러 메시지를 반환한다.

💊 취약

• DeepLink를 통해 접근하는 기능 및 데이터에 대해 인증 및 권한 검사가 이루어지지 않고 접근이 가능하다.

• DeepLink URL이 화이트리스트로 관리되지 않고, 모든 링크가 허용된다.

• DeepLink의 파라미터 검증이 부족하여, 인젝션 공격이나 기타 악성 행위가 발생했을 때 접근이 가능하다.

➰ 점검 방법

1. 앱에 등록된 Custom scheme을 조작하여, URI 접속을 통해 특정 activity 호출을 통한 인증우회 ,임의페이지 리다이렉션, Javascript Code 실행이 가능 여부를 점검한다.

딥링크 구성 예시
> schema://host.name/path/to/endpoint?

쿠팡은 coupang://category/1/product/12345678 이렇게 되어 있으며 각 어플마다 맨 앞의 SCHEME가 다르다.

2. 인텐트 스키마를 도용하여, 내부 파일에 접근, webview 조작 등 임의 기능을 실행 할 수 있는지를 점검한다.

점검실습

1. AndroidManifest 에 명시된 딥링크(http://xe1.com, https://xe1.com) 확인한다. deepLink가 설정되어 SendMoney에 연결되는 것을 확인할 수 있다. ** android:scheme 필드와 android:host 필드가 명시되어 있어야 함

2. SendMoney Activity가 실행 될 때 data에서 파라미터로 account와 money라는 값을 받아오는 것을 알 수 있다.

3. http://xe1.com?account=282838&money=500 처럼 해커의 account와 원하는 금액을 넘기는 URL를 만들고 Short URL을 이용하여 URL을 감춘 뒤 피싱 메세지를 보낸다.

   short url 만드는 주소: https://www.shorturl.at/

4. 만들어진 shortURL를 실행한다.

 https://shorturl.at/qRUW7

5. Oh Bank를 통해 열리게 되어 SendMoney가 작동하여 해커의 account로 인증도 없이 이체가 되는 것을 확인한다.

** Deeplink는 도용할 수 있는 방법이 점점 많아지고 있다. 따라서 점검 실습도 다양하다. 그중에서 가장 간단한 예시를 들었다. 추가로 필요한 부분은 DeepLink 메뉴얼을 참고하길 바란다.

➰ 대응 방안

• 공격자가 임의의 URI를 로드할 수 없도록 WebView에 로드하는 URI 또는 Domain에 대한 추가 검증을 진행한다.

• 딥링크 URI 파싱 시 취약한 함수 사용을 금지 하고, getQueryParameter 등의 함수를 활용하여 사전에 정의된 인자 값을 파싱하도록 조치한다.

  • 필터링 없이 가져오는 함수 : split, getHost, substring
  • 사전에 정의된 인자 값을 파싱하는 함수 : getQueryParameter

• 인가된 URI에만 자바인터페이스 권한을 부여한다.

• 도메인 검증을 이용한 우회를 방지한다.

  • uri.startsWith 함수를 통해 URI를 검증한다.

• 서브 도메인 악용을 막기 위해 슬래쉬(/)로 끝나도록 도메인명 작성

• URI.parse 함수 사용하는 경우 특수 문자를 필터링한다.

➿ 경험담

인턴 기간 동안 가장 기억에 남는 취약점이 바로 DeepLink이다. 당시 링크 접속을 통한 피싱 사례가 많이 나타났고, 2023년에 처음으로 전자금융기반시설 취약점 목록에 추가되었기 때문에 각 공공기관에서도 딥링크 취약점을 좀 더 자세히 봐달라고 할 정도였다. 모든 앱의 apk 파일을 jadx 로 풀어서 딥링크가 있는 Activity를 모두 확인했다..ㅎㅎ

실제로 점검을 진행했을 때 딥링크가 포함되어 있는 액티비티가 많았고 많이 활용되고 있었다. 딥링크를 이용한 악용사례가 점점 다양해지고 있어서 완전히 방지하기란 어려울 것 같다. 그래도 URI 파싱을 할 때 필터링을 하거나 취약한 함수 사용을 금지함으로써 방지할 수 있는 부분은 방지하고, 금융권에서 딥링크로 인해 악용 사례가 나타나지 않길 하는 마음으로 점검을 진행했던 것 같다. 추후에 딥링크 기법에 대해서 좀 더 공부해보고 싶다.

➰ 참고

• KISA 딥링크 취약점 조치 방안

• https://ohbank.online/Exploits/deeplink.html

• https://www.boannews.com/media/view.asp?idx=88439

• https://aeng-is-young.tistory.com/entry/Deeplink%EB%94%A5%EB%A7%81%ED%81%AC-%ED%99%9C%EC%9A%A9-%EC%B7%A8%EC%95%BD%EC%A0%90%EA%B3%BC-%EA%B7%B8-%EC%8B%9C%EC%97%B0

개발 과정에서 개발자들은 에러를 추적하거나 테스트를 목적으로 시스템에 로그를 찍어 확인하고, 이 과정에서 민감한 정보들이 로그에 기록된다. 배포 시에 해당 로그 코드를 모두 지워야 하지만 개발자의 실수로 이를 모두 포함하여 출시할 경우 해당 정보를 다른 취약점에 연계해서 사용할 수 있으므로 제거해야 한다.

"디버그 로그 내 중요정보 노출 여부" 취약점은 시스템 디버깅 과정에서 생성된 로그 파일에 중요한 정보가 포함되어 외부에 노출될 위험을 말한다. 로그 파일에 기록될 경우, 로그 파일에 접근 가능한 사용자나 해커에 의해 민감한 정보가 유출될 수 있다.

*아래와 같이 log.info로 로그를 찍어 디버깅을 한다.

로그 파일에 민감한 정보가 유출되지는 않았는지 디버그 로그 정보를 확인해보자.

➰ 취약점 내용

DDMS 등 디버그 로그를 확인 할 수 있는 도구를 이용하여 디버그 로그 내 *중요정보 *노출 여부를 점검한다.

중요정보란? 개인정보(주민등록번호), 금융정보(비밀번호, 카드번호, OTP, 보안카드 번호 등), 기타 중요정보라 판단되는 정보

➰ 점검기준

🌱 양호

• 디버그 로그에 사용자 비밀번호, 신용카드 정보, 개인 식별 정보 등 민감한 정보가 기록되지 않는다.

• 앱 동작 시, 로그 파일에 민감한 정보가 포함되는 경우, 해당 정보가 철저히 마스킹 또는 암호화되어 있다.

• 운영 환경에서는 디버그 로그가 비활성화되어 있다.

• 로그 파일에 기록되는 정보가 최소한으로 제한되며, 민감한 데이터는 포함되지 않는다.

💊 취약

• 디버그 로그에 사용자 비밀번호, 신용카드 정보, 개인 식별 정보 등 민감한 정보가 평문으로 기록된다.

• 로그 파일에 민감한 정보가 마스킹 또는 암호화되지 않고 그대로 기록되어 노출된다.

• 운영 환경에서도 디버그 로그가 활성화되어 있고, 민감한 데이터가 로그에 포함되어 있다면 점검 기준 "취약"이다.

• 로그 파일에 불필요한 정보가 과도하게 기록되어 있으며, 이를 통해 민감한 데이터가 노출되어 있다.

➰ 점검 방법

1. LogFilter 다운로드 후 Logfilter.jar를 실행시켜 압축을 해제한다. LogFilter download link

2. Logfilter.bat 파일 실행한다.

3. 점검용 모바일 디바이스를 PC에 디버깅 모드로 연결하고, 좌측 상단 device select 탭에서 android 선택 후 ok 버튼 클릭하여 연결된 디바이스를 선택한다.

4. 연결된 앱의 pid를 확인한다.

   > adb shell pidof com.app.damnvulnerablebank
   > 3921

   

5. Tag Filter 탭에 pid 입력 후 확인하고자 하는 앱(Ohbank)의 로그만 필터링한다.

** 그 외에도 다양한 옵션들이 있는데 LogFilter 메뉴얼을 확인하면 된다.

5. Ohbank 앱에서 로그인 후 찍히는 로그를 확인한다.

6. 로그에서 accesstoken이 그대로 노출된 것을 확인할 수 있다.

점검결과 : 취약

➰ 대응 방안

1. 앱 배포전 개발 시 사용되는 모든 로그 메시지 삭제 처리한다.

2. 개발 환경에서만 디버그 로그를 활성화하고, 운영 환경에서는 디버그 로그를 비활성화한다.

3. 민감한 정보는 마스킹 또는 암호화하여 기록한다.

➿ 경험담

실제로 자주 나오는 취약점은 아니다. 디버그 로그가 남아있다고 해도 민감한 정보가 포함되어 있는 경우는 드물다. (주민등록번호의 경우 뒷자리는 대부분 마스킹되어 있다.)

그래도 로그 내에 토큰이 포함되어 있는 경우는 종종 본 것 같다. 그래서 해당 취약점을 확인하고 싶다면 로그 파일을 .txt 파일로 저장하고, ctrl+f로 accessToken 을 검색해보거나 카드번호 등만 확인해보면 될 것 같다. 오래 볼 취약점은 아니고 간단하게 검색해보고 넘어가면 된다.

➰ 참고

• https://download.cnet.com/logfilter/3000-2218_4-76361225.html?ex=WLS-1348.5

• https://lyk00331.tistory.com/104

• https://ohbank.online/

'화면 강제실행에 의한 인증단계우회' 취약점은 사용자가 인증 절차를 거치지 않고도 애플리케이션의 주요 기능이나 민감한 정보에 접근할 수 있게 하는 보안 취약점이다. 이는 특정 방법을 통해 앱의 인증 화면을 우회하고, 보호된 기능이나 데이터(개인정보, 금융정보, 계좌번호 등이 포함된 화면)에 무단 접근할 수 있는 가능성을 의미한다.

즉, 로그인 하지 않은 화면에서 인증시에만 접속할 수 있는 화면(Activity)을 강제호출하여 인증을 건너뛰고 접속이 가능하다면 해당 항목이 취약한 것이다.

취약점 내용을 살펴보고 점검을 해보자.

➰ 취약점 내용

화면 강제실행에 의한 인증단계 우회 취약점은 악의적인 사용자가 특정 명령어를 사용하여 인증 절차를 거치지 않고도 기기의 보호된 영역을 우회하여 접근할 수 있게 만드는 보안 취약점을 의미한다.

➰ 점검기준

*🌱 양호 *

1. 모든 민감한 기능 및 화면은 반드시 인증 절차를 거쳐야 접근할 수 있다.

2. 앱의 백그라운드 상태에서 강제 실행을 통해 인증 단계를 우회할 수 없다.

📍앱의 백그라운드 상태란? 백그라운드 상태는 앱이 꺼져있거나 앱을 사용하다가 홈 버튼을 눌러서 빠져나온 경우를 의미한다. 음악을 들을 때 홈 버튼을 눌러서 빠져나왔는데도 음악이 계속 나오듯이 백그라운드 상태에는 앱은 온전히 종료되지 않는다.

3. Activity 간 전환 시 인증 상태를 검증하고, 인증되지 않은 사용자의 접근을 차단한다.

📍안드로이드에서 Activity란? Android 액티비티(Activity)는 앱의 화면이다. 앱을 켰을 때 홈 화면은 Main Activity 이며 필요에 따라 다른 창 위에 작게 띄울 수도 있다. 그래서 Activity 간 전환이라는 말은 화면 간 전환이라고 이해할 수 있다. Activity는 UI를 제공하여 사용자와 상호작용을 하며, class에서 activity를 상속받아 사용할 수 있다.

💊 취약

1. 인증 절차를 거치지 않고 민감한 기능이나 화면에 접근할 수 있다.

2. 앱이 백그라운드 상태일 때 강제 실행을 통해 인증을 우회할 수 있다.

3. 인증 상태를 검증하지 않고 Activity 전환이 이루어져 인증되지 않은 접근이 가능하다면 취약이다. 출처 : Ohbank 모의해킹 진단 가이드

➰ 점검 방법

1. Jadx 에서 AndroidManifest.xml 파일을 열어 exported="true"인 Activity를 확인한다.

** exported="false"이면 외부에서 호출이 되지 않기 때문에 true인 Activity를 찾아서 점검해야 한다.

2. adb shell에 접속하여 현재 포커스된 창과 앱 정보를 확인하여, 강제실행하려는 대상이 정확한지 검증한다.

   > adb shell "dumpsys window windows | grep -E 'mCurrentFocus|mFocusedApp'"

*결과창 *

ex) mCurrentFocus=Window{9dff664 u0 StatusBar}
ex) mFocusedApp=AppWindowToken{7d916f3 token=Token{cc9c562 ActivityRecord{157c2d u0 [패키지명]/.ui.mainnew.MainAccountActivity t74}}}

현재 window 창이 포커스되어 있고, 포커스되어 있는 앱의 정보는 위와 같으면 MainAccountActivity가 활성화되어 있다.

3. adb shell에 접속하여 아래의 명령어를 이용하여 activity를 강제 호출한다.

   > adb shell "am start -a android.intent.action.MAIN -n [패키지명]/[호출할 Activity명]"
   

am start -n com.app.damnvulnerablebank/com.app.damnvulnerablebank.SendMoney

![](https://velog.velcdn.com/images/cielo_g/post/76ace0ad-fab3-454d-977f-0f8f2c3d6d86/image.png)

** 웹 프록시 도구를 활용한다면 위 단계를 Ctrl + R(repeater)를 실행하여 반복 호출할 수 있다. 
(SendMoney가 반복호출된다면 돈이 계속 보내지는 것이니 위험하다.)

4. 위 명령어를 실행했을 때 SendMoney activity가 실행되는 모습을 확인할 수 있다.
![](https://velog.velcdn.com/images/cielo_g/post/ae631e51-f9da-4b1b-afcb-c34242edf4a7/image.png)
_출처 : Ohbank 모의해킹 진단 가이드_

## ➰ 대응 방안
1. 다른 App과 연동이 필요한 경우가 아니라면 Activity의 **exported ="false"**로 변경한다.

2.  중요 Activity의 경우 **화면 호출 조건을 설정**하여 특정 조건에 맞지 않을 경우 호출되지 않도록 설정한다.

3. 모든 민감한 기능 및 화면에 접근하기 전에 **인증 절차**를 거치도록 한다. 

4. Activity 간 전환 시 항상 현재 인증 상태를 확인하고, **인증되지 않은 접근을 차단**한다. ("_해당 페이지에 접근하기 위해서는 인증이 필요합니다. 인증을 해주세요_" 라는 에러 페이지를 출력하여 차단한다.)

5. 백그라운드에서 앱이 포그라운드로 전환될 때 **인증 상태를 검증**한다.

---

📍 해당 취약점은 처음에는 어렵게 느껴졌던 취약점인데 막상 실습을 해보니 우회가 될 만한 액티비티를 찾아가고, 강제실행을 하는 과정이 재밌었다. 실제로는 인증과 관련된 중요한 액티비티는 모두 검증 단계를 거치기 때문에 화면 강제실행을 통한 인증단계가 우회되는 앱이 많지는 않은 것 같다.

---
## ➰ 참고
- https://ohbank.online/Exploits/file_and_export.html#_2-%E1%84%80%E1%85%A9%E1%86%BC%E1%84%80%E1%85%A7%E1%86%A8-%E1%84%87%E1%85%A1%E1%86%BC%E1%84%87%E1%85%A5%E1%86%B8

- https://developer.android.com/privacy-and-security/security-tips?hl=ko

- https://blog.peanutz.site/168

단말기는 브라우저와 다르게 많은 정보를 내부에 저장하여 사용한다. 이는 단말기 내에 민감한 정보가 저장될 가능성이 높다는 것을 의미한다. 단말기 내에 개인정보, 금융정보, 의료정보 등 민감한 정보가 있을 경우, 해커가 물리적 접근이나 악성 소프트웨어를 통해 이를 탈취할 수 있어 심각한 보안 위협이 된다. 따라서 단말기 내에 민감한 중요 정보가 있는지 확인하고, 만약 저장되어 있다면 그것이 암호화되어 있는지 확인해보자.

📍실제로 점검을 진행하면 자주 발견되는 취약점은 아니지만 전송 중 데이터가 평문으로 전송되거나 캐시 내 토큰 등 중요 정보가 들어가 있는 경우가 종종 발견된다.

** ❓ 왜 단말기는 브라우저와 다르게 내부에 많은 정보를 저장할까?**

1) 단말기는 인터넷 연결이 없거나 불안정한 상태에서도 앱이 정상적으로 동작할 수 있도록 데이터를 로컬에 저장한다. 연락처, 일정, 메시지, 미디어 파일 등은 오프라인 상태에서도 접근할 수 있어야 하기 때문에 이러한 정보들을 로컬에 저장한다.

2) 응답 시간을 단축하고 네트워크 요청을 최소화하여 앱의 성능을 향상시키기 위해 데이터를 로컬에 저장한다.

3) 복잡한 기능을 제공하기 위해 데이터를 로컬에 저장한다. 예를 들어, 지도 앱은 지도의 일부를 로컬에 저장하여 빠르게 로드할 수 있게 한다.

단말기는 성능 향상, 오프라인 접근성, 복잡한 앱 기능 구현 등의 이유로 단말기 내부에 많은 정보들을 저장한다.

➰ 취약점 내용

동적 분석 항목 중 하나인 '단말기 내 중요정보 저장 여부'는 _애플리케이션 사용 폴더 및 외부 저장소에 존재하는 파일 내 중요정보 저장 여부_를 점검한다.

➰ 점검기준

** 민감한 정보 : 주민등록번호, 카드번호, OTP, 카드 비밀번호 등 중요정보라고 판단되는 정보

** 🌱 양호**

1. 단말기 내에 저장된 모든 민감한 정보는 강력한 암호화 알고리즘(AES, RSA 등)을 사용하여 암호화되어 있다.

2. 민감한 정보는 최소한의 권한으로 접근할 수 있으며, 접근 권한이 엄격하게 관리되고 있다.

3. 민감한 정보를 전송할 때 HTTPS와 같은 안전한 통신 프로토콜을 사용하여 암호화하여 전송한다.

** 💊 취약**

1. 단말기 내에 민감한 정보가 암호화되지 않고 평문으로 저장되어 있다.

2. 민감한 정보가 안전하지 않은 저장소(일반 파일 시스템 등)에 저장되어 있다.

3. 민감한 정보에 접근할 수 있는 권한이 과도하게 부여되어 있으며, 접근 권한 관리가 미흡하다.

4. 민감한 정보를 전송할 때 암호화되지 않은 상태로 평문으로 전송한다.

➰ 점검 방법

1. 점검 디바이스를 디버깅 모드로 연결하여 쉘에 접속한다.

   > adb devices
   > adb shell

   

2. 데이터가 저장되어 있는 위치로 이동한다.

   > cd /data/data
   

![](https://velog.velcdn.com/images/cielo_g/post/0093c043-70ea-4a62-bc7d-1f578f5ff2f3/image.png)


3. 중요정보를 확인할 앱의 패키지로 이동한 후 파일 구조를 확인한다.
_해당 경로는 시스템 영역으로 **루팅된 기기**에서만 접근이 가능하다._

cd com.app.damnvulnerablebank/

![](https://velog.velcdn.com/images/cielo_g/post/c6f71b10-cf8e-47b1-a93e-7cf4244af1c9/image.png)

- cache, code_cache, lib, shared_prefs 가 있는 것을 확인할 수 있다. 
주로 _shared_prefs를 먼저 확인_하는 편이다.

4. 분석하기 위해 **해당 디렉토리를 압축**한다.

tar -cvf [압축 후 파일 이름 지정][압축대상]

tar -cvf test01.tar *

![](https://velog.velcdn.com/images/cielo_g/post/1a38cf70-6b63-41a4-bf86-be8467c19e78/image.png)

  _예제는 apk 파일이 저장되어 있는 **/data/app/com.app.damnvulnerablebank-1** 경로에서 진행했지만 **/data/data/com.app.damnvulnerablebank-1** 경로에서 실행해주면 된다. 무엇을 압축해서 정보를 확인할 것인지에 따라 다르기 때문에 중요한 설정 정보 등이 저장되어 있는 /data/data 경로에서 진행하면된다._

---
**📍Trouble Shooting #1**
> 
**_/data/data $ tar -cvf test01.tar *
tar: test01.tar: Permission denied_**

_ -> 루팅 권한이 없어서 발생하는 문제_

> 1. su 명령어 실행 //루팅 권한으로 접속
2. |crownlteks:/data/data $ tar -cvf test01.tar * //재실행

---

5. adb 명령어를 통해 압축한 파일을 **지정 폴더로 이동**시킨다.

mv test01.tar /data/local/tmp

![](https://velog.velcdn.com/images/cielo_g/post/634964e3-ac7c-43e1-becb-5ec7c47a0fdf/image.png)

6. 새로운 cmd 창을 켜서 압축 파일을 **로컬 PC 로 추출**한다.
_**(adb shell 창 exit 후 새로운 cmd 경로에서 실행해야 한다.)**_

adb pull [압축파일이 있는 경로] [압축파일을 받을 경로]

adb pull /data/local/tmp/ ./

```

7. 파일을 열어 중요 정보가 노출되었는지 확인한다.

➰ 대응 방안

• 암호화된 저장소 사용한다.

• 인증 토큰과 같은 중요한 정보는 하드코딩된 암호화 혹은 암호화키에 의존하지 않게 하고 운영체제에서 제공하는 암호화 메커니즘 이상의 암호화 메커니즘 고려한다.

• SharedPreferences.xml에는 꼭 필요한 데이터만 저장하도록 한다.

*➿ 내 생각 *

위 취약점을 처음 접했을때 중요 정보가 저장되어 있는지 확인하는 것보다 중요 정보가 저장된 경로에서 파일을 압축하고 로컬에다가 옮겨서 푸는 과정이 더 오래걸렸다.

파일을 열면 내용이 많기도 하고, 코드를 잘 모르면 각각의 의미하는 바가 무엇이고 어디에 중요 정보가 저장되는지 감도 못잡아서 취약점을 못 찾거나 엄청난 시간이 걸리기도 한다. 필자는 개발을 했기 때문에 중요 파일만 열어서 확인하고, Ctrl+F를 해서 중요 정보가 될 만한 것들을 검색해서 찾는 편이다.

이 취약점은 아무래도 노하우가 필요한 취약점이다. 노하우가 있는 선임분들은 필요한 부분만 확인하시고 시간이 남으시면 좀 더 뒤져보는 방식으로 진행하셨다. 무작정 찾기 보다는 해당 취약점이 취약했던 예시들을 보며 익히는 방법도 노하우인 것 같다.

➰ 참고

• KISA 모바일 대민 서비스 취약점 가이드

• https://www.hani.co.kr/arti/economy/it/865770.html

• https://ohbank.online/Exploits/logcat.html

루팅(Rooting)이란 안드로이드 기기에서 최고 권한(root)을 얻는 것을 의미한다. 루트 권한을 획득하면 사용자는 시스템 파일과 설정에 완전한 접근이 가능해진다. 이를 통해 시스템 내부 저장소 접근, 권한 변경 등 다양한 작업을 수행할 수 있습니다.

안드로이드에서는 기기의 안정적인 동작을 보장하기 위해 일반 사용자에게 루트 권한을 제한하고 있다. 따라서, 앱의 안정성과 무결성을 유지하고, 사용자 데이터를 보호하며, 악성 행위를 방지하기 위해 루팅 탐지가 필요하다.

루팅 우회는 Frida를 통해 이루어지기 때문에 Frida 서버가 먼저 실행중이어야 한다. 기기에 Frida 서버가 있는지 확인을 먼저 해야한다.

➰ Frida 설치 확인

1. 기기와 PC를 연결한다.

• 안드로이드 기기로 점검을 진행한다면 USB 케이블로 기기와 PC를 연결한다. **usb 디버깅을 켜줘야 한다.

• PC 에 깔린 Nox Player로 점검을 진행한다면 Root를 켜주고 아래 명령어를 통해 PC와 Nox player를 연결한다. *시스템 설정 - 기본 설정 - ROOT 켜기

  
  > adb connect 127.0.0.1:62001
  

2. 연결을 확인한다.

   > adb devices

   

3. 애뮬레이터에 접속하여 기기에 프리다 서버 설치 여부를 확인한다.

> adb shell

> cd /data/local/tmp

> ls -al

📍** 기기에 프리다 서버가 없다면 설치된 프리다 서버를 기기에 전송해주어야 한다.**

3-1. 새로운 cmd 창을 열어서 아래 명령어를 실행한다. * adb shell 이 아닌 윈도우 cmd에서 진행하여야 한다.

> cd [윈도우에서 frida-server가 설치된 경로]
> adb push frida-server-xx.x.x-android-arm64 /data/local/tmp/

• 설치된 프리다 서버를 기기에 전송한다.

3-2. 애뮬레이터에 다시 접속하여 기기에 프리다 서버 설치 여부를 확인한다.

> adb shell

> cd /data/local/tmp

> ls -al

3-3. 프리다 서버를 실행하기 위해 실행권한을 부여한다.

chmod 755 /data/local/tmp/frida-server-xx.x.x-android-arm64

기기에 Frida Server가 설치되어 있는 것을 확인하고 실행권한을 부여했다.

🌱 프리다 서버를 이용하여 루팅 우회를 진행하는 과정에서 bypass_root.js 파일이 루트 우회만 하는 스크립트가 작성되어 있다. 따라서 frida 탐지를 하는 Oh bank 앱에서 루트 우회를 하기 전에 frida 우회를 한 후 실행시키고, 루트 우회를 해야 한다. Frida 안티디버깅 우회를 먼저 해보자.

➰ Frida 안티디버깅 우회

안티디버깅 우회란?

안티디버깅은 디버깅을 방지하여 소스코드 분석을 하지 못하도록 하는 기술이다. 안티디버깅 우회를 한다는 것은 애플리케이션이 디버거(Frida 포함)의 존재를 감지하는 방법을 우회하는 것을 의미한다. Oh bank의 경우 프리다의 기본 포트(27042)를 사용하고 있는지 확인함으로써 Frida 탐지를 하고 있다. 따라서 Frida를 실행할 때 기본 포트를 사용하지 않으면 프리다 감지를 하지 않을 것이다. 이 방법으로 우회를 진행해보자.

1. 단말기를 컴퓨터와 연결한 경우 adb를 사용해 포트 포워딩을 해주고, NOX player를 사용중인 경우 nox_adb를 통해 포트포워딩 해준다.

  > adb forward tcp:17000 tcp:17000

  > nox_adb forward tcp:17000 tcp:17000

• 로컬 머신의 17000번 포트와 안드로이드 기기의 17000번 포트 간에 네트워크 통신이 가능하다는 의미이며, 모두 17000포트를 사용하게 한다는 의미이다.

2. frida 서버도 17000 포트로 실행시킨다.

> adb shell /data/local/tmp/frida-server-16.1.4-android-arm64 -l 0.0.0.0:17000 &

• & 는 백그라운드에서 실행시킨다는 의미이다. (생략가능)

3. 윈도우 cmd에서 frida-server 가 실행중인지 확인한다.

> frida-ps -Ua

-> Oh bank 앱에서 frida-server 가 실행중이다.

➰ 루팅 우회

1. 아래 링크에서 frida로 루트 우회하는 js 파일을 다운받는다.

   frida-script

   >frida-android-hook > methods > bypass_root.js

   이 외에 다양한 스크립트가 있으니 참고해보면 좋을 것 같다.

2. 새로운 윈도우 CMD 에서 frida로 루팅 우회하는 스크립트를 실행하여 루팅 우회를 시도한다.

frida -U -f com.app.damnvulnerablebank -l C:\Users\MBD-N-05\Desktop\frida-android-hook-master\frida-android-hook\methods\bypass_root.js

** ❓ com.app.damnvulnerablebank란?**

실행중인 프로세스의 identifier 이다.

> frida-ps -Ua

➰ 참고

• https://learnfrida.info/

• https://baldeagle.tistory.com/93

• https://frida.re/docs/home/

• https://ohbank.online/Bypass/root__frida_detection.html#_2-%E1%84%80%E1%85%A9%E1%86%BC%E1%84%80%E1%85%A7%E1%86%A8-%E1%84%87%E1%85%A1%E1%86%BC%E1%84%87%E1%85%A5%E1%86%B8

웹 애플리케이션의 보안 취약점을 식별하기 위해서는 우선 웹 점검 환경을 구축하는 것이 필요하다. 따라서 이번 블로그 포스팅에서는 피들러(Fiddler), Frida, Nox Player, JADX, OpenSSL를 활용하여 웹 점검 환경을 구축하는 방법을 알아보려 한다.

➰ 위 기술들을 선택한 이유

1. Oh Bank

• OhBank는 Damn Vulnerable Bank라는 오픈소스를 기반으로 의도적으로 취약하게 만들어진 테스트 앱이다.
• 특정 앱을 테스트 대상으로 선택하는 것보다 금융 앱 특유의 복잡한 시나리오와 민감한 데이터를 다루기 때문에 그 취약점을 이용해 공격하는 방법을 배울 수 있어 선택하였다.

2. Frida

• Frida는 동적 분석 도구로서, 앱의 실행 중에 코드를 수정하고 감시할 수 있도록 해주는 오픈 소스 프레임워크이다.
• 프로세스를 모니터, 디버깅을 위해 사용할 수 있는 도구로써 앱의 실행 중에 프록시 도구(Fiddler)를 사용하는 환경에서 필요하기 때문에 선택하였다.

3. Nox Player

• 안드로이드 애뮬레이터로, 모바일 애플리케이션을 PC에서 편리하게 실행하고 테스트하기 위해 설치하였다.

*만약 모바일을 직접 연결하여 점검을 진행한다면 Nox player는 사용하지 않는다.

*4. JADX *

• Jadx는 안드로이드 디컴파일러로, 안드로이드 앱의 APK 파일을 추출하고 소스 코드를 분석하는데 사용된다.
• 기존의 모바일 앱의 소스코드 분석은 APK 파일 추출 -> apkTool -> dex2jar -> jd-gui 과정을 거친다. 하지만 jadx는 4단계의 반복적인 과정을 한번에 수행할 수 있도록 4단계의 도구와 기능이 합쳐져 있어 쉽게 소스코드로 변환할 수 있어 선택하였다.

5. OpenSSL

• OpenSSL은 암호화된 트래픽을 분석하고, 인증서 관리를 도와주는 툴이다.
• Fiddler 인증서를 관리하고, 피들러와 OpenSSL로 캡쳐하고 분석한 트래픽 데이터를 바탕으로, 데이터 전송 과정에서의 보안 취약점을 식별하기 위해 openssl 를 설치하여야 한다.

** 6. Fiddler **

• 웹 브라우저와 서버 간의 모든 HTTP/HTTPS 요청 및 응답을 캡쳐하고, 디버깅하여, API 테스트하는데 유용하다.
• Fiddler는 주로 웹 트래픽에 집중되어 있어, 다른 네트워크 트래픽 분석 도구보다 가볍고 빠르다.
• 윈도우에서만 사용이 가능하다.

Burp Suite

• 피들러와 동일하게 HTTP/HTTPS 트래픽을 캡처하고, 분석하며, 조작할 수 있다.
• Burp Suite는 많은 보안 기능을 포함하고 있어 속도가 느릴 수 있지만, 매우 강력한 기능을 제공한다.
• 맥/윈도우 모두 사용이 가능하다.

WireShark

• 네트워크 인터페이스를 통해 전송되는 모든 패킷을 캡처하고 분석할 수 있어, 전체 네트워크 트래픽을 세밀하게 분석할 때 사용한다.
• 다양한 프로토콜 지원과 깊이 있는 분석 기능을 제공하지만 다소 무겁다.

🌱 우선 네트워크 레벨에서 이루어지는 점검이 아니라 웹 트래픽 분석을 메인으로 진행할 예정이라 Fiddler와 Burp Suite 중에 골라야 했다. 둘 다 세팅해보고 써본 결과 인코딩/디코딩을 활용할때 Burp Decoder보다 TextWizard에서 제공해주는 기능이 훨씬 많고 사용자 인터페이스도 편했다. 그리고 필요한 세션만 선택해서 모의해킹을 진행할 수 있고, 가볍고 빠르다는 장점이 있어 Burp Suite가 아닌 Fiddler를 선택했다.

📍 하지만 다양한 보안 기능을 제공하는 Burp Suite를 어쩔 수 없이 써야할 때가 있고 네트워크 레벨에서 점검이 필요한 경우가 때문에 Burp Suite와 WireShark 모두 쓸 줄 알아야 한다.

➰ 설치

➿OpenSSL 설치

https://slproweb.com/products/Win32OpenSSL.html

위 링크로 들어가서 자신의 운영체제에 맞는 최신 버전의 OpenSSL을 다운로드 받는다. 필자는 Window를 사용하고 있어 Win64 OpenSSL v 3.3.1 의 EXE를 눌러 다운 받았다.

➿Frida 설치

1. Frida는 Python 기반으로 제작된 도구이기 때문에 파이썬이 설치되어 있지 않으면 파이썬을 먼저 설치한다.

   https://www.python.org/

2. 파이썬을 통해 frida를 설치하고, 버전을 확인한다.

   pip install frida
   
   pip install frida-tools
   
   frida --version

3. 아래 링크로 들어가서 설치된 frida 버전에 맞는 frida-server를 다운받는다.

   https://github.com/frida/frida/releases

   frida-core-devkit-16.4.5-android-arm64.tar.xz 클릭

![](https://velog.velcdn.com/images/cielo_g/post/249e52bc-359b-4bf7-9f76-37e02aed7862/image.png)

➿Jadx 설치

https://github.com/skylot/jadx/releases

위 링크로 들어가서 jadx-gui-1.5.0-no-jre-win.exe 를 클릭하여 Jadx를 다운받는다.

➿Nox Player 설치

https://kr.bignox.com/

위 링크로 들어가서 자신의 운영체제에 맞는 최신 버전의 Nox Player를 설치한다.

➿Oh bank 다운로드

https://github.com/sidereumare/OhBANK

위 링크로 들어가서 Oh bank 앱의 소스코드와 apk 파일을 다운받는다.

_** 원래는 apk 파일을 jadx로 디컴파일해서 소스코드를 분석하지만 OhBank는 취약점 테스트를 위해 소스코드가 github에 올라와있어 소스코드를 추가로 다운받는다. _

➿ Fiddler 설치

1. 아래 사이트에 접속하여 Fiddler Classic 버전을 설치한다.

   https://www.telerik.com/download/fiddler

설치에 필요한 옵션은 작성하여 *Download for Windows**를 클릭한다.

*Fiddler는 Window에서만 동작한다. 다른 운영체제의 경우 제대로 작동하지 않거나 제공하지 않는다.

2. Fiddler 인증 기관(CA)의 인증서를 생성하기 위해 아래 사이트에 접속하여 Fiddler 인증서 생성 툴을 설치한다.

   https://www.telerik.com/fiddler/add-ons

   CertMaker for ios and windows > Download

   

   대부분 사용자 정보, 결제 정보, 로그인 등과 관련된 페이지들은 민감한 정보들을 포함하고 있기 때문에 HTTPS 통신을 이용한다. HTTPS 패킷의 경우 암호화가 되어 있어 Fiddler 인증서를 설치해야 해당 패킷의 내용을 확인할 수 있다.

   그래서 Fiddler의 경우, Fiddler에서 생성한 인증 기관(CA) 인증서(아직 신뢰 되지 않음)를 신뢰할 수 있는 루트 인증서로 등록하고, Fiddler proxy를 통해 접근하는 웹 사이트의 모든 인증서를 Fiddler CA가 발행한 인증서로 대체하여, 브라우저에서는 HTTPS 통신의 내용을 확인할 수 있는 방법을 제공한다.

3. 다운받은 Fiddler에 접속하여 PC에 Fiddler 인증서를 설치한다.

   Tools > Options > HTTPS > Actions > Trust Root Certificate 클릭한다.

   

   

Yes를 클릭한다.

![](https://velog.velcdn.com/images/cielo_g/post/eef1b3c7-7cc6-4867-b3de-c77c23227ff2/image.png)



_    만약 Trust Root Certificate를 했는데 Root에 인증서가 없다고 뜨거나 지정되지 않았다고 뜬다면? _

→ **Export Root Certifiate to Desktop을 한 후에 Trust Root Certifiacte를 다시 시도**한다.
→ 옵션도 아래와 같이 체크해준다.

![](https://velog.velcdn.com/images/cielo_g/post/d1f3eb40-3cb0-48bf-8459-3e39cc92c0c1/image.png)

4. 인증서 연결을 위한 Connection 설정도 추가해준다.

   *Tools > Options > Connections *

   1. 포트 지정
   2. Allow remote computer to connect 체크

5. 휴대폰에 Fiddler 인증서를 설치한다.

   5.1 wifi > 네트워크 설정 관리 접속해서 아래와 같이 정보를 입력한다.

   프록시 호스트 이름 : 192.168.0.18 프록시 포트 : 8888 프록시 우회 대상 : ~

   

5.2 휴대폰에 fiddler 인증서를 다운로드 한다. 

>[http://ipv4.fiddler:8888](http://ipv4.fiddler:8888/) 

모바일에서 해당 링크에 접속하여 핸드폰에 인증서를 다운로드 한다.

![](https://velog.velcdn.com/images/cielo_g/post/a03e8f8e-0515-44cf-a163-372b5068d45c/image.png)

**FiddlerRoot certificate를 클릭**한다. 

다운로드 하고 인증서 이름을 입력하면 자동 등록된다.

![](https://velog.velcdn.com/images/cielo_g/post/a9e3da9b-e0ce-4b19-878c-e063a34bba71/image.png)

6. 설치된 인증서 추출 후 변환하고 휴대폰에 넣는다. (사용자 인증서를 시스템 인증서로 옮기기)

   6.1 .cer 파일을 adb pull 명령어로 추출한다.

   adb pull 인증서 저장된 경로/FiddlerRoot.cer
   adb pull /sdcard/Download/FiddlerRoot.cer

   6.2 openssl을 사용하여 인증서를 변환하고 해시값을 추출한다.

   openssl x509 -inform DER -in FiddlerRoot.cer -out cacert.pem
   openssl x509 -inform PEM -subject_hash_old -in cacert.pem

   6.3 인증서 이름을 아래와 같은 형식으로 변경한다. *이름은 해시 값.0 확장자로 이름을 변경한다. 6.4 이름 변경을 완료한 인증서를 시스템 경로에 넣어준다.

   adb shell // adb를 통해 기기 명령어 실행
   
   - adb 관리자 쉘 에서 system 폴더 마운트
   # mount -o rw,remount /system
   

   6.5 adb push 명령어로 인증서를 */system/etc/security/cacerts/ *경로로 복사한다.

   # cd C:\Users\2-02\Desktop> //인증서가 있는 경로로 이동 
   
   # adb push 9a5ba575.0 /system/etc/security/cacerts/

   6.6 사용자 인증서가 정상적으로 시스템 인증서로 이동이 완료되었다. 6.7 adb shell 에 접속하여 해당 인증서가 있는지 확인한다.

   
   # adb shell 
   
   # /system/etc/security/cacerts/9a5ba575.0 에 해당 인증서가 있는지 확인
   # ls -l /system/etc/security/cacerts/9a5ba575.0 

7. 아래와 같이 Capturing이 켜져 있으면 프록시를 통헤 패킷을 확인할 수 있다.

➰ 결론

이로써 피들러(Fiddler), Frida, Nox Player, JADX, OpenSSL, Oh bank을 활용한 웹 점검 환경 구축 과정을 완료하였다. 구축을 하면서 각 도구들이 왜 필요한지, 그리고 다른 도구들과 비교하여 왜 이 도구들을 선택했는지에 대해 깊이 고민할 수 있었다.

피들러는** 웹 트래픽 분석, Frida는 **런타임 분석, Nox Player는 모바일 애플리케이션 테스트, JADX는 소스코드 분석, OpenSSL은 암호화 통신 분석, Oh bank는 실제 금융 시나리오 테스트에 최적화된 도구로 활용하여 취약점 점검을 진행하고자 한다.

➰ 참고

• https://philosopher-chan.tistory.com/366

• https://www.dongyeon1201.kr/d00a24ff-04df-428a-a2a7-d62fe14bc982

• https://surfshark.com/ko/blog/proxy-server

OWASP가 OWASP API Security Top10(2019)을 공유한 지 4년 만에 2023년에 새롭게 갱신된 OWASP API Security Top10(2023)을 발표했다.

4년만에 발표를 했기 때문에 개정된 내용을 살펴보며 어떤 보안 취약점을 살펴보는 것이 더 중요한지 파악하고 변경된 부분을 확인하며 4년 사이에 어떤 기술들이 발전했는지 흐름도 살펴보도록 하자.

➰ OWASP란

OWASP(The Open Web Application Security Project)는 안전한 웹 및 어플리케이션을 개발할 수 있도록 지원하기 위해 미국에서부터 시작된 비영리 단체이며, 오픈소스 웹 어플리케이션 보안 프로젝트를 진행하는 단체이다.

OWASP는 가장 큰 오픈소스 웹 애플리케이션 보안 프로젝트로 주로 웹에 관한 정보노출, 악성 파일 및 스크립트, 보안 취약점 등을 연구하며, 10대 웹 애플리케이션의 취약점(OWASP TOP 10)을 발표한다.

OWASP는 개방형 커뮤니티로, 모든 자료와 정보가 모든 사람을 위해 웹사이트에서 무료로 쉽게 액세스 할 수 있다. OWASP는 보안 취약점의 기준이 되고, 대응방안은 국내 공식 자료로 활용되기도 한다.

필자도 OWASP가 개방형 커뮤니티로 운영되는지는 몰랐다. 보안취약점 가이드, 대응 가이드, 질문 등이 있다면 위 커뮤니티를 이용하면 될 것 같다.

🌱 OWASP 커뮤니티 주소 https://owasp.org/www-community/

➰ OWASP Mobile Top 10 2024

OWASP TOP 10은 악용가능성, 탐지가능성 및 영향에 대해 빈도수가 높고 보안상 영향을 크게 줄 수 있는 10가지 웹 애플리케이션 보안 취약점 목록이다.

• M1: 부적절한 자격 증명 사용(Improper Credential Usage)
• M2: 불충분한 공급망 보안(Inadequate Supply Chain Security)
• M3: 보안에 취약한 인증 및 권한 부여(Insecure Authentication/Authorization)
• M4: 부족한 입력/출력 검증(Insufficient Input/Output Validation)
• M5: 안전하지 않은 통신(Insecure Communication)
• M6: 불충분한 개인 정보 보호 제어(Inadequate Privacy Controls)
• M7: 부족한 바이너리 보호(Insufficient Binary Protections)
• M8: 잘못된 보안 구성(Security Misconfiguration)
• M9: 안전하지 않은 데이터 저장소(Insecure Data Storage)
• M10: 불충분한 암호화(Insufficient Cryptography)

➿ OWASP Mobile Top 10 (2019 vs 2024)

1. 기존 M3와 M6이 신규M3으로 통합되었다.

2. 기존 M8과 M10은 2024 Top10에서 제외되었다.

3. 기존 M2와 M4, M9는 2024 Top10에서 순위는 동일하지만 내용이 업데이트 되었다.

4. M6, M7, M10이 신규 취약점으로 랭크되었다.

• 최신 API 기반 애플리케이션은 수천 개의 API 엔드포인트와 수많은 매개변수로 인해 점점 더 복잡해지고 있다. 그래서 액세스 제어 및 승인이 API 보안에서 더 중요한 부분으로 자리잡고 있다. OWASP top 10에서 상위 5개 중 3개가 권한과 관련된 항목이고 이 트렌드를 보여준다.
• SSRF(Server Side Request Forgery, 서버 측 요청 위조)가 목록에 추가되었다. 기존에 있던 취약점이지만 MSA 아키텍쳐 사용 빈도가 늘어나고, 실시간 기능을 활용하는 사용자가 늘어나면서 해커가 SSRF 취약점을 악용하기 쉬워지면서 OWASP Top 10 에 포함되었다. MSA 구조로 코드를 작성하고 실시간 기능을 사용하면서 해커가 SSRF 공격을 하기 좋은 환경을 조성해준 셈이다.

➰ 결론

마이크로 서비스 아키텍쳐가 많이 활용되고, 수천개의 API 엔드포인트가 생성되면서 OWASP에서도 변화를 인식하고 2019년 이후로 처음으로 항목들을 개정하여 API Security Top10 2023을 발표했다. 위 취약점 외에 다른 취약점은 중요하지 않다는 것은 아니다. 주로 많이 발생하고 중요성이 큰 취약점을 기준으로 10가지를 발표한 것이고 이 외에도 주의해야 할 많은 취약점이 있다.

이를 예방하기 위해 개발과정에서도 보안을 고려하는 시큐어 코딩이나 방화벽을 강화하는 등 보안 대책이 필요하다. 이제는 개발자도 보안을 알아야 하는 시대가 온 것이다.

➰ 참고

• https://12bme.tistory.com/98
• https://www.lgcns.com/blog/cns-tech/security/54998/
• https://medium.com/@razzsecu18ry/owasp-top-10-vulnerabilities-how-to-prevent-them-in-2024-1c885dc3fcb9
• http://www.opennaru.com/opennaru-blog/owasp-zap-devops-and-security/

금융감독원은 안정성과 신뢰성을 확보하기 위해 매년 전자금융기반시설 보안 취약점(WEB/MOB/HTS) 평가기준 정리와 수정을 실시한다. 개정된 2024년도 전자금융기반시설 보안 취약점 평가기준을 살펴보자.

➰ 2024년도 평가기준 개정결과

웹은 10가지, 모바일 11개, HTS 6개 항목이 개정되었다.

출처 : 24년도 전자금융기반시설 보안 취약점 평가기준 설명회

➰ 가이드

보안 취약점 가이드는 아래를 참고하였다.

1. 금융보안원 보안평가기술팀

2. KISA 모바일 대민서비스 보안취약점 점검 가이드

3. 주요정보통신기반시설 기술적 취약점 분석, 평가 방법 상세 가이드

4. 금융감독원 점검 가이드

➰ 전자금융기반시설 보안 취약점 평가기준(기존)

**임의의 기준으로 작성한 취약점 점검 기준으로, 가이드와 상이할 수 있습니다.

➰ 전자금융기반시설 보안 취약점 평가기준(2024년도) 개정 후

아래의 2개의 항목이 추가되고 4개의 항목이 삭제되었다. 또한 9개 항목이 점검 기준이 개정되었다.

📍 '[전자금융] 단말기 브라우저 영역 내에서의 중요정보 노출' 항목 또한 2024년부터 삭제되었으나 기존 취약점 점검 항목에 포함되어 있지 않아 표시되어 있지 않다.

직접 엑셀로 취약점 점검 기준을 제작한거라 오류가 있을 수 있습니다. 수정해야 할 부분이 있으면 언제든지 댓글로 알려주세요.

최근 정보통신기술의 급속한 발전과 함께 AI, 블록체인 등 전자금융거래 환경이 다양해지고 있다. 그러나 이와 동시에 금융 시스템을 악용하려는 공격자들의 위협도 증가하면서 금융권 보안이 심각한 위기에 처해 있다는 경고가 나오고 있다.

또한 금융전산망 마비 사고와 고객 정보 유출 사건이 빈번하게 발생하면서 금융기관들은 큰 어려움에 봉착하고 있다. 최근 발생한 몇 가지 사례를 보면, 해커들은 점점 더 정교한 방법을 사용하여 금융 시스템의 취약점을 공략하고 있다.

그 결과, 금융권 내에서는 여러 규제들이 만들어졌고, 이로 인해 금융권 IT 종사자들은 관련 기술을 활용하는 데 제약을 받게 되었다.

또한 금융기관들의 보안 취약점에 대한 인식과 대응책을 강화하기 위해 아래와 같은 전자금융거래법 및 전자금융감독규정이 만들어졌다. 규정에 따라 금융기관들은 보안 취약점 점검을 매년 실시하게 되었다.

📍 대규모 시스템 마비와 막대한 금융적 손실을 막기 위해 금융기관들이 실시하는 전자금융기반시설 보안 취약점 점검 절차와 개요에 대해 알아보자.

🌱 실제로 필자는 보안 취약점을 찾고 대응책을 마련해주는 보안 컨설팅을 수행하는 업무를 했다. ** 보안 취약점 점검 절차 및 모의해킹 기법을 알아두면 개발자여도 개발할 때 잠재적 위험을 방지할 수 있고 **이행점검이니 금취분평이라던지 용어에 익숙해져 정보보안팀과 소통도 잘 되기 때문에 알아두면 정말 좋다.

➰ 전자금융거래법

" 정보통신기술 발전에 따라 전자금융거래 환경이 다양해지고 이를 악용하여 금융적 이익을 취하려는 공격자로 인하여 금융 전산망 마비 사고 및 고객 정보 유출 사고와 같은 위험이 발생하고 있다. 이에 따라 금융사는 전자금융거래법 및 동법 시행령 전자금융감독규정 등에 의하여 금융 정보통신의 정보보호 규정에 따라 매년 취약점 분석·평가를 의무적으로 수행해야 한다."

"금융회사 및 전자금융업자는 「전자금융거래법」 제21조에 따라 전자금융거래의 안전성과 신뢰성을 확보하기 위하여 전자금융기반시설에 대하여 「정보통신기반보호법」 제9조에 근거한 취약점 분석·평가를 1년을 주기로 실시하여 그 결과를 금융위원회에 보고하여야 한다. 또한 취약점 분석·평가의 대상, 기간, 절차, 방법, 소요예산 편성 및 집행 등 취약점 분석·평가를 구체적으로 시행하기 위하여 필요한 계획을 수립·시행하여야 한다."

요약하면 아래와 같다.

• 은행과 같은 금융사는 그들이 운영하는 금융 시스템을 1년을 주기로 시스템의 보안 취약점을 분석하고 평가하는 것이 법적으로 의무화 되어 있다.

• 실제로 금융 회사들은 매년 취약점 분석 및 평가를 수행하고 있다. 만약 수행하지 않으면 벌금과 불이익이 어마어마한 걸로 알고 있다.

• 우리가 사용하는 은행의 뱅킹 앱, 뱅킹 사이트 들은 매년 보안 취약점 점검을 받아야 한다.

➰ 전자금융기반시설 보안 취약점 개요

전자금융감독규정 37조의2 (전자금융기반시설의 취약점 분석·평가 주기, 내용 등)   금융기관 또는 전자금융업자는 연 1회 이상 전자금융기반시설의 취약점 분석·평가를 실시하고, 이행계획을 수립·시행 하여야 한다.

금융 보안원은 보안 취약점을 참가기관의 전자금융기반시설, 주요정보통신기반시설 등에 대한 자산분석, 취약성 분석 등을 통해 해당 시설의 전자적 위협 요인을 파악한 후, 위협요인에 대한 취약점을 식별하고 파급 영향을 분석하여 정보보호 대책 수립을 지원한다고 정의한다.

➰ 보안 취약점 진단 목적

보안 취약점 진단은 고객사의 주요 정보시스템을 대상으로 취약점 평가 항목을 점검하여 내재되어 있는 보안 취약점을 도출하고, 그 발생 원인을 분석하여 보안 수준을 강화함으로써 서비스의 안전한 운영을 목적으로 하고 있다.

➰ 점검내역

1. 점검기준: 전자금융기반시설 보안 취약점 평가기준 안내서 (금융보안원, 제2024-1호)

2. 점검주기: 인프라 연1회, 모의해킹(웹/모바일) 연 2회

3. 점검절차: ①점검대상 선정 → ②취약점 진단 → ③도출취약점 이행개선 → ④도출취약점 이행진단 → ⑤정보보호위원회 승인 → ⑥금융감독원 제출

4. 진단 절차: ①현황분석 -> ②취약점 진단 -> ③위험 평가 및 분석 -> ④보호대책 수립 및 이행점검 -> ⑤보고서 작성

➰ 점검대상

*실제 점검 대상 개수를 정확히 기입해주셔야 합니다.

(이렇게 표로 정리되어 있는 걸 원했는데 공식 문서에는 이렇게 정리되어 있는게 없어서 https://smartari.tistory.com/4 여기에서 가지고 왔습니다)

(실제로 이런식으로 표로 몇대가 점검 대상인지 정리해서 공유해줍니다)

➰ 분야별 점검 사항

➰ 점검업체선정

금융회사 및 전자금융업자는 「전자금융거래법」 제21조에 따라 「정보통신기반보호법」 제9조 ③항에서 한국인터넷진흥원, 정보공유·분석센터(ISAC), 정보보호 전문서비스 기업 및 한국전자통신연구원(ETRI) 에 재직중인 인원 중 과학기술정보통신부에 기술인력으로 등재된 인원만 소관 주요정보통신기반시설의 취약점을 분석·평가하게 할 수 있다.

금융기관에서는 지정된 전자금융기반시설의 취약점 분석∙평가 전문기관 중에서 몇개를 선정하여 경쟁입찰을 진행하고 여러 요소를 고려하여 보안 컨설팅 업체를 선정한다.

➰ 전자금융기반시설 보안 취약점 평가 기준

정보보호업체마다 각각의 고유한 취약점 진단 기준이 존재한다. 하지만 전자금융기반시설 보안 취약점 평가 기준이 가장 기본이다.

각각의 고유한 취약점 진단 기준으로 보안 취약점을 찾아내고 대응 방안을 작성하여 평가 결과물을 전달한다.

📍 전자금융기반시설 분야별 보안 취약점 평가 기준은 2024년을 기준으로 개정된 부분이 몇가지 있습니다. 다음 포스팅에서 개정된 전자금융기반시설 취약점 분석 평가 기준(웹/모바일)에 대해서 자세히 다뤄보겠습니다.

➰ 이행 점검 후 완료

선정된 보안 컨설팅 업체에서 취약점 점검을 마친 후 발견된 취약점이 제대로 조치가 되었는지 확인하는 이행점검까지 완료하고 결과보고서를 작성하면 보안 취약점 점검 절차가 마무리 된다.

➰ 참고

• https://www.g-enews.com/ko-kr/news/article/news_all/2024062119165323550687539213_1/article.html

• https://www.sisaweek.com/news/articleView.html?idxno=146469

• https://smartari.tistory.com/4

• https://www.fsec.or.kr/bbs/103

• https://securityse.tistory.com/31

• https://securityse.tistory.com/31

진행하는 프로젝트에서는 Keycloak 기본 회원가입 창에서 제공하는 사용자 필드 외에도 주소, 성별, 생년월일 등의 정보도 필요했다. 그래서 Spring과 Keycloak을 연동하여 CustomUserFederation을 구현하였다.

Keycloak 자체 로그인을 하면 회원가입 시 추가 정보들도 입력할 수 있도록 바로 아래에 필드들이 떴지만 SSO(Google, Github) 로그인 시에는 로그인 인증을 각 identity provider에서 해주기 때문에 기본적인 사용자 정보만 제공한다.

• 위 로그인 창의 register 버튼을 눌러 회원가입을 하고 로그인 창에서 로그인을 하면 추가로 필요한 사용자 정보가 저장된다. with Github, with Google 로그인 시 문제가 발생한다.

➰ 이슈

우선 SSO 로그인 시 우리 프로젝트에 필요한 추가 회원 정보를 입력받기 위해 login-update-profile.ftl를 구현하였다. 하지만 Google, Github 로그인 시 사용자 프로필 업데이트 페이지가 나타나지 않고 바로 로그인 성공 창으로 이동했다.

• SSO 로그인 시 Email 등 필요한 정보는 제공해주지 않아 위와 같이 저장되어 있다.

➰ 원인

GitHub 또는 Google과 같은 외부 IdP(Identity Provider)는 로그인 시 사용자 정보를 제공하고 Keycloak은 이를 그대로 사용한다. 따라서 기본적으로 Keycloak은 외부 IdP로부터 필요한 모든 정보를 가져와 사용자의 프로필을 업데이트한다.

Keycloak에서 사용자 프로필 업데이트 페이지가 나타나도록 하려면 인증 흐름에 Update Profile 액션을 추가해야 한다. 그러나 외부 IdP의 경우 이 액션이 자동으로 실행되지 않기 때문에 이슈가 발생했다.

실제로 인증 흐름을 보면 *Review Profile 이 Required로 설정**되어 있다.

이를 해결하기 위해 Keycloak 내에서 인증 흐름을 수정해야 한다.

➰ 해결방법

1. 인증 흐름에 Update Profile 액션을 추가하기 위해서 Keycloak 관리 페이지에 접속한다.

2. Master Realm(적용하고자 하는 렐름) > Authentication > Flow details > first broker login 을 클릭한다.

3. Review Profile 에서 오른쪽 톱니바퀴 모양 버튼을 클릭한다.

4. Review Profile Config > Update Profile on First Login 을 Required -> On 으로 변경한다.

➰ 결과

설정을 변경하고 SSO 로그인을 하면 아래와 같이 사용자 프로필 업데이트 페이지가 뜨는 것을 확인할 수 있다.

➰ 참고

• https://github.com/keycloak/keycloak/issues/22403

• https://github.com/MAXIMUS-DeltaWare/material-keycloak-theme/blob/master/material/login/login-update-profile.ftl

• https://stackoverflow.com/questions/62815811/how-to-add-custom-ftl-pages-in-keycloak

Keycloak을 도커를 통해 실행하고, 이를 AWS 환경에 배포하였다.

배포된 주소로 키클락 로그인 페이지에 접속하면 배포된 주소에서 연결을 거부했다(ERR_CONNECTION_REFUSED)며 접속이 되지 않았다.

에러 메시지

Globally disable https keycloak

➰ 원인

Keycloak 서버와 이를 사용하는 클라이언트 간의 모든 통신에 SSL/HTTPS를 사용하지 않으면 중간자 공격에 매우 취약해진다. OAuth 2.0/OpenID Connect는 보안을 위해 액세스 토큰을 사용하는데, SSL/HTTPS 을 사용하지 않으면 네트워크 통신이 암호화되지 않은 상태로 전송되고 공격자는 민감한 정보(액세스 토큰 등)을 엿보고 획득할 수 있다. 액세스 토큰을 획득하면 해당 토큰에 허가된 모든 작업을 수행할 수 있기 때문에 보안면에서 매우 취약해진다.

따라서 Keycloak은 SSL Required 를 기본적으로 external로 설정하여 제공하고 있다.

기본값

"ssl-required" :  "external"

이는 외부 요청(localhost가 아닌 네트워크에서 오는 요청)에 대해서는 SSL이 필요하지만, 내부 요청(localhost)에는 SSL이 필요하지 않다는 의미이다. 그래서 로컬 환경에서는 에러가 나지 않았고 배포를 했을때 SSL 설정 관련 에러가 난 것이었다.

그 외에도 SSL 설정이 어려울 수 있으므로 Keycloak은 localhost, 192.168.x.x와 같은 사설 IP 주소를 통해 비-HTTPS 통신을 허용한다. 또한 localhost, 192.168.x.x와 같은 사설 IP 주소가 아니더라도 Keycloak이 SSL 신뢰 관리자(trust manager)를 끄는 것을 허용한다.

SSL 껐을 때

"ssl-required" :  "none"

➰ 프로덕션 환경임에도 SSL 를 비활성화 해야 했던 이유

프로덕션 환경에서는 SSL이 전반적으로 활성화되고 필수로 설정되도록 해야 한다.

하지만 HTTPS가 아닌 HTTP 통신을 사용하고 있었고, SSL을 활성화할 경우 인증서 관리의 복잡성 때문에 프로덕션 환경에서도 SSL 를 비활성화하고 배포하기로 했다.

또한 Keycloak과 클라이언트 간의 통신이 신뢰할 수 있는 환경에서 이루어졌고 실제 운영을 하는 서비스가 아니었기 때문에 빠른 배포와 테스트를 위해 SSL 를 비활성화하고 키클락을 배포하였다.

➰ 해결

📍 실패

처음에는 키클락 Admin 페이지에 접속해서 Master Realm > Real settings > Require SSL > None으로 설정해주면 된다고 생각했다. 하지만 키클락을 배포할 때 SSL 설정이 기본적으로 external로 활성화되어 있기 때문에 접속조차 안됐고, 이 방법은 사용할 수 없었다.

*📍해결 : 도커에서 설정 *

Docker를 사용하여 Keycloak을 배포하고 있기 때문에 도커에서 관련 설정을 비활성화해주면 된다.

도커에서 SSL을 비활성화 하는 방법을 인터넷 검색를 통해 찾았지만 최신 버전으로 업그레이드 된 후로 경로도 바뀌고, 명령어도 먹지 않았다.

키클락 21 버전이 되면서 설정 파일이 저장되어 있는 경로가 조금 바뀐 듯하다. 그래서 직접 ls 명령어를 치면서 파일위치을 찾았고 명령어도 바꿔가면 내가 찾은 방법을 공유하려 한다.

1) ec2 접속한다.

> ssh -i pemkeyname,pem ec2-users@12.111.12.1111

• pem 키로 접속 시 Permission Denied가 발생하면 pem키에 권한을 준다.

  > chmod 400 pemkeyname.pem

2) Keycloak Admin CLI를 실행하기 위한 스크립트 파일(./kcadm.sh)이 있는 경로로 이동한다.

> cd opt
> cd keycloak
> cd bin
> ls 

• ls를 하면 하위 경로에 있는 파일(client, kcadm,bat, kcadm.sh..)들을 볼 수 있다.

3) Keycloak Admin CLI를 사용하여 로컬 Keycloak 서버에 대한 관리자 자격 증명을 설정한다.

> .kcadm.sh config credentials --server http://localhost:8080/ --realm master --user admin

• 명령어 입력 후 기존에 로컬에서 사용했던 키클락 admin 비밀번호를 입력한다.

4) Keycloak Admin CLI를 사용하여 특정 Realm의 SSL 설정을 none으로 변경한다.

> .kcadm.sh update realms/master -s sslRequired=NONE

➰ 결과

배포된 주소로 다시 접속하면 로그인 페이지가 뜨고, 회원가입 시 아래와 같이 회원정보 추가 입력창까지 뜬다.

(1년전 프로젝트라 사진이 이거밖에 없다ㅠㅠ 기록을 잘하자)

최신 버전의 자료가 없어서 더욱 잡기 어려웠던 에러였다. 하지만 보안회사에서 파일 경로 찾고 뜯어보면서 모의해킹 했던 경험이 에러를 해결하게 해줬다.

자료 조사와 내 경험을 합쳐서 트러블 슈팅을 한 것이 이번에 처음이었다. 자료에만 의존하여 문제를 해결하였는데 이 경험 덕분에 트러블 슈팅을 하는 방법을 조금씩 터득하게 되었다. 앞으로 어떤 에러이든 자료에만 의존하지 않고 많은 방법을 시도해보면서 나만의 노하우를 만들어야겠다.

➰ 참고

• https://www.keycloak.org/docs/latest/securing_apps/
• https://wjw465150.gitbooks.io/keycloak-documentation/content/server_admin/topics/threat/ssl.html
• https://stackoverflow.com/questions/38337895/globally-disable-https-keycloak