CSRF On stealing lock in support.mozilla.org
Categories
(support.mozilla.org :: General, task)
Tracking
(Not tracked)
People
(Reporter: roldanbrandon62, Assigned: tasos)
Details
(Keywords: reporter-external, sec-low, wsec-csrf, Whiteboard: [reporter-external] [web-bounty-form] [verif?])
Attachments
(1 file)
|
156.02 KB,
image/png
|
Details |
Hi. The steal-lock function, allows get request making it vulnerable to csrf attacks since get requests in django doesnt need csrf protections. The endpoint is defined in wiki/urls.py in
re_path(r"^/steal_lock$", views.steal_lock, name="wiki.steal_lock"),
This is the steal lock function
@login_required
def steal_lock(request, document_slug, revision_id=None):
doc = get_object_or_404(Document, locale=request.LANGUAGE_CODE, slug=document_slug)
user = request.user
ok = _document_lock_steal(doc.id, user.username)
return HttpResponse("", status=200 if ok else 400)
So, when we trick a victim into following https://support.allizom.org/en-US/kb/<article_slug>/steal_lock, the document will be locked even if the victim is not actually editing the article.
Comment 1•4 years ago
|
||
Hello Brandon,
Thank you for your report.
Were you able to reproduce this issue in the app?
Thanks,
Frida
| Reporter | ||
Comment 2•4 years ago
|
||
Hi. Yeah. For the steps to reproduce
- Have two accounts, we will call these two users as user a and user b
- Pick an article
- As user a, go to https://support.allizom.org/en-US/kb/<article_slug>/steal_lock replace article_slug with the article that you chose
- Now as user b, try editing the article and you will see the lock saying that user a is editing the article without user a knowing
Comment 3•4 years ago
|
||
Users are still able to edit the article as you can see in the attached screenshot, tricking the user to lock the article won't completely deny other users from editing the article.
Comment 4•4 years ago
|
||
Updated•4 years ago
|
| Reporter | ||
Comment 5•4 years ago
|
||
Hi. Yes but i thought it would still be worth reporting. With this, the victim wont know and wont be able to remove the lock unless other people take the lock. Other people might not be able to work to the article thinking someone is already working on it
Comment 6•4 years ago
|
||
true, I agree that we need to address the issue, however, I assigned it with low severity since it doesn't completely restrict other users from editing the article.
Comment 7•4 years ago
|
||
Hello Tasos,
Can you please take a look? This is another endpoint that is vulnerable to CSRF.
Thanks,
Frida
| Assignee | ||
Comment 8•4 years ago
|
||
Thanks Frida. Given the other bugs filed, I would agree this is low severity. I will return to this once more important bugs are fixed.
Updated•4 years ago
|
| Assignee | ||
Updated•4 years ago
|
| Assignee | ||
Comment 9•4 years ago
|
||
| Assignee | ||
Comment 10•4 years ago
|
||
The fix has been released to prod.
Updated•4 years ago
|
Updated•3 years ago
|
Updated•1 year ago
|
Description
•