- #Session hijacking code
- #Session hijacking password
In this case, user authentication does not result in the creation of an active session maintained on the server side. This means that each action carried out on the application is considered independent, as no “state” is kept in memory by the server. It should be noted that, depending on the technologies used, the application can be said to be “stateless”. In fact, this is used in particular in social engineering attacks, such as phishing, because it becomes possible to collect the users’ session after all authentication factors have been entered. Indeed, when a session is hijacked, it means that the user has completed the authentication phase. If session hijacking allows to get rid of the password, it also has the advantage (for an attacker) of getting rid of the multiple authentication factors.
#Session hijacking password
This mechanism is used to prevent an attacker from taking control of a user’s account based solely on the password (in the case of a data leak, for example).
#Session hijacking code
This can be, for example, a code sent by SMS or email.
Bypassing MFA: Multifactor authentication (abbreviated to MFA), involves requiring a second (or more) authentication factor when a user logs in. An attacker listening in on the network could therefore intercept these communications, and thus collect the users’ session IDs. Lack of TLS encryption (HTTPS): when the server does not implement encryption (platform in HTTP rather than HTTPS ), this means that communications between the user and the web platform are transmitted in clear text. If an attacker knows of such an ID, he/she can simply wait for a session to be attached to it and hijack it. This implementation flaw is called session fixation, because the ID is “fixed” before a session is even attached to it. However, it is sometimes possible to know in advance (before a user is authenticated) the ID that will be assigned to the user’s session after the user logs in. 
Session fixation: the session ID provided by the server to identify the user’s session must be random and robust, to prevent it from being guessed via brute force. XSS Exploitation: The XSS vulnerability, which consists of injecting malicious JavaScript code into an application, can be exploited to steal a user’s session ID (their session cookie, token or JWT). In the following chapter, we will see in practice four scenarios that correspond to common cases of session hijacking: There are several attacks that can be used to hijack a user session. What are the most common session hijacking attacks? Session hijacking therefore consists of stealing this ID in order to take possession of the active session. In other words, it is this ID that authenticates the user without the latter having to provide his identifiers. This ID is therefore crucial from a security point of view, as it allows a user to be identified and therefore to access his/her data and the platform’s functions. When the user performs actions on the platform, this ID, stored in his/her browser, will systematically be transmitted to the server so that it can identify the corresponding session. To refer to this session, the server gives the user a unique identifier (ID), usually a session cookie, or a bearer token. This is possible because the server maintains an active session for the user. When a user logs on to a platform, they remain authenticated for a period of time without the need to systematically enter or retransmit their login credentials. 
Session hijacking consists of stealing access to a platform, without the need to collect the login and password associated with the account. In this article, we present the main attacks and exploits. XSS exploitation, session fixation, lack of encryption, MFA bypass, etc., there are many techniques to hijack a user’s session.
It must be based on robust authentication and session management that takes into account various security risks, such as session hijacking. Access control is a central element in ensuring the security of web applications.
0 kommentar(er)
