Sessions
A session is the total time devoted to an activity. In computer systems, a user session begins when a user logs in to or accesses a particular computer, network, or software service. It ends when the user logs out of the service, or shuts down the computer. A session can temporarily store information related to the activities of the user while connected. A session cookie is used in web pages for storing information in case the user leaves the web page or closes down their Internet browser. For example, this is one way a website can remember what is in your shopping cart if you leave and come back.
Cookie
A cookie is a small file with the maximum size of 4KB that the web server stores on the client computer. Once a cookie has been set, all page requests that follow return the cookie name and value. A cookie can only be read from the domain that it has been issued from. Most of the websites on the internet display elements from other domains such as advertising. The domains serving these elements can also set their own cookies. These are known as third party cookies. A cookie created by a user can only be visible to them. Other users cannot see its value. Most web browsers have options for disabling cookies, third party cookies or both.
Session Fixation
The Session Fixation attack consists of the exploitation of the web session control mechanism, which is normally managed for a session token. Because HTTP communication uses many different TCP connections, the web server needs a method to recognize every user’s connections. The most useful method depends on a token that the Web Server sends to the client browser after a successful client authentication. A session token is normally composed of a string of variable with and it could be used in different ways, like in the URL, in the header of the http requisition as a cookie, in other parts of the header of the http request, or yet in the body of the http requisition.
Session Hijacking
Session Hijacking is simply the act of stealing an existing, valid session cookie. Most commonly through sniffing network traffic (a MITM attack), Cross site scripting or cross site tracing attack but also through any other ways that a session ID may be leaked. Session fixation is similar but inverted — a pre-defined session cookie is planted into the victim’s browser. So after the victim logs into a website, they will use the same session cookie that the attacker already knows, and thus the attacker-owned cookie is now authenticated and can be exploited. Of course that requires an attacker to have temporary access to the victim’s browser itself, but the principle is very simple — there’s no need to steal the data if it is under your control in the first place.
How to Test Session Fixation
Session-ID same pre and post login.[Session Fixation] [Require physical access to the victim’s browser to set previously known valid session ID and exploit it later to visit or modify victims web content]
Step 1
Visit login page. Go to cookie editor extension which is already
installed in web browser and edit cookies. Copy Session-ID.
Step 2
Login into application. Again, visit cookie editor. Copy the cookie.
Step 3
If both cookies are same then report the issue.
To better understand it, I would add one example which is exploited in real-world pen-testing experience.
Note: Browser Chrome Used By- Attacker & Browser Firefox Used By- Victim.
● As an attacker, browse the application from chrome and make a note of the session-id without logging in from the admin by just requesting any page within the application and intercepting that request. The intercepted request will have the session-ID ―PHPSESSID.
● Now the task is to fix the session-ID (PHPSESSID) noted in the previous step into the victim’s browser. This can be done by exploiting XSS vulnerability or by making the victim click on the URL having session-ID in GET parameter. Here we have fixed the session into the victim’s browser that is firefox by setting the session-ID noted previously in his browser.
● Now, let the victim login into the application having the attackers session-ID. Note that application doesn’t set a new session-ID when user logs in into the application and session-ID (Attacker’s) remains same even after login.
● Now, from the attacker’s browser, hit refresh. It is observed that admin panel will be accessed without entering credentials.
● Boom!! Attacker can access the functionalities.
Impact
After the attack is successful, the account of the user can be completely compromised and the attacker will be able to perform all the operations that the user can perform.
Countermeasures
● The standard method is to change the session ID right after the user logs in. This eliminates most session fixation vulnerabilities.
● An additional countermeasure is to change the session ID with the slightest suspicion of potential wrongdoing. For example, the web application may test whether the IP address or the user-agent of the client changed and if it did – provide a new session ID.
● You should also invalidate session IDs after a timeout. For example, 10 minutes of no activity should cause an automatic logout. This gives the attacker a small window of opportunity to use the fixed session ID.
● Some sources recommend changing the session IDs with every user action. However, this is a drastic, unnecessary, and potentially harmful – it may impact user experience and performance (for example, it might be impossible when using applets). To minimize the impact, you may change the session ID before every important user action on the website.
● Remember to use session cookies for session management and do not accept session IDs from HTTP requests and HTTP headers.
● HTTPS (HSTS), anti-CSRF tokens, and suitable cookie flags (Secure, SameSite) can be helpful in avoiding session fixation, too.
Captcha Bypass
Completely Automated Public Turing test to tell Computers and Humans Apart (CAPTCHA) is a type of challenge-response test that is used to distinguish humans from automated programs i.e., bots. Many websites use CAPTCHAs on their login pages to protect against automated attacks such as user identifier enumeration, brute-force password guessing, credential stuffing and password spraying attacks. Typically, CAPTCHAs are image based that require users to recognize a distorted sequence of alpha-numeric letters or solve a simple mathematical puzzle. The hypothesis is that humans are good at recognizing letters and solving puzzles presented within a distorted (noisy) image whereas automated programs are not. However, advancements in computer vision have rendered seemingly complex CAPTCHAs’ ineffective. Researchers have developed efficient and accurate machine learning and deep learning algorithms to recognize characters present in the CAPTCHA images.
Methods to bypass Captcha.
● Changing request methods.
It is an easy method to check for bypass captcha just by changing the ―request method of your request‖ and removing the captcha parameter
ex- POST — — -> GET (POST request to GET) #more preferable
POST — — → PUT (POST request to put)
● Removing the parameter or using the previously used captcha.
This might not work usually but doing things just right could hit the spot and give the results.
● Using extra headers for rate limiting.
There are some headers that you can use to bypass captcha/ratelimiting.
headers: X-Originating-IP: 127.0.0.1
X-Forwarded-For: 127.0.0.1
X-Remote-IP: 127.0.0.1
X-Remote-Addr: 127.0.0.1
if this does not work try to use ―x-forwarded-for: 127.0.0.1 twice.
● Missing Server Side Validation of the Captcha Field.
Some applications send Captcha Parameters on the client side but they do not validate this on the server side.
Simply, Remove the “Captcha” parameters and see if the request is processed successfully.
If yes, you can now use this request to perform your brute-force or rate limiting attempts.
● Missing Captcha Field Integrity Checks.
There are multiple scenarios around this one, this happens when the application validate whether the captcha parameters are present but not the “value”.
Simply, send an empty captcha parameter and see if the request works successfully.
Change some specific characters of the captcha parameter and see if it possible to bypass the restriction. This usually happens when only string length is validated at the server-side.
● Reusuable Captcha
Just repeat the request using the same Captcha key multiple times and see if that works.
One of my weird finding was, Capture the Request in Burp Proxy and send it to Intruder. Hold the request in Proxy Tool don’t let it go.
Run the Intruder and observed that same captcha can be reused any no. of time until you drop off the original request from proxy.
Reference
● https://owasp.org/wwwcommunity/attacks/Session_hijacking_attack
● https://www.geeksforgeeks.org/session-hijacking/
● https://us.norton.com/blog/id-theft/session-hijacking
● https://www.geeksforgeeks.org/session-fixation-attack/
● https://www.acunetix.com/blog/web-security-zone/what-issession-fixation/
● https://www.venafi.com/blog/what-session-hijacking
● https://secureteam.co.uk/articles/web-application-securityarticles/understanding-session-fixation-attacks
