과제1 - Auth Basic
1.세션의 개념을 이해할 수 있다.
 -세션 id와 세션 객체의 차이에 대해 이해할 수 있다.
 -세션 시크릿이 왜 필요한지 이해할 수 있다.
2.쿠키와 세션은 서로 어떤 관계이며, 각각이 인증에 있어서 어떤 목적으로 존재하는지 이해할 수 있다.
3.세션의 한계를 이해할 수 있다.
과제2 - Auth Token
4.JWT을 이용한 토큰 인증 방식을 구현할 수 있다.
 -Refresh Token과 Access Token의 차이를 이해한다.
 -왜 Access Token이 Refresh Token보다 짧은 주기를 갖는 지 이해한다.
5.JWT의 작동원리에 대해 이해할 수 있다.
 -header, payload, signature가 각각 어떤 역할을 하는 지 이해할 수 있다.
 -JWT에 salt가 필요한 이유를 이해할 수 있다.
 -JWT가 어떻게 토큰의 변조를 판별하는 지 이해할 수 있다.
6.토큰 방식의 한계를 이해할 수 있다.
과제3 - Auth OAuth
7.직접 OAuth로 로그인 가능한 애플리케이션을 제작할 수 있다.
8.Oauth의 작동 방식을 이해할 수 있다.
 -"브라우저" - "내 서버" - "인증 대행 서비스"간 요청/응답을 주고받는 다이어그램을 그릴 수 있다.
9.Authentication과 Authorization의 차이를 이해할 수 있다.
10.OAuth의 키워드를 설명할 수 있다.
 -Authorization Code와 Access Token의 차이에 대해 이해할 수 있다.
 -Authorization 서버와 Resource 서버의 차이에 대해 이해할 수 있다.
 
 
1.세션 id는 일반 id와 같이 구별을 위한 고유한 태그 또는 인증용 이름표와 같으며 세션 객체란 세션id에 종속되는 데이터 덩어리라고 볼 수 있다.
 
2.쿠키는 서버에서 부담을 줄이고 빠른 반응성을 위해 클라이언트(사용자)측에 데이터를 저장시키는 방식이며 세션은 서버에서 정보를 관리하지만 데이터적 부담이 큰 방식이다. 인증을 위해 중요정보는 세션으로 관리하고 민감하지 않은 정보들은 쿠키로 보관하는 등의 방법을 사용한다.
 
3.세션은 하나의 서버에서만 상태를 가지고 있기 때문에 분산에 불리함을 가지고 있으며 세션도 쿠키를 이용하기 때문에  세션-쿠키가 탈취될 경우 문제가 될 수 있다.
 
4.JWT(JSON Web Token)은 세션의 부담을 클라이언트에 떠넘기기 위해 고안되었다. 인증을 해야 정보를 주는 방식을 채택했는데 인증을 주기적으로 받자면 처리 속도도 문제고 사용자의 불편함도 있기 때문에 Refresh Token으로 긴 시간 인증을 유지(사용자가 선택한다면)할 수 있게 하고 중간중간 간편인증식으로 Access Token을 받을 수 있다. 

5.JWT는 header.payload.signature로 구성되어 있으며 암호화 방식이 인코딩된 header, 유저의 정보가 인코딩된 payload, salt와 header, payload를 이용해 암호화한 signature로 구성되어있다. 서버는 일정 규칙을 가지고 변조된 토큰인지를 판별하는 데이터만 보유하면 되기 때문에 세션과는 다른 무상태성에 가까운 상태를 가진다.

6.토큰을 강제종료할 수 없기 때문에 한번 탈취되면 만료까지는 해커가 마음대로 이용할 수 있다는 점?

7.대충은 알 것 같지만 로그아웃이 안된다..

8.대충은 알겠지만 그림까지 그려가면서 하기에는 아직 헷갈리는 것 같다.

9.Authentication은 인증하는 절차를 의미하며 Authorization은 토큰을 주는 등의 권한을 부여하는 방식이다. 간단하게 말해서 Authorization으로 권한을 주고 재 접근시 Authentication을 통해 확인한다.

10.Authorization Code는 Authorization Grant의 한 타입으로 액세스 토큰을 발급받기 위한 Code를 의미하며 Access Token은 발급을 받았다는 인증서 같은 역할을 한다. 위에서 언급했던 것 처럼 Code를 통해 토큰을 발급하고 토큰을 통해 인증을 받을 수 있다.
Resource Server는 클라이언트의 요청을 수락하고 응답할 수 있는 데이터가 저장되어 있는 서버이며 Authorization Server는 토큰을 발급하 인증 서버로 사용자가 요청 후 인증할 경우 Resource Server에 토큰을 발급한다.

뭔가 9,10번은 중복느낌이 많이 나는 것 같다..
이번 과제는 세션에서도 완료가 안됬을정도로 이상한게 많았다.
로그인은 일단 포기..

'회고' 카테고리의 다른 글

프론트엔드 부트캠프(코드스테이츠) 3개월차 회고  (0) 2022.07.20
Mini Hackathon 소그룹 회고  (0) 2022.07.19
학습(알고리즘)  (0) 2022.07.17
학습(알고리즘)  (0) 2022.07.16
[Backend] 인증 / 보안-2  (0) 2022.07.15

Chapter3. 웹 공격의 종류
1.SQL injection 공격에 대해 이해할 수 있다. (사용자의 입력값을 무조건 신뢰하면 안되는 이유에 대해 이해할 수 있다.)
2.XSS 공격에 대해 이해할 수 있다. (Stored XSS와 Reflected XSS의 차이에 대해 설명할 수 있다.)
3.CSRF 공격에 대해 이해할 수 있다.
4.Clickjacking 공격에 대해 이해할 수 있다.
Chapter4. Token / OAuth
5.토큰의 개념을 이해할 수 있다. (Refresh Token과 Access Token의 차이를 이해한다.\)
6.쿠키 / 세션 방식과 토큰 방식의 차이를 이해할 수 있다.
7.JWT의 작동원리에 대해 이해할 수 있다. (header, payload, signature가 각각 어떤 역할을 하는 지 이해할 수 있다), (JWT가 어떻게 토큰의 변조를 판별하는 지 이해할 수 있다)
8.토큰 방식의 한계를 이해할 수 있다.
9.Authentication과 Authorization의 차이를 이해할 수 있다.
10.OAuth의 키워드를 설명할 수 있다. (Authorization Code와 Access Token의 차이에 대해 이해할 수 있다), (Authorization 서버와 Resource 서버의 차이에 대해 이해할 수 있다)

1.SQL injection 공격이란 내부 값을 혼동시켜 추가로 입력한 값 까지를 명령어로 인식하게 만들어 내부 정보를 빼오거나 데이터를 지우는 등의 공격을 하는 방식으로 사용자의 입력값과 명령 부분을 독립적으로 처리하게 하거나 영향을 주는 부분을 입력하지 못하게 하는 등의 조치를 해야한다.

2.XSS(Cross-Site Scripting)는 공격자가 악의적인 스크립트를 심어놓는 행위로 서버에 저장해 지속적으로 피해를 줄 수 있는 Stored XSS와 URL 파라미터를 사용해 스크립트를 만드는 일시적 또는 비 지속적으로 피해를 줄 수 있는 Reflected XSS기법이 있다.

3.CSRF(Cross-Site Request Forgery)공격은 이름처럼 타 사이트에서 요청을 위조하는 방식이다. 실제 요청 내용(송금/개인정보 전송 등 악의적 행동)과는 다르게 혜택을 보는 듯한 링크를 제공한 후 피해자가 링크를 누를 경우 실제로는 송금 등의 기능을 하게 만들어 기관에서는 피해자가 요청했다고 생각하고 허용하고 피해자는 단지 링크를 클릭했을 뿐이지만 돈이 인출되게 만드는 방식이다.

4.CSRF와 유사하지만 다른 방식으로 눈속임을 하는 공격법이다. 클릭하는 내용에 표시되는 것과 실제 동작하는 기능이 다르게 만들어 피해자가 정보를 기입하면 그 정보를 바탕으로 개인정보를 탈취하거나 컴퓨터의 제어권을 빼앗는 등의 행동을 할 수 있다.

5.토큰이란 민감한 개인정보를 계속해서 인증에 사용하게 되면 공격자가 탈취할 우려가 있으므로 토큰이라는 인증권한을 제공해 사용하게 만드는 방식이다.
토큰에는 Access Token과 Refresh Token이 있는데 Access Token은 승인받았다는 의미의 일반적인 토큰으로 유효기간이 짧으며 Refresh Token은 Access Token을 자주 발급하기 애매한 경우 더 긴 유효기간을 두고 Access Token을 자동 발급해주는 역할을 하는 토큰이다. 그렇기 때문에 Refresh Token이 탈취될 경우 위험할 수 있어 사용하지 않는 곳도 많다.

6.쿠키는 데이터를 클라이언트측에 보관하는 방식이고 세션은 서버측에 저장하는 방식이지만 각각의 장단점이 있는데 장점을 모아 만든 것과 유사하게 쿠키처럼 클라이언트측에 데이터를 보관시키지만 중요정보는 토큰화해서 세션을 사용한 것 처럼 보안성 또한 챙길 수 있다. 서버에는 클라이언트의 정보를 보관하지 않고 토큰에 간한 가벼운 정보만 보관하기 때문에 서버 확장도 용이하며 안전하고 권한설정을 따로 하기에도 편하다.

7.JWT(Json Wep Token)는 Header, Payload, Signature로 구성되어 있으며 Header는 어떤 알고리즘으로 암호화 할지에 대해 JSON 형식으로 정보를 담고 있으며 Payload는 서버에서 활용할 수 있는 유저의 정보가 base64방식으로 인코딩되어 담겨있고 Signature로 서버의 비밀키와 헤더에서 지정했던 알고리즘을 이용해 암호화를 한다. Payload를 변조하여 제공하더라도 시그니처값과 다르기 때문에 변조를 확인할 수 있다.

8.토큰은 강제로 만료시킬 수 없기 때문에 만약 탈취당한다면 만료까지 계속해서 공격자에게 이용당할 수 밖에 없는 단점이 있으며 이를 극복하고자 짧게 한다면 사용자의 불편함을 초래한다.

9.Authentication은 인증하는 절차를 의미하며 Authorization은 토큰을 주는 등의 권한을 부여하는 방식이다. 간단하게 말해서 Authorization으로 권한을 주고 재 접근시 Authentication을 통해 확인한다.

10.Authorization Code는 Authorization Grant의 한 타입으로 액세스 토큰을 발급받기 위한 Code를 의미하며 Access Token은 발급을 받았다는 인증서 같은 역할을 한다. 위에서 언급했던 것 처럼 Code를 통해 토큰을 발급하고 토큰을 통해 인증을 받을 수 있다.
Resource Server는 클라이언트의 요청을 수락하고 응답할 수 있는 데이터가 저장되어 있는 서버이며 Authorization Server는 토큰을 발급하 인증 서버로 사용자가 요청 후 인증할 경우 Resource Server에 토큰을 발급한다.

백엔드과정을 짧은 시간에 지나치게 구겨넣는 느낌을 계속해서 주고 있다..
전반적인 내용을 잘 이해해서 언젠가는 써먹을 수 있으면 좋겠다.

'회고' 카테고리의 다른 글

학습(알고리즘)  (0) 2022.07.17
학습(알고리즘)  (0) 2022.07.16
[Backend] 인증 / 보안  (0) 2022.07.14
[네트워크] 심화  (0) 2022.07.13
[사용자 친화 웹] 웹 표준 & 접근성-3  (0) 2022.07.12

Chapter1. 웹 인증/보안
1.왜 HTTPS가 HTTP보다 안전한 지 이해한다.
2.HTTPS의 암호화 방식에 대해 이해한다.
3.HTTPS에서 사용하는 대칭키, 비대칭키 방식에 대해 이해한다.
4.직접 로컬에서 HTTPS 인증서를 발급할 수 있다.
5.Hashing이 필요한 이유에 대해 이해한다.
6.데이터베이스에 유저의 비밀번호와 같이 민감한 정보를 평문으로 저장하지 않는 이유에 대해 이해한다.
Chapter2. Cookie / Session
7.쿠키의 작동 원리를 이해할 수 있다
8.회원가입 및 로그인 등의 유저 인증에 대해 설명할 수 있다.
9.세션의 개념을 이해할 수 있다.
10.쿠키와 세션은 서로 어떤 관계이며, 각각이 인증에 있어서 어떤 목적으로 존재하는지 이해할 수 있다.
11.세션의 한계를 이해할 수 있다.


1.HTTPS는 HTTP에서 S(Secure Socket layer)이 추가된 것으로 통신을 하는 과정에서 데이터를 암호화하여 전송하는 방법이다.

2.키 제작용 랜덤 스트링을 전송하고 세션 키로 암호화 된 메세지를 보내고 받은 메세지는 받은 키로 해독한다.

3.대칭키는 간단하게 말해서 순수함수를 적용한 느낌으로 변경시키기 때문에 그 역계산을 통해 암호화 -> 복호화를 할 수 있다. 하지만 비대칭키는 암호화 된 과정을 거꾸로 작동시켜도 복호화가 되지 않기 때문에 보안에 있어서 더 뛰어나다.

4.mkcert -key-file key.pem -cert-file cert.pem localhost 127.0.0.1 ::1을 통해 인증서를 발급할 수 있다.

5.hashing을 하지 않고 단순하게 암호화 -> 역암호가 가능한 단순한 암호화를 할 경우 중간에 탈취된 데이터에 암호화의 반대과정을 적용하면 암호화를 한 의미가 없으므로 hashing을 통해 중간 과정에서 민감정보가 탈취되더라도 복호화를 할 수 없게 한다.

6.데이터베이스에 평문으로 저장할 경우 중간에서 가로챌 수 있다/

7.쿠키는 서버가 클라이언트에 특정한 데이터를 저장하는 방식으로 무상태성과 빠른 반응을 위해 쿠키를 이용한다.

8.회원 가입은 서버에 그 회원의 데이터를 올리는 작업이고 로그인은 아이디와 비밀번호를 전송해 해당 데이터와 일치하는 회원의 데이터가 있는 경우 그 값을 반환해주는 방식으로 진행된다.

9.세션은 사이트측에서 회원의 로그인정보를 기억하고 있는 방식이다.

10.쿠키는 클라이언트측에 기억하게 강요한다면 세션은 중요정보는 서버측에서 가지고 있는 방식으로 보안면에서는 세션이 더 유리하다.

11.무상태성이 아닌 상태성이 되어버리므로 서버를 확장하거나 다른 서버에서 처리할 수 없는 등의 불리함을 가지고 있다.

오늘이 역대 가장 어려웠던게 아닌가 싶을 정도로 엄청난 난이도였다..
데이터를 주고 이해하는 방식이라면 크게 어렵지 않았을 것 같은데
어려운 난이도에 정보도 조금 부족했기 때문에 종료시간에서 10분이 지났음에도 119명이 방에 남아있는 어마어마한 모습을 볼 수 있었다.

'회고' 카테고리의 다른 글

학습(알고리즘)  (0) 2022.07.16
[Backend] 인증 / 보안-2  (0) 2022.07.15
[네트워크] 심화  (0) 2022.07.13
[사용자 친화 웹] 웹 표준 & 접근성-3  (0) 2022.07.12
[사용자 친화 웹] 웹 표준 & 접근성-2  (0) 2022.07.11

+ Recent posts