7/21 (목) 인증 / 보안 기초 2️⃣

 

 

 

 

 

❑ Session

 

 

➤ Session 이란?

 

• 서버와 클라이언트 간 연결이 활성화된 상태에서 데이터를 서버에 저장
• 서버가 클라이언트에 유일하고 암호화된 ID를 부여
• 중요 데이터는 서버에서 관리

 

 

 

➤ Authorization (인가, 접근권한)

 

• 사용자가 아이디와 비밀번호를 올바르게 입력해서 인증(Authentication)에 성공 ➡️ 서버가 해당 유저가 인증에 성공했다는 것을 저장
• 인증에 따라 리소스 접근권한(Authorization)이 달라진다.
• ex) 인증 후 user인지 admin인지에 따라 리소스의 접근권한이 달라진다.

 

 

 

➤ Session 기반 인증

 

 

 

 

사용자가 인증에 성공한 상태를 Session(세션) 이라고 부른다.

서버는 일종의 저장소에 세션을 저장한다.

주로 in-memory, 또는 세션 스토어(redis 등과 같은 트랜잭션이 빠른 DB)에 저장한다.

세션이 만들어지면 각 세션을 구분할 수 있는 세션 아이디도 만들어 진다. ➡️ 클라이언트에 세션 성공을 증명할 수단으로써 쿠키에 세션 아이디를 함께 전달

웹사이트에서 로그인을 유지하기 위한 수단으로 쿠키에 서버에서 발급한 세션 아이디를 저장한다.

 

 

 

➤ 로그아웃

 

• 서버 : 세션 정보를 삭제
• 클라이언트 : 쿠키를 갱신

 

서버가 임의로 클라이언트의 쿠키를 삭제할 수는 없다.

➡️ 대신 set-cookie로 전송할 때 세션 아이디의 키값을 무효한 값으로 갱신할 수 있다.

 

 

 

 

❑ 웹 보안 공격

 

 

➤ SQL Injection

 

• 웹 해킹을 접한다면 가장 먼저 배우는 공격 기법
• 간단하지만 아주 강력한 공격이다.
• 데이터베이스에 임의의 SQL문을 실행할 수 있도록 명령어를 삽입하는 공격 유형이다.
• 응용프로그램의 보안상의 허점을 이용해 데이터베이스를 비정상적으로 조작, 기록이 삭제되거나 유출될 수 있다.

 

 

 

▶️ SQL Injection 대응 방안

 

1. 입력(요청) 값 검증

SQL문은 자연어와 비슷하기 때문에 키워드를 막는데엔 한계가 있다.

➡️ 화이트리스트 방식으로 해당 키워드가 들어오면 다른 값으로 치환하여 SQL Injection을 막는다.

 

화이트리스트 : 보안에서 기본 정책이 모두 차단된 상황에서 예외적으로 접근이 가능한 대상을 지정하는 방식, 또는 그 지정된 대상 (반대말은 블랙리스트)

 

 

2. Prepared Statement 구문 사용

사용자의 입력값이 전달되기 전에 데이터베이스가 미리 컴파일하여 SQL을 바로 실행하지 않고 대기하며, 사용자의 입력값을 단순 텍스트로 인식한다. 입력값이 SQL문이 아닌 단순 텍스트로 적용되어 공격에 실패하게 된다.

 

 

3. Error Message 노출 금지

공격자는 데이터베이스의 Error Message를 통해 테이블이나 칼럼 등 데이터베이스의 정보를 얻을 수 있다. 에러가 발생한 SQL문과 에러 내용이 클라이언트에 노출되지 않도록 별도의 에러핸들링이 필요하다.

 

 

 

➤ Cross-Site Request Forgery (CSRF)

 

▶️ Web application Security란?

 

- 개발자들이 웹사이트, 모바일, 어플, 웹 API 등을 만들 때에 해커들의 공격을 막기 위해서 보안(security)은 필수 사항

- 여러가지 공격들

• SQL Injection
• XSS
• CSRF

 

 

▶️ CSRF 란?

 

- 다른 사이트(cross-site)에서 유저가 보내는 요청(request)을 조작(forgery)하는 것

ex) 전자 게시판에 공지글로 위장하여 악성 코드를 심은 글을 작성한다. 사용자가 글을 클릭하면 은행계좌에서 돈이 빠져나감

 

- 해커가 직접 데이터를 접근할 수 없다.

ex) 다른 사이트이기 때문에 response에 직접 접근할 수 없음

 

 

▶️ CSRF 공격을 하기 위한 조건

 

- 쿠키를 사용한 로그인

유저가 로그인 했을 때, 쿠키로 어떤 유저인지 알 수 있어야 함

 

- 예측할 수 있는 request parameter를 가지고 있어야 함

request에 해커가 모를 수 있는 정보가 담겨있으면 안됨

 

 

▶️ GET 요청으로 CSRF 공격하기

 

계좌이체에 사용되는 GET 요청

http://wisebank.com/transfer?account_number=useraccount&amount=100000$

 

 

사용자의 브라우저 환경에서 악성 링크가 담겨있는 페이지를 클릭하게 유도

➡️ 클릭하면 해커의 계좌로 돈을 송금하는 요청을 은행에 보낸다.

 

http://wisebank.com/transfer?account_number=해커계좌번호&amount=100000$”>

 

 

▶️ POST 요청으로 CSRF 공격하기

 

비밀번호 변경에 사용되는 POST 사용

POST

http://wisebank.com/password/change

 

body

{password:user’s-new-password}

 

 

▶️ CSRF 막기

 

- CSRF 토큰 사용하기

서버측에서 CSRF 공격에 보호하기 위한 문자열을 유저의 브라우저 웹 앱에만 제공

 

- same-site cookie 사용하기

같은 도메인에서만 세션/쿠키를 사용할 수 있다.

 

 

 

 

 

감사합니다.

오개념에 대한 지적은 언제나 환영입니다.