Skip to content

Next

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
    • Help
    • Support
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
GitLab FOSS
GitLab FOSS
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
    • Cycle Analytics
    • Insights
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Charts
    • Locked Files
  • Issues 1
    • Issues 1
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 0
    • Merge Requests 0
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
    • Charts
  • Security & Compliance
    • Security & Compliance
    • Dependency List
  • Packages
    • Packages
    • Container Registry
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Charts
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • GitLab.org
  • GitLab FOSSGitLab FOSS
  • Issues
  • #29374

Closed
Open
Opened Mar 12, 2017 by Brian Neel@briann
  • Report abuse
  • New issue
Report abuse New issue

HackerOne report: Markdown link filter improperly parses hostname, vulnerable to tabnabbing

We received a HackerOne report that the markdown link filter in GitLab does not properly parse the user@host field of a URL. This allows an attacker to have an external link tagged as internal, which prevents anchor tags such as target=_blank from being removed. An attacker including target=_blank can then use tabnabbing attacks to inject data into the calling web page.

The full report is below:

Summary

Gitlab.com is vulnerable to reverse tabnabbing in issues, comments, etc. This is the same type of issue as https://hackerone.com/reports/211065, but far worse since in the previous report only a user with developer access to a project could view the "Environments" tab. In this case, the issue affects anywhere where HTML can be added.

Why does this vulnerability exist?

By creating a link with https://gitlab.com@example.com the parser ignores it and does not add the usual rel="nofollow noreferrer" which is located on all other links. I discovered this, because I noticed that internal links are treated differently than external links. So in the example above the victim ends up on example.com, which is where the same scenario as https://hackerone.com/reports/211065 can be performed.

In order to demonstrate this issue the following payload can be used:

Reverse Tabnabbing

Where does the issue lie?

The issue appears to lie in the following lines of code:

def external_url?(url)
   !url.start_with?(internal_url)
end

Related issues

  • Discussion
  • Designs
Assignee
Assign to
9.2
Milestone
9.2
Assign milestone
Time tracking
None
Due date
None
4
Labels
Next Patch Release Platform [DEPRECATED] S3 security
Assign labels
  • View project labels
Reference: gitlab-org/gitlab-foss#29374