Cross Site Request Forgery (CSRF) Attack

In the city of Wonderland, Joy, a regular person working at a

computer, got into a bit of trouble online. One day, during a break
from work, Joy checked her bank account but forgot to log out.
Later, when she was playing games online, she clicked on a link that
looked fun. Unfortunately, that link was bad news, and hackers used
it to take money from her bank account without her knowing.
It was only later, when Joy checked her bank statement, that she
realized what happened. Panicking, she contacted her bank to fix
things. This experience taught Joy the importance of being careful
online and making sure to log out of accounts. Now, she tells others
to do the same and stay safe in the digital world.
Prior to delving into Cross-Site Request Forgery (CSRF) attacks and
their execution, it is imperative that we comprehend many key
terminologies that enable apps to be secure in one way or another.
Cookies: In essence, cookies are little text files that are saved on
the client’s browser as name-value pairs and have a maximum capacity
of 4KB. Cookies are mostly used to track or observe how a client
uses a web application. They can also store sensitive information
like session IDs, password preferences, and usernames, which can be
transmitted back to the server in response to an authentication
request.
Session ID: Sessions are little files, much like cookies, but they
are created and saved on the server's end. A session ID is linked to
every session. A session is generated with a session ID once a user
logs in. This session ID then combines with the cookie, gets saved
in the client browser, and is sent back to the web server each time
the browser sends an HTTP request.
Thus, these sessions end when the client signs out or the browser
closes. Additionally, a new session with a session ID is created
with each login.
Cross-Site Request Forgery (CSRF) is a security vulnerability where
an attacker tricks a user's web browser into making unintended and
unauthorized requests to a web application on which the user is
authenticated. In a CSRF attack, the attacker typically injects
malicious code or a crafted URL into a website that the victim is
likely to visit. This injected content triggers requests to another
site where the victim is authenticated. Since the Same-Origin
Policy, a security feature in web browsers, does not prevent CSRF
attacks, the attacker's request is treated as legitimate. The
victim, while authenticated on a targeted site, unknowingly performs
actions initiated by the attacker, such as changing account settings
or making financial transactions. To prevent CSRF attacks, web
developers commonly use anti-CSRF tokens. These tokens, unique and
unpredictable, are embedded in web pages and included in requests.
The server checks if the token matches, ensuring the legitimacy of
the request. CSRF poses risks of unauthorized actions and data
modification, emphasizing the importance of implementing proper
countermeasures and security best practices in web applications.

Mitigation
a) Use Anti-CSRF Tokens: Implement anti-CSRF tokens in web forms
and requests. These tokens are unique to each user session and
must be submitted with every form or request. The server
validates the token to ensure the request is legitimate.
b) Token Placement: Place anti-CSRF tokens in a location that is
not accessible to attackers. Commonly, these tokens are
embedded in hidden fields within HTML forms.
c) SameSite Cookie Attribute: Utilize the SameSite cookie
attribute to control when cookies are sent with cross-site
requests. Setting it to "Strict" ensures that cookies are only
sent in a first-party context, providing an additional layer
of protection.
d) HTTP Referer Header Check: checking the HTTP Referer header
can help verify that requests originate from the expected
source. However, note that this header can be manipulated, and
not all browsers consistently send it.
e) Custom Request Headers: Include custom request headers in AJAX
requests and ensure that the server verifies the presence and
correctness of these headers.
f) Double-Submit Cookies: Implement double-submit cookie patterns
where the anti-CSRF token is stored both in a cookie and as a
request parameter. The server compares the values to validate
the request.
g) Use Frameworks with Built-in CSRF Protection: Many web
development frameworks provide built-in mechanisms for CSRF
 protection. Utilize these features and follow best practices
recommended by the framework.
h) Educate Developers: Train developers on secure coding
practices, emphasizing the importance of implementing anti-
CSRF measures in web applications.
i) Implement Referer Policy: Set the Referrer-Policy header to
control how much referrer information is included with
requests. This can help in reducing the risk of CSRF attacks.
j) Check for Same-Site Cookie Support: Regularly check and ensure
that web applications and third-party libraries used in the
application support the SameSite cookie attribute.
k) Use Content Security Policy (CSP): Implement Content Security
Policy headers to restrict the sources from which resources
can be loaded. This can mitigate the risk of loading malicious
scripts.
Cookie Stealing and Session Hijacking

Cookie theft is a type of cyberattack in which an attacker obtains

unauthorized access to a user's session data by stealing the user's
browser cookies. It is also referred to as session hijacking or
session stealing. Websites employ cookies, which are little data
files stored on a user's computer to keep track of their session,
preferences, and status of login. They are frequently used for user
authentication and identification.
The process of cookie stealing can be explained as follows in simple
terms:
 User authentication: Upon logging in, the website's server
establishes a session and provides your browser with a
distinct session identifier via a cookie.
 Cookie Theft: An attacker can use this session cookie to
pretend to be the user without knowing their real login
information if they are successful in obtaining it. This could
occur via a number of techniques, including employing
malicious software, hacking into unprotected Wi-Fi networks,
and taking advantage of security holes in websites.
 Session Impersonation: After obtaining the stolen cookie, the
attacker can use it to enter the victim's account and carry
out actions—like making unsanctioned transactions, gaining
access to private data, or changing account settings—on their
behalf.

Mitigation
Implementing security measures at the user and website/application
levels is necessary to mitigate the danger of cookie theft and
session hijacking. The following tactics can be used to lessen these
risks:
For Users:
 Use HTTPS: Verify that HTTPS is being used by the websites you
visit. In order to increase the difficulty of attackers
intercepting and stealing your session cookies, HTTPS encrypts
the data transferred between your browser and the website.
 Awareness of Public Wi-Fi: Use caution when connecting to
public Wi-Fi networks. Refrain from logging into crucial
accounts or gaining access to private information while using
unsafe networks.
 Log Out: Whenever you're finished using an account, make sure
to log out, especially on shared or public computers. This
makes it more difficult for attackers to use stolen cookies
and helps invalidate the session.
 Two-Factor Authentication (2FA): Enable two-factor
authentication (2FA) whenever it's feasible. An extra element,
 such as a temporary code from your phone, would still be
required for access to your account even if an attacker were
to get to obtain your session cookie.
 Frequent Cookie Clearing: Especially after using a public
computer, periodically delete the cookies from your browser.
By eliminating older session cookies, this lessens the
possible impact of cookie theft but won't stop it entirely.

For Website/Application Developers:

 Use Secure Cookies: Make use of secure cookie flags like
HttpOnly and Secure. The HttpOnly flag lowers the possibility
of cookie theft via cross-site scripting (XSS) attacks by
preventing the cookie from being accessible by client-side
scripts, while the Secure flag guarantees that the cookie is
only sent over HTTPS connections.
 Implement Session Timeout: After a predetermined amount of
inactivity, users should be automatically logged out. As a
result, attackers have a shorter window of time to use stolen
session cookies.
 IP tracking: Throughout a session, keep an eye on and log user
IP addresses. Unusual IP address changes could be a sign of
questionable activities.
 User-Agent Checking: Make that the session is being utilized
by the same browser and device by checking the User-Agent
header. A session hijack attempt could be indicated by unusual
changes.
 Security Headers: To improve overall web application security,
use security headers like Strict-Transport-Security (HSTS) and
Content Security Policy (CSP).

Strong security procedures on the developer side combined with user

awareness can greatly lower the dangers of cookie theft and session
hijacking.