Project

General

Profile

Actions

Bug #91

closed

Feature #65: Security Audit

[Security Audit ] 26 -Cross-Site Request Forgery (CSRF)

Added by Kalyan Battula about 1 year ago. Updated 7 months ago.

Status:
Closed
Priority:
Low
Category:
-
Target version:
Start date:
17/04/2024
Due date:
% Done:

0%

Estimated time:
Deployed In:
Category:

Description

26- Cross-Site Request Forgery (CSRF)

CWE : CWE-352
Description :
Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute
unwanted actions on a web application in which they're currently authenticated. CSRF
attacks specifically target state-changing requests, not theft of data, since the attacker
has no way to see the response to the forged request. With a little help of social
engineering (such as sending a link via email or chat), an attacker may trick the users of
a web application into executing actions of the attacker's choosing. If the victim is a
normal user, a successful CSRF attack can force the user to perform state changing
requests like transferring funds, changing their email address, and so forth. If the victim
is an administrative account, CSRF can compromise the entire web application.
Affected Path(s) :
https://his-core-domainservice.satragroup.in/master/hospital/location/deletelocationby-locationId/215449
*-Applicable to entire application
Impact :
Depending on the application, an attacker can mount any of the actions that can be
done by the user such as adding a user, modifying content, deleting data. All the
functionality that’s available to the victim can be used by the attacker. Only exception to
this rule is a page that requires extra information that only the legitimate user can know
(such as user’s password).
Recommendation :
Use anti-CSRF tokens:
The anti-CSRF token should be unique for each user session
The session should automatically expire after a suitable amount of time
The anti-CSRF token should be a cryptographically random value of significant
length
The anti-CSRF token should be cryptographically secure, that is, generated by a
strong pseudo-random number generator (PRNG) algorithm
The anti-CSRF token can be added as a hidden field for forms or within URLs
(only necessary if GET requests cause state changes, that is, GET requests are
not idempotent)
The server should reject the requested action if the anti-CSRF token fails
validation
Implement Samesite cookie attribute and set its value to "Strict/Lax".
Reference: https://cheatsheetseries.owasp.org/cheatsheets/CrossSite_Request_Forgery_Prevention_Cheat_Sheet.html
Evidence/Proof Of Concept
Step 1: Csrf token not implemented as shown in below screenshot.


Files

clipboard-202404171609-t7zh7.png (58 KB) clipboard-202404171609-t7zh7.png Kalyan Battula, 17/04/2024 04:09 PM
Actions #1

Updated by Vasudev Mamidi 12 months ago

  • Status changed from New to Resolved
Actions #2

Updated by Karthik Daram 12 months ago

  • Status changed from Resolved to In Progress
Actions #3

Updated by Vasudev Mamidi 12 months ago

  • Assignee set to Vasudev Mamidi
Actions #4

Updated by Sivakanth Kesiraju 12 months ago

  • Target version set to Security Audit
Actions #5

Updated by Vasudev Mamidi 11 months ago

  • Status changed from In Progress to Resolved
Actions #6

Updated by Gautam Kumar 7 months ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF