개발일지

 🏀 문제

불합격 😥

풀다가 막혀서 다른사람의 코드를 보고 작성 해보았다.

합격코드

function solution(priorities, location) {
  let answer = 0;
  let count = 0;
  let target_location = location;

  while (priorities.length > 0) {
    let first = priorities.shift();
    if (priorities.filter((e) => e > first).length > 0) {
      priorities.push(first);
    } else {
      count += 1;
      if (target_location === 0) {
        return (answer = count);
      }
    }
    target_location -= 1;
    if (target_location === -1) {
      target_location = priorities.length - 1;
    }
  }

  return answer;
}

// console.log(solution([2, 1, 3, 2], 2));
console.log(solution([1, 1, 9, 1, 1, 1], 0));

먼저 몇번째로 출력되었는지를 알려주는 count , 내가 출력하려는 타겟이 배열의 몇번째 위치에 있는지 알려주는 변수를 선언했다.

while문으로 배열의 길이가 0보다 클때가지 로직을 돌려 주었지만 내 타겟이 출력되면 return으로 while문을 강제 종료시켰다.

first라는 변수에 배열의 첫번째 값을 빼서 저장시켜주고 그 값을 기준으로 배열의 filter함수를 돌려 기준값보다 큰 값이 배열에 존재하는지 여부를 판단했다.

만약 배열의 길이가 0보다 크다면 현재 기준 값보다 큰 숫자가 배열에 존재한다는 뜻임으로 우선순위에서 밀려나며 그 값은 다시 배열의 마지막으로 들어간다.

이제 first 보다 큰 값이 없다는 뜻은 현재 기준값을 출력해줘야 한다는 뜻이고 출력과 동시에 count숫자를 올려주고 출력값은 사라진다.

현재 타겟의 위치가 0이라는 것은 내가 출력하려는 값이 가장 앞에 와있고 우선순위에 가장 높다는 뜻임으로 return으로 while문을 종료시켜준다. 

if else의 조건문과 별개로 while문이 돌아갈때마다 타겟의 위치는 변해야하며 내가 출력하려는 타겟의 위치가 첫번째를 지나 -1이되면 다시 타겟의 위치를 배열의 가장 마지막으로 보내준다.

문제를 풀고난후

한글로 코드를 설명하며 정리하려다 보니깐 더 어려운점이 있는것 같다. 

가장 헷갈렸던 부분이 로직을 몇번 돌려야 할지 고민하는 것이 였는데 위에 코드처럼 while문으로 로직을 가장 마지막 발생할수잇는 경우의 수까지 돌린 다음 조건이 맞으면 return문으로 강제 종료시키는 방법도 좋은것 같다.

📌 문제풀러가기 https://programmers.co.kr/learn/courses/30/lessons/42587

프로젝트를 진행하면서 props로 전달되는 값을 가지고 css스타일링을 변경 할 일이 생겼다.

원래는 여러개의 ClassName을 주고  이벤트가 발생함에 따라 원하는 스타일을 골라주는 방법을 썼었는데 

(이런식으로 name값이 있으면 css내에서 pink로 설정해둔 값이 적용되고 없으면 grey)

마우스의 위치를 props로 받아 해당위치에 컴포넌트를 위치시키려면 위처럼 미리 setting(?)이 불가능했다.

해결방법

우선 클릭시 위치를 받아오기 위해 useState로 상태관리 메소드를 만든 setLocation함수에 x,y좌표의 위치를 객체로 저장시킨다.

그럼 locaiont함수에 x,y값이 저장되어있고 그 값을 이용해서 컴포넌트 위치를 잡아 줄 것이다

여기서 나는 postCss대신 컴포넌트함수 내에서 스타일링 해주는 styled-components를 사용했다.

참고하면 좋은글 : https://velog.io/@devstone/React%EC%97%90%EC%84%9C-Styled-components%EB%A1%9C-%EC%8A%A4%ED%83%80%EC%9D%BC%EB%A7%81-%ED%95%98%EA%B8%B0

left와 top스타일을 컴포넌트내에서 변경시켜주기 위해 리터럴 문법을 이용해서 WirteOrView함수의 props값을 받아와 내가 원하는 대로 바꿔주었다

클릭하는 마우스를 기준으로 가운데 위치시켜주고 싶엇는데 일단 방법을 몰라 width와height가 100px이라 -50해주었다... (바꿔야함 반응형처리 불가)

JWT도대체 어디에 저장해야 할까?

졸업작품을 만드는데 로그인을 구현하면서 서버가 넘겨준 jwt토큰을 과연 어디에 저장하고 사용해야 jwt토큰의 장점을 살리면서 보안의 위협도 적어질까라는 고민으로 자료조사를 해보았다

그리 간단한 내용이 아니라는것을 깨닫고 이참에 처음부터 끝까지 정리해보자라는 마음으로 포스트를 업로드했다.

로그인 인증을 할 수 있는 방법인 쿠키/세션,jwt,jwt의 2가지토큰인 Access,refresh token을 업로드하고 보안상으로 문제가 될 수 있는 csrf,xss까지 정리해보았다.(webStorage도)

소셜미디어와 비슷한 성격을 지닌 저의 졸업작품 특성상 한번 로그인하면 로그인한 상태를 쭉 이어가야 했고 그렇다면 그 중 가장 좋은 방법인 refresh token을 과연 어디에 저장하고 사용 해야 가장 안전하면서 로그인한 상태를 유지할 수 있을까 

refresh token을 cookie에 저장하는 경우

(장점)

XSS공격으로 부터 localStorage에 비해 안전하다.

쿠키의 httpOnly 옵션을 사용하여 브라우저에서 쿠키를 접근 할 수 없게 만들어 주고 Secure 옵션을 사용하여 웹브라우저와 웹서버가 HTTPS로 통신하는 경우에만 웹브라우저가 쿠키를 서버로 전송.(httpOnly,Secure는 서버에서 설정)

즉 해커가 사용자의 쿠키를 탈취하기 위해 미리 악성 스크립트 파일을 심어 두어도(xss) 스크립트 파일에 해커가 적어둔 js코드로 쿠키에 접근 자체를 못함(그래도 공격하는 방법이 있다고 함...)

(단점)

CSRF 공격에 취약하다.

쿠키가 자동으로 http request에 담아서 보내기 때문에 공격자가 request url만 안다면 사용자가 관련 link를 클릭하도록 유도하여 request를 위조하기 쉽다.

-> 쿠키에 refresh token이 저장되어잇는 상태에서 서버와 통신을 하면 쿠키 특성상 계속 서버로 보내지기 때문에 해당 링크를 클릭하면 refresh toekn을 이용하여 accesstoken을 탈취해 개인 정보를 빼낼 수 잇음

refresh token을  localStorage에 저장하는경우

(장점)

CSRF 공격에는 안전하다.
자동으로 request에 담기는 쿠키와는 다르게 js 코드에 의해 헤더에 담기므로 공격자가 사용자인 척 request를 보내기 어려움

(단점)

XSS에 취약하다.

자바스크립트 접근이 너무쉬움

그렇다면 도대체 어디?

내가 조사 한 결과 가장 안전하다고 판단 되면서 jwt의 장점을 살릴 수 잇는 방법은 refresh token을 DB에 저장하는 것 이다.

로그인을 하면 서버에서는 access token을 클라이언트에 refresh token의 DB 인덱스값과 함께 보내주고

클라이언트에서는 값을 받아 access token은 클라이언트내에서(유효기간이 짧아 털려도 비교적 괜찮음... 물론털리면 안좋음..) 사용하고 인덱스값은 쿠키나 로컬스토리지에 저장하고 사용한다.

이때 인덱스값을 그냥 넣는것이 아니라 해시화를 진행해주어 보안을 조금 더 유리하게 만들어준다.

결국 refresh token을 클라이언트에서 관리하지 않고 access token만 관리하는 방법을 선택했다.

클라이언트에서 직접 토큰을 관리해 서버 부하를 줄여주자는 jwt의 원래 성격과는 조금 거리가 있으나 보안상 이점도 챙겨면서 세션 방식을 사용한것 보단 서버의 부하를 줄여주는 위의 방법이 그나마 제일 난것같다.

다른 옵션

refresh token을 쿠키에 저장하고 사용하는 방법이다 쿠키에는 Secure,HTTPOnly,Same-Site 등 여러 보안 옵션이 있어 비교적 안전하다고 생각되어 사용하는것 같다.

그럼에도 클라이언트에서 중요한 정보를 다루기에는 여전히 많은 문제가 있고 추후 똑똑한 사람들이 좋은 라이브러리를 만들어 주어 해결 할때 까지 존버하자...

마치며

로그인을 구현하는데 생각보다 복잡한 문제들이 껴 있었고 나는 하나씩 그 문제들을 찾아가며 정리하다 보니 생각보다 오랜시간을 잡아 먹었다.

본인 프로젝트의 특성을 고려하여 UX가 중요한 문제인지 보안이 더 중요한 문제인지를 판단하고 어떤 방법을 사용할 지 결정해야 하는것 같다. 

다음으로는 실제 프로젝트에 직접 적용해보고 포스트를 작성하겠다...

참고자료

https://doogle.link/jwt-%ED%98%B9%EC%9D%80-oauth2-%EC%9D%98-refresh-%ED%86%A0%ED%81%B0%EC%9D%84-%EC%96%B4%EB%94%94%EB%8B%A4-%EC%A0%80%EC%9E%A5%ED%95%B4%EC%95%BC-%ED%95%A0%EA%B9%8C/

https://velog.io/@0307kwon/JWT%EB%8A%94-%EC%96%B4%EB%94%94%EC%97%90-%EC%A0%80%EC%9E%A5%ED%95%B4%EC%95%BC%ED%95%A0%EA%B9%8C-localStorage-vs-cookie#1-jwt

Web Storage란?

Web Storage는 2016년부터 실제로 쓰이게 되었으며 브라우저에 매우 종속된 기술이라고 볼 수 있다.

브라우저(클라이언트)에 key-value형태로 데이터를 저장 하는 방식으로 쿠키와 굉장히 유사하다

쿠키와 Web Storage의 차이는 밑에서 보기로 하고 일단 Web Storage에는 Local Storage, Session Storage의 2가지 저장소가 분리되어있다. 

Local Storage

• localStorage는 시간제한이 없고 브라우저가 꺼져도 죽지 않는다. (브라우저를 종료하고 나중에 다시 접속해도 값이 유지가됨)
• 관리자가 데이터를 명시적으로 삭제 시켜줘야만 데이터 삭제가 된다. 
• 탭을 여러개 열어도 공유된다

Session Storage

• 브라우저가 열려있는 동안만 데이터가 살아있으며 브라우저 종료시에 데이터도 함께 없어진다.
• 새로고침을 해도 데이터는 유지된다.
• 탭마다 별도의 저장소가 분리 되어 있어 데이터를 공유하지 않는다

Local Storage , Session Storage의 차이

Local storage와 Session Storage의 가장 큰 차이는 브라우저 종료시 데이터가 사라지냐 이다.

Local Staroage는 관리자가 별도로 데이터를 삭제 해 주지않는 이상 데이터를 계속 가지고 있으며 Session Storage는 브라우저 종료시 데이터가 사라지는 것을 볼 수있다!

Cookie와 WebStorage의 차이

1.제한

cookie - 용량제한, 시간제한, 갯수제한 존재

webstorage - 용량제한만 존재

2.시간제한 설정

cookie - 시간제한 설정가능

webstorage - 시간제한 설정 불가능

3.데이터형

cookie - 문자열만 저장가능

webstorage - javascript 객체 저장가능

4.데이터 전송

cookie - 모든 쿠키를 전송해야함, cookie를 가공함으로써 발생하는 side effect존재

webstorage - 개발자가 선택해서 전송할 수 있고 가공할 수도 있음

5.세션의 정의

cookie - 같은 브라우저면 다른 탭이나 다른 창(프로세스)일지라도 같은 세션이라고 정의

webstorage - 같은 브라우저일지라도 sessionStorage의 경우 다른 탭이면 다른 세션이라고 정의

6.이벤트

cookie - 이벤트 없음

webstroage - 이벤트 존재

쿠키와 비교해서 WebStroage가 더 나은 모습을 보이지만 데이터의 영속성 때문에 유지보수,데이터관리를 함에 있어 조금 더 까다로운점이 존재한다.

마지막으로 글을 조금 더 보태자면 세션은 이러한 클라이언트에서 데이터를 보관하는 방법보다 더 안전한 방법이다.

하지만 서버에 걸리는 부하때문에 cookie와 webstorage같은 곳으로 데이터를 분산한다.

참고 자료

https://velog.io/@ejchaid/localstorage-sessionstorage-cookie%EC%9D%98-%EC%B0%A8%EC%9D%B4%EC%A0%90

https://kamang-it.tistory.com/entry/Web%EC%A1%B0%EA%B8%88-%EB%8D%94-%EC%9E%90%EC%84%B8%ED%9E%88cookie%EB%8A%94-%EB%84%88%EB%AC%B4-%EA%B5%AC%EC%8B%9D%EC%95%84%EB%83%90-%EC%9D%B4%EC%A0%9C%EB%B6%80%ED%84%B4-Web-Storage

Refresh Token이란?

Refresh Token은 Access Token과 마찬가지로 로그인을 할때 서버에서 발급해주는 jwt(json web token)이다

그렇다면 왜 로그인을 했을때 서버에서 2가지의 토큰을 발급 해 주는 것일까?

이 문제의 해답은 Access Token의 단점과 연결 된다.  

2021.08.02 - [Web] - JWT 지난 포스트에서 jwt의 단점 중 Access token을 발급하고 유효기간이 지나기 전 까지는 해커에게 토큰이 털려도 손 쓸 방법이 없다고 글을 작성했다. 그렇다면 "Access token의 유효기간을 짧게 하면서 문제를 해결 할 수 있는 방법이 없을까?"

라는 물음의 답이 바로 Refresh token인 것이다.

예를 들어 Refresh Token의 유효기간은 1주, Access Token의 유효기간은 1시간이라 생각해보자. 

사용자는 1시간동안 Access token을 이용하여 서버로부터 데이터를 받을 수 있으며 1시간이 지나면 다시 로그인을 하는 방식이 아닌 그 전에 발급 받은 refresh token으로 다시 Access token을 발급 받는 것 이다.

이런 refresh token의 장점은 Access token으로만 데이터를 주고 받는 서버에서 Access token의 유효기간을 줄이고 보다 더 안전한 사용이 가능하게 만들어 준다.

하지만 refresh token 또한 단점이 존재한다

일단 구현자체가 좀 복잡하고 refresh token을 어디에 저장해야 안전한지 (다음 포스트예약) 만약 refresh token을 탈취 당한다면 어떻게 해야할지 등 여러 문제가 있다.  

그럼에도 현재 로그인을 구현하는 가장 대표적이고 안전한 방식이 refresh token을 사용하는 것이라는 거에는 변함이 없다.

Refresh Token인증과정

1번부터 7번까지의 과정은 Access Token의 인증과정과 별 다를게 없다(refresh token을 함께 받아오는것 빼곤)

만약 Access Token의 유효기간이 만료가 되면 서버는 클라이언트에서 보낸 Access token의 유효기간이 지난 것을 확인하고 유효기간이 지났다고 응답한다. 그 다음 Access token의 재발급을 위해 클라이언트는 refresh token을 보내며 서버는 이를 확인 하고 Access token을 발급한다 

