HttpOnly 쿠키는 AJAX 요청과 어떻게 작동합니까?

HttpOnly 쿠키는 AJAX 요청과 어떻게 작동합니까?

---

쿠키를 기반으로 한 액세스 제한이있는 사이트에서 AJAX를 사용하는 경우 JavaScript는 쿠키에 액세스해야합니다. HttpOnly 쿠키는 AJAX 사이트에서 작동합니까?

편집 : Microsoft는 HttpOnly가 지정된 경우 쿠키에 대한 JavaScript 액세스를 허용하지 않음으로써 XSS 공격을 방지하는 방법을 만들었습니다. FireFox는 나중에 이것을 채택했습니다. 그래서 내 질문은 : 당신이 StackOverflow와 같은 사이트에서 AJAX를 사용하는 경우 HTTP 전용 쿠키가 옵션입니까?

편집 2 : 질문 2. HttpOnly의 목적이 쿠키에 대한 JavaScript 액세스를 방지하고 XmlHttpRequest 객체를 통해 JavaScript를 통해 쿠키를 검색 할 수 있다면 HttpOnly의 요점은 무엇 입니까?

편집 3 : 다음은 Wikipedia의 인용문입니다.

브라우저가 이러한 쿠키를 수신하면 다음 HTTP 교환에서 평소와 같이 쿠키를 사용해야하지만 클라이언트 측 스크립트에 표시하지 않아야합니다. [32] HttpOnly플래그는 모든 표준의 일부가 아니며, 모든 브라우저에서 구현되지 않습니다. 현재 XMLHTTPRequest를 통해 세션 쿠키를 읽거나 쓰는 것을 막을 수는 없습니다. [33].

나는이 이해 document.cookie는 Http 만을 사용할 때 차단됩니다. 그러나 XMLHttpRequest 객체에서 쿠키 값을 계속 읽을 수있어 XSS를 허용합니다. HttpOnly는 어떻게 당신을 더 안전한가요? 쿠키를 본질적으로 읽기 전용으로 만들었습니까?

귀하의 예에서는 귀하의에 쓸 수 없지만 document.cookieXMLHttpRequest 객체를 사용하여 쿠키를 훔쳐 내 도메인에 게시 할 수 있습니다.

<script type="text/javascript">
    var req = null;
    try { req = new XMLHttpRequest(); } catch(e) {}
    if (!req) try { req = new ActiveXObject("Msxml2.XMLHTTP"); } catch(e) {}
    if (!req) try { req = new ActiveXObject("Microsoft.XMLHTTP"); } catch(e) {}
    req.open('GET', 'http://stackoverflow.com/', false);
    req.send(null);
    alert(req.getAllResponseHeaders());
</script>

편집 4 : 죄송합니다. XMLHttpRequest를 StackOverflow 도메인으로 보낸 다음 getAllResponseHeaders () 결과를 문자열에 저장하고 쿠키를 정규식으로 저장 한 다음 외부 도메인에 게시 할 수 있음을 의미했습니다. Wikipedia와 ha.ckers가 이것에 관해 나와 동의하는 것처럼 보이지만, 나는 다시 교육 받기를 원할 것입니다 ...

최종 편집 : 아, 분명히 두 사이트 모두 잘못 되었습니다 . 실제로 FireFox 의 버그입니다 . 실제로 IE6 & 7은 현재 HttpOnly를 완벽하게 지원하는 유일한 브라우저입니다.

내가 배운 모든 것을 되풀이하려면 :

• HttpOnly는 IE7 및 FireFox에서 document.cookie에 대한 모든 액세스를 제한합니다 (다른 브라우저에 대해서는 확실하지 않음)
• HttpOnly는 IE7의 XMLHttpObject.getAllResponseHeaders ()에있는 응답 헤더에서 쿠키 정보를 제거합니다.
• XMLHttpObjects는 원래 도메인에만 제출 될 수 있으므로 쿠키의 도메인 간 게시는 없습니다.

편집 :이 정보는 더 이상 최신 정보가 아닙니다.

