We try to do our best for your safety. On this site there have been deployed security mechanisms, which largely prevent the interception and misuse of information, which are displayed on the website, stored in a database or entered by the individual user. Some techniques that have been implemented in the context of web security are listed below.
The security of the web is not a property, but only its degree. The purpose of deploying security measures is, if possible, to prevent the misuse of data, which are transmitted between you and the web server. Whether it is about typing login data, standard activity with the site or just recording the pages that you are viewing. This site is among a growing group of sites that are secured by modern technologies and meet recommended safety criteria.
Here you can quickly check what the security implementation status on this site is. If you are interested in the details of individual security principles, you can found them below in short.
The modern protocol for securing Transport Layer Security (TLS 1.3). is used for all communication between the user and server. For key exchange (which is one of the steps in the content encryption) there is used an advanced algorithm ECDHE, which is working with cryptography over elliptical curves.
Here you can verify the security described: https://www.ssllabs.com/ssltest/analyze.html?d=campula.cz
The use of a digital certificate is currently a standard of the modern web, and also the need for encryption of communication between a user's browser and the web server. This system ensures to the visitor that there would not be possible to intercept the data and that the visitor will be certain that he is communicating with the right web server and not with the server of a possible attacker. In addition the certificate itself contains among others the domain name (campula.cz), which is basically compared with the address in the address bar. If the certificate is evaluated as valid, a visitor can be almost certain that he was not fraudulently redirected to another site. If these data do not match, the browser displays a warning about the mismatch of the certificate.
A DV certificate (domain verification) is used on this web, which verifies the domain without further authentication of the owner, company, etc. The use of another type of certificate is currently neither too significant nor economically advantageous.
Theoretically there is an existing possibility of working with fake certificate with the effort to redirect to the attacker's server without the user's knowledge, though very unlikely. However, the Certificate Transparency system, in which are stored all the certificates issued by world certification authorities, has been trying to prevent it. The browser then uses the control mechanism, which verifies whether the certificate is valid and whether it had not been forged.
Here you can verify which certificates were issued for this site and whether they are valid:
The domain campula.cz is registered with a certified registrar that supports DNSSEC. security. The aim of this system is to protect the translation of domain names to the servers IP addresses. If the user enters into the browser the website address, this address translates to the IP server address where the site is located. All the information displayed on the page, are loaded from this server. If there was a situation that the attacker causes a change in the translation of IP addresses, he could redirect a visitor to his web site with a similar graphical layout and hereby draw the sensitive data from the user. DNSSEC technology prevents this option by asymmetric cryptography within the translation of domain names into IP addresses. When you request the campula.cz page view you always receive information from the server, the only official one.
Here you can verify the security described: https://viewdns.info/dnssec/?domain=campula.cz
Users passwords are nowhere stored in the original format per users. They are hashed by modern method bcrypt (Wikipedia) (for the curious ones - with the parameter cost = 10) before storage to database Hashing algorithm is artificially slowed down with the aim to significantly reduce the possibilities of estimating the passwords by brute force for possible attackers. The slowdown lies in the limitations of processing capabilities at about 10 passwords per second (a modern device would otherwise be able to “blindly” try billions of passwords per second until the successful user's password detection). In the worst case, if the system database is received by an unauthorized person, it still would not be possible to detect the hashed passwords to the original shape. In the case the user has the identical password for more internet services, the other services would not be thus threatened.
Passwords from this system are never sent by e-mail (the only possibility, for example, during registration or when a password is forgotten). If the system were including this function, its user’s protection would be significantly reduced. There is very easy to capture the e-mail message and extract the password from such message. If the attacker did not score immediately, the user would still certainly keep it in his e-mail inbox, where would be threatened in the case of assault on this e-mail box. Information about the registration or forgotten passwords is of course sent by us, but via safe way using the time-limited link. The user is also informed about every change of login details.
Cookies variables (RFC, Wikipedia) are containing, for example, the user settings of website or they store the user identification. Therefore there is very important to protect the identification chain as because if acquired by an attacker, it could be very easy to simply log in instead of the authorized user. The settings used will ensure that the content of these variables is not possible to send by using the scripts outside of this web site to the third parties. The contents of the cookies it is further possible to transmit only through the encrypted connection.
The information that the so-called mixed content (mixed content) is used on the web means that some content on the site is obtained by a secure connection, but some by unsecured (such as images, etc.). This may indicate increased vulnerability of site against attacks, that is why this web site does not contain mixed content and all the content comes from a secure connection. If the content from a non-secure connection on the web sometimes would appear in the future by influence of error, for example, due to a system update, this content would be automatically blocked by intern browser, and it would not be shown.
Here you can verify the security described: https://www.jitbit.com/sslcheck/#url=https://campula.cz
In some cases there are loaded on the web scripts or graphic styles from other sources due to the optimization of page loading. For example, these could be servers with general graphics, images or user elements. As these resources are not under our control, it is not possible to ensure the safety of the servers providing the required data. In such cases it is therefore pre-calculated hash of uploaded files and each use is checked, whether the file on the remote server hasn't changed. If there is a change (for example, by the influence of the attack on these servers), the data would be still downloaded in the browser, but not shown then. The data security stored on other servers is also ensured by this process.
The entire web uses a system for the control of its content. This tool offers the possibility of detailed definition of the used resources of embedded scripts, images, fonts, etc. The possibility of fraudulently paste script, image and other components that originate from untrusted source on web is thus significantly limited. Similarly, it is not possible to send sensitive data from the forms outside of this site. This technology limits the use of attack Cross-site scripting (XSS). If there is a violation of set rules, for example, by the influence of the attack on this site, the untrusted data would not be shown to the user at all and the initial incident is reported immediately to the system administrator.
The certificate that is used on this website and ensures the connection encryption is written down on the Certificate Transparency. service list. If you access the site using the Chrome browser, it is automatically checked, whether the certificate is registered on this list together with its validity. If you are using another browser, a web includes the information requesting this control, which should be taken into consideration by other browsers, and the certificate should be checked, too. If there is found a disagreement in the certificate, this is reported to the system administrator.
On the internet there is existing commonly a transmit of basic information between the page containing a link, and between the page, where this link is heading. This method allows for example to track where your site visitors are coming from, what pages are going through etc. It is appropriate to limit this behavior and to control what data are sent away by each click. They are set up therefore the site rules, which determine what information is directed to the web, to which the reference is made. In the case of transition to another page the information on the original page could be provided, but only if it is still the secure (HTTPS) connection. If the link shall be pointing to an unsecure connection (HTTP), the information on the original page would not be submitted.
Web uses HSTS (RFC, Wikipedia)technology that makes impossible to communicate outside secure encrypted connections (HTTPS). If the user does not specify an address starting with "https://" (and thus will not force a secure connection), the browser seizes this action and redirects it to a secured version of the site before submitting the page view request. This reduces the possibility of using the SSL Stripping attack.
However, the browser does not know that only a secure connection is to be used before the first page visit. This information comes from the server just after the page is first loaded, often through an insecure connection. This fact may pose a security risk, so the site is written down to the HSTS preload list. This list is included directly in internet browsers and ensures that you do not even need this first unsecured site visit. The browser has information on the need to use a secure connection before the user enters the site for the first time.
Here you can check the security described: https://hstspreload.org/?domain=campula.cz
Any external component of the site should, if possible, be obtained through a secure connection. Similarly, links to external sites should be preferred using HTTPS protocol. This site is tailored to these requirements and is set up so that a secure connection is automatically established even if a source is requested using an unsecured connection.
The site has a forced check between the content and its type designation. For example, if a script for working with user data is playing the role as not to be a script, but an innocent text or image, the script is not executed at all. Otherwise, there might be a risk of running an unwanted script where we do not know its behavior and which could be dangerous with user data handling.
This setting prohibits inserting parts of this site into other web sites. This ensures the consistency of the information provided, and no other web site can automatically take over parts of this site through the frames embedded. Otherwise, the information may be extracted from the context and the dissemination of misleading information could happen.
The use of the XSS Auditor. is required on the site. This tool causes that the browser checks if scripts are being manipulated in the context of the request and render of the page. If it does, the browser does not try to fix this status (as was the case earlier), but it will not display the page at all because it could potentially bring vulnerability to the site again. This system limits the Cross-site scripting (XSS). attack. In the case of such status detection, the incident is immediately reported to the system administrator.
Here you can check the security described: https://securityheaders.io/?q=https://campula.cz&followRedirects=on