A profile page of a user can be denied from loading by appending .html to the username

HackerOne report #475098 by maruthi12 on 2019-01-05, assigned to dappelt:

Summary: I was able to create a user with the username "dashboard.html". Once, the account is set up, when the user clicks on his profile, the actual dashboard will show up instead of his profile page. Same can be done for all the HTML pages in GitLab.

Steps To Reproduce:

1. Register a new user with "some_html_page_in_gitlab.html"
2. After logging in. click on the profile tab, it will be redirected to the dashboard page.
3. I even tried the username "profile.html", it is getting directed to the profile tab.

Impact

The major impact here I can think of is that a user can hide his profile from the public just by having a clowny username.

added HackerOne security labels

HackerOne comment by maruthi12:

This issue is reproducible. To add a more broad impact, ".html" are sensitive web page extensions. They need to be stripped during the signup flow. This is in scope.

HackerOne comment by maruthi12:

Some of the other usernames that support this are

• profile.html
• search.html
• admin.html

HackerOne comment by maruthi12:

Also, setting username as any_organization.html, for example, "gitlab-org.html" redirects to the organization page upon clicking the profile tab. This means that it will be possible to add 1000s of invalid profiles with organization's names.html

HackerOne comment by exc3lsior:

Based on your initial description, there do not appear to be any security implications as a direct result of this behavior.

If you disagree, please reply with additional information describing your reasoning.

Including a working proof-of-concept that shows one of these implications can be incredibly helpful in our assessment of these claims.

HackerOne comment by maruthi12:

Hi @exc3lsior, I want to reopen this report and rename the title of the vulnerability and increase the Severity too. I found a way to take over a profile page of a victim. Using this technique, I can take over any profile that ends with a ".html"

Steps To Reproduce:

1. Victim creates his GitLab profile with the user the username "victim.html".
2. Now, since the profile page of the victim is public, an attacker now sees this page https://gitlab.com/victim.html and notices that .html extension is not removed from it when the page loads.
3. The attacker now decides to take over the page.
4. The attacker goes to his personal GitLab Account,
5. He creates a "new group" named "victim".
6. Now, whenever https://gitlab.com/victim.html (the profile) is loaded, it will be redirected to https://gitlab.com/victim (the group).
7. The attacker has now successfully taken over the profile page of the victim.

Kindly reopen this issue.

Thanks and Regards, Maruthi Adithya

HackerOne comment by maruthi12:

This issue is reproducible. I have added the security impact this report creates. And, this is within the scope of the program.

HackerOne comment by maruthi12:

Any updates on this??? I want to update the Severity to Medium as well as per GitLab's policy that says " the finding impacts few customers in our customer base."

HackerOne comment by maruthi12:

Any updates on this? @exc3lsior . I believe this has crossed the SLA period :(

HackerOne comment by maruthi12:

Any updates on this @jritchey ??

HackerOne comment by dappelt:

Hi @maruthi12,

please excuse the delay. We are looking into your report and will come back to you soon.

Best regards, Dennis GitLab Security Team

@asaba Do you know which team this belongs to?

added priority3 severity3 labels

@asaba Do you know which team this belongs to?

@jramsay @jeremy My initial guess would be ~Create since that was how gitlab-ce#54278 was assigned, but maybe it's falls under ~Manage since the impact is more broad?

This seems related to gitlab-ce3338737 and gitlab-ce3338736, ~Manage it is

added Manage [DEPRECATED] devopsmanage labels

changed due date to March 23, 2019

added [deprecated] Accepting merge requests label

Also works with projects. Update from the reporter:

I found an another vulnerability that is quite similar to this one. Using this vulnerability, I can takeover any project that ends with a ".html". To reproduce:

1. Go to a group.
2. Create a project named "victim-project.html" so that the slug is the same.
3. A new project will now be created and slug will be /victim-project.html
4. Now go to the same group, create a subgroup with the name "victim-project" and ensure that the matches the same.
5. Once the group is created, navigate to the project url.
6. It will be redirected to the subgroup.

Using this technique any project that ends with ".html" can be taken over by the attacker. Kindly make sure that the fix handles this as well.