DO MY BEST

• Destination unreachable: 목적지를 못 찾을 때
• Source Quench: 수신하는 버퍼의 크기가 모자랄 때
• Time exceeded: time-to-live값이 0이 되었을 때
• Parameter problems: 예, do not fragment 비트가 설정되었을 때
• Redirection: 더 좋은 경로가 존재할 때

• Bootkit은 boot + rootkit의 합성어로 부팅 시에 운영체제 보다 먼저 실행되도록 한 루트킷을 말한다.
• 2006년 Black Hat Briefings에서 시연된 Blue Pill 프로젝 트가 최초로 구현된 bootkit이다.
• 운영체제보다 위에서 실행되어 운영체제 및 그 밑에서 도는 보안 소프트웨어를 완전히 속일 수 있다.

대응책

• 시큐어 부트 (Secure Boot) - Windows 8 이후로 적용된 Secure Boot는 PC 펌웨어 표준인 UEFI에서 제공하는 보 안 기능으로, 펌웨어를 디지털 서명으로 검증하는 기능 이다.

• Rootkit은 원래 공격자가 root 권한을 얻은 뒤 시스템에 설치하는 kit라는 뜻이다.
• 윈도우에서는 시스템에 설치되어 멀웨어의 동작을 은폐 하는 소프트웨어를 말한다.
• 주로 커널 드라이버 형태로 만들어져 운영체제와 동일 한 권한을 가진 채로 동작한다
  
  • 루트 권한으로 시스템 자원에 접근 가능
• 2005년에는 소니 사의 음악 CD에 복사 방지 목적으로 루트킷이 내장되어 논란이 된 적이 있다.

대응책

• GMER - 2004년에 처음 만들어진 프로그램으로, Rootkit의 존재 여부를 전문적으로 검사해 준다. ( http://www.gmer.net/ )
• 코드 서명 (Code signing) - 어떤 프로그램이 신뢰할 만한 것임을 증명하기 위해 신뢰할 수 있는 기관으로 부터 서명된 디지털 서명을 이용한다. 64비트 윈도우에서는 디지털 서명된 커널 드라이버만 로드가 가능하게 하여, kernel mode rootkit의 실행을 방지한다.
• 커널 패치 보호 (KPP) - 윈도우 커널의 무결성을 체크하여 후킹(hooking)과 같은 시스템 변조가 감지될 때 컴퓨터를 즉시 재부팅시킨다. 후킹이란 소프트웨어 구성 요소 간에 발생하는 함수 호출, 메시지, 이벤트 등을 중간에서 바꾸거나 가로채는 행위이다.

이진 분류는 분류 규칙에 따라 집합의 요소를 두 그룹으로 분류하는 작업입니다

참 양성(true positive, TP)
참 음성(true negative, TN)
거짓 양성(false positive, FP)

거짓 음성(false negative, FN)

평가 점수

정확도 (accuracy)

       ACC=(TP+TN)/(TP+TN+FP+FN)

정밀도 (precision) - 실제 virus가 있는데, 있다고 판명한 경우

       PPV = TP / (TP + FP)

재현율 (recall) - virus가 있다고 판명했는데 실제 virus가 있는 경우

       TPR = TP / (TP + FN)

거짓 경보 (false alarm) - virus가 없다고 판명했는데 실제 virus가 있는 경우

       FPR = FP / (FP + TN)

예시

다음은 안티바이러스 프로그램의 성능 평가 실험을 한 결과이다.

• 실험을 한 총 파일은 1200개이다.
• 이 중에서 악성코드가 있는 파일의 수는 100개이다.
• 실험 결과 악성 코드가 있는 파일 중에서 90개의 파일이 악성 코드가 있는 것으로 판명 되었다.
• 실험 결과 악성 코드가 없는 파일 중에서 1000개의 파일이 악성 코드가 없는 것으로 판 명되었다.

(1) 이 안티바이러스의 정밀도(precision)는 얼마인가?

(2) 이 안티바이럿의 재현율(recall)은 얼마인가?

(3) 거짓 경보(false alarm)는 얼마인가?

(4) 정확도(accuracy)는 얼마인가? 

풀이

(1) 이 안티바이러스의 정밀도(precision)는 얼마인가?

       답 : TP / (TP + FP) = 90 / 100

(2) 이 안티바이럿의 재현율(recall)은 얼마인가?

       답 :  TP / (TP + FN) = 90 / 190

(3) 거짓 경보(false alarm)는 얼마인가?

       답 :  FP / (FP + TN) = 10/1010

(4) 정확도(accuracy)는 얼마인가? 

       답 :  (TP + TN) / (TP + TN + FP + FN) = 1090 / 1200

리액트는 컴포넌트 기반의 View를 중심으로 한 라이브러리이다. 그러다보니 각각의 컴포넌트에는 라이프사이클 즉, 컴포넌트의 수명 주기가 존재한다. 컴포넌트의 수명은 보통 페이지에서 렌더링되기 전인 준비 과정에서 시작하여 페이지에서 사라질 때 끝이난다.

라이플사이클 과정: 

컴포넌트가 생겼다가 사라진다. 생겼다가 사라지는 동안에 어떤 작업을 할 것인데, 

클래스인 경우, constructor -> render -> ref -> componentDidMount -> (setState/props 바뀔때) ->  shouldComponentUpdate(true)-> render -> componentDidUpdate -> 부모가 나를 없앴을 때 -> componentWillUnmount  -> 소멸 

 (클래스 설명) : constructor(state, 메서드 등)이 실행되고 처음으로 render가 실행된다. 그 다음 ref를 설정해주는 부분이 실행된다. 그리고 componentDidMount가 실행되고 setState나 Props가 바뀔 때 componentDidUpdate가 실행되고 부모가 나를 없앴을 때 componentWillUnmount가 실행되고 소멸된다.

componentDidMount에서 비동기 요청을 많이 한다. 예를 들어 setInterval이 될 수 있다. 그리고 componentWillUnmount에서는 비동기 요청을 정리한다. 

setInterval이 일정 시간마다 반복 작업을 해주는 것임을 우리는 알고 있다. 그러면 렌더링 후에 componentDidMount 실행되어서 일정시간 간격으로 하는(setInterval) 반복 작업을 계속 해준다. 문제는 컴포넌트가 사라져도 setInterval을 취소 해주지 않는다. 그러면 웹사이트를 끌 때 까지 해당 컴포넌트가 사라졌다해도 계속 setInterval은 실행되고 있다.
여기서 더 큰 문제가 발생할 수 있다. 만약 RSP 라는 컴포넌트가 있고 렌더링 되고 setInterval이 1초마다 실행된다. 그리고 RSP컴포넌트가 사라졌다가, 또 어떤 계기로 RSP 컴포넌트가 화면에 붙었다가 사라지면, 기존에 실행되고 있었던 setInterval에다가setInterval 하나 추가 되어서 두개가 같이 돌아가게 된다. 이 작업이 반복되면 setInterval이 계속 중첩이된다. 이러한 비동기 함수들이 메모리를 계속 차지하기 때문에 flooding이 생긴다. 그래서 완료되지 않는 비동기 요청은 componentWillUnmount에서 처리를 해줘야한다.

그래서 취소를 해주어야한다.

이런 식으로 해준다.

render가 처음 실행되고 성공적으로 실행됐다면 componentDidMount가 실행된다. 그 다음 setState로 인해서 리 렌더링이 일어날 때는 componentDidMount가 실행되지 않는다.

그리고 컴포넌트가 제거되기 직전에는 componentWillUnmount 가 실행된다. 부모가 나(컴포넌트)를 없앴을 때 실행된다.

render에서 setState를 사용하면 무한하게 렌더링 되어서 문제가 생긴다. 그러면 render에 setState를 사용해야 하는 상황에는 어디에다 써야할까? componentDidMount에 사용해야한다. 

componentDidUpdate는 setState를 하던 Props가 바뀌었다하면 render 부분이 다시 실행되잖아요. 리렌더링 후에는 componentDidUpdate가 실행된다.

hooks의 특성이 컴포넌트 전체가 계속 다시 실행되는 것이다. 만약 매번 다시 실행되는 것이 만약 10초가 걸리는 함수가 있다면 렌더링 할 때 마다 10초가 걸리기 때문에 문제가 발생한다. 해결법은 캐싱 하는 것이다. 이 때 다시 실행되지 않고 기억할 수 있게 useMemo가 쓰인다. (함수를 실행한 결과값을 저장해 두려면 useMemo이다)

※ useEffect, useMemo, useCallback은 두번째 인자가 있다.

const ____ = useMemo( ( ) => getWinNumbers(), []); 두번째 인자가 바뀌지 않는한 함수가 다시 실행되지 않는다.

다시 말해 두 번째 인자인 [ ]가 바뀌기 전 까지 함수의 결과값을 기억한다.

이렇게 되면 hooks가 getWinNumbers() 함수의 리턴값을 기억할 것이다. 이렇게 하지 않으면 getWinNumbers()같은 함수는( 반복문이 돌 때 마다 or 렌더링이 될 때 마다 )계속 실행 될 것이다.

useMemo: 복잡한 함수 결과값을 기억

useCallback: 함수 자체를 기억

useRef: 일반 값을 기억

여기서 tip:

함수 안에 console.log를 하나씩 찍어두고 내가 진짜 필요할 때 돌아가는게 맞는지 확인해주기!

useEffect, useCallback, useMemo 다 같듯이

const _____ = useCallback(() => {

}, [ ]);

-두 번째 인자인 [ ]가 바뀌면 새로 실행된다.

-두 번째 인자인 [ ]가 바뀌기 전 까지 함수 자체를 기억한다. 

문제점

const onClickRedo = useCallback(() => {

    console.log(winNumbers);

},[]);

이렇게 하면 winNumbers에서 받아온 값들을 계속 기억한다. 

반면 계속 새로운 값들로 업데이트 하려면

const onClickRedo = useCallback(() => {

    console.log(winNumbers);

},[winNumbers]);

이렇게 해야한다.

어떨 때 함수를 실행할지 정하는곳이 “ [ ] “ 이다.

자식 컴포넌트로 함수를 넘길 때 useCallback을 꼭 해줘야한다. useCallback이 없으면 매번 새로운 함수가 생성된다. 그러면 자식 컴포넌트는 부모로 받은 props가 바뀌었다고 인식하여 매번 새로 렌더링을 해버리기 때문이다.(함수 자체는 사실상 바뀐게 없는데 이렇게 되면 매우 비효율적이다)

그러므로 결론은 자식 컴포넌트에 props로 함수를 넘길때는 자식이 헷갈리지 않게 useCallback을 해주어서 자식이 쓸때없이 리 렌더링이 되지 않고 부모로 부터 받은 함수가 같음을 알아차리게 해줘야한다.

state개수를 줄여준다. 

state가 많아지면 state, setState의 쌍들이 점점 늘어나기 때문에 관리하기 힘들고, 다른 컴포넌트에 넘겨줄게 너무 많아지기 때문에 useReducer를 사용해서 하나의 state와 하나의 setState로 통일할 수 있다. 이것이 useReducer를 사용하는 목적이다.

const initialState = {

	state1: ‘0’,

	state2: ‘0’,

	state3: ‘0’,

	state4: ‘0’,

};





const UseReducerTest = () => {

	const [state, dispatch] = useReducer(reducer, initialState);



	// const [state1, setState1] = useState('');

	// const [state2, setState2] = useState('');

	// const [state3, setState3] = useState('');

	// const [state4, setState4] = useState('');



}

state(initialState)가 있고 그 안에 객체 형식으로 데이터를 둔다고 가정하자. 이 state는 아무도 직접 수정할 수 없다. 클릭같은 것들을 담당하고 있는 이벤트들이 웹서비스로 부터 계속 발생하는 영역이다.

state를 아무도 수정할 수 없고 이것을 수정하고 싶으면 action을 만들고 이것을 실행(dispatch) 해야한다. 이 action을 어떻게 처리할지는 reducer에서 관리한다. 

요약: state가 있고 이 state는 직접 건들수가 없고 바꾸고 싶으면 이벤트가 실행될 때 action을 dispatch해서 state를 바꿔야한다. state를 어떻게 바꿔야할지는 reducer에 기록해야한다.

contextAPI는 부모와 자식간에 다층관계가 되면 props 물려주는게 힘든점을 개선해준다. contextAPI에서 접근할 수 있는 데이터가 있는데, 여기에 접근하고 싶은 컴포넌트들을 contextAPI가 제공하는 Provider로 묶어줘야한다.(아래 참고)

Main.jsx

import React, {createContext} from 'react';

export const TableContext = createContext({
    tableData: [],
    dispatch: () => {},
});

여기에서는 이렇게 전달할 데이터들의 모양만 맞춰주면 된다.

…
<TableContext.Provider value={{ tableData: state.tableData, dispatch }}>
    <Form />
    <div>{state.timer}</div>
    <Table />
    <div>{state.result}</div>
</TableContext.Provider>

데이터들은 value에 넣는다. 이 데이터들은 자식 컴포넌트들에게 바로 전달해줄 데이터들이다. 그러면 자식 컴포는트들에서 접근 가능한 데이터들이 된다. 

그리고 자식 컴포넌트에서 contextAPI를 연결 시키는 방법은

Form.jsx

import React, { useContext } from 'react';

const Form = () => {
	const value = useContext(TableContext);
…
}

이런식으로 하면 된다. 그러면 가져올 때는

value.dispatch, value.tableData 이렇게 가져올 수 있다. 또한

{ tableData, dispatch } = useContext(TableContext);

이런식으로 구조분해해서 사용 가능하다.

대부분의 소프트웨어는 완벽하지 않다. 소프트웨어에 존재하는 결함은 버그 (bug)라고 부른다. 보안 문제를 일으키는 버그를 취약점 (vulnerability)이라고 부른다. 공격자가 취약점을 이용하여 수행하는 보안 공격을 익스플로잇 (exploit)이라고 한다. 즉, 취약점은 익스플로잇을 할 수 있는 버그이다.

제로데이 공격 (0-day attack)

소프트웨어의 취약점이 발견되고 패치되기 까지는 어느정도 시간이 필요하다. 아직 패치가 나오지 않은 취약점을 제로데이 취약점 (0-day vulnerability)이라고 부른다. 패치가 나오지 않은 시점에 이루어지는 보안 공격을 제로데이 공격 (0-day attack) 이라고 한다.

버퍼오버플로우 (buffer overflow)

int main() {
	int buffer[10];
    buffer[12] = 55;
}

다음의 코드를 실행하면 어떤 일이 벌어질까?

• 임시메모리공간에buffer[10](10개의공간)을할당
• buffer[12] 위치의 메모리에 55이 할당된다.

입력 받는 데이터의 크기가 버퍼의 크기를 벗어나는지 제대로 체크하지 않을 경우 공격자는 버퍼를 벗어난 메모리 의 공간의 데이터를 수정할 수 있다.(혹은 자신이 원하는 값 을 쓸 수 있다.)

• C언어에서 사용자 입력을 받는 gets() 함수는 버퍼의 크기를 체크할 수 없어 버퍼 오버플로에 취약하다.
• Morris worm이 gets() 함수의 취약점을 이용했다.

char buf[100]; // 100바이트짜리 버퍼

gets(buf); // 입력 데이터가 100바이트를 넘기는지 확인하지 않는다.

buffer overflow의 대응책

[첫 번째]

스택 카나리아(stack canary)

• 카나리아라는 명칭은 탄광의 유독 가스 를 알아차리기 위해 카나리아라는 새를 이용한 데에서 유래
• Stack canary라는 임의의 난수 값을 스택 메모리의 리턴 주소 전에 저장해 둔다.
• 공격자가 스택 메모리 공간을 덮어써서 리턴 주소를 조작할 경우, 중간에 위치한 stack canary가 손상된다는 점을 이용해 함수 리턴 전에 stack canary를 확인하는 방법
• 컴파일러에서 제공하는 보안 기능이다.

[두 번째]

데이터 실행 방지(DEP, data execution prevention)

OS에서 제공하는 보안 기능으로, 실행 금지(NX)라고도 부름.

• 메모리 할당 시에 읽기/쓰기/실행 속성을 지정할 수 있는데, 데이터 영역 메모리는 실행 금지(NX)로 함
• 해커가 임의의 코드를 데이터 영역에 실어서 실행하는 것을 차단
• 두가지방식이있다.
  • CPU 차원에서의 하드웨어 지원
  • 소프트웨어 에뮬레이션: 스레드 태스크 스위칭 시 코드 주소를 확인 하여 실행 속성이 없는 메모리일 경우 실행을 중단

[세 번째]

데이터 실행 방지(DEP, data execution prevention) - Windows 10의 Windows 보안 설정

반환 지향형 프로그래밍 (ROP : Return-Oriented Programming)

• DEP를 우회하기 위해 고안된 코드 취약점
• 메모리 상에 존재하는 라이브러리 함수 코드 일부를 가져와서 리턴 주소 체인을 만들어 실행시키는 방식

정상적으로 존재하는 코드 메모리의 일부를 이용했으므로 DEP에 의해 차단되지 않는다.

ROP 의 대응책

ASLR(Address Space Layout Randomization)

• 해커가ROP에쓰이는코드조각의메모리주소를알수없도 록 메모리 공간의 배치를 랜덤화한다.
• OS에서 제공하는 보안 기능이다.
• Windows 10의 Windows 보안 설정 ( 밑에 그림 참고)

FSB (Format String Bug)

서식 문자열 버그(FSB, Format String Bug)

• C언어에서 콘솔 출력을 수행하는 printf 함수는 서식 문자열과 출력할 데이터를 인자로 전달받는다.
• 문자열데이터str을출력할때printf(“%s”,str)대신 printf(str) 형태로 출력할 경우 서식 문자열 버그에 취약하다.
• Printf 함수에 의해서 해석되는 “str”은 출력하고자 하는 문자열이 아 니라 printf 함수에서 사용할 각종 형식 지시자(%d, %s 등)를 포함한 format string으로 인식한다.
• 따라서출력하려는문자열내에지시자(directive)가들어있으면, printf 함수에 전달된 인자의 개수와는 상관없이 이러한 형식 지시자 의 개수 만큼의 인자들이 스택으로부터 추출된다.
• 공격자는 입력되는 str 문자열에 % 기호를 포함시켜 서식 문자열을 구성 할 수 있다. 서식 문자열 중 %n은 공격자는 이것을 이용하여 메모리 값을 조작할 수 있다.
• %n 형식은 format string 내에서 %n 지시자 전에 지정된 출력되어야 하는 모든 공간의 개수를 해당 변수로 저장한다.
  • 예) int val;
    printf(“aaaa%n”, &val); // val에 문자의 개수인 4가 대입된다.
• printf 함수가 %n 지시자를 만나면 이 지시자의 순서에 해당하는 내용을 스택에서 pop하고 pop된 내용을 주소로 하여 해당 주소에 지금까지 출력 된 문자의 개수를 저장하게 된다. 이때 만약 이 주소가 어떤 함수의 리턴 주소가 저장되어 있는 곳이라면 프로그램의 흐름이 변경될 수 있다.

FSB (Format String Bug) 의 대응책

• 시스템 차원에서는 대응할 수 없고 컴파일러 차원에서 대응하고 있다.
• FSB를 예방하기 위해 많은 C/C++ 컴파일러에서 printf(str)와 같은 문장을 경고로 처리한다.
• 또, 많은 C/C++ 컴파일러에서 표준이 아닌 서식 문자 인 %n의 지원을 없애 FSB를 이용한 메모리 조작의 가능 성을 없앴다.
• 그러나 FSB를 이용하여 민감한 정보를 읽어보는 것은 여 전히 가능하기에 printf(str)와 같은 문장은 피해야 한다.