---

예,이 기능에는 HTTP 전용 쿠키가 적합합니다. 서버에 대한 XmlHttpRequest의 요청이 계속 제공됩니다.

스택 오버플로의 경우 쿠키는 XmlHttpRequest 요청의 일부로 자동 제공됩니다. Stack Overflow 인증 공급자의 구현 세부 정보를 모르지만 해당 쿠키 데이터는 자동으로 "투표"컨트롤러 방법보다 낮은 수준에서 신원을 확인하는 데 사용됩니다.

더 일반적으로 AJAX 에는 쿠키가 필요 하지 않습니다. XmlHttpRequest 지원 (또는 구형 브라우저의 iframe 원격)도 기술적으로 필요한 모든 것입니다.

그러나 AJAX 지원 기능에 보안을 제공하려는 경우 기존 사이트와 동일한 규칙이 적용됩니다. 각 요청 뒤에있는 사용자를 식별 할 수있는 방법이 필요하며 쿠키는 거의 항상 그 목적을위한 수단입니다.

귀하의 예에서는 document.cookie에 쓸 수 없지만 XMLHttpRequest 객체를 사용하여 쿠키를 훔쳐 내 도메인에 게시 할 수 있습니다.

XmlHttpRequest는 도메인 간 요청을하지 않습니다 (정확한 이유 때문에).

일반적으로 iframe 원격 또는 JSONP를 사용하여 쿠키를 도메인에 보내는 스크립트를 삽입 할 수 있지만 쿠키는 액세스 할 수 없으므로 쿠키 만 다시 보호합니다.

서버 쪽에서 StackOverflow.com을 손상시키지 않으면 쿠키를 훔칠 수 없습니다.

편집 2 : 질문 2. Http-Only의 목적이 쿠키에 대한 JavaScript 액세스를 방지하는 것인데 XmlHttpRequest 객체를 통해 JavaScript를 통해 쿠키를 검색 할 수 있다면 Http-Only의 요점은 무엇입니까?

이 시나리오를 고려하십시오.

• JavaScript 코드를 페이지에 삽입 할 수있는 방법을 찾았습니다.
• Jeff가 페이지를로드하고 악의적 인 JavaScript가 쿠키를 수정하여 쿠키를 수정합니다.
• Jeff는 귀하의 질문에 대한 훌륭한 답변을 제출합니다.
• 그는 쿠키 데이터 대신 쿠키 데이터를 제출하기 때문에 대답이 내 것이됩니다.
• 당신은 "나의"별의 대답을 투표하십시오.
• 내 실제 계정이 포인트를 얻습니다.

HTTP 전용 쿠키를 사용하면 두 번째 단계를 수행 할 수 없으므로 XSS 시도가 실패합니다.

편집 4 : 죄송합니다. XMLHttpRequest를 StackOverflow 도메인으로 보낸 다음 getAllResponseHeaders () 결과를 문자열에 저장하고 쿠키를 정규식으로 저장 한 다음 외부 도메인에 게시 할 수 있음을 의미했습니다. Wikipedia와 ha.ckers가 이것에 관해 나와 동의하는 것처럼 보이지만, 나는 다시 교육 받기를 원할 것입니다 ...

맞습니다. 그래도 세션 도용이 가능합니다. 그것은 XSS가 당신을 해킹하더라도 XSS를 성공적으로 실행할 수있는 사람들의 무리를 상당히 얇게 만듭니다.

그러나 예제 시나리오로 돌아 가면 HTTP 전용 이 클라이언트 쿠키 수정에 의존하는 XSS 공격을 성공적으로 차단하는 위치를 확인할 수 있습니다 (드문 경우는 아님).

It boils down to the fact that a) no single improvement will solve all vulnerabilities and b) no system will ever be completely secure. HTTP-Only is a useful tool in shoring up against XSS.

Similarly, even though the cross domain restriction on XmlHttpRequest isn't 100% successful in preventing all XSS exploits, you'd still never dream of removing the restriction.

---

Not necessarily, it depends what you want to do. Could you elaborate a bit? AJAX doesn't need access to cookies to work, it can make requests on its own to extract information, the page request that the AJAX call makes could access the cookie data & pass that back to the calling script without Javascript having to directly access the cookies

---

Yes, they are a viable option for an Ajax based site. Authentication cookies aren't for manipulation by scripts, but are simply included by the browser on all HTTP requests made to the server.

Scripts don't need to worry about what the session cookie says - as long as you are authenticated, then any requests to the server initiated by either a user or the script will include the appropriate cookies. The fact that the scripts cannot themselves know the content of the cookies doesn't matter.

For any cookies that are used for purposes other than authentication, these can be set without the HTTP only flag, if you want script to be able to modify or read these. You can pick and choose which cookies should be HTTP only, so for example anything non-sensitive like UI preferences (sort order, collapse left hand pane or not) can be shared in cookies with the scripts.

I really like the HTTP only cookies - it's one of those proprietary browser extensions that was a really neat idea.

---

There's a bit more to this.

Ajax doesn't strictly require cookies, but they can be useful as other posters have mentioned. Marking a cookie HTTPOnly to hide it from scripts only partially works, because not all browsers support it, but also because there are common workarounds.

It's odd that the XMLHTTPresponse headers are giving the cookie, technically the server doesn't have to return the cookie with the response. Once it's set on the client, it stays set until it expires. Though there are schemes in which the cookie is changed with every request to prevent re-use. So you may be able to avoid that workaround by changing the server to not provide the cookie on the XMLHTTP responses.

In general though, I think HTTPOnly should be used with some caution. There are cross site scripting attacks where an attacker arranges for a user to submit an ajax-like request originating from another site, using simple post forms, without the use of XMLHTTP, and your browser's still-active cookie would authenticate the request.

If you want to be sure that an AJAX request is authenticated, the request itself AND the HTTP headers need to contain the cookie. Eg through the use of scripts or unique hidden inputs. HTTPOnly would hinder that.

Usually the interesting reason to want HTTPOnly is to prevent third-party content included on your webpage from stealing cookies. But there are many interesting reasons to be very cautious about including third-party content, and filter it aggressively.

---

Cookies are automatically handled by the browser when you make an AJAX call, so there's no need for your Javascript to mess around with cookies.

---

Therefore I am assuming JavaScript needs access to your cookies.

All HTTP requests from your browser transmit your cookie information for the site in question. JavaScript can both set and read cookies. Cookies are not by definition required for Ajax applications, but they are required for most web applications to maintain user state.

The formal answer to your question as phrased - "Does JavaScript need access to cookies if AJAX is used?" - is therefore "no". Think of enhanced search fields that use Ajax requests to provide auto-suggest options, for example. There is no need of cookie information in that case.

---

As clarification - from the server's perspective, the page that is requested by an AJAX request is essentially no different to a standard HTTP get request done by the user clicking on a link. All the normal request properties: user-agent, ip, session, cookies, etc. are passed to the server.

---

No, the page that the AJAX call requests has access to cookies too & that's what checks whether you're logged in.

You can do other authentication with the Javascript, but I wouldn't trust it, I always prefer putting any sort of authentication checking in the back-end.

---

Yes, cookies are very useful for Ajax.

Putting the authentication in the request URL is bad practice. There was a news item last week about getting the authentication tokens in the URL's from the google cache.

No, there is no way to prevent attacks. Older browsers still allow trivial access to cookies via javascript. You can bypass http only, etc. Whatever you come up with can be gotten around given enough effort. The trick is to make it too much effort to be worthwhile.

If you want to make your site more secure (there is no perfect security) you could use an authentication cookie that expires. Then, if the cookie is stolen, the attacker must use it before it expires. If they don't then you have a good indication there's suspicious activity on that account. The shorter the time window the better for security but the more load it puts on your server generating and maintaining keys.

참고URL : https://stackoverflow.com/questions/27972/how-do-httponly-cookies-work-with-ajax-requests