Executive Summary

A security vulnerability of the type reflected Cross-Site Scripting (XSS) was identified, which could be exploited to compromise the security of user data.

The vulnerability is caused by the possibility of injecting code through an input field. Such code is then executed in the web browser of other users, which may result in the disclosure of sensitive information (for example cookies) or lead to other security issues.

In plain terms: the website takes whatever a visitor types into the search box and hands it straight back to the browser as part of the page. If that text is actually a small program, the browser runs it — trusting it because it appears to come from the observatory's own site.

The vulnerability was observed on the following websites:

• https://hvezdarnacb.cz
• https://www.planetky.cz
• https://klet.cz
• https://klet.org
• https://www.komety.cz

Proof of Concept

The search form on all of the listed websites contains a reflected XSS vulnerability. Entering the following into the search field:

"><script>alert('reflected')</script><img src=x style=display:none onerror=null alt="

triggers the reflected XSS.

This is only a proof of concept: the victim is aware of what is happening, and the result is plainly visible on screen. An attacker would not act this way in practice — a real attack would look very different, as shown below.

Abuse Cases

In a real attack the exploitation would be quiet and invisible, going completely unnoticed by the victim. It could look like this:

1. The victim opens a link — for example from a QR code on a flyer, a Facebook event, or an email. The link itself may look completely normal; shortened URLs are common and raise no suspicion. The attacker relies on social engineering, for instance by inviting the victim to look at an astronomical object or pretending to ask about a guided tour.
2. The page then silently redirects the victim, as expected, to the legitimate website https://hvezdarnacb.cz. The observatory's site appears normal and works as intended.
3. However, alongside the legitimate site loading, the victim's browser is invisibly poisoned — with no visible sign at all.
4. Depending on its complexity, the injected code can carry out the attacker's intentions. Through JavaScript, the attacker could effectively take control of the victim's browser remotely, without their knowledge. This could include stealing access to the administration panel, attempting to reach the webcam, spawning fake login prompts for services such as Facebook, or silently recording the user's activity on the site.

The upper screen is the victim; the lower one is the attacker.

Remediation

Mitigations

The good news is that there are well-established protective mechanisms that prevent this behaviour, or at least mitigate it, and they are commonly implemented in practice.

• Filter and encode user input in forms, so that submitted text is treated as data, never as code.
• Implement a Content Security Policy (CSP), which prevents arbitrary scripts from being loaded into the victim's browser (arbitrary scripts pose the highest risk).
• Set cookie security attributes — HttpOnly, Secure, SameSite — which prevent an attacker from easily reading or manipulating cookies and impersonating an administrator.

security.txt

A good practice is to publish a security.txt file in accordance with RFC 9116. The file belongs at the canonical path /.well-known/security.txt. It is a small, simple text file that tells ethical researchers how to securely report any findings. Some examples for inspiration:

Disclosure Timeline

17 November 2024  - vulnerability reported24 August 2025    - follow-up report resent9 June 2026       - follow-up report resent30 September 2026 - phone call with the IT department; the vulnerability was explained. The department indicated it does not intend to fix the finding at this time. I let them know it would be published here on this site.