During a recent pen test of GitLab, Imperva researchers were surprised to come across a vulnerability that leaves users exposed to session hijacking attacks.
The vulnerability stems from the type of session tokens used by GitLab. According to Imperva, the tokens are troublesome because: They are short, making them susceptible to brute-force attacks; they are persistent, meaning they never expire; and they lack role-based access control, meaning a simple copy/paste of the token grants access to every actionable item on the GitLab platform, eg, user dashboards, account information, individual projects and website code.
Session hijacking is a serious threat to online users’ privacy, money and identity; it involves the interception of session tokens that identify individual users logged into a website. An attacker can use a hijacked token to access a user’s account, make illegal purchases, change login credentials and access credit-card details, among other things.
In this case, the vulnerability can have wide-ranging consequences, given that GitLab is a widely used SaaS provider that focuses on developer-related issues, including Git repository management, issue tracking and code review.
Methods for stealing session tokens include: Man in the middle (MITM) attacks, in which forged authentication keys are used to pass off a connection as secure; brute force attacks, in which a botnet executes millions of requests using random session IDs until an authorized token is found; and SQL injections, in which malicious SQL code is used to access sensitive data, Imperva noted in an analysis.
GitLab has already taken steps to minimize the exposure of private tokens, and has introduced role-based security controls to minimize the access a compromised token would provide. Additionally, GitLab is replacing private tokens with RSS tokens for fetching RSS feeds to avoid exposing session IDs; and is gradually phasing out private tokens altogether.