Display incognito / chrome private browser history / chrome history :
-> run as administrator
-> ipconfig/displaydns
-> ipconfig/flushdns
How to see and DELETE your incognito history (step-by-step guides)
https://myactivity.google.com
-> Other Google Activity
-> Manage Activity
-> Not Saving Activity
How to recover deleted files: Quick and easy tips
Relation between sessions and cookies
Tech Pechu – ssl certificate
Cookie
A cookie is just a key-value pair that is stored in the user’s browser. A cookie is sent to your browser as part of the HTTP response that contains the web page you requested.
When your browser receives a cookie, it stores it, and sends it back to the server with every subsequent request it makes on the same website.
Because cookies are part of the HTTP request and response headers, they are somewhat limited in size.
Typical information stored in cookies:
- Session IDs (see below)
- Tracking IDs (Google Analytics, etc.)
- User preferences (preferred language or currency, etc.)
- For larger, or sensitive data, you typically store values in the session. The cookie is only there to identify the proper session.
A cookie can be configured to only live until the browser window is closed, or have a configurable lifetime (1 week, 1 month, 1 year, whatever). If you visit the website again during this period, your browser will send the cookie with every request.
Session
A session is a set of data that is stored on the server, usually as key-value pairs. A session is assigned a pseudo-random, secret ID that is usually stored in the user’s browser using a cookie, for example SESSID=abcdef123456789. The session ID typically matches the name of a file containing the session data on the server.
Sessions are usually short-lived, and automatically deleted if unused for some time (20 minutes or so).
Typical information stored in a session:
Example
Let’s say I visit a website for the first time. The website detects that I didn’t send a session cookie, so it creates a session for me. It creates a session file on the server, such as /tmp/sess_abcdef123456789.
Then it sends a cookie header with the HTTP response that contains the web page:
HTTP/1.1 200 OK
Set-Cookie: SESSID=abcdef123456789My browser stores this cookie. If I visit another page on the same server, my browser will send this cookie with the request:
GET /cart HTTP/1.1
Cookie: SESSID=abcdef123456789When receiving the second request, the server can check if there’s a session file with this ID, and use it to retrieve the session data.
Your web programming language will offer support for sessions, and should handle most of this complexity for you. You can usually directly use the session array/object, which will be already populated with the session data specific to the user visiting your website, and will be automatically saved if you update the session data; this should be totally transparent to you.
Session unlike cookie stores the data on the server. However, session information is stored in the user cookie
Session uses cookies to store information about yourself in the user’s browser. For example cookie SSID contains a session identifier, for which the server will understand what kind of session is tied to this user
The COOKIE resides on the client, i.e. the browser. The COOKIE is automatically passed with the request to the server, where the server uses the cookie to fetch any SESSION data that the server has stored for that client.
Security
When logging in a user to your website, always store the user ID in the session. Never trust a user ID stored in a cookie to load user data.
It’s very easy to forge a cookie. If you were to load user information based on a user ID stored in a cookie, it would be easy to change the user ID in this cookie to gain access to any user’s account on your website.
On the other hand, if you store the user ID in the session, which is assigned a pseudo-random session ID, it will be hard for an attacker to guess the session ID that is currently assigned to the user.
Browser cookies
- Cookie basics:
- The first time a browser connects with a particular server, there
are no cookies. - When the server responds it includes a Set-Cookie: header
that defines a cookie. - Each cookie is just a name-value pair.
- In the future whenever the browser connects with the same server, it
includes a Cookie: header containing the name and value,
which the server can use to connect related requests.
- The first time a browser connects with a particular server, there
- What’s in a cookie?
- Name and data.
- Data size limited by browsers (typically < 4 KB).
- A server can define multiple cookies with different names, but
browsers limit the number of cookies per server (around 50).
- Domain for this cookie: server, port (optional),
URL prefix (optional). The cookie is only included in
requests matching its domain. - Expiration date: browser can delete old cookies.
- Name and data.
Sessions
- Cookies are used by the server to implement sessions:
- A pool of data related to an active connection (one browser instance).
- Typically the cookie for an application contains an identifier
for a session. - Web frameworks like Rails do most of the work of managing
sessions and cookies:- Rails provides session, a hash-like object in which you can store
anything you like- Data will be available in all future requests from the same browser.
- Rails automatically checks for a session cookie at the start of each
request:- Cookie exists? use it to find session data
- No cookie? Create new session, new cookie
- End of each request: save session data where it can be found by
future requests.
- Rails provides session, a hash-like object in which you can store
- Managing session state:
- Approach #1: just keep state in main memory
- Approach #2: store session state in files on disk
- Approach #3: store session state in a database
- Most frameworks allow you to control session storage:
- Provide an object that saves and restores session data.
- Server must eventually delete stale session data.
- Sessions have numerous security issues, which we will discuss later.
HTTP Authentication Schemes
Authentication Scheme Name [Reference]
Basic [RFC7617]
Bearer [RFC6750]
Digest [RFC7616]
HOBA [RFC7486, Section 3]
Mutual [RFC8120]
Negotiate [RFC4559, Section 3]
OAuth [RFC5849, Section 3.5.1]
SCRAM-SHA-1 [RFC7804]
SCRAM-SHA-256 [RFC7804]
vapid [RFC 8292, Section 3]
Here’s how to use the Set-Cookie header in various server-side applications (Node.JS):
response.setHeader(name, value)
Sets a single header value for implicit headers. If this header already exists in the to-be-sent headers, its value will be replaced. Use an array of strings here to send multiple headers with the same name.
Example:
response.setHeader('Content-Type', 'text/html');or
response.setHeader('Set-Cookie', ['type=ninja', 'language=javascript']);Attempting to set a header field name or value that contains invalid characters will result in a TypeError being thrown.
When headers have been set with response.setHeader(), they will be merged with any headers passed to response.writeHead(), with the headers passed to response.writeHead() given precedence.
// returns content-type = text/plain
const server = http.createServer((req, res) => {
res.setHeader('Content-Type', 'text/html');
res.setHeader('X-Foo', 'bar');
res.writeHead(200, { 'Content-Type': 'text/plain' });
res.end('ok');
});Other ways to store information in the browser
1.Web Storage API
- window.sessionStorage
- -window.localStorage
- IndexedDB API(Making PWAs work offline with Service workers)
The two mechanisms within Web Storage are as follows:
sessionStorage – maintains a separate storage area for each given origin that’s available for the duration of the page session (as long as the browser is open, including page reloads and restores).
localStorage does the same thing, but persists even when the browser is closed and reopened.
These mechanisms are available via the Window.sessionStorage and Window.localStorage properties — invoking one of these will create an instance of the Storage object, through which data items can be set, retrieved, and removed. A different Storage object is used for the sessionStorage and localStorage for each origin — they function and are controlled separately.
So, for example, initially calling localStorage on a document will return a Storage object; calling sessionStorage on a document will return a different Storage object. Both of these can be manipulated in the same way, but separately.
1.sessionStorage – data in sessionStorage is cleared when the page session ends.
- -A page session lasts as long as the browser is open, and survives over page reloads and restores.
- -Opening a page in a new tab or window creates a new session with the value of the top-level browsing context, which differs from how “session cookies” work.
- -Opening multiple tabs/windows with the same URL creates sessionStorage for each tab/window.
- -Closing a tab/window ends the session and clears objects in sessionStorage.
Data stored in sessionStorage is specific to the protocol of the page. In particular, data stored by a script on a site accessed with HTTP (e.g., http://example.com) is put in a different sessionStorage object from the same site accessed with HTTPS (e.g., https://example.com).
The keys and the values are always in the UTF-16 DOMString format, which uses two bytes per character. As with objects, integer keys are automatically converted to strings.
2.localStorage – data stored in localStorage has no expiration time.
-Data in a localStorage object created in a “private browsing” or “incognito” session is cleared when the last “private” tab is closed..
3.IndexedDB API – IndexedDB is a JavaScript-based object-oriented database. IndexedDB lets you store and retrieve objects that are indexed with a key;You need to specify the database schema, open a connection to your database, and then retrieve and update data within a series of transactions.IndexedDB originally included both synchronous and asynchronous APIs. The synchronous API was intended for use only with Web Workers but was removed from the spec because it was unclear whether it was needed.
Cross-origin data storage access :
Access to data stored in the browser such as Web Storage and IndexedDB are separated by origin. Each origin gets its own separate storage, and JavaScript in one origin cannot read from or write to the storage belonging to another origin.
HTTP authentication
The OAuth 2.0 Authorization Framework: Bearer Token Usage
The ‘Basic’ HTTP Authentication Scheme
Cookies and Sessions
4 Most Used REST API Authentication Methods
-
1. HTTP Authentication Schemes (Basic & Bearer)
- Basic Authentication
- Bearer Authentication
- 2. API Keys
- 3. OAuth (2.0)
-
4. OpenID Connect
- JWT
JWT Authentication Flow with Refresh Tokens in ASP.NET Core Web API
- 1.Click-jacking
- 2.Cross-site request forgery (CSRF)
- 3.Cross-site scripting (XSS)
- 4.Man-in-the-middle (MitM)
- 5.Session hijacking
Encryption – In cryptography, encryption is the conversion of cleartext into a coded text or ciphertext. A ciphertext is intended to be unreadable by unauthorized readers.
Encryption is a cryptographic primitive: it transforms a plaintext message into a ciphertext using a cryptographic algorithm called a cipher. Encryption in modern ciphers is performed using a specific algorithm and a secret, called the key. Since the algorithm is often public, the key must stay secret if the encryption stays secure.
Without knowing the secret, the reverse operation, decryption, is mathematically hard to perform. How hard depends on the security of the cryptographic algorithm chosen and evolves with the progress of cryptanalysis.
Decryption – In cryptography, decryption is the conversion of ciphertext into cleartext.
Decryption is a cryptographic primitive: it transforms a ciphertext message into plaintext using a cryptographic algorithm called a cipher. Like encryption, decryption in modern ciphers is performed using a specific algorithm and a secret, called the key. Since the algorithm is often public, the key must stay secret if the encryption stays secure.
Decryption is the reverse of encryption and if the key stays secret, decryption without knowing the specific secret, decryption is mathematically hard to perform. How hard depends on the security of the cryptographic algorithm chosen and evolves with the progress of cryptanalysis.