FAQ for admins

In computer security or elsewhere, responsible disclosure is a vulnerability disclosure model in which a vulnerability or an issue is disclosed only after a period of time that allows for the vulnerability or issue to be patched or mended.

Relevant to the university is the fact that all vulnerabilies are reported to our security team first. This gives us time to fix the problem, either by updating the system, configuration or patching the software, before the vulnerability is disclosed publicly.

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.

The aim is to increase the security of IT systems. This happens by sharing information about vulnerabilities. System owners can resolve those vulnerabilities before they are actively exploited by third parties. As a result, the damage can be prevented or limited.

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.

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.

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 you think you won't be able to stay within that deadline, contact responsible-disclosure@utwente.nl immediately.

We would like to be kept informed of the progress.

You can always ask for help via responsible-disclosure@utwente.nl.

Send your report to responsible-disclosure@utwente.nl.

The SQL injection vulnerability is one of the most dangerous issues for data confidentiality and integrity in web applications and has been listed in the OWASP Top 10 list of the most common and widely exploited vulnerabilities since its inception. Read the history of the SQL injection vulnerability for a more detailed explanation of how the SQL Injection vulnerability originated.

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.

Possible solutions: 

Server-side scripting languages are not able to determine whether the SQL query string is malformed. All they can do is send a string to the database server and wait for the interpreted response. Sanitization is often proposed as a solution. However, applying sanitization at the query itself is a very poor coding practice and difficult to maintain or keep track of.  This is where database systems have employed the use of prepared statements.

Cross-site scripting (XSS) is a type of security vulnerability typically found in web applications. XSS attacks enable attackers to inject client-side scripts into web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same-origin policy.

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 an attacker can do with scripts and the problem needs to be solved.

Possible solutions:

The solution that will work for your website depends on the kind of XSS vulnerability and how your website is build.

Contextual output encoding/escaping of string input. Most web applications that do not need to accept rich data can use escaping to largely eliminate the risk of XSS attacks in a fairly straightforward manner.

Safely validating untrusted HTML input. Many operators of particular web applications (e.g. forums and webmail) allow users to utilize a limited subset of HTML markup. Untrusted HTML input must be run through an HTML sanitization engine to ensure that it does not contain XSS code.

Selectively disabling scripts. Content-Security-Policy (CSP) allows HTML documents to opt-into disabling some scripts while leaving others enabled.

Other considerations:

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.

A good article on how to prevent XSS attacks can be found on the site of Acunetix.

Clickjacking is a malicious technique of tricking a user into clicking on something different from what the user perceives, thus potentially revealing confidential information or allowing others to take control of their computer while clicking on seemingly innocuous objects, including web pages.

Using this vulnerabilities an attacker can show 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 interacting with your site. 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.

Possible solution:

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 them 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.

Cross-origin resource sharing is a mechanism that allows restricted resources on a web page to be requested from another domain outside the domain from which the first resource was served. A web page may freely embed cross-origin images, stylesheets, scripts, iframes, and videos.

While CORS is essential to some website, their implementation of CORS may contain mistakes or be overly lenient to ensure that everything works, and this can result in exploitable vulnerabilities.

Possible solution:

Check your Access-Control-Allow-Origin and Access-Control-Allow-Methods to see if it can be configured more strictly.

There are various, comprehensive manuals for this on the internet. It goes too far to repeat them here.