728x90
반응형
request.headers().get("Cookie") 같은 명령어로 server 에서 뽑아낼 수 있다.
Server 측에서 주로 사용하는 데이터이긴 하지만, client 측에서도 javascript 를 통해서 접근 가능하기도 해서 XSS (Cross Site Script) 공격에 취약하기도 하다. 그래서 만들어진 것이 HttpOnly Cookie 로 해당 domain server 에서만 이 cookie 를 생성, 삭제, 접근 가능하도록 design 되었다. 이 HttpOnly cookie 는 javascript 를 이용해서 생성할수도 삭제할수도 읽어들일수도 없다.
그래도 우선 javascript 를 통해 어떻게 cookie 를 생성하고 삭제하고 읽어들이는지, browser 에는 어떻게 저장되어 있는지, 특정 domain/path 에서 어떤 cookie 들이 접근 가능한 것인지, 특정 domain/path 에 HTTP request 를 보낼 때 어떤 cookie 들이 그 domain server 로 전송되는지를 공부해 놓는 것이 좋아 보인다. 그래야 server 를 돌릴때에도 어떻게 client 의 cookie 를 관리할지 구상하기 쉬워질테니...
ps. Server 에서 쓸 data 가 아니라 client 측에서만 계속 사용할 data 라면, cookie 에 저장하기 보다 다른 local storage API 를 쓰는 것이 더 좋아보인다. Cookie 는 매번 server 에 (HTTP request 의 header 에 포함되어) 보내지는 data 이기 때문이다.
## PH
- 2024-01-07 : Small edit.
- 2015-07-10 : cookies.js 수정.
- 2014-08-31 : First posting.
allCookies is a string containing a semicolon-separated list of cookies (i.e. key=value pairs).
document.cookie = updatedCookie;
// updatedCookie is a string of form key=value. Note that you can only set/update a single cookie at a time using this method.
document.cookie =
"key=value" // 굳이 key=value 형태로 저장 안해도 된다는거 같은데, 그냥 이렇게 씁시다. 이렇게 안하면 나중에 찾기도 지우기도 쉽지 않을테니.
// The belows are optional, and they can be in any order.
+";max-age="+(365*24*60*60)
// or +";expires="+(new Date(2017,1,10).toUTCString())
+";domain="+window.location.host
// The current window.location.host is "".
+";path="+window.location.pathname
// The current window.location.pathname is "".
+";secure";
```/
와 같이 그냥 assign "=" 명령어 이용해서 읽고 쓰는 것이지만, 다음과 같은 Javascript Object 하나 만들어서 정의해놓고 쓰는것이 여러모로 더 좋아 보임 .
ps. Ref. - 4.1.2.2. The Max-Age Attribute : "If a cookie has both the Max-Age and the Expires attribute, the Max-Age attribute has precedence and controls the expiration date of the cookie. If a cookie has neither the Max-Age nor the Expires attribute, the user agent will retain the cookie until "the current session is over" (as defined by the user agent)."
### cookie.js : How to use
우선 code 및 간단한 사용 방법은 다음과 같다. (Ref. 도 참고 하시면서...)
#### Writing (Creating or Overwriting) a cookie
```[.linenums.lang-js]
// Syntax:
docCookies.setItem(name, value[, end[, path[, domain[, secure]]]]);
// return false if name(key) is invalid, e.g. predefined keys (expires|max-age|path|domain|secure).
// return true when the cookie is properly set.
docCookies.setItem(
String name
, String value
// The belows are optional arguments.
[, Number|String|Date end
// Number or String or Date object
// If not specified or null, it will expire at the end of session (when closing the browser tab?).
// Number: max-age in seconds (e.g. 365*24*60*60 for a year, Infinity for a never-expires cookie)
// String: expires date in GMTString format string
// Date: expires date as Date object
[, String path
// E.g. "/", "/mydir"; if not specified, defaults to the current path of the current document location.
// Defaults to "window.location.pathname"???, which is "/entry/Cookie-in-Web-HTML-Javascript" in this document.
[, String domain
// E.g. "example.com", or "subdomain.example.com"; if not specified, defaults to the host portion of the current document location.
// Defaults to "window.location.host", which is "kipid.tistory.com" in this document.
// Note: The dot, e.g. ".example.com", may be needed by old browser implementing the deprecated RFC 2109. Cookie is sent to all subdomains of cookie's domain attribute in browser implementing RFC 6265 (2011-04). So a leading %x2E (".") in domain, if present, will be ignored.
[, boolean secure
// The cookie will be transmitted only over secure protocol as https.
]]]]
);
// Examples:
docCookies.setItem("Hello", "World!");
docCookies.setItem("Hello", "World!", 24*60*60);
docCookies.setItem("Hello", "World!", 24*60*60, "/");
docCookies.setItem("Hello", "World!", 24*60*60, "/", "example.com");
docCookies.setItem("Hello", "World!", 24*60*60, "/", "example.com", true);
```/
Default 값에 대한 설명이 뭔가 애매모호하고 접근 권한 (읽기 권한, 쓰기 권한) 에 대한 설명이 없다 ㅡㅡ;;;;
- 같은 domain/host [e.g. example.com] 에 있다면 (sub domain [e.g. sub.example.com] 이라고 할지라도), 하위 path 는 상위 path 에 저장된 cookie 도 접근 (읽거나 덮어쓰거나 지우거나) 할 수 있는건가? 읽는건 가능한거 같은데, 덮어쓰거나 지울 수 있는지는 모르겠네;;;
- 다른 domain 의 cookie 도 마음대로 저장할 수 있구나??? 읽지만 못하는건가? 테스트 해보니 쓰는것도 안되는거 같은데... 아마도 main host [e.g. example.com] 는 같아야 하는듯?
document.cookie 자체가 상위 path 에 저장된 cookie 들도 모두 읽어 들이는듯?
읽기 권한에 관한 자세한 이야기는 section expires 를 현재 이전 날짜로 설정해서 해당 key 의 cookie 값을 저장하는 방식으로 이루어진다.
그런데 현재보다 상위 path 에 저장된 cookie 는 path 값을 지정해야만 지워지는듯? 그냥 지우려니까 안지워지네?
쓰기/지우기 권한 및 identification of cookie 에 관한 자세한 이야기는 section F12, and Press Ctrl+Shift+I to open console in chrome browser. It might be the same way in other browsers.)
#### Simple {setItem, getItem} test
#### Deleting all cookies just by keys (will fail)
#### 접근권한 test
#### Delete all test cookies (including button)
The whole test cookies created here was deleted in the beginning, to show consistant results. (But to delete the test cookies afterwards, you have to click the button below. Check your browser cookie settings before and after the deleting.)
Click the below button to delete all test cookies. Then check your browser cookie settings again.
##[#sec-Cookie-access] Cookie 접근 권한
Cookie 가 어떻게 동작해야 하는지, 어떻게 접근 권한을 부여해야 하는지는 에서 규정하고 있고, 설명은 에 잘 되어 있는듯 하군요.
(둘 다 헷갈리게 작성되어 있긴 함.... 제대로 이해하려면 본인이 직접 이것저것 테스트를 해봐야 할듯.)
### Identification of a cookie
Cookie 를 구분하는 인자는 name-domain-path-secure 이렇게 4개이다.
즉, name-domain-path-secure 이 같은 cookie 를 다시 저장하면 이전 cookie 가 덮어씌워진다. Expiration date 는 identification 에 들어가지 않기 때문에 이 option 이 없이 새로운 cookie 를 덮어쓰면 이전의 expires 는 그대로 남아있고 "key=value" 값만 바뀐다.
별로 권장되는 설정법은 아닌듯 함. 그래도 persistent cookie 가 session cookie (browser 를 닫으면 사라지는) 로 쉽게 바뀌지는 않는다는 것은 알아야 할테니...
### Expiration of a cookie
From Ref. - Using expiration dates :
When a cookie is created with an expiration date, that expiration date relates to the cookie identified by
name-domain-path-secure. In order to change the expiration date of a cookie, you must specify the exact same tuple. When changing a cookie’s value, you need not set the expiration date each time because it’s not part of the identifying information. Example:
```Set-Cookie: name=Mike; expires=Sat, 03 May 2025 17:44:22 GMT```/
The expiration date of the cookie has now been set, so the next time I want to change the value of the cookie, I can just use its name:
```Set-Cookie: name=Matt```/
The expiration date on this cookie has not been changed, since the identifying characteristics of the cookie are the same. In fact, the expiration date won’t change until you manually change it again. That means a session cookie can become a persistent cookie (one that lasts multiple sessions) within the same session but the opposite isn’t true. In order to change a persistent cookie to a session cookie, you must delete the persistent cookie by setting its expiration date to a time in the past and then create a session cookie with the same name.
Keep in mind that the expiration date is checked against the system time on the computer that is running the browser. There is no way to verify that the system time is in sync with the server time and so errors may occur when there is a discrepancy between the system time and the server time.
From Ref. - 4.1.2.2. The Max-Age Attribute :
If a cookie has both the
### Cookie 읽기 권한
보통 하위 domain/host 는 상위 domain/host 의 cookie 를 읽을 수 있는듯? 하위 path 들도 마찬가지로 상위 path 의 cookie 를 읽을 수 있는듯 하고... 글로만 설명을 읽으니 헷갈린다;;;;;
"example.com" 에 저장된 쿠키는 "blog.example.com" 같은 domain/host 에 접속했을 때도 읽어들일 수 있고, "example.com/super-directory/sub-directory" 같은 domain/host + path 에 접속했을 때도 읽어들일 수 있는거 같음. 반대로는 안되고.
"example.com/super-directory/sub-directory" 에 저장된 쿠키는 "blog.example.com" 에서는 읽을 수 없고, "blog.example.com/super-directory/sub-directory/subsub-directory" 에서는 읽을 수 있는듯.
즉, domain 과 path 모두 request-domain, request-path 와 같거나 super (상위) 이어야만 읽어들이는듯. Request-domain 과 request-path 는 당연히 현재 domain 과 path 이고.
#### Domain matching
Max-Age and the Expires attribute, the Max-Age attribute has precedence and controls the expiration date of the cookie. If a cookie has neither the Max-Age nor the Expires attribute, the user agent will retain the cookie until "the current session is over" (as defined by the user agent).
From - 5. User Agent Requirements - 5.1.3. Domain Matching (헷갈리게 쓰여 있어서 조금 수정. 제대로 수정한건지 모르겠네;;;) :
A request-domain domain-matches a given cookie-domain if at least one of the following conditions hold:
Current domain 의 super domain 의 cookie 를 모두 읽어들인다는 뜻인듯. 즉, browser 가 "https://kipid.tistory.com" 에 접속을 시도하면,
```
Get all cookies accessible from domain="https://kipid.tistory.com" (https 접속에서는 with and withOUT secure cookie 두 타입 다 보냄.);
// 같은 명령어로 Local Cookie DB 에 Cookie Request 를 보내고.
HTTP Request to "kipid.tistory.com" with these cookies;
// 이 쿠키를 포함시켜서 host 에 HTTP request 를 보내는듯?
// Path 로도 걸러내긴 하는듯. 구체적인 이야기는 다음 section 에서...
// 이 때 포함되는 cookie 는
Cookies with domain="http://kipid.tistory.com"; path=all-super-paths-of-the-current-path;
and withOUT secure;
Cookies with domain="http://tistory.com"; path=all-super-paths-of-the-current-path;
and withOUT secure;
// Super domain 에서도 current path 포함 super path 를 모두 찾는듯. Super domain 이라 path="/" 에 있는거만 가져올줄 알았는데.....
// The cookie string is always returned in order from most specific - The cookie-domain and the request-domain are identical. (Note that both the cookie-domain and the request-domain will have been canonicalized to lower case at this point.)
- All of the following conditions hold:
- The cookie-domain is a suffix of the request-domain. (Cookie 의 domain 이 요청한 request-domain 의 끝부분과 일치해야 하고.)
- The last character of the request-domain that is not included in the cookie-domain is a %x2E (".") character. (Request-domain 의 마지막 문자가 "." 이라면 "." 빼고 검사한다는 뜻인가?)
- The request-domain is a host name (i.e., not an IP address). (Request-domain 은 host name 과 같아야 함. 다른 domain 에 저장된 cookie 는 접근할 수 없다는 뜻인듯?)
path-secure tuple to least specific.
```/
위와 같은 cookie 들을 HTTP request header 에 포함시키는 듯.
Browser 가 "http://kipid.tistory.com" 에 접속을 했다면, javascript 로 얻어지는 cookie 는 마찬가지로 (but, HttpOnly 도 제외하면서)
```
document.cookie;
// returns
Cookies with domain="kipid.tistory.com"; path=all-super-paths-of-the-current-path;
and withOUT secure; HttpOnly;
Cookies with domain="tistory.com"; path=all-super-paths-of-the-current-path;
and withOUT secure; HttpOnly;
// Super domain 에서도 current path 포함 super path 를 모두 찾는듯. Super domain 이라 path="/" 에 있는거만 가져올줄 알았는데.....
// The cookie string is always returned in order from most specific path-secure tuple to least specific.
```/
#### Path matching
From - 5. User Agent Requirements - 5.1.4. Paths and Path-Match :
A request-path path-matches a given cookie-path if at least one of the following conditions holds:
Current path 의 super path 에 있는 cookie 를 모두 읽어들인다는 뜻인듯. 즉, browser 가 "https://kipid.tistory.com/super0-path/super1-path/current-path/index.html" 에 접속을 시도하면,
```
Get all cookies accessible from domain="https://kipid.tistory.com"; path="/super0-path/super1-path/current-path/index.html" (https 접속에서는 secure or not 두 타입 cookie 들을 다 보냄.);
// 같은 명령어로 Local Cookie DB 에 Cookie Request 를 보내고.
HTTP Request to "kipid.tistory.com" with path="/super0-path/super1-path/current-path/index.html"; and these cookies;
// 이 쿠키를 포함시켜서 host 에 HTTP request 를 보내는듯?
// 이 때 포함되는 cookie 는
Cookies with domain="kipid.tistory.com"; path="/super0-path/super1-path/current-path";
and withOUT secure;
Cookies with domain="tistory.com"; path="/super0-path/super1-path/current-path";
and withOUT secure;
Cookies with domain="kipid.tistory.com"; path="/super0-path/super1-path";
and withOUT secure;
Cookies with domain="tistory.com"; path="/super0-path/super1-path";
and withOUT secure;
Cookies with domain="kipid.tistory.com"; path="/super0-path";
and withOUT secure;
Cookies with domain="tistory.com"; path="/super0-path";
and withOUT secure;
Cookies with domain="kipid.tistory.com"; path="/";
and withOUT secure;
Cookies with domain="tistory.com"; path="/";
and withOUT secure;
// The cookie string is always returned in order from most specific - The cookie-path and the request-path are identical.
- The cookie-path is a prefix of the request-path, and the last character of the cookie-path is %x2F ("/").
- The cookie-path is a prefix of the request-path, and the first character of the request-path that is not included in the cookie-path is a %x2F ("/") character.
path-secure tuple to least specific.
// Test 해보니 domain 은 accessibility 만 처리하고 정렬은 path 기준으로만 되는듯???
```/
### Cookie 쓰기 권한
쓰기 권한은 domain attribute 로만 판별하는듯.
#### The Domain Attribute
From Ref. - 4. Server Requirements - 4.1. Set-Cookie - 4.1.2.3. The Domain Attribute (일부만 발췌) :
The Domain attribute specifies those hosts to which the cookie will be sent. For example, if the value of the Domain attribute is "example.com", the user agent will include the cookie in the Cookie header when making HTTP requests to example.com, www.example.com, and www.corp.example.com. (Note that a leading %x2E ("."), if present, is ignored even though that character is not permitted, but a trailing %x2E ("."), if present, will cause the user agent to ignore the attribute.)
// leading %x2E (".") 가 있으면 무시한 뒤/지운 뒤 처리하고, trailing %x2E (".") 가 있으면 아예 domain attribute 를 무시한다는 뜻인가???
The user agent will reject cookies unless the Domain attribute specifies a scope for the cookie that would include the origin server. For example, the user agent will accept a cookie with a Domain attribute of "example.com" or of "foo.example.com" from "foo.example.com", but the user agent will not accept a cookie with a Domain attribute of "bar.example.com" or of "baz.foo.example.com".
NOTE: For security reasons, many user agents are configured to reject Domain attributes that correspond to "public suffixes". For example, some user agents will reject Domain attributes of "com" or "co.uk".
Current domain 의 super domain 쿠키를 쓸 수 있다는 뜻인듯. 즉, "http://foo.example.com" 에 접속했을 때에는 domain="example.com" 의 쿠키를 쓸 수 있음. (당연히 읽을수도 있고.) 하지만, domain="bar.foo.example.com" 의 쿠키나 domain="sub.example.com" 의 쿠키는 쓸 수 없다는 말. (당연히 읽을수도 없음.)
#### The Path Attribute
From Ref. - 4. Server Requirements - 4.1. Set-Cookie - 4.1.2.4. The Path Attribute :
The scope of each cookie is limited to a set of paths, controlled by the Path attribute. If the server omits the Path attribute, the user agent will use the "directory" of the request-uri's path component as the default value. (See Section 5.1.4 for more details.)
The user agent will include the cookie in an HTTP request only if the path portion of the request-uri matches (or is a subdirectory of) the cookie's Path attribute, where the %x2F ("/") character is interpreted as a directory separator.
위에 설명은 되어 있지 않은데, 읽는 권한은 current path 의 super path 의 쿠키들만 읽을 수 있지만, 쓰는건 domain 에만 권한이 있으면 path 에는 제한이 없는듯??? Chrome 에서만 이렇게 동작하는 것일지도?
## Cookies in chrome
Chrome browser 에서 쿠키를 확인하는 방법은 chrome://settings/content (Settings - Privacy - Content settings...) 접속해서 Cookies 부분에 "All cookies and site data..." button 누르면 되는듯. 여기서는 [Domain, Path, Send for, Accessible to script, Created, Expires] 등의 정보도 다 볼 수 있음.
개인 보안을 위해서라도 쿠키는 주기적으로 한번씩 다 지워주는게 좋아보임. 다시 모든 사이트 로그인을 다시 해야한다는 번거로움이 있긴 하지만...
## Cookie handling from/by Server: and HttpOnly cookie
HTTP header 에 다음과 같은 것들을 담아서 client 에 보내면 cookie 가 저장되는듯 함.
```
Set-Cookie: name=value[; expires=date][; domain=domain][; path=path][; secure][; HttpOnly]
```/
여러개의 cookie 는 다음과 같은 명령어로...
```
req.response()
.putHeader("Set-Cookie", "some=cookie;max-age=1000;path=/;HttpOnly"
+"\nSet-Cookie: next=cookie"
+"\nSet-Cookie: nnext=cookie;HttpOnly");
// Header 에서 보내지는 데이터는...
HTTP/1.0 200 OK
Content-type: text/html
Set-Cookie: some=cookie;max-age=1000;path=/;HttpOnly
Set-Cookie: next=cookie
Set-Cookie: nnext=cookie;HttpOnly
(content of page)
```/
Set-Cookie header 는 여러개가 있을 수 있는듯.
그런데 쿠키란 놈 보안에 너무 취약한거 아닌가? Domain (url) 별로 따로 cookie 를 저장하고, 이 domain 에 접속할때에만 이 cookie 를 그 domain server 에 쏘는 것이긴한데, XSS 같은 것들 이용해서 다른 도메인의 cookie 도 쉽게 빼낼수 있다는거 같은데.... 민감한 정보는 저장해 놓으면 안될듯.
그런데 로그인 유지하는거랑 브라우저를 껐다 켰을때도 기억해서 다시 로그인 시켜주는 기능은 cookie 를 쓰는거 같긴한데 어떻게 보안 문제를 해결하는거지???
HttpOnly option 도 있는거 같던데, javascript 에서는 이런 HttpOnly cookie 를 생성할수도 없는듯? (From : A HttpOnly cookie means that it's not available to scripting languages like JavaScript. So there's in JavaScript absolutely no API available to get/set the HttpOnly attribute of the cookie, as that would otherwise defeat the meaning of HttpOnly.)
이 type 의 cookie 는 server 에서 "Set-Cookie" header 를 붙여서만 생성할 수 있는듯. 이거 이용해서 보안문제를 어느정도 해결하는구나. 뭐 이런것도 bypass 가 존재하는것 같기도 하지만 , 꾸준히 업데이트 해서 해결하고 있는 중인듯. 뭐 공격하는 쪽도 꾸준히 방법을 찾긴 하겠지만...
뭐 XSS (Cross Site Script) 같은 방법이 아니라 아예 사용자 컴퓨터/스마트폰을 해킹해 놨다던가 통신 중간과정에서 가로챈다던가 하는 방법을 시도한다면 이런 방식으로는 해킹을 못막을거 같긴 하다. (이런 방법은 전체 사용자를 터는게 아니라 특정 사용자를 타겟 잡아서 그 사람이 쓰는 컴퓨터/스마트폰이나 통신망에 접근해야 하는거라 개인이 보안에 신경써야 하는 부분일지도...)
http://stackoverflow.com/questions/4773609/what-is-a-relatively-secure-way-of-using-a-login-cookie,
http://jaspan.com/improved_persistent_login_cookie_best_practice,
http://fishbowl.pastiche.org/2004/01/19/persistent_login_cookie_best_practice/,
http://stackoverflow.com/questions/1062963/how-do-browser-cookie-domains-work
## Other local storage API
Cookie 는 항상 server 로 보내지는 자료라서 용량이 크면 안되고 (보통 4 Kbyte 정도로 제한이 있는듯), server 에서 굳이 쓸 자료가 아니라면 쓸데없이 통신용량만 크게 만들기도 하기 때문에 다른 local storage API 가 유용하게 쓰일때도 많은데...
최근에 localStorage 라는 window.localStorage (read-only property) 가 대부분의 browser 에 구현되었다는듯? .
## Tistory (티스토리) 에 로그인 한 상태인지 로그아웃 한 상태인지 cookie 로 알아내는 방법.
작성중.
```[.scrollable]
// 티스토리에서만 로그아웃 했을때.
// Printing all cookies before deleting.
__T_ : 1
REACTION_GUEST : 717e9af107d75cd4b4d0f6f95a9cc7c2cb7e7509
adfit_sdk_id : 868e6ef5-c465-4bd3-8ede-06d77b3e8ac9
_ga_J6J4DYK8ZE : GS1.1.1685208498.2.0.1685208498.0.0.0
_gid : GA1.2.1108358244.1685335121
_ga_GXNF57DKBV : GS1.1.1685335117.1.1.1685335194.0.0.0
_ga_XTF2JZHP53 : GS1.1.1685335126.1.1.1685335194.0.0.0
_ga_58F0SSR83N : GS1.1.1685335307.1.1.1685335361.6.0.0
_ga_Z6RR16MYPK : GS1.1.1685410847.1.1.1685411243.0.0.0
FCNEC : [["AKsRol-l0lDBDdS0JXdL30LXg6jJ9Chu2c8R0Mg2Y90ONEwMftctZ8L2AU13ElYjboUrS_VJpP0LKgLQB3RDWKXCbqn3jCiJKuGhsmgEGLtEDjGjjwdWTq5dGw7k-7kTxQh99yXBH4tRmHLABtkJ1iis1LUHjym5qA=="],null,[]]
_ga_BRF81BBF84 : GS1.1.1685412886.1.1.1685413184.0.0.0
_ga : GA1.2.369709155.1685171162
_ga_DM7ZZZ4XER : GS1.1.1685415642.1.0.1685416522.0.0.0
__gads : ID=2d75c1b61fe53107-228c2cc4c3e000e8:T=1685012399:RT=1685443539:S=ALNI_MbIOx7NRqpmuLqCaxlNH8Bqw3UsXA
__gpi : UID=00000c325c64b491:T=1685012399:RT=1685443539:S=ALNI_MYV1h8mBHBbtrrY0EijnOmyEc1kOQ
// 티스토리에 로그인 했을때.
// Printing all cookies before deleting.
__T_ : 1
adfit_sdk_id : 868e6ef5-c465-4bd3-8ede-06d77b3e8ac9
_ga_J6J4DYK8ZE : GS1.1.1685208498.2.0.1685208498.0.0.0
_gid : GA1.2.1108358244.1685335121
_ga_GXNF57DKBV : GS1.1.1685335117.1.1.1685335194.0.0.0
_ga_XTF2JZHP53 : GS1.1.1685335126.1.1.1685335194.0.0.0
_ga_58F0SSR83N : GS1.1.1685335307.1.1.1685335361.6.0.0
_ga_Z6RR16MYPK : GS1.1.1685410847.1.1.1685411243.0.0.0
FCNEC : [["AKsRol-l0lDBDdS0JXdL30LXg6jJ9Chu2c8R0Mg2Y90ONEwMftctZ8L2AU13ElYjboUrS_VJpP0LKgLQB3RDWKXCbqn3jCiJKuGhsmgEGLtEDjGjjwdWTq5dGw7k-7kTxQh99yXBH4tRmHLABtkJ1iis1LUHjym5qA=="],null,[]]
_ga_BRF81BBF84 : GS1.1.1685412886.1.1.1685413184.0.0.0
_ga : GA1.2.369709155.1685171162
_ga_DM7ZZZ4XER : GS1.1.1685415642.1.0.1685416522.0.0.0
__gads : ID=2d75c1b61fe53107-228c2cc4c3e000e8:T=1685012399:RT=1685443539:S=ALNI_MbIOx7NRqpmuLqCaxlNH8Bqw3UsXA
__gpi : UID=00000c325c64b491:T=1685012399:RT=1685443539:S=ALNI_MYV1h8mBHBbtrrY0EijnOmyEc1kOQ
```/
차이나는건 REACTION_GUEST 뿐임. 이걸로 check 하면 될듯.
## RRA
- tools.ietf.org - RFC 6265 - HTTP State Management Mechanism, 2011-04
// HTTP Cookie 와 Set-Cookie header fields 에 대한 규약인듯? 문서가 구식 스타일로 되어 있어서 읽기 편하지는 않은듯. 그래도 이 규약을 바탕으로 브라우저들이 cookie 를 구현해 놓은듯하니 최종 reference 로 생각하면 될듯. - NCZ Online - HTTP cookies explained, 2009-05-05, by Nicholas C. Zakas;
and NCZ Online - Cookies and security, 2009-05-12, by Nicholas C. Zakas
// 꽤나 자세하게 cookie 에 대해 설명되어 있음. 꼭 읽어보시길 추천. MDN 문서보다 더 자세한듯도... - MDN - Web security
- owasp.org - HttpOnly
// Wiki 랑 거의 똑같은데 이건 뭔 사이트지? Cookie 의 HttpOnly 관련 설명이 있음. - Stack Overflow - Set a cookie to HttpOnly via Javascript, 2013-02-04, asked by Robert P., answered by BalusC
- natexim.com - How to Bypass HttpOnly, 2013-09-10, by Natexim
// Apache 2.2.22 이전 version 에서의 문제였던거 같음. "The versions 2.2.x to Apache 2.2.21 are vulnerable, in fact when sending malformed HTTP request, Apache returns in response to an error 400 (Bad Request), to the delight of hackers, this response contains HTTP headers including Cookies with the HttpOnly flag."
// 고쳐졌다는거 같긴 함. - JAVA SE 8 API - Class java.net.HttpCookie
- MDN :: Web - API - Window - localStorage, and MDN :: Web - API - Web Storage API - Using the Web Storage API
Cookie
Web security and HttpOnly option
Local storage API
Etc. (Cookie for log in | sign in)
728x90
반응형
'[IT/Programming] > HTML related' 카테고리의 다른 글
| Getting Data from Google Spreadsheet or Excel (1) | 2024.02.09 |
|---|---|
| Getting html of container including the container itself (0) | 2024.02.06 |
| 구글 크롬 브라우저 캐시 지우기 및 강력 새로고침 하는 방법 (2) | 2024.02.04 |
| 구글 검색 바로 할 수 있게 input 및 button 만들기 (1) | 2023.12.28 |
| Parent DOM (Document Object Model) 이 hidden 일 때, child element 가 update 되면 hidden 이 풀릴 때 해결법 (2) | 2023.12.03 |
| 브라우저에서 자동 비밀번호 완성 (Auto password completion) 일 때, 이를 파악해서 바로 로그인 시켜주는 방법 (2) | 2023.12.01 |
| imgur - Embed album (5) | 2023.11.28 |