Asked  7 Months ago    Answers:  5   Viewed   16 times

I have two HTTP services running on one machine. I just want to know if they share their cookies or whether the browser distinguishes between the two server sockets.



The current cookie specification is RFC 6265, which replaces RFC 2109 and RFC 2965 (both RFCs are now marked as "Historic") and formalizes the syntax for real-world usages of cookies. It clearly states:

  1. Introduction


For historical reasons, cookies contain a number of security and privacy infelicities. For example, a server can indicate that a given cookie is intended for "secure" connections, but the Secure attribute does not provide integrity in the presence of an active network attacker. Similarly, cookies for a given host are shared across all the ports on that host, even though the usual "same-origin policy" used by web browsers isolates content retrieved via different ports.

And also:

8.5. Weak Confidentiality

Cookies do not provide isolation by port. If a cookie is readable by a service running on one port, the cookie is also readable by a service running on another port of the same server. If a cookie is writable by a service on one port, the cookie is also writable by a service running on another port of the same server. For this reason, servers SHOULD NOT both run mutually distrusting services on different ports of the same host and use cookies to store security sensitive information.

Tuesday, June 1, 2021
answered 7 Months ago

Yes, the SSL connection is between the TCP layer and the HTTP layer. The client and server first establish a secure encrypted TCP connection (via the SSL/TLS protocol) and then the client will send the HTTP request (GET, POST, DELETE...) over that encrypted TCP connection.

Tuesday, June 1, 2021
answered 7 Months ago

You have used this line -

 if (sessionCookie != null) {


. To ensure you receive new cookie everytime.

Seems like you have gone through same issue as I faced, check below link -

removeSessionCookie() issue of android (

it says that removeSessionCookie() is implemented in a thread, so whenever it is called; a thread starts and after your setCookie(url, cookieString); is called, it removes the new cookie you just set. So for some devices it works well as removeSessionCookie() is already executed, while, for some, it remove the cookie, and we get that problem.

by using SystemClock.sleep(500); , you just gave system to finish removeSessionCookie() first

I suggest you remove this removeSessionCookie(); as you are setting only one cookie, so it won't conflict with other cookies. Your code will work seamlessly.

Tuesday, August 3, 2021
K. Gl.
answered 4 Months ago

If it's medical data and you live in the United States, there is an excellent chance that access to it is subject to HIPAA regulations, including security requirements. You should review If you don't live in the United States, I would suggest that you could still point to HIPAA as relevant to the domain.

If your vendor tries to push back with an additional fee, say "Are you saying that you're not compliant with the relevant governmental standards? Golly, maybe you should provide us with complete documentation on your security and privacy standards, safeguards, and procedures. Because obviously if we got hit with a fine, we'd be coming after you. " (IANAL and all that.)

From a technical level, certainly the suggestion of an ethereal trace showing how easy it is to scavenge usernames and passwords should be eye-opening to your management. Given how trivially easy it is to sniff normal network traffic and how easy it is to use SSL for transport, the idea of a vendor pushing back on that as a "security enhancement" is outrageous.

Sunday, September 26, 2021
answered 3 Months ago

Welp, that's embarassing. Here's what my problem turned out to be.

  • When the user tried to visit an HTTPS site from an HTTP one, their request would start as HTTP
  • I would check their login credentials (which would fail, because the secure cookie wasn't there), then redirect them to HTTPS. My "require login" and "require HTTPS" systems were separate (a bad design now, but it was convenient in the bad old days where the login cookie wasn't secure)
  • I thought my secure cookie was being deleted because the Chrome cookie browser doesn't show secure cookies when the page being shown is HTTP. The cookies were there all along.
Wednesday, October 20, 2021
answered 2 Months ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :