Closed Bug 1764724 Opened 4 years ago Closed 4 years ago

CSRF On stealing lock in support.mozilla.org

Categories

(support.mozilla.org :: General, task)

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: roldanbrandon62, Assigned: tasos)

Details

(Keywords: reporter-external, sec-low, wsec-csrf, Whiteboard: [reporter-external] [web-bounty-form] [verif?])

Attachments

(1 file)

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.

Flags: sec-bounty?

Hello Brandon,

Thank you for your report.

Were you able to reproduce this issue in the app?

Thanks,
Frida

Hi. Yeah. For the steps to reproduce

  1. Have two accounts, we will call these two users as user a and user b
  2. Pick an article
  3. 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
  4. 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

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.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: sec-low, wsec-csrf

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

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.

Hello Tasos,

Can you please take a look? This is another endpoint that is vulnerable to CSRF.

Thanks,
Frida

Flags: needinfo?(tasos)

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.

Flags: needinfo?(tasos)
Component: Other → General
Product: Websites → support.mozilla.org
Assignee: nobody → tasos

The fix has been released to prod.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Flags: sec-bounty? → sec-bounty+
Group: websites-security
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: