Prezi allows you to create cool presentation, which you can later share with your audience. It also allows you to add collaborator who can assist in your presentation creation
I started testing Prezi for security vulnerabilities (bugbounty.prezi.com) and found an Authorization bug which allowed me to Add/Delete/Modify Collaborator for any public prezi which were not even mine.
While adding collaborator to your prezi presentation, below PUT request is fired
PUT /api/v1/share/<presentation_id>/permissions/ HTTP/1.1
User-Agent: <User agent string>
Cookie: <Cookie for email@example.com>
Explanation of above request:
1) <presentation_id> is Victim’s presentation
2) firstname.lastname@example.org: Attacker who is firing the above request
3) attackerNewIdOrRealCollaborator@gmail.com: It can be either Attacker id or a genuine collaborator of this presentation with editor rights.
1) If Attacker used his own id in the body parameter, then he would become part of the presentation <presentation_id> without victim permission.
2) If Attacker used a genuine collaborator id having editor rights, then after firing this request, the collaborator permission would lower from editor to viewer only
3) If Attacker, simply changes the above request header from PUT to delete then any collaborator (except owner) passed within body parameter would get deleted from that presentation
4) This attack worked only for public prezis (and not for private prezis) because they are somewhat special - everyone has view permissions by default, although they are not collaborators of it (people who are explicitly added to view/edit the prezi). The vulnerable endpoint unfortunately considered this "default view permission" as a "collaborator permission", which allowed you to add anyone else as a view collaborator. This "collaborator privilege" enabled you to lower the existing collaborators' permission to view level by re-adding them.
I reported the same to Prezi which was fixed fast and Prezi rewarded a nice bounty :)