Linux | Red Hat Certified | IT Technology | Operations Engineer
👇 Join our technical exchange QQ group with the note 【Official Account】 for faster access
1 -> Introduction to HTTP Cookies
1.1 -> Definition
HTTP Cookies (also known as web cookies, browser cookies, or simply cookies) are small pieces of data sent from a server to a user’s browser and stored on the browser. They are sent back to the same server with subsequent requests, allowing the server to identify whether the requests come from the same browser, such as maintaining user login status and recording user preferences.
1.2 -> How They Work
When a user first visits a website, the server sets the Set-Cookie field in the HTTP response header to send a cookie to the user’s browser.
The browser stores the cookie locally (usually by domain).
In subsequent requests, the browser automatically includes the cookie in the HTTP request header, sending the previously stored cookie information back to the server.
1.3 -> Types
Session Cookies: These expire when the browser is closed.
Persistent Cookies: These have a specific expiration date or duration and can exist across multiple browser sessions.
If a cookie is a persistent cookie, it is essentially a file related to the browser stored in a specific directory. However, directly viewing these files may show garbled or unreadable content, as cookie files are usually stored in binary or SQLite format. Generally, you can view them directly in the corresponding options of the browser.
Similar to the following method:
1.4 -> Security
Since cookies are stored on the client-side, there is a risk of tampering or theft.
Uses
User authentication and session management (most important)
Tracking user behavior
Caching user preferences, etc.
For example, in Chrome browser, you can directly access: chrome://settings/cookies
2 -> Understanding Cookies
HTTP has a header option: Set-Cookie, which can be used to set cookie values in the browser.
This is added in the HTTP response header, and the client (such as a browser) retrieves and saves the cookie.
2.1 -> Basic Format
Set-Cookie: <name>=<value> where: <name> is the name of the cookie, <value> is the value of the cookie.Complete Set-Cookie
Set-Cookie: username=zzl; expires=Thu, 5 Dec 2024 12:00:00 UTC; path=/; domain=.example.com; secure; HttpOnlyThe time format must comply with RFC 1123 standards, specific format examples:Tue, 01 Jan 2030 12:34:56 GMT or UTC (recommended).
About time explanation
Tue: Tuesday (abbreviation for the day of the week), : comma separator 01: date (two-digit representation) Jan: January (abbreviation for the month) 2030: year (four-digit) 12:34:56: time (hours, minutes, seconds) GMT: Greenwich Mean Time (abbreviation for time zone)2.2 -> GMT vs UTC
GMT (Greenwich Mean Time) and UTC (Coordinated Universal Time) are two different time standards, but they are very close in most cases and are often confused. Here is a simple explanation and distinction between the two:
1. GMT (Greenwich Mean Time):
GMT is the abbreviation for Greenwich Mean Time, which is the world time standard based on the Greenwich area in London, England.
GMT is not affected by daylight saving time or other factors and is commonly used in maritime, aviation, scientific, and astronomical fields.
The calculation of GMT is based on the Earth’s rotation and revolution.
2. UTC (Coordinated Universal Time):
UTC stands for Coordinated Universal Time, which is the standard time formulated and maintained by the International Telecommunication Union (ITU).
UTC is calculated based on atomic clocks rather than the Earth’s rotation, making it more accurate than GMT. It is said that the world’s most precise atomic clock has an error of only one second over 5 billion years.
UTC is the current time standard, and most global networks and software systems use it as the standard time.
The English full names and related information for GMT and UTC are as follows:
1. GMT (Greenwich Mean Time)
Full English name: Greenwich Mean Time
GMT refers to the standard time of the Royal Observatory in Greenwich, located in the suburbs of London, England, because the prime meridian is defined as the longitudinal line that passes through there. Theoretically, noon Greenwich Mean Time is the time when the sun crosses the Greenwich meridian.
However, it is worth noting that the Earth’s rotation is somewhat irregular and is slowly decelerating. Therefore, Greenwich Mean Time is no longer used as the standard time.
2. UTC (Coordinated Universal Time)
Full English name: Coordinated Universal Time
UTC is the main global time standard based on the length of an atomic second, aiming to be as close as possible to Greenwich Mean Time.
UTC is widely used in computer networks, aerospace, and other fields because it provides a very accurate and reliable time reference.
In summary, both GMT and UTC have been important international time standards, but due to the irregularity of the Earth’s rotation and the precision of atomic clocks, UTC has become the global standard time, while GMT is more often used as a historical and geographical reference.
Differences:
Calculation method: GMT is based on the Earth’s rotation and revolution, while UTC is based on atomic clocks.
Accuracy: Since UTC is based on atomic clocks, it is more accurate than GMT, which is based on the Earth’s rotation.
In practical use, the difference between GMT and UTC is usually small, and they can often be used interchangeably. However, in situations requiring high-precision time measurement, such as scientific research and network communication, UTC is the more accurate choice.
Explanation of Other Optional Attributes
expires=<date> [to be verified]: Sets the expiration period/time for the cookie. If this attribute is not specified, the cookie defaults to a session cookie, which expires when the browser is closed.
path=<some_path> [to be verified]: Restricts which paths the cookie is sent to the server. The default is the path that set it.
domain=<domain_name>: Specifies which hosts can receive the cookie. The default is the host that set it.
secure: The cookie is only sent when using HTTPS protocol. This helps prevent cookies from being intercepted over insecure HTTP connections.
HttpOnly: Marks the cookie as HttpOnly, meaning that the cookie cannot be accessed by client-side scripts (like JavaScript). This helps prevent cross-site scripting attacks (XSS).
The following is a concise introduction to the Set-Cookie header field
Attribute Value Description username zzl This is the name and value of the cookie, identifying the username as "zzl". expires Thu, 5 Dec 2024 12:00:00 UTC Specifies the expiration time of the cookie. In this example, the cookie will expire after 12:00:00 UTC on December 5, 2024. path / Defines the scope of the cookie. The root path is set to /, meaning the cookie can be used for all paths under the .example.com domain. domain .example.com Specifies which domains can receive this cookie. The dot prefix (.) indicates all subdomains are included. secure - Indicates that the cookie can only be sent over HTTPS protocol, not over HTTP, increasing security. HttpOnly - Prevents client-side scripts (like JavaScript) from accessing this cookie, helping to prevent cross-site scripting attacks (XSS).Note:
Each cookie attribute is separated by a semicolon (;) and a space ( ). The name and value are separated by an equal sign (=). If a cookie's name or value contains special characters (such as spaces, semicolons, commas, etc.), URL encoding is required.3 -> Cookie Lifecycle
If the expires attribute is set, the cookie will expire after the specified date/time.
If the expires attribute is not set, the cookie defaults to a session cookie, which expires when the browser is closed.
3.1 -> Security Considerations
Security considerations
Using the secure flag can ensure that cookies are only sent over HTTPS connections, thereby enhancing security. Using the HttpOnly flag can prevent client-side scripts (like JavaScript) from accessing cookies, thus preventing XSS attacks. By properly setting the format and attributes of Set-Cookie, the security, effectiveness, and accessibility of cookies can be ensured to meet the needs of web applications.3.2 -> Security Testing Cookies
Comm.hpp HttpProtocol.hpp InetAddr.hpp LockGuard.hpp Log.hpp Main.cc Makefile Socket.hpp TcpServer.hpp Thread.hpp ThreadPool.hpp3.2.1 -> Testing Cookie Writing to Browser
3.2.2 -> Testing Automatic Submission
Refresh the browser, and the recently written cookie will be automatically submitted to the server.
3.2.3 -> Testing Expiration Time Writing
You need to form a unified standard time in UTC; the following is C++ code.
std::string GetMonthName(int month){ std::vector<std::string> months = { "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" }; return months[month];}std::string GetWeekDayName(int day){ std::vector<std::string> weekdays = { "Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat" }; return weekdays[day];}std::string ExpireTimeUseRfc1123(int t) // Seconds-level future UTC time{ time_t timeout = time(nullptr) + t; struct tm* tm = gmtime(&timeout); // Cannot use localtime here because localtime includes the timezone by default. gmtime gets the UTC time char timebuffer[1024]; // Time format: expires=Thu, 18 Dec 2024 12:00:00 UTC snprintf(timebuffer, sizeof(timebuffer), "%s, %02d %s %d %02d:%02d:%02d UTC", GetWeekDayName(tm->tm_wday).c_str(), tm->tm_mday, GetMonthName(tm->tm_mon).c_str(), tm->tm_year + 1900, tm->tm_hour, tm->tm_min, tm->tm_sec ); return timebuffer;}
3.2.4 -> Testing Path
Submit to a non-/a/b path
For example: http://8.137.19.140:8888/a/x For example: http://8.137.19.140:8888/ For example: http://8.137.19.140:8888/x/y
Submit to the /a/b path
Core code:
class Http{private: std::string GetMonthName(int month){ std::vector<std::string> months = { "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" }; return months[month]; } std::string GetWeekDayName(int day){ std::vector<std::string> weekdays = { "Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat" }; return weekdays[day]; } std::string ExpireTimeUseRfc1123(int t) // Seconds-level future UTC time{ time_t timeout = time(nullptr) + t; struct tm* tm = gmtime(&timeout); // Cannot use localtime here because localtime includes the timezone by default. gmtime gets the UTC time char timebuffer[1024]; // Time format: expires=Thu, 18 Dec 2024 12:00:00 UTC snprintf(timebuffer, sizeof(timebuffer), "%s, %02d %s %d %02d:%02d:%02d UTC", GetWeekDayName(tm->tm_wday).c_str(), tm->tm_mday, GetMonthName(tm->tm_mon).c_str(), tm->tm_year + 1900, tm->tm_hour, tm->tm_min, tm->tm_sec ); return timebuffer; }public: Http(uint16_t port) { _tsvr = std::make_unique<TcpServer>(port, std::bind(&Http::HandlerHttp, this, std::placeholders::_1)); _tsvr->Init(); } std::string ProveCookieWrite() // Prove that cookie can be written to the browser{ return "Set-Cookie: username=zhangsan;"; } std::string ProveCookieTimeOut(){ return "Set-Cookie: username=zhangsan; expires=" + ExpireTimeUseRfc1123(60) + ";"; // Make cookie expire in 1 min } std::string ProvePath(){ return "Set-Cookie: username=zhangsan; path=/a/b;"; } std::string HandlerHttp(std::string request){ HttpRequest req; req.Deserialize(request); req.DebugHttp(); lg.LogMessage(Debug, "%s\n", ExpireTimeUseRfc1123(60).c_str()); HttpResponse resp; resp.SetCode(200); resp.SetDesc("OK"); resp.AddHeader("Content-Type: text/html"); //resp.AddHeader(ProveCookieWrite()); // Test if cookie is written and automatically submitted //resp.AddHeader(ProveCookieTimeOut()); // Test expiration time writing resp.AddHeader(ProvePath()); // Test path resp.AddContent("<html><h1>helloworld</h1></html>"); return resp.Serialize(); } void Run(){ _tsvr->Start(); } ~Http() {}private: std::unique_ptr<TcpServer> _tsvr;};4 -> What Problems Can Arise from Using Cookies Alone
Security Issues: Data in cookies is transmitted in plaintext, which means that during network transmission, the data may be intercepted or tampered with. For example, in shopping scenarios, if cookies contain sensitive information such as payment amounts, attackers can illegally modify the payment value before the cookie is sent back to the server. Additionally, sensitive information such as passwords stored locally may also be forcefully accessed by phishing website servers.
Privacy Issues: Some websites may use cookies to track user browsing behavior, which may involve user privacy issues. For example, some websites may record users’ browsing history through cookies for targeted advertising.
Data Integrity Issues: Since cookies are stored on the client-side, users can modify or delete cookies through browser settings, which may affect data integrity. For example, if users modify certain key information in cookies, it may prevent the server from correctly identifying the user’s identity or status.
Performance Issues: Cookies are attached to every HTTP request, which inadvertently increases network traffic, especially when the amount of cookie data is large, potentially impacting network performance.
Storage Limitations: Cookies typically have size limitations (generally around 4KB), which may not be sufficient for some complex storage needs. For example, if large amounts of user data or complex application state information need to be stored on the client-side, cookies may not meet the requirements.
To address these issues, cookies are usually used in conjunction with sessions and other technologies. Sessions store information by default in the server-side database table and only return a key to unlock the session (i.e., Session ID) to the browser, thereby improving data security and integrity to some extent while better managing user session status.
For course inquiries, add: HCIE666CCIE
↓ Or scan the QR code below ↓
What technical points and content would you like to see?
You can leave a message below to let us know!