9~11의 과정은 프론트쪽에서 Access Token의 Payload를 통해 유효기간을 알 수 있어 유효기간이 끝나가는 시점에서 자동으로 Access Token을 재발급 받아주는 로직을 작성하면 된다.

참고

https://tansfil.tistory.com/59?category=475681 

JWT란?

Json Web Token의 약자로 모바일이나 웹의 사용자 인증을 위해 사용하며 인증에 필요한 정보들을 암호화시킨 토큰을 뜻한다!(토큰기반 인증방식)

https://jwt.io jwt사이트를 들어가 보게되면 암호화된 토큰을 볼 수 있는데 

토큰을 만들기 위해서는 크게 3가지, Header,Payload, Verify Signature가 필요하다!

Header : 위 3가지 정보를 암호화할 방식(alg 알고리즘 Verify Signature를 만드는 알고리즘이 들어감), 타입(jwt고정) 등이 들어감

Payload : 서버에서 보낼 데이터가 들어가며 일반적으로 유저의 고유 ID값, 유효기간이 들어간다

Verify Signature :  Base64 방식으로 인코딩한 Header,payload 그리고 SECRET KEY를 더한 후 서명된다.

최종적인 결과 : Encoded Header + "." + Encoded Payload + "." + Verify Signature

Header, Payload는 인코딩될 뿐(16진수로 변경), 따로 암호화 되지않는다. 따라서 누구나 디코딩하여 정보를 볼 수 있으며 Payload에 유저의 비밀번호같은 중요한 데이터가 들어 가면 매우 위험하다!

하지만 Verify Signature는 SECRET KEY를 알지 못하면 복호화할 수 없다!

예를 들어 사용자 A가 사용자 B의 정보를 훔쳐보고 싶어 Payload에 있던 A의 id대신 B의 id로 다시 인코딩한 후 받아온 토큰 값을 서버로 보냈다고 가정해보자.이때 서버에서는 Verify Signature 검사를 하게 되는데 Payload에 B의 id가 들어 있어도 A의 Payload로 기반으로 만들어진 Verify Signature때문에 유효하지 않은 토큰인 것 을 알 수 있다!결국 SECRET KEY를 알지 못하면 토큰을 조작 할수 없다는 것을 알 수 있다

JWT 인증방식

사용자가 로그인을 하면 서버에서는 DB에서 사용자가 맞는 지 확인 한 후 Access Token을 발급 하여 사용자에게 보내준다.

이렇게 로그인이 되고 사용자는 데이터를 요청하기위해 발급 받은 Access Token을 다시 서버로 보낸다. 그러면 서버는 Access Token값을 기준으로 판단하여 사용자가 맞는지 판다하고 요청하는 데이터를 응답해준다.

(장점)

1. 세션/쿠키는 별도의 저장소의 관리가 필요한것에 비해 JWT는 발급한 후 검증만 하면 되기 때문에 추가 저장소가 필요 없어 간편하다.

이는 Stateless 한 서버를 만드는 입장에서는 큰 강점이다!

Stateless : 어떠한 별도의 저장소도 사용하지 않는, 즉 상태를 저장하지 않는 것을 의미한다

2. 토큰 기반으로 하는 다른 인증 시스템에 접근이 가능하여 확장성이 뛰어남. (ex FaceBook,Google)

(단점)

1. 이미 발급된 JWT에 대해서는 돌이킬 수 없다. 세션/쿠키의 경우 만일 쿠키가 악의적으로 이용된다면, 해당하는 세션을 지워버리면 된다. 하지만 JWT는 한 번 발급되면 유효기간이 완료될 때 까지는 계속 사용이 가능하여 한번 털리면 유효기간 끝날때까지 방법이 없다.

-->  해결책 : 기존의 Access Token의 유효기간을 짧게 하고 Refresh Token이라는 새로운 토큰을 발급한다(다음 포스트 당첨)

2. Payload 정보가 제한적이다. 위에 말했던 이유인 Payload의 값은 누구나 디코딩이 가능하여 중요한 정보를 넣을 수 없다!

