Irrational programming decisions exposed by blocking Referer header in browsers
Anyone with the slightest concern for privacy blocks or replaces the Referer header in HTTP requests. In Firefox, this is achieved through the about:config option network.http.sendRefererHeader. In Chrome, this is achieved through any of a few extensions made for the purpose.
In viewing the Frankfurt Declaration, I saw that several popups displayed German references, i.e. names of books in German and use of comma between chapter and verse instead of colon. This, despite the fact that the page is in English, and the translation being used is ESV. (See collage of 5 screenshots below.) I discovered that when the page is loaded in the browser without blocking Referer header, these references revert to being in English.
Digging in a little deeper, I found that the server does other strange and disturbing things. When loading a reference, the response headers from reftagger.bibliacdn.com typically contain a set-cookie header, requesting to set a cookie with the name ExternalReferrer. This cookie request is always ignored, because the domain attribute of the set-cookie header is biblia.com, which is "invalid with regards to the current host url." When Referer is enabled, the server seems to simply echo that value back in its set-cookie request, i.e. with this particular website, Referer: https://frankfurtdeclaration.com/ in the request headers will result in response headers containing Set-Cookie: ExternalReferrer=https://frankfurtdeclaration.com/; domain=biblia.com; expires=...; path=/ . However, when sending the Referer header is not enabled, things get weird. Sometimes, dependent on the particular reference/url being requested, the server does not request any cookie named ExternalReferrer. Other times, again, depending on the particular reference/url, the ExternalReferrer cookie is requested, but with some kind of cached value that is arbitrary and most often wrong.
Here is a summary of my survey of the references on that one page:
37x [no ExternalReferrer set-cookie]
Exod.1.17 Ex20.1-17 Ps.9.7-8 Dan.6.11 Micah.6.8 Acts4.19 Acts9.25 Acts12.17 Rom.1.32 Heb.11.3 Gen.6.5 Ps.19.1-8 John3.33 Rom.1.18-20 2Cor.4.2 Eph.2.3 James2.9 Rev.13.11-15 Dan.3.1-30 Matt.25.31-40 1Cor.6.12-20 1Thess.4.11-12 James5.14-15 Rev.13.16-17 Matt.22.20-21 Eph.5.21-6.4 Col.3.18-20 1Tim.2.1-2 Heb.13.17 1Pet4.15 Rev.13.7-8 Acts5.28-29 Acts10.36 Rom.13.6-7 Eph.1.20b-23 Rev.5.9 1Cor.16.13-14
14x ExternalReferrer=https://www.gotquestions.org/
Acts5.29 Acts17.31 Rom2.14-16 Rom11.36 1Tim6.15-16 Ps31.6 Ps119.160 John14.6 John17.17 John17.14 Rom13.1-7 Matt22.21 Eph4.15-16 Josh1.9
12x ExternalReferrer=https://frankfurtdeclaration.com/
2Sam.12.1-14 Acts4.24-29 1Pet.2.13-14 Josh.2.3-6 1Tim.1.17 Matt.18.20 1Tim.6.3-5 Dan.3.16-18 2Sam.12.1-14 Dan.5.23-24 Matt.24.12-13 Eph.5.10-13
4x ExternalReferrer=https://www.desiringgod.org/
John16.13 Gen2.24 Matt28.18-19 Acts20.28
2x ExternalReferrer=https://sermons.faithlife.com/
Gen.1.1 Col.1.27
2x ExternalReferrer=https://founders.org/
James4.12 Exod.20.9
2x ExternalReferrer=https://warrentondeclaration.com/
Gen.1.26-28 Deut.6.6-7
1x each ExternalReferrer=
Rom.13.1-7 https://www.redeemerchurchofsouthhills.org/
Gen2.15-17 https://www.covlife.org/
Matt.28.19 https://westminsterstandards.org/
Col.1.16 https://thirdmill.org/
2Tim.3.16-17 https://www.gracebibleva.org/
Rev.4.11 https://www.fbcatown.com/
Eccles.7.29 https://www.christchurchwc.org/
1Tim.3.15 http://evangelicaltextualcriticism.blogspot.com/
Gen9.6 https://answersingenesis.org/
James3.9 https://www.hopechurchva.org/
Rom.12.1-2 https://openheaven.net/rccg-sunday-school-teachers-manual-sunday-24th-of-july-2022-lesson-forty-seven-47/
Phil.2.14-16 https://www.stmichaelschurch.net/
1Cor.12.12-13 https://grace.community/
2Cor.4.5 https://www.acts29.com/
2Cor5.10 https://www.denisonforum.org/
Eph3.20 https://biblicalcounseling.com/
Heb.10.24-25 https://donnareidland.com/
Note that in one of the above cases, not only the domain but the particular page on the website is specified. Browsers often trim the Referer header to just the domain, but it can be set to send the entire url. The presence of this value suggests that it was collected from a browser using that setting. Note also that one of the sites was specified as http instead of https. These things suggest that the server is doing no sanitizing of the data being provided to it by whatever browsers it is collecting this data from. Programmers should be aware of the dangers of storing and regurgitating unsanitized data.
Another issue I saw was with the expires attribute of the ExternalReferrer cookie the server was attempting to set. It was almost always in the past with regard to when the request was made, usually by a few days or at least several hours. Only twice was the value in the future, and always less than a hour.
Recommendations:
- Don't return different results depending on the presence or absence of a Referer in the request headers.
- Don't try setting any cookies in the response headers. It simply doesn't work; ever. And currently it is leaking information about other websites that use RefTagger. (It's not just the
ExternalReferrercookie that doesn't work; theASP.NET_SessionIdand_culturecookies are ignored/blocked as well because of similar issues affecting cross-site cookies.) - Do a systematic review of your server code for instances where it collects information. Make sure that data is sanitized before use/storage, make sure it's even worth collecting and storing, and make sure that it isn't leaked out in irresponsible ways through bad programming decisions.
Comments
-
Playing with it some more, I've confirmed that I can indeed coerce the server to store and later regurgitate arbitrary strings, whether they look like URLs or not, and with no limit to length found yet.
Examples:
Ps149.9-150.1 :: https://jerryspizzaemporium.com/
Ps148.14-149.1 :: whatHenrydoesntknow
Ps147.20-148.1 :: [Here, I stored the entire text of Poe's poem "The Raven" -- it's over 6kb long, so I won't reproduce it here.]
Programmers must think about these kinds of things. Do you realize I've found a way to coerce your servers into storing and serving arbitrary strings of my choosing? This may not be particularly useful, but it's technically exploitable. I could write a script right now that would capable of storing and retrieving a whole movie on your server, simply by finding and using as many never-before used references as it takes to store it, and then store the list of references in another reference. Or, let me put it this way: If I had child p*rn, I could store it on your servers, and then send out a script, which I could also store on your servers, allowing people to download it.
Please have some competent programmers look over your codebase and fix these kinds of problems because frankly this doesn't inspire a lot of confidence. I am by no means even a proficient hacker, so that makes me wonder what someone with real skills could do to you. If you're struggling with understanding what I've revealed here, just ask; I'm happy to help.
0 -
This is surprising (to me). And important to fix.
“The trouble is that everyone talks about reforming others and no one thinks about reforming himself.” St. Peter of Alcántara
0 -
Thanks for this report. I've asked a developer to take a look.
0 -
So, I did another survey of that site, and the problems are by no means fixed, but it should be noted that it's a moving target. Today, most of the response headers didn't request any cookies. A small minority (I didn't count) requested cookies with the "correct" value ( ExternalReferrer=https://frankfurtdeclaration.com/ ). And then a few oddballs:
6x https://www.gotquestions.org/
Gen2.24 Gen9.6 Rom13.1-7 Acts10.36 Acts20.28 2Cor5.10
1x each
Rom11.36 https://www.desiringgod.org/
2Tim.3.16-17 https://slcc.faith/
James3.9 https://endabortionnow.com/
Matt22.21 https://www.rethinknow.org/As you can see, these are all different from before. Also, today, the references that were showing in German before are in English, but now another is in Spanish (or Italian).
0 -
We stripped all Set-Cookie headers from Reftagger responses.
The ones you're seeing are likely cached responses in the CDN that haven't expired yet. They should expire soon, which will resolve the problem. (We didn't forcibly purge all entries in the CDN.)
Geronimo Roundtree said:Also, today, the references that were showing in German before are in English, but now another is in Spanish (or Italian).
We have not yet investigated this problem; thanks for reporting it.
0 -
Geronimo Roundtree said:
Also, today, the references that were showing in German before are in English, but now another is in Spanish (or Italian).
We fixed a cache configuration bug that was causing the same responses to be cached for different Accept-Language headers.
As with the other problem, we have not purged the CDN, so it may take a week or so for the wrong responses to expire out of cache.
0
