JavaScript cookies如何發送到瀏覽器，以及它們如何驗證？

我知道，當cookies通過服務器語言設置它們從服務器發送到瀏覽器時，它通過http或ssl或https發生。那麼javascript cookie去哪裏了，一旦腳本：「document.cookie =」，在瀏覽器中執行，並通過哪個協議/傳輸方案？JavaScript cookies如何發送到瀏覽器，以及它們如何驗證？

來源

2011-12-07 Sam Adamsh

如果您正在尋找如何在服務器和客戶端之間交換cookie，您可以查看一下：http：/ /en.wikipedia。org/wiki/HTTP_cookie＃Implementation – HoLyVieR

這個我明白了，但是整個javascript cookie是很奇怪的，因爲如果它被設置在瀏覽器中而不是服務器/主機上，並且它使用一些隨機邏輯來設置，爲什麼瀏覽器不能只需發送任何cookie就可以了 –

瀏覽器僅僅發送所有的過期HTTP cookies（不SSL有關！）在其「餅乾罐」符合傳出HTTP請求的域（也可能是路徑）其中：在「曲奇一次jar「，cookie將自動發送給所有將來的請求。通過Set-Cookie標頭從服務器發送的cookie會自動添加到「cookie jar」中，但如前所述，cookie也可以從JavaScript *中添加。在這兩種情況下，客戶端/瀏覽器通過Cookie頭將cookie 返回發送到服務器。

這就是爲什麼像所有用戶輸入，餅乾應謹慎對待和必須備份/驗證對「安全敏感」操作每個請求。通常使用session cookie，通過的nonce來提供這種保護，因爲它們是（或應該是）大型密碼聽起來的隨機數字，它們永遠不會被重複使用並且是不可預測的。

然後，會話cookie /隨機數僅僅是查找包含諸如「用戶ID」之類的狀態的持久存儲（通常是數據庫）的查找。它是分離和隨機特性的組合，它可以防止客戶根據cookie的值選擇他們自己的「用戶ID」，但是...

...「安全性」是一個複雜的主題，會話cookie 不需要可以防止所有惡意JavaScript，例如使用CSRF或類似的惡意JavaScript，並且它們對中間人攻擊或竊聽沒有幫助，並且只對重放攻擊有效，因爲它們的到期時間。驗證cookie的另一個（經常被忽視的）方法是使用防篡改驗證散列，例如ASP.NET使用查看狀態。

一味使用的服務器程序/信任LoggedInUserId或IsAdministrator餅乾的確會非常不安全的設計！ :)

快樂編碼。

*所有最近瀏覽器都支持HTTPOnly餅乾，不能讀/由JavaScript覆蓋：他們仍然可以通過其他程序被欺騙，但是！（有些瀏覽器只在最近纔得到支持：例如Chrome 12，iOS4，Safari 5.）

來源

2011-12-07 03:05:33

通過Javascript設置的Cookie不需要傳輸：它們由在瀏覽器中運行的代碼設置，並且它們也由瀏覽器（如所有Cookie）存儲。您可以將其視爲瀏覽器寫下自己的提醒。

來源

2011-12-07 02:40:38 Jon

@AmirRaminfar：我想你誤會了。 – Jon

但是一旦它們被瀏覽器存儲，我認爲它們將以某種方式被服務器/主機使用。因此，沒有任何cookie可以真正「設置」，並且瀏覽器理論上可以開始發送任何它想要的cookie值，並且主機會認爲它是合法的，只要它是第一個。它是否正確？ –

@SamAdams是的，客戶可能會欺騙cookie。這就是爲什麼像所有的用戶輸入一樣，應該謹慎對待，除非支持附加的*可驗證的*信息 - 例如服務器隨機會話或防篡改/重放校驗哈希等。盲目使用/受信任的'LoggedInUserId'的服務器程序確實設計得非常糟糕！ – 2011-12-07 02:59:57

JavaScript cookies如何發送到瀏覽器，以及它們如何驗證？

回答

相關問題