3. 세션/쿠키 방식에 비해 JWT의 길이는 길어 인증이 필요한 요청이 많아질 수록 서버의 자원낭비가 발생하게 된다!

참고 

https://tansfil.tistory.com/58?category=475681 

CSRF란?

사이트 간 요청 위조또는 크로스 사이트 요청 위조(Cross-site request forgery, CSRF, XSRF)는  웹사이트 취약점 공격의 하나로, 사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위(수정, 삭제, 등록 등)를 특정 웹사이트에 요청하게 하는 공격을 말한다.

CSRF공격을 성공하려면 

• 사용자가 로그인이 되어 있어야한다.
• 사용자가 해커가 심어놓은 게시글이나 이미지를 클릭해야한다!

밑에 글을 보며 자세히 이해해보자!

CSRF의 공격순서

1. 먼저 해커가 보안이 취약한 웹사이트에 HTTP로 작성된 요청문을 게시글에 작성한다(사용자의 정보를 얻기위해 해당 게시글을 누르면 작성된 요청문이 실행되어 해커에게 정보가 날라감)
2. xss와 마찬가지로 해커에게 정보가 날라가는 요청문이 DB에 저장되게 된다.
3. 사용자가 게시판을 내려보다 해커가 심어놓은 해당 게시글을 클릭하게되면 해당 링크 또는 해당 게시글의 이미지를 클릭햇을때 해커가 작성한 HTTP요청을 사용자 본인의 권한으로 실행하게 된다 (이때 사용자가 로그인이 되어있어야함, 로그인이 되있는 상태에서 클릭시 해커가 심어놓은 HTTP요청을 사용자 본인의 요청으로 실행하게되고 해당 정보는 해커에게 넘어간다)

CSRF의 취약한지 판단하는 방법

위의 사진처럼 img src를 이용하여 유저를 강제 로그아웃(사용자에게 피해를 끼치는) 시키는 코드를 작성하고 임의의 유저가 해당 이미지를 클릭시 해당 요청이 실행된다면 csrf의 취약하다고 판단할 수 있다 (img는 기본적으로 get요청을 사용하기 때문에 위와 같은 코드가 가능함)

실제로 2008년 옥션에서 발생했던 관리자 계정 탈취 사건도 관리자가 admin 권한으로 로그인 한 상태에서 피싱 메일을 열람하였고 피싱 메일안에 숨겨진 CSRF코드가 실행되어 관리자 권한을 탈취하게 된 것이다.

그렇다면 CSRF의 대응 할 수 있는 방법!

1. Referrer 검증법

클라이언트가 서버로 데이터를 요청할때마다 request의 header에 담겨있는 referrer값을 확인하여 같은 도메인에서 보낸 요청인지를 확인하고 차단하는 방법이다.

하지만 동일 사이트 내에서 XSS 취약점이 발견된다면 이를 통하여 CSRF 공격을 실행할 수 있다는 점을 유의해야 하며 이는 페이지 단위까지 쪼개어서 도메인 검증을 하는것으로 페이지 간 CSRF 공격을 방어할 수 있다!

2. CSRF Token 사용

사용자의 세션에 임의의 값을 저장하여 모든 요청마다 그 값을 포함하여 전송한다.(세션로그인 방식)

그리고 요청이 들어올 때 마다 백엔드에서 세션에 저장된 값과 요청으로 전송된 값이 일치하는지 검증하여 방어하는 방법!

referrer 검증법과 같이 XSS를 통한 CSRF 공격에 취약하다는 특징이 있다!

XSS와 CSRF의 차이

- XSS는 사이트변조나 백도어를 통해 클라이언트에 대한 악성공격을 한다.

- CSRF는 요청을 위조하여 사용자의 권한을 이용해 서버에 대한 악성공격을 한다.

참고사이트

https://tibetsandfox.tistory.com/11

https://crossjin.tistory.com/entry/CSRFCross-Site-Request-Forgery%EB%9E%80