What is responsible disclosure?
Responsible disclosure is a disclosure of IT vulnerabilities in a responsible manner and in collaboration between a reporter and the university. Everyone can make a responsible disclosure report to the university. We then have the chance to resolve the vulnerability before it becomes publicly known.
First and foremost, the university and the person reporting must adhere to the agreements made regarding the disclosure of IT vulnerabilities. The university has drawn up a policy for this.
What is the aim of responsible disclosure?
The aim is to increase the security of IT systems by sharing knowledge about IT vulnerabilities. IT system owners can then resolve vulnerabilities before they will be actively exploited by third parties. As a result, the damage can be prevented or limited as much as possible.
I have received a Responsible Disclosure notification from CERT-UT. What does that mean?
An external party, usually a security investigator, has sent us a report about a vulnerability in a system or some software that you manage or for which you are responsible. After an initial analysis, we concluded that the vulnerability is sufficiently serious to resolve.
That means they have broken into my system. Can't we go to the police? So I don't have to do anything.
The idea behind the Responsible Disclosure policy of the university is that vulnerabilities will always be found one way or another. We would rather have a well-intentioned investigator find a vulnerability and report it to us, than a criminal finding one and abusing it. The chance of this is very high.
So you definitely have to do something.
How soon should I solve the problem?
The simple answer is: As soon as possible.
Bear in mind that a researcher might want to publish about interesting vulnerabilities, or vulnerabilities in frequently used systems. On the one hand for self-promotion, but on the other hand also to warn users of those systems that their data may not be secure.
A usual period is 90 days. Our experience has shown that most vulnerabilities can be resolved within a week to a month. We expect that from you in the first instance. If that does not work, please contact firstname.lastname@example.org.
We would like to be kept informed of the progress.
Who can I contact if I have questions?
You can always ask for help via email@example.com.
Where should I report that I have resolved the issue?
Send your report to firstname.lastname@example.org.
WHAT DOES A ... mean?
SQL injection (SQLi)?
This vulnerability occurs if the input of a webpage is not properly checked and is (almost) directly passed on to the underlying database. This offers an attacker the option of entering SQL commands. These are then passed on to the database. This can result in authorizations that the attacker should not have. Or the contents of the database can be shown to the attacker.
A vulnerability report does not necessarily have to show that such a thing is possible. Due to the risk of unauthorized access and / or access to too much information, a reporter will often only demonstrate that the input is not being properly checked.
You can solve this by making use of so-called 'prepared statements' in your code. Make sure that this does not introduce any new SQLi vulnerabilities.
Cross Site Scripting (XSS)?
This vulnerability occurs if the input of a web page (cookie, input data, URL) is not properly checked. This data is then reflected in the output of the web page and thus in the browser of the end user. The problem occurs if that input can consist of (malicious) scripts.
In most cases, the reporter demonstrates the vulnerability by means of a modified URL so that a pop-up window is displayed. This does not mean that the page is only vulnerable to pop-ups. There is much more to do with scripts and the problem needs to be solved.
This can be solved by adding Contenct-Security-Policy headers to your web pages. There are various, comprehensive manuals for this on the internet. It goes too far to repeat it here.
In some cases the script may be stored on the server. For example, with web pages where comments are possible. Although you will prevent running the scripts via the Contenct-Security-Policy header, it is advisable to clean the database. Due to some malfunction or another vulnerability, it might still be possible that casualties occur.
With this vulnerability, an attacker shows your site in a frame. He then places an invisible layer over that frame with which he can capture input fields and buttons. A visitor to that page will think that he is doing something on your site by pressing a button. However, it is the attacker who catches the click, possibly changes it, and then forwards it to your server. Your server will then send the response to the attacker's server. In this way, the attacker can, for example, capture login cookies and other (personal) data.
This can be solved by adding the right Contenct-Security-Policy headers to your web pages. There are various, comprehensive manuals for this on the internet. It goes too far to repeat it here.
Normally web servers display formatted web pages. However, due to configuration errors, or intentional, it can happen that a visitor to the website sees a list of files. Often there are also other directories in it and the visitor can study the "backside" of the website.
If this has been done deliberately, we would like to hear from you. In any case, check whether a visitor cannot reach places where you do not want him to be able to look around.
If this is not done deliberately, correct the configuration so that directories are protected.