1. 쿠키의 인식
쿠키 1) 쿠키는 특정 사이트가 사용자의 신분을 식별하고session 추적을 하기 위해 사용자 로컬 단말기에 저장한 데이터를 말한다
쿠키의 로그인 1) 사용자가 브라우저 쿠키와 쿠키를 수동으로 삭제하는 것을 제외하고 한 번 로그인한 경우 다음에 이 사이트를 방문하면 사용자가 사용자 이름과 비밀번호를 입력하지 않아도 사이트에 들어갈 수 있다 쿠키의 생명주기 1) 쿠키를 만들 때 쿠키를 지정하는 값: Expire, 이것은 쿠키의 유효기간, 즉 쿠키의 생명주기입니다. 설정한 이 생명주기를 초과하면 쿠키는 삭제됩니다2) 이 값인 Expire를 0 또는 마이너스로 설정하면 이러한 설정은 브라우저를 닫을 때 쿠키를 제거하는 것입니다. 이런 방식은 더욱 안전합니다session과 cookies의 다른 1) 저장 위치가 다른session은 서버에서 발생하여 비교적 안전하지만 session이 많으면 성능에 영향을 줄 수 있다. cookies가 클라이언트에서 발생하고 안전성이 약하다2) 성명 주기가 다르면session의 생명 주기는 지정된 시간(예를 들어 20분)이 지나면 종료되고 지정된 시간이 되지 않는다.브라우저 프로세스가 끝나면 cookies가 종료됩니다. 기본적으로 브라우저 프로세스가 끝나면 종료됩니다. 그러나 수동으로 시간을 지정하면 브라우저 프로세스 종료의 영향을 받지 않습니다. 3) 정보 저장 시효가 다르기 때문에session을 사용하여 사용자 정보를 저장하고 사용자 정보를 잃어버려서 다시 로그인하고 cookies를 사용하여 사용자 정보를 저장하면 사용자 정보가 장시간 유효합니다2. 쿠키의 안전 위험
쿠키의 불안정 1) HTTP 프로토콜은 무상태이다. 즉, 사용자가 서버에 도착할 때마다 HTTP 서버는 이 사용자가 누구인지, 로그인했는지 등을 모른다.브라우저가 우리가 로그인했는지 알 수 있는 이유는 서버가 로그인할 때 브라우저의 쿠키를 설정했기 때문이다.session은 쿠키를 빌려 이루어진 더 높은 서버와 브라우저 간의 세션 2) 쿠키는 브라우저에 저장된다. 즉, 사용자 로컬이다. 브라우저를 통해 쿠키를 캡처할 수 있다. 예를 들어 스크립트,도구 캡처 등 3) 쿠키를 이용하여 사용자의 로그인 상태를 표시한다. a. 사용자가 사용자 이름과 비밀번호를 제출하는 폼이다. 이것은 보통 POST HTTP 요청 b. 서버에서 사용자 이름과 비밀번호를 검증하고 합법적이면 200(OK)으로 돌아가며 Set-Cookie를 authed=true c. 브라우저로 설정하여 이 쿠키 d를 저장한다. 브라우저가 요청을 보낼 때 쿠키 필드를 authed=true로 설정하면 서버는 두 번째 요청을 받는다.쿠키 필드에서 이 사용자가 로그인했다는 것을 알 수 있다. 로그인한 사용자의 권한에 따라 이번 요청을 처리한다. 4) HTTP 요청을 보내는 것은 브라우저뿐만 아니라 많은 HTTP 클라이언트 소프트웨어(curl, Node.js 포함)도 임의의 HTTP 요청을 보낼 수 있고 헤더 필드를 설정할 수 있다.만약에 우리가 직접 쿠키 필드를authed=true로 설정하고 이 HTTP 요청을 보내면 서버는 속습니다. 이런 공격은 쿠키에 대해 쉽게 변경됩니다2. cookie의 불안정한 표현 1) 쿠키 사기는 이 쿠키의 구체적인 의미를 알 필요가 없다. 이 쿠키를 서버에 제출(아날로그 인증)하면 인증이 통과된 후에 도난당한 쿠키 대응 사용자를 사칭하여 사이트를 방문하고 심지어 사용자의 프라이버시 정보를 얻을 수 있다.사용자의 프라이버시에 심각한 해를 끼친다2) 쿠키 캡처는 순수한 텍스트 형식으로 브라우저와 서버 간에 전달되고 웹 통신할 때 불법 사용자에게 캡처되고 이용되기 쉽다.불법 사용자가 쿠키를 캡처한 후 쿠키의 유효 시간 안에 서버에 다시 발급하면 이 불법 사용자는 이 합법적인 사용자의 모든 권한을 가지게 된다. 3) Flash의 내부 코드 위험은 Flash 내부에 getURL() 함수가 있는데 Flash는 이를 이용하여 지정한 페이지를 자동으로 열 수 있다.Flash를 볼 때 특수한 조작 페이지를 열 수 있다. 목마일 수도 있고 현재 쿠키나 사용자 정보를 원격으로 입력할 수 있다. 이 동시에 이것은 Flash 내부의 조작이기 때문에 사이트에서 금지할 수 없다. 이것은 매우 위험하다.
3. 쿠키의 변조 방지 메커니즘과 안전 해결
쿠키의 변조 방지 메커니즘 1) 서버는 모든 쿠키 항목에 서명을 생성할 수 있다. 사용자가 쿠키를 변경한 후에 대응하는 서명을 생성할 수 없기 때문에 서버는 사용자가 쿠키에 대해 변조를 했다는 것을 알 수 있다. 2) 검사 과정은 서버에 알려지지 않은 문자열을 설정할 수 있다. 예를 들어 x$sfz32 서버가 쿠키를 설정해야 할 때(예를 들어 authed=falseauthed의 값을false로 설정할 뿐만 아니라 값의 뒤에 서명을 하나 더 설정한다. 최종적으로 설정된 쿠키는 authed=false|6hTiBl7lVpd1P 서명6hTiBl7lVpd1P이 이렇게 생성된다. Hash('x$sfz32'+'false').설정할 값은 시크릿과 합쳐서 해시 사용자가 HTTP 응답을 받고 헤더 필드 Set-Cookie: authed=false|6hTiBl7lVpd1P 를 보냈을 때 authed 값을 변경하고 헤더 필드 Cookie: authed=true|??? 를 설정합니다.사용자가 Secret을 모르기 때문에 서명을 생성할 수 없으며 HTTP 요청을 받은 서버만 입력할 수 있습니다Cookie: authed=true|???.서버에서 검사를 시작합니다. Hash('true'+'x$sfz32') 사용자가 제공한 서명이 정확하지 않은 것을 발견할 수 있습니다. 3) 쿠키는 명문 전송입니다. 서버가authed를 한 번 설정하면 이 서명으로 서버를 속일 수 있습니다.쿠키에 민감한 데이터를 저장하지 마십시오. 쿠키는 보통 하나의session Id만 저장하고session은 서버에 저장합니다 쿠키의 안전 해결 1) 쿠키 설정의 유효기간은 너무 길지 않고 적당하면 2) HttpOnly 속성을true로 설정하면 js 스크립트가 쿠키 정보를 읽는 것을 방지하고 XSS 공격을 효과적으로 방지할 수 있다. 3) 복잡한 쿠키를 설정하고 암호화된 쿠키의 키는 uid를 사용한다. 쿠키를 무작위로 생성하는value는 복잡한 조합을 사용할 수 있다. 예를 들어 사용자 이름 + 현재 시간 + 쿠키 유효시간 + 무작위 수 4) 사용자가 처음 로그인할 때ip+cookie 암호화를 저장한 token은 요청할 때마다 현재 cookie와 ip를 조합하여 암호화한 token과 저장된 token을 비교하고 완전히 대응해야만 검증에 성공할 수 있다5)session과 cookie가 동시에session Id를 사용하면 cookie에 놓이지만 상대적인session이 더욱 안전하여session6에 상대적으로 중요한 정보를 저장할 수 있다) 만약에 사이트에서https를 지원한다면https를 사용할 수 있다.쿠키에 Secure 속성을true로 설정하면 쿠키는 https 프로토콜로만 서버에 전송할 수 있고 https는 http보다 더욱 안전합니다
