Accessibility statement

Vulnerability disclosure policy

Protecting our systems and data from security vulnerabilities is integral to what we do. We aim to identify and address any weaknesses that could allow an attacker to compromise the integrity, availability, or confidentiality of any University product, service or system.

We also value the vital work done by security researchers in making the Internet a safer and more secure space, and have developed this policy using guidance from ISO 29147:2018. If you have identified a security vulnerability in our products, services or systems we would like to work with you to improve our systems.

Please review this policy before attempting to test or report a vulnerability.

University employees and contractors

If you are an employee or contractor of the University of York please contact CERT (Computer Emergency Response Team) prior to taking any action under this policy:

Reporting vulnerabilities

You can report any vulnerability you discover in our systems by contacting CERT (Computer Emergency Response Team):

See Communicating with us for more details on how to contact us, including how to secure your communications.

In all cases, you must:

  • Respect privacy. Contact us immediately if you access anyone else’s data - personal or otherwise. This includes usernames, passwords and other credentials. You must not save, store or transmit this information.
  • Act in good faith. You should report the vulnerability to us with no conditions attached.
  • Work with us. Promptly report any findings to us, stop after you find the first vulnerability and request permission to continue testing. Allow us a reasonable amount of time (at least 90 days) to resolve the vulnerability before publicly disclosing it.

You must not:

  • Exfiltrate data - instead use a proof of concept to demonstrate a vulnerability
  • Use a vulnerability to disable further security controls
  • Perform social engineering
  • Perform any testing of physical security
  • Break the law, or any agreements you may have with the University of York or third parties.

Testing for vulnerabilities

If you want to actively test our systems for vulnerabilities, you must:

  • Only test systems that are in scope of this policy
  • Use a test, or other non-production, environment if it is available to you
  • Only test vulnerabilities using your own accounts, or accounts that you have permission to test with.

You must not:

  • Perform testing likely to:
    • provide you with access to someone else’s data
    • delete, destroy or corrupt anyone else’s data
    • affect other users, for example denial of service and brute-force attacks, spamming
  • Use automated scanners/fuzzers
  • Test systems outside the scope of this policy.

How you can help us

  • Provide the IP address from which you performed the testing so that we can view logs related to your testing
  • Clearly identifying your traffic, for example by including a unique custom HTTP header such as X-York-CVD:<youremail@address>
  • If you are attempting to demonstrate root level access, please use touch /root/<uniqueid>
  • Provide us with detailed information about the vulnerability to help us confirm it, for example:
    • The URL or DNS name of the product, service or system
    • If the vulnerability is in code that we distribute and the version number
    • A description of the vulnerability
    • The steps needed to reproduce the vulnerability, plus any proof-of-concept code
    • Any relevant screenshots
    • Details of the web browser and operating system used during testing
    • How you prefer to be contacted
    • Any current plans you have to disclose the vulnerability.

What we'll do

Upon receiving your report, we will:

  • Respond and acknowledge your report within seven calendar days
  • Ask for any additional information we need to investigate your report
  • Work with you to confirm the vulnerability, the extent to which it affects us, and let you know how long we think the vulnerability will take to fix. Our aim is to fix vulnerabilities within 90 days of confirmation
  • Notify you when the vulnerability has been fixed
  • Where appropriate, release information about the issue to our members, partners, or the public to help others determine if they are affected by the vulnerability, and if so, what they need to do
  • Review what went wrong and update our practices and processes to improve our products and services
  • If you wish, acknowledge your assistance to the University on this page
  • Promise not to take legal action against you for accessing (or attempting to access) our systems, as long as this policy is followed and you do not cause foreseeable harm
  • Treat your report as confidential, treat your data according to our data protection policies, and not pass your personal data onto any third parties without your permission

Issues not considered security vulnerabilities

There are some issues that we may not consider to be security vulnerabilities, but you can still report them to us. We will respond and inform you why we do not consider it to be a security vulnerability. These are largely non-exploitable vulnerabilities or configuration issues, for example:

  • Missing security headers that may be best-practice but do not impact on the security of the system in this instance
  • Support for older, but non-exploitable, protocols and cipher suites such as TLS 1.1
  • Fingerprinting/version detection
  • Out of date software, with no exploitable vulnerability.

Communicating with us

Confidentiality

If you are worried about the confidentiality of information sent to the University as part of this process, we recommend you send the information to us using PGP/GPG.

Working through a third party

You may prefer to work through a third party such as a CSIRT team. We may work with other CERTs and CSIRTs if we need to collaborate with a wide variety of organisations or coordinate the release of information. You can decide to work through a third party for any reason, even after contacting us directly.

Remaining anonymous

You may wish to report something to us entirely anonymously. We are happy for you to do this, but it may make it difficult for us to confirm the vulnerability and to acknowledge your efforts if we are unable to contact you. We may also fail to identify activity if you are anonymous, for example, if you do not wish to provide us the IP address used to test our systems.

Scope of the policy

This policy is under active development. We are using a limited scope to help us explore what works well and what does not. The scope of the policy will change over time.

Systems in scope

The fully qualified domain names of the systems within scope are listed below. Subdomains not explicitly listed are in-scope ONLY if they are hosted in the IPv4 range 144.32.0.0/16 or the IPv6 range 2001:0630:0061::/48.

  • york.ac.uk

Systems not in scope

If you are unsure as to whether a system is in scope, please contact us first.

Credits and thanks

The University of York thanks the following people for their help with vulnerability reports:

  • Syed Muhammad Asim
  • Lütfü Mert Ceylan
  • Ash Holland (two reports)
  • Serji Lacroute
  • Hoggervr
  • Marks Polakovs
  • Shripad Rachha
  • Mehedi Hasan Remon
  • Bhargab Kaushik
  • Tayfun Akyildiz
  • Harshal S. Sharma
  • Chirag Ketan Prajapati
  • Sndp Giri
  • Tri Wanda Septian
  • Deepak Kumar Singh
  • Ismail Tasdelen
  • niggy
  • Alana Witten
  • Selvavinayagan Babiharan
  • Prince Prafull
  • Abhith Damodaran
  • Rakan Abdulrahman Al-Khaled
  • Emily Dennison
  • Younghun Lee
  • Akash Rajendra Patil
  • Rakesh Sharma
  • Dzmitry Smaliak
  • Nimmagadda Sai Krishna
  • Vinayak Sakhare
  • Felipe Gabriel Renzi
  • Joshua Arulsamy
  • Urvesh Shankar Waghela
  • Adrian Tirado Garcia
  • Ayushi Poreddiwar 
  • Steven n0tst3 Black (two reports)
  • Yasser Alenazi - Twitter (@firfox20)
  • Karan Rathod
  • Navreet (Country: India)
  • Aviv Keller (@RedYetiDev)
  • Mohamed Akees (Country: Sri Lanka)
  • Everton Silva - Instagram (@hydd3n.sec)
  • Jitendra Behera
  • Ori